By Brian Holecko Certified Magento Developer at InteractOne
Avoid budget-busters and broken deadlines.
A Magento Requirements analysis will help to avoid one of the most common budget-busters – your team developed the wrong functionality. This will happen when communication is not clear, especially on large projects. In order to reduce miscommunications, you need to track requirements as they emerge in a spreadsheet with both business and technical requirements side-by-side. Business requirements tend to be generalized whereas technical requirements tend to be specific and detailed. Oftentimes, a single business requirement needs to be broken down into multiple technical requirements.
Prior to Magento, I was an enterprise Java developer for highly customized systems. I also attended a certification class which taught this method which is easily transferable to Magento systems and shines brightest when dealing with large requirement sets. Brand new sites need to consider this approach.
A good plan goes a long way.
Create a spreadsheet with the following headers: #, Business Requirement, Technical Requirement, Est. Hours. When capturing a business requirement, put it in plain English so anybody can understand. Then, translate this into one or more technical requirements which allows tech jargon only a developer can understand. The business requirements need to clearly communicate what the client is asking for without referencing technical requirements. By laying this all out, both sides will be able to spot conflicting and/or missing requirements before development starts.
Next, provide estimates at the technical requirements level, summing them into a total estimate at the bottom. Next, add an additional 20% increase in hours for QA to ensure the requirements are delivered accurately since not all requirements can be captured down to the fine details.
If the list of business requirements is long, add an additional column to categorize the requirements by a system attribute like usability, scalability, UX, etc. There should not be no more than 3-5 of these attributes/categories and need to be defined before defining any requirements. This guides the discussion around the attributes/categories most desirable and will result in an attribute-driven approach to designing and developing the site.
The above method will prevent your team from breaking budgets and missing deadlines on large projects as well as providing an attribute-driven architecture of the store.
By Brian Holecko Certified Magento Developer at InteractOne
Abide by the Magento Code
Magento coding standards for Magento 1.x exist to aid in proper modifications to the system. Although these standards may seem overbearing, they are a reflection of the sensitivity and scope of the complex websites we work on. As a developer, if you are not going to follow these standards it’s a good idea to obtain client approval.
Core modifications
Code residing in app/code/core/ is intended to remain intact exactly as they were coded to allow for easy upgrades. It is possible to override this functionality by copying the files to app/code/local/, however, this should be done only in rare cases where a custom extension cannot override the core. A common example is modifying the translator function within app/code/core/Mage/Core/functions.php for WordPress integration.
A common mistake is to create a php file in the web root and include Mage.php which is problematic because it bypasses important core features.
It should also be noted to keep the web root free of extraneous files which can be accessed via public URL since they might contain sensitive data (DB dumps for example).
Be sure to keep all files in the distribution intact which are beneficial but might be missed during project installations and migrations. A common example is var/.htaccess which prevents these files from being publicly accessible.
Default theme files
Use a custom directory in either the default, enterprise, or rwd directories for theme modifications.
Do not copy layout XML files into custom theme directories. Any modifications to these files can be made using a custom layout XML file.
Use a custom CSS file for style modifications unless styles.css is going to be heavily modified.
Shell scripts
Make sure shell scripts extend Mage_Shell_Abstract and reside in the shell directory.
Custom code
If confused about how to solve a problem, consider using the core for example solutions.
What you need to know about upgrading PHP v5.5 to v5.6
If you’re a Magento merchant or developer, you’re well aware that the platform is well into its new life as Magento 2, however, you may not be aware that it is also well underway into a new life of patches and upgrades. Magento 2.0 was released in Q4 2015, and now – at the time of this writing – has iterated from version 2.0.0 all the way up to 2.1.1. That’s eleven minor version upgrades! Now, is that something new or abnormal? Nope. This happens all the time with software, but sometimes updates occur within these minor upgrades that can affect things immensely, so it’s important to keep on top of what has changed and how it could affect your Magento store’s online environment.
Magento is, of course, built on PHP, and in an effort to stay up-to-date with technology, the requirements to run Magento have updated as well.
In the initial minimum requirements published with the M2 release, PHP versions 5.5.22 to 7.1.0 were acceptable.
from the original Magento 2 Developer Documentation
PHP
5.6.x
5.5.x, where x is 22 or greater
7.0.2 up to 7.1.0, except for 7.0.5
However, upon the release of Magento 2.1, support for PHP 5.5 ended.
from updated M2 Developer Documentation
System requirements
Our technology stack is built on PHP and MySQL. Magento 2.1.0 supports:
PHP 5.6 We do not support PHP 5.5x
PHP 7.0.2, 7.0.6 up to 7.1
MySQL 5.6
Apache 2.2 or 2.4
nginx 1.8(or latest mainline version)
Why does this matter?
It matters because your hosting company is likely about to automatically upgrade PHP on all of their servers to 5.6 from 5.5, and your M1 installation may not be ready for it! One day you wake up, your site is down, and clearing those Magento caches has zero effect.
All you see is something like this in the error log:
ERR (3): Deprecated functionality: iconv_set_encoding(): Use of iconv.internal_encoding is deprecated in lib/Zend/Locale/Format.php on line 311
Why is this happening?
Because PHP 5.5 has come to an “end of life” (EOL) and nobody invited you to the funeral!
So long PHP 5.5!
How do I fix it?
To keep your sturdy M1 site humming right along, there are a few simple fixes to get it to play nicely with PHP 5.6:
Fix #1: Upgrade to the latest version!
Magento’s latest releases of M1 have made the backwards compatibility to handle the deprecated functions. You can simply upgrade to the latest versions of Community Edition (1.9.2.4) or Enterprise Edition (1.14.2.4) and the deprecated functionality shouldn’t be an issue.
Fix #2: Patch the offending files in the Zend
The main issues really fall in the Zend library that ships with M1. If upgrading isn’t immediately possible (let’s inject here that official upgrades and updates are always recommended), a mediary solution can be to simply patch the offending files in the Zend folder by copying them to your local codepool and modifying the necessary lines.
Edit the newly copied files by searching for “internal_encoding” and replacing it with “default_charset”. Be sure that the “internal_encoding” string is a parameter of an iconv related function, otherwise it will break the code. (EXAMPLE: Don’t replace any other parameters or variable names by accident, such as “mb_internal_encoding” or “$internal_encoding” or any other unrelated elements, or you may otherwise certainly break your code.
In the official releases of the latest versions, the files listed above have defined constants to compare the PHP version against and they set the encoding accordingly.
Example:
However, setting the encoding in the above listed files to a fixed value should be fine as long as the PHP version is 5.6 or above.
Example:
With the actively occurring PHP upgrades happening now among hosting companies across the internet, it’s imperative to make sure your online store is up-to-date and ready. Many hosting companies will upgrade their servers without warning which could cause major outages and downtime. It is often up to merchants to be pro-active and ensure their stores remain open for business in the event of an unanticipated update such as this (which is no longer in the distant future!).
Contact InteractOne today and have our Magento team review your site’s integrity and viability for growth!
By Brian Holecko Certified Magento Developer at InteractOne
The One Technique to Further Boost Magento Performance
There are many techniques available for optimizing page-specific CSS/JS which are well documented throughout the Magento ecosystem, however, there is one technique to further boost performance which should be more commonly noted. This technique is only beneficial when using merged CSS/JS, which should be used in all production environments, however, lack of awareness regarding this technique might prevent the use of merged CSS/JS all together due to an innate downside.
Magento’s default theme includes some CSS/JS files on a limited set of pages rather than the entire site. Notably, customized themes commonly include this type of file. When page-specific CSS/JS is available, the merge process combines it with site-wide CSS/JS into its own bundle, forcing the site-wide CSS/JS to be re-downloaded. By leveraging Magento’s available capabilities, these page-specific files can easily be separated from site-wide files. This prevents them from being re-downloaded and improves average page load times for the site. Which overall, maintains a more consistent user experience. By setting a parameter named “page” on the addition of CSS/JS in the layout XML, these files will be separated and bundled independently when merged.
Here is an example setting:
Here is an example result:
Developers should analyze the layout XML and use the page parameter on the addition of CSS/JS files outside of the default and print layout handles which are considered common CSS/JS.
Contact us if you need help optimizing your Magento code.
As a Magento website development agency, we have to answer the two inevitable questions from clients:
t
"What am I going to need?"
“How much will this cost?”
"When will it be done?”
These questions are often difficult both to answer and to deliver promised result for. Although, experience has taught us valuable lessons in how to manage project timelines and budget.
1. Invest Time Reviewing and Planning Business Requirements
We have our business analyst work with clients to discuss and discover their business needs. This collaboration allows us and our clients to think creatively about alternative lower cost ways to fulfill requirements.
For cost efficiency, we try to keep custom coding to a minimum. We typically pursue the following line of questioning when first addressing a customer feature request:
1. Does Magento’s out-of-the-box functionality already have the feature you need?
2. Is there a way your business process could be slightly modified so that Magento’s native features could solve your problem?
3. Is there a quality Magento extension already built that will satisfy your business need?
If you answer “no” to all of the above, ONLY then will we proceed with a plan for custom Magento development. When custom development is required, we take our time breaking down the request to ensure we start simple. It is better to build and release a solid simple working feature and then add complexity. We avoid starting with a great big frankenapp!
2. Budget for Quality Not Bargain Basement Prices
In an attempt to win business, some agencies provide low estimates based on developer hours only. This doesn’t budget for the time it takes a quality assurance team and project manager to properly test that your new or updated Magento baby is bug-free. We have inherited many projects that were begun and then abandoned because of poor planning and estimates.
When we estimate, we include time for development setup, testing and doing mock runs of pushing large releases to production environments. This ensures we have an accurate picture of the total time and effort needed to complete a project. We’ve found that this level of accountability is appreciated in the end. We like to avoid $urprises.
3. Don’t Set It and Forget It. Review the Budget Every Day
A lot can change as a team works its way through a software project. Scope and requirements are continuously evolving within an agile project framework. For this reason, we check our budgets every day and are very proactive in addressing possible changes in budget or requirements with our clients. Particularly with previously customized installations, working in an agile project framework can avoid sinking a lot of time into a feature that is resisting the best efforts of skilled developers; you can’t change course if you’re not looking ahead to see the brick wall zooming toward you!
We have honest discussions with our clients about how to shape scope in order to work within their budget. By having these discussions early and often we work to avoid missed expectations and poor quality.
Are You Ready to Start Planning Your Magento Migration?
A Magento migration, or upgrading to the latest version, can be great for your eCommerce business. With any important business decision, it is best to go in armed with information and confidence in your partner. We’ve launched many Magento sites. We know what creates the most successful Magento migrations. We’d like to take credit for our success stories but the truth is, your expectations and prep are as important to the project as our expertise.
Contact us or call us at 513-469-3361 to get started on your project!
Contact us to learn more about Migrating to Magento 2!
By Brad Leslie, Certified Magento Developer at InteractOne
With so many options, how do you know which Magento partner to choose?
While evaluating Magento developers, shop owners must take all of their business requirements into consideration: Why is a Magento developer required? What will the Magento developer be asked to accomplish? Is there a specific timeline that the development must be completed within? What is the fundamental reasoning behind the request?
Some common reasons for a shop owner to seek out a Magento developer are when they want to migrate to Magento, if they’d like an on-going support plan, need custom development or integration with third party systems. Magento has multiple tiers of ‘Magento Solution Partners’, which are web development agencies who have a specialty in Magento development. The tiers are most closely related to the size of the agency, but the partner portalalso breaks down the partner list by specialization, which is helpful for shop owners with a specific need.
Agencies who are not listed as Magento Solution Partners may have experience with Magento development, but becoming a solution partner displays a dedication to the platform and requires the agency to have multiple Magento Certified Developers on staff. Magento offers several certifications for developers and solution providers, which cover all areas of development and admin processes: front end, back end and solutions. These certifications serve as the credential of choice for many agencies and developers who are focused on Magento development.
Once a potential Magento development agency has been chosen, the shop owner should open up a conversation about their specific needs and how the agency’s developers will be accomplishing the requested tasks. Most agencies offer case studies and / or a portfolio of previous work, but it may be worthwhile to ask about the development team’s credentials and processes so there aren’t any surprises once development is underway. Some agencies employ developers in various parts of the world, which can delay communications if improperly managed.
After vetting the Magento-related qualifications of the agency, it may be helpful to consider the following:
Location: Is meeting with the project managers and developers face-to-face important or are weekly phone calls sufficient?
Quality: Does the agency implement high quality development processes like version control, code reviews, deployments and documentation?
Additional offerings: Does the agency offer any other desired services like internet marketing, design, SEO, etc?
Personalities: Are the contacts within the agency easy to work with and communicate with? Will the relationships be enjoyable throughout the development process?
In addition to the agency itself, the proposed solution should be evaluated to ensure that the budget and timeline requirements are being met. Depending on the technical knowledge of the shop owner, the quality of the proposed solution should also be taken into consideration. While shop owners should have confidence in the solution partners, nobody is perfect and it’s better to question a solution before it’s been developed than during development or after.
These questions may include: how will the proposed solution scale with the growth of the shop? If the solution needs to be expanded upon in a few months, will that be possible? Are there any performance implications associated with the proposed solution? If so, how can those be offset? What changes to the requirements can expedite the development process?
Non-technical shop owners may not always know the best questions to ask, but a good rule of thumb is to provide as much information as possible to the agency. The best agency – client relationships are when the agency has a complete understanding of the client’s code base, existing issues and road-map for the future.
As one of Magento’s oldest partners, we know Magento. We can build from the ground up or finish what you’ve started. We have on-shore support, so no more call center hassles. We’ve worked on many specialized and complicated projects, with that comes great experience. Our proven strengths in Magento development, on-shore support and maintenance, as well as abandoned Magento sites will get your online business running full speed ahead.
By Brad Leslie, Certified Magento Developer at InteractOne
What to consider when Migrating?
With roughly 200,000 eCommerce shops using its platform, Magento has established itself as one of the most popular and most powerful ecommerce solutions in the industry. Due to this fact, shop owners are investigating Magento now more than ever before. One of the most important questions (and the one with the most complicated answer) is ‘how will my shop migrate from the legacy system to Magento?’.
As is true with any website migration, there are a few major factors that must be evaluated before the migration can be considered viable:
Functionality
Performance
Legacy Data
Magento is a complete eCommerce solution out of the box, meaning that all product, customer and order functionality is included by default — as well as a number of other pieces of functionality that are useful within an eCommerce shop. Magento currently offers Community Edition (CE) for free and Enterprise Edition (EE) for a yearly license fee. The feature listincludes a breakdown of all CE and EE features, which makes it easy to see which pieces of functionality are included in each version.
If non-default functionality is required within Magento, shop owners have two options: install an extension or develop a custom module with the desired functionality. See our articles on ‘third party extensions vs custom development’ and ‘finding a Magento developer’ for more information.
Performance has always been a concern for Magento shops and has been a major pain point when migrating from legacy shops to Magento. PHP7 offers a tremendous improvement to Magento’s performance with minimal effort, as detailed by our blog post Improve Magento Performance By Upgrading to PHP7. While Magento 1 requires an extension to support PHP7, Magento 2 supports PHP7 out of the box.
Depending on how long the legacy shop has been active, there could be a lot of important data within the legacy database. While it’s typically a good idea to migrate legacy product, customer and order data, the shop owner must decide which data needs to be migrated. Inactive customers and orders that are several years old are sometimes ignored, but allowing the customer to review their legacy orders and re-order products are known to improve the customer user experience and lower customer service inquiries post-migration.
Once migrating to Magento has been determined to be viable, it’s helpful to turn the focus to the future. There are some important things to keep in mind:
Upgrades: Magento regularly publishes new releases of EE and CE, which contain bug fixes, new features, security updates, etc. Keeping Magento up to date with the latest version is a best practice and ensures that the shop is as secure as possible.
Security: Anytime a new security vulnerability is exploited, Magento issues a security patch and new version of Magento, which includes the patch files. It’s important to understand how the vulnerabilities affect the shop and how the patch should be applied so that customer data cannot be compromised.
New Technologies: While not necessarily a Magento-specific concept, it’s always a good idea to stay current with the latest technologies. In addition to the programming languages Magento is built with, SSL certificates and other security measures are regularly improved and released. Magento often partners with service providers who can help improve the quality of the code base, as well, such as New Relic and Blackfire.io.
Although migrating to a new eCommerce platform can seem like a daunting task, formulating a solid plan and understanding all aspects of the migration will make the process as efficient as possible. Magento has done a great job of improving documentation and community resources over the past few years in an attempt to make the Magento experience as straightforward as possible.
Here at InteractOne we understand that choosing a Magento migration from other eCommerce platforms, or even upgrading to the latest version of Magento, can feel daunting. Having launched many Magento sites, we know the common elements of what creates the most successful Magento migrations. Let InteractOne float you through it.
By Brad Leslie, Certified Magento Developer at InteractOne
Third party extensions vs custom development. How to choose?
Within engineering, there are often multiple solutions to the same problem. The most appropriate solution can depend on any number of factors: budget, deadline, the abilities of the engineer / firm, third parties that need to be involved, etc. Magento development is no different.
Due to the large number of eCommerce stores built with Magento and their varying sizes, budget is often the first consideration when developing a solution. If the store needs a third party ERP integration, but has a budget of less than $1,000, custom development is most likely not the answer.
The Magento community offers a unique advantage to merchants who have lower budgets, in that there is an abundance of extensions and themes that are available within the marketplace, Magento Connect. These extensions and themes are individual pieces of functionality that can be installed to expand the features of Magento. There are a few things to keep in mind while browsing the marketplace:
Reviews: Learn from those who have already installed the extension. Determine whether there are issues with the functionality, the author’s support and / or compatibility.
Popularity Score: This is the number of referrals to the site and downloads. A higher popularity score does not always mean it’s a good extension — especially if it’s free. The opposite is also true.
Developer Info: Is the developer a solution partner? Have they published other extensions? Do those have good reviews as well?
Extension Versions: Is the extension updated regularly? Has it been updated recently? Is it compatible with the latest versions of Magento, including the latest security patches?
A combination of good reviews and a high popularity score gives the best possibility of the extension being high quality. Additional vetting of the extension author can help eliminate the possibility of issues down the road if support is needed.
Other than a tight budget, a short deadline is the best reason to use a third party extension or theme rather than developing a custom solution. Extension installation is very simple and rarely causes issues unless there is a conflict between multiple extensions attempting to override the same piece(s) of core Magento functionality.
Third party extensions and themes can be good solutions to a large number of problems / business requirements. The code should be evaluated before installing to ensure that best practices are followed and there aren’t any security flaws, but good reviews and high popularity score are typically good indicators of code quality.
While third party extensions and themes are appropriate for some situations, they are not always the best solutions. Poorly developed extensions and themes can lead to conflicts, upgrade issues, security vulnerabilities, and unnecessary headaches.
If the budget and deadline allow, custom solutions can solve the same problem as a third party extension with greater levels of efficiency and customization. If the solution architect and developers are familiar with the code base’s integrity, they can adjust the solution for that particular merchant. Whether the store needs a simple report generated each day or reporting functionality that’s scalable and customizable, the solution can be tailored to the specific need of the merchant.
Enterprise Edition (EE) merchants often have a higher budget, which allows for more custom solutions. Based on the size of the merchant, many EE (and larger Community Edition) installations have restrictions on the solutions that can be implemented.
For instance, if a merchant has 100,000 products and needs an importer that updates some custom attributes on each product every day, dataflow profiles or an import with normal product saves are probably not a viable solution. As developers know, full product saves are notoriously inefficient because the related indexes are updated at that time. Saving individual attributes or using direct MySQL queries are much more efficient and can cut down the import time drastically. While direct queries are not typically considered to be an appropriate solution for smaller merchants, cases like this require creativity.
Magento merchants should rely on the guidance and expertise of Magento Solution Partners to help determine the best possible solution for each requirement. That said, merchants need to understand the limitations of each proposed solution and how those solutions are able to scale as the merchant’s store grows.
By Brad Leslie, Certified Magento Developer at InteractOne
Magento Enterprise Edition (EE) is the premium version of Magento’s eCommerce platform and currently has an $18,000/year price tag. While EE is typically recommended for shops that have a high sales volume and/or a large product catalog, that price tag can become a burden quickly given the right series of events.
If EE has to be abandoned, that doesn’t mean that Magento has to be also. Magento’s open source Community Edition (CE) is completely free. CE is actually what EE is built on top of, so with the exception of some more powerful features like customer segmentation and automated admin processes, CE and EE are virtually the same.
Note: Before beginning the downgrade, evaluate which EE features are being used within the current installation and determine whether they’re necessary. If so, there may be a CE extension available. This is also a good time to clean up the web root, remove any unused or unwanted extensions and make sure that the install is in good shape.
The biggest problem with downgrading from EE to CE is derived from the differences in password hashing. While there are a few ways to deal with this, the easiest is to create a custom module that contains the code in app/code/core/Enterprise/Pci/Model/Encryption.php and tell Magento to use that for the encryption model. Since the password hash is different between CE and EE, skipping this step means that all passwords (admin and otherwise) must be reset. While there are more graceful ways to handle resetting every customer’s password, it is rarely a viable option for shop owners.
With the encryption model taken care of, it’s safe to delete all references to EE from the file system. This typically includes:
At this point, all of the core EE references have been eliminated from the file system. The remaining file system shouldn’t have any other references to EE, but that should be double checked. Any EE-specific extensions that were installed will need to be evaluated and replaced, if necessary.
Now that the file system is cleansed of all references to EE, the only issues remain in the database. Specifically, EE attributes and URL keys. In regards to EE-specific attributes, there are a couple of options. The simplest being to delete all of them, which will work, but also eliminates the ability to access that data. Alternatively, EE-specific attributes could be converted to CE attributes using custom source and / or backend models. This allows the site to continue using those attributes down the line without the EE license, which can be useful for reporting, customer service, etc.
URL keys in EE use a different backend table, so the ‘url_key’ attribute needs to be updated to use the standard table. Once that has been completed, it’s possible that many URLs within the site no longer work. The reason being that those URLs have rewrites referencing the EE backend table. Clearing out the ‘core_url_rewrite’ table and copying the URL keys will fix this issue.
Downgrading from EE to CE is sometimes necessary, but doesn’t mean that sacrifices have to be made. There are a lot of successful CE extensions that emulate EE features. Many of which are paid extensions, but they directly impact the user experience and, ultimately, conversions.
If you need to downgrade from EE to CC, InteractOne can help. Contact us today!
By Brad Leslie, Certified Magento Developer at InteractOne
Upgrading to Magento Enterprise Edition
Most eCommerce shop owners would agree that many of their business decisions are made based on improving the customer experience. From the platform the site is developed on to the features that are added on top. The customer experience reigns on both ends of the spectrum. Magento Community Edition (CE) is a great framework for most small or medium-sized businesses, but larger shops often upgrade to Magento Enterprise Edition (EE). The main reason being: improve the customer experience even more.
Improved Customer Experience
At a glance, EE and CE are very similar. Digging deeper, it’s easy to see that EE is just CE with additional features. Many of which are, unsurprisingly, aimed at improving the customer experience. One of the most beneficial features of EE is ‘customer segmentation’. This allows a shop owner to show the customer a version of the site that is customized for them or their customer segment. Product listing, static blocks, etc can be adjusted to target each individual segment based on a number of attributes.
In addition to manipulating what specific customers see on the site, ‘persistent shopping’ ensures that the customer’s cart, wish list, recently viewed and recently compared history is always available to them regardless of their browser or device. Persistent shopping paired with dynamic, rule-based product relations means that the customer is always seeing: a) products they’ve already showed interest in and b) new products based on relations configured via the admin panel.
Now that the customer is seeing targeted products and banners throughout the site, they are much more likely to add a product to their cart and make a purchase. If they don’t make the purchase, EE’s abandoned cart emails can help secure those conversions. Configurable parameters ensure that these emails are being sent to the customers who are most likely to go back to complete their purchase.
EE has improved performance over CE due to full page caching and optimized indexing. Search results are also improved with the addition of a Solr search module. This allows for more relevant and related search results to be displayed than the default Magento search.
In addition to these features, which really aim to increase conversions, there are many new features for the customer to use directly. Gift registry, gift wrapping / message, reward points, store credit / gift card, multiple wish lists, the ability to add products to the cart by SKU and a configurable order tracking widget are a few.
Streamlined Admin
The rest of the EE-specific features are meant to streamline admin processes and ensure their scalability. Admin logging increases accountability, website/store-specific admin roles restricts administrators to their store exclusively and price/promo permissions can be set so only certain admins can change those values.
The dynamic, rule-based product relations mentioned earlier not only improve the products the customer sees, but they drastically reduce the overhead associated with creating product relations. This is especially true for shops with a large product catalog. The ability to automate which products are cross-sells, up-sells and related saves time and money, but also reduces margin of error.
There are additional Magento Enterprise Edition features designed to improve workflow, including scheduled imports/exports, scheduled backup and rollback, the staging, merging and rollback of content, customer attribute management and more. Order archiving and optimized indexing aim to improve performance when working with large catalog and order collections. The ability to use a CDN or the database for media storage can also improve performance on the front end.
Increased Security
Security has also been increased by using improved encryption and hashing methods. Administrators have the ability to ‘lock down’ the front end as well, via the use of private sales and limited catalog access, based on customer group.
Magento Enterprise Edition is the only Magento version fully supported, meaning that bugs will be patched and a support portal is available should anything come up with a site. There is a cost associated with upgrading from CE to EE, but there are plenty of powerful features that justify the investment. Shop owners who have a large sale volume, product catalog and/or a lot of administrators working with the admin panel should strongly consider upgrading to Magento Enterprise Edition.
If you’re interested in learning more about Magento’s Enterprise Edition or think it’s the right platform you, Contact Us today!