Common Magento Mistakes

Magento can be a fickle beast indeed. It’s a fair guess that most entrepreneurs and developers would position themselves as perfectionists, and it can seem unduly difficult to wrangle a Magento build to perfection. To that end, it behooves us Magentians to look around at all the ways Magento platforms can go wrong, and—more importantly—how to correct a glitchy system. Thanks to Maria at Magento Store Manager Blog, we’ve got some great insights into the usual culprits.

What causes most Magento mistakes? At the big-picture level, tampering with design and structure. Many values in the database or core folders are precariously balanced with one another, such that a seemingly simple tweak can have confusing and long-lasting consequences. One accidental click here, another random confirmation dialogue there, and suddenly you’re ticking up support hours just to get back where you started.

So, ground rules: think before applying changes, document any of these changes, and always double-check with developers, either in-house or on web support forums. Remember, Magento isn’t very forgiving of click-happy users without thorough system familiarity. Let’s examine some common Magento mistakes:

Upgrading a Customized or Module-Enhanced Shopping Cart

This is a big one. Because it’s open source by nature, Magento offers up its code to any enterprising coder with an idea for an extension, and thus the perennial compatibility problems once Magento itself issues an upgrade. Furthermore, damage can occur on both sides—your store might suddenly malfunction in key areas, or the extensions themselves may get very sick. Sadly, you can’t just take someone at their word when they say their module is compatible with the latest Magento version, either.

What to do? Firstly, don’t fix what isn’t broken; there’s no need to jump on the brand-new upgrade bandwagon if you’re already running a stable version that fits your needs. You worked hard to get it that way, enjoy it as long as possible! If the upgrade is critical for your continued success, be sure to set up a new Magento installation on your server. Only then should you install necessary extensions, test them redundantly, and open your new store to the public.

Restoring an Older Shopping Cart Backup over a New Installation

This is kind of the last Magento mistake in reverse. Let’s say you’ve recently bumped up from Magento version 1.2 to 1.5, implementing massive system changes in the process, but then find that you’d like to restore a backup of your previous shopping cart. In this case, you’ll be trying to create a restore using files from the newer Magento version while pulling from the database corresponding to the older Magento version. That breaks Magento, plain and simple.

Here, the regular upgrade process will not work. You’ll have to make piecemeal renovations using Magento Import/Export instead of standard Backup and Restore procedures, and you should only restore backups that correspond with your current database.

Updating the ID Field to Varchar

A little more on the technical side, this hiccup arises when you want to modify fields with restrictions. For example, you might want to alter Product ID numeration or add extra values. Often, users will access the database via the control panel and manually set a field to varchar or any other type. Problem is, in the database the field ID must be set to “integer type with auto increment” in order to retain database integrity. Moreover, due to the Magento database’s complex structure (Entity Attribute Value (EAV) with all values mapped by ID), this then break s all database relationships.

Basically, you should avoid changing type for any ID field. Once a change is made, you’ll have to restore to pre-change backups in order to preserve functionality.

Deleting or Updating System Magento Attributes

Now, you may need to input some special value that doesn’t precisely fit a certain attribute or field, but it bears repeating: find some other means to do so. Messing with system Magento attributes can seriously hamper important tools, up to and including product creation/editing, order processing, and even frontend product visibility. Don’t do it, you will regret it.

Instead, search for the solution in default Magento functionality. You could, for example, create a new Magento attribute for the necessary data.

Changing Database Access Details

This can occur via the hosting control panel and is compounded when users forget to change said details in Magento itself. Should that be the case, products in the site will become unavailable and the following error message will display:

Access denied for user ‘your_magento_user’@’localhost’ (using password: YES)

The solution, as you may have guessed, involves inputting the same access details in the local.xml file (app/etc/local.xml, the Magento configuration file) as those in the control panel. Be extra cautious, because this procedure could cause serious damage if done incorrectly. We do not recommend updating or deleting users from the control panel.

Things can get pretty hairy if you try to change details during a Magento import or re-index. For example, if you’re using outside developers for certain services and you want to give them access as soon as possible, you may accidentally change access details while an important operation is running. It’s hard to tell what exactly will happen, but this Magento mistake often results in incomplete table alterations and/or missing data. Ergo: wait for all active processes to finish before attempting to change access details.

Forgetting to Disable Shopping Cart Maintenance Mode

Like leaving the parking brake on, this Magento mistake can show up even for otherwise diligent Magentians. If you’re dealing with extension installation or operations and forget to disable maintenance mode, the following error message will display:

Fatal error: Class ‘TBT_Common_Model_Resource_Mysql4_Setup’ not found in /var/www/html/includes/src/Mage_Core_Model_Resource_Setup.php on line 234

So disable maintenance mode and rest easy! Alternatively, you can work around this by manually deleting the maintenance.flag file from the root of your Magento directory. We don’t recommend this—it’s only applicable to rare fringe cases.