Magento

10 Things Magento Developers Should Be Aware Of

There are many things that trial and error teaches us when working with frameworks in general, these are some of the ones I’ve found to be important when working with Magento stores.

10. Version Control

Even if you’re working alone, there are several reasons why Version Control is a good idea. Say for example, you made a few edits to a layout XML or a Model for one of your Modules, at some point you may want to reverse your changes. If you’re like a lot of developers, you may have downloaded the file and edited it on your pc, then uploaded it back to your website via FTP or maybe even in SSH. With this method we would have to save an original version of the file, just in case something went wrong. With Version Control, (GitHub is one example), you would commit and push your changes, then edit again. Every time you do that, it will create a separate snapshot of the file, and if you wanted to, using a command you can revert the file to any one of those commits. If for some reason your computer crashes, or the server’s files become corrupt, or even deleted, you can simply checkout the file or repository at any given moment in the development process. Less desk pounding = less confused neighbors/co-workers.

9. Beware of Indexes!

When in the development process, it’s common to find that you added or changed a product, and it isn’t appearing in your store. There are a few possible reasons for this:

  • Your product may not be set to In-Stock with Quantity more than 0, or is disabled
  • Your collection caches aren’t up to date (if enabled)
  • Your indexes weren’t updated after adding or changing product attributes

Magento uses these indexes and caching so it doesn’t have to query the database as often, as that can cause excessive loading times with larger databases.

8. Caching: A Developer’s Worst Nightmare

If you’ve ever been sitting at your desk, scratching your head because the changes you made to CSS or JavaScript are not showing up on your shop, the reason may be simpler than you think. Caching is commonly used to boost performance in Magento. There are a few things you can enable during the development process to save time with page loads, just be aware if any of them change so you can refresh them as needed.

Be sure to refresh your Blocks HTML output cache after editing products (and Full Page Cache if applicable), or when making any changes to template .phtml files. If you make changes to your layout XML files, the cache type to refresh is the Layout cache.

Some good types of cache to enable during development are:

  • XML Config Caching (refresh this if you add new modules or make XML changes)
  • Collections Data (refresh after adding or changing products)
  • EAV Types and Attributes
  • Enabling these will cut down the time it takes to load stores. It is not recommended to enable other types of caching until the site is production ready.

    To clear your cache, you have one of two options. The recommended approach is to use the admin panel under System > Cache Management. Clearing your JavaScript/CSS cache can be done from here. Also use the Flush Magento Cache button. The other option is to manually delete the contents of /var/cache/.
    Image cache for products is stored in /media/catalog/product/cache. External caching services such as CloudFlare can also interfere with changes showing up. Log into the service you’re using (if any) and disable these cloud caching solutions during development. If all else fails, clear your browser cache and close the browser and open it again to clear all volatile cache.

    7. Try not to keep anything too important in the var/ folder

    This folder is, by design, a disposable folder. When migrating Magento to another location, you can exclude the var/ folder entirely, and it will be created when the store runs again. You can also exclude the aforementioned Product Image Cache folder. to cut down on the overall transfer size of Magento. SQL Backups may also exist in var/backups if you ever enabled that option in Magento Connect when installing a module. Logs are also there, and can become very large over time.

    6. Migration

    Another reason version control is great is the ability to easily move your site. If you use a Magento .gitignore file, all you have to do in the new location is unzip the Magento install package, set it up to connect to the database, run the installer, then pull the git repo in your Magento document root, import the MySQL backup in some method (phpMyAdmin is one way), and your site should work great, as long as the url you’re using to access the site hasn’t changed (such as moving to localhost). If that is the case, you’ll have to query and update the database yourself to change the base url and secure base url so the site will function again.

    5. Module Woes

    At some point you may have trouble with a Module you just installed. Perhaps your site has crashed completely because of this. Finding the module’s config file isn’t too difficult when you compare the namespace of the failed Module and find the corresponding XML file in /app/etc/modules. Check your logs in var/log in system.log or exception.log. You can either rename the config file to an extension other than XML, such as namespace_module.xml.off, or you can edit the file and set the Active flag to false, which is considered the proper way of doing it. Remember to refresh your XML Cache if you have that enabled. If a module installation or update fails for any reason, your site will be in maintenance mode. Delete the file /maintenance.flag to put the site back online again.

    4. Friends don’t let friends mix Backups

    As tempting as it may be to slip some customer data tables in without importing the rest of the backup and “piece together” a database from several backups, this is a very bad idea. Even if it seems like everything is running fine at first, it will likely catch up with you. Tables are tied together in large clusters, so any data from one table that is inconsistent with another can topple the Jenga tower. It’s not so easy to recover from this unless you import a full backup from before, but then you’ll be losing data that was added since that backup. Long story short, just don’t try it. Use Magento factory methods in a standalone PHP script, those will ensure all data is updated properly with any related events and observers that need to run.

    3. Never/Edit/Core/Code/

    Besides a possible nuclear meltdown of your site, there are several reasons why:

    1. Consideration for other developers
    2. Updates overwrite modifications
    3. There’s other ways to go about this

    Consider This:

    Other Developers write modules that depend on an unmodified Magento Core. If you change it for a specific purpose, you risk losing functionality in other places that depend on it. In addition, if someone else works with your site later, they won’t be able to find your modifications easily if they need to change something. If you use local overrides, you can also disable the modification simply by renaming the file.

    The Magento Way:

    When Magento runs, it looks for files to include in app/code/local first, then app/code/community second, and finally, app/code/core, so if you really feel that you have to change something in the core (or override an installed community module), create the same folder structure in local and copy the file there, then edit that. Just be aware that it’s there if you decide to update Mage to a newer version. If you edit the core files, your changes would just be overwritten when you update Magento. You can lose time and work that way. If you use Github for version control, you probably have app/code/core ignored anyway, so changes in those files won’t even be monitored.

    2. Watch your Analytics

    Numbers speak. You can watch how your traffic flows and make your site better if you know where it’s going – or not going. Be sure to serve sitemaps to Google, Bing, Yahoo, and other search engines regularly. For example, you might find a problem with the checkout if you see customers are adding items to the cart, but not actually buying them, and so on. Try using A/B testing if your click through conversions don’t seem to work well.

    1. Have a solid Backup Solution

    Using Version Control for files along with a good database backup solution can keep you in good shape in case anything goes wrong. Try to avoid using mysqldump, it can lock tables while Magento is trying to run, and cause data corruption and inconsistency in some cases. There are other ways to backup your data without interfering with the site’s operation. Bear in mind that this also has side effects, where keeping the site running during a “hot backup” may also cause inconsistency, though this is less likely. Unfortunately, the best solution I know to this is to use maintenance mode while backing up the database (like Magento Connect does when installing modules, and for good reason). And realistically, mysqldump does it’s job fairly quickly, so a 1 minute downtime is really nothing. Keep in mind if you do this with a bash script on a cron job, you must be absolutely certain that the maintenance.flag is removed after. If your site sync’s with eBay(M2ePro), several hours of downtime may cause some issues for your data.
    You can make use of things such as Duplicity, Rsync, and other methods to safely store these backups off-site, just in case of a major meltdown. You can even go as far as to propagate databases to other servers, in case one crashes you can have a fallback set up to use if one is inaccessible for any number of reasons. Run cron jobs during low traffic times, especially if you use cron jobs to reindex. Tables can also get locked during reindexing in Community Edition, as a failsafe in Magento to safeguard data against inconsistency. Take some time to become familiar with other aspects of data flow in MySQL if you aren’t already, so you can be proactive to better manage performance, and prevent issues before they occur.

    Update: Magento CE 1.9.1 and EE 1.13+ have new methods of reindexing which addresses the issues mentioned. If you want to make a clean backup, stop all Magento cron jobs, then make your backups. The new changes to the indexing process are much more efficient now, and handled by cron.

    The following two tabs change content below.

    Dave Wilson

    Senior Engineer at BuyerQuest
    Dave Wilson is a web developer focused on the newest technologies, Social Networking, SEO, and Marketing. I have been working with computers since the days of Apple ][ and MS-DOS.

    Latest posts by Dave Wilson (see all)

Posted in Magento.

Leave a Reply