5/07/2013

Dumb Ways to Break Your Magento

magento import issues

Often people are aiming at development of perfect Magento websites. Though, it is easier said than done. You know what’s much easier? To ruin everything. It can be done in seconds. Many of us experimented with design, tried to change some values directly in database or via Magento import, did some special modifications to Magento attribute etc. All of these can lead to hours of investigations, blaming for your hosting or developer. Even unintentionally pressing wrong key combination or randomly clicking OK in the wrong dialog box can change important options and break the whole system.

One move can crash your Magento, so you have to be very careful and think before applying any changes. Here’s a list of most common missteps can be made and the ways to steer clear of them.


Upgrade shopping cart if you have tons of modules installed and customizations made

If you need to update your Magento to the latest version, but have extensions installed or some customizations made, you might get into trouble. The modules most likely will not support latest versions of shopping cart, since Magento versions differ in internal structure. Even if extension is compatible with newer version, there is no guarantee that upgrade will go smoothly and without a hitch. It is a complete gamble as to whether it destroys your store or not. There is also the chance that a portion of extensions’ files/pieces of code will be damaged, which is no good either.

The solution is: if the current version is relatively stable – leave it that way. If you need that upgrade, do brand new Magento installation somewhere on your server in any subfolder and only after everything is set up, install extensions and make the store publically accessible.


Restore backup of older shopping cart version over latest installation

Lets say, you formerly used Magento ver. 1.2, but recently upgraded to ver. 1.5. After massive changes you need to restore backup to return previous data and you have found backup of older version. What will happen if you restore back of older version over new one? Database to be restored will change the structure of current database. During this process the files will be the ones belonging to new Magento version, but database itself will be the old one. It is understandable that under these circumstances Magento will be down. If the versions differ that much, the regular update will not work. Install the latest version of the shopping cart on you server and after that make any renovations using Magento import / export, but not backup/restore procedures. Restore only backups that correspond to the database you currently use.


magento varchar

Update ID field to varchar

Sometimes there emerges the need to modify the fields with restrictions. Lets say, change products IDs by adding to them some values or start numeration from 0. For that users access database using control panel or any other tool and manually set let’s say ID database field (value_id or entity_id or any other) to varchar or any other type. This makes possible to re-write products IDs or add values to them. What happens next? In database the field ID must be set to integer type with auto increment in order to keep Magento database integrity. If this was changed, naturally that database integrity would be lost.

Moreover, basing on the complexity of the database structure (as Magento has EAV structure and all values are mapped by IDs) - all database relations become broken. To avoid this, under no reason, do not change type for any ID fields. If the change is made to fix it you need to restore the backup before the change was made.


Delete or update system Magento attributes

If you need to change system Magento attribute, as there is the necessity to input some special value that does not suit the attribute or field, then keep up to the advice - find some other means to implement desired. Playing around with system Magento attributes in most cases ends sadly, as this important change will definitely influence the process of products creation/editing, order processing or even product visibility at the front-end. You should search for the solution in default Magento functionality. For example, create new Magento attribute with necessary data, since Magento wide possibilities were created specially to satisfy users’ needs with out-of-the-box functionality.


Change database access details in hosting control panel, forgetting to change them in Magento itself

If the mentioned was done the products at the site will become unavailable at there will be the following error:

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

To fix this, you have to indicate the same access details in local.xml file (app/etc/local.xml - Magento configuration file) as you have added in control panel. Please note, this procedure can be harmful and we do not recommend to update or delete users in control panel.


Change database access details during Magento import or re-index

People change access details (user, password) in control pannel due to security reasons. Lets say you provide access to developers or companies that make some services for you and you rush to change access details as soon as you can. This can be dangerous. In case you have some operation still running at your store, for example Magento import, then having changed the access details to database may badly influence the active process, since Magento will not finish up all the alterations in tables (some of them will contain data and some will not) and this will definitely lead to damaged Magento.

How to safely change database access details? Make sure that all the active processes have finished and are not running at the moment when you are going to change access details. Only after that you can add new user, change details in local.xml file and after that delete the old user. This procedure is potentially harmful, thus is not recommended to perform.


Forget to disable maintenance mode of your shopping cart

In case of some operations/extensions installation you may need maintenance mode to be enabled. Please make sure to disable it afterwards, or you may have the following error all of a sudden:

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

It’s hard to say how it occurs, but it surely will make you sweat for a while trying to fix it.

How to eliminate it? Disable maintenance mode or manually delete the maintenance.flag file from the root of your Magento directory.

broken magento

These are not all the things and actions that can break your Magento site. The actual list is much wider. We encourage you to add in comments your experience and ways to solve issues you encountered with Magento import, Magento attribute or other things, for other users to avoid mishaps or solve them with minimum efforts and damage.

Source - http://blog.mag-manager.com/2013/04/dumb-ways-to-break-your-magento.html


By Maria Kvasnytska

No comments:

Post a Comment