There is a problem in Magento that when you try to move a category by dragging it in the admin, it can cause the above error, whilst causing the rest of the site to slow down.

This is caused by the system trying to re-index every product within the space of a transaction.

An easy way to get round this is to switch the indexing mode from auto to manual and then move the categories.

You will still need to re-index the site, but this can be run on a cron when the site is quite.

If you have switched to Gnome Shell or Gnome 3 then you are no doubt making a lot of use of the overview and alt tab functionality to switch between your windows.

To make this easier (if you have a mouse with extra buttons) you can map your extra buttons to do these actions with a few simple tools.

Firstly you need to install xbindkeys and xdotool

sudo apt-get install xbindkeys xdotool

If you need to know your mouse buttons, try running this command:

xev | grep button

This will give you a window you can click on with your mouse and it will tell you which button you clicked.

Then finally you need to edit your xbindkeys configuration. This is my xbindkeys config:

#gnome shell button 8 to alt tab
"xdotool keydown alt key Tab; sleep 2; xdotool keyup alt"
release + b:8

#gnome shell button 9 to overview
"xdotool key Super_L"
release + b:9

I needed to set up a design change for a new store which I was programatically creating. One aspect which I was still doing manually was the design change. Lots of tutorials on the web suggest how to accomplish this in the Admin, but this wasn’t what I was after.

I’ve done this by updating the store’s config as shown below. Hope it helps someone out there too

$config = new Mage_Core_Model_Config();
$config->saveConfig('design/theme/template', <store name>, 'websites', storeId);
$config->saveConfig('design/theme/layout', <store name>, 'websites', storeId);
$config->saveConfig('design/theme/skin', <store name>, 'websites', storeId);

What EC2 is and how it differs from standard hosting

Aside from shared hosting, Virtual Private Servers and Dedicated Servers, another form is cloud hosting. EC2 is Amazon’s answer to this

EC2 allows you to run “instances” which are prebuilt images which from your perspective is just like a virtual machine. The difference being that it’s in no way fixed to a physical machine, or even datacentre.

Using Magento with EC2

Obviously there are prebuilt images for various platforms (Ubuntu, CentOS, Debian etc) and Magento can be installed on these as with any server.

If you’d like to avoid that Bitnami provides a very nice Magento EC2 instance which has Magento running out of the box, and it’s really the best way to get started with Magento on EC2.

One issue we have previously hit is the machine reporting itself to be out of disk space, but actually the issue was down to running out of what are known as inodes. We’ve documented this previously, but should be a very rare case

Sometimes Magento will some times return no results with the message “Your search returns no results” for terms that you would expect it to return many results for.
This can happen for a number of reasons including misconfiguration of search or attributes.

Unfortunately the way Magento speeds up search queries suffers from a race condition that can lead Magento to think it has cached a query when it has not and at the same time believes there are no products for that search because the cache for that query was dropped. This is a tough issue to solve but it can be done.

The two methods that work effectively to resolve the race condition problem (thus far) are to first make sure that the query cache isn’t empty before using the cached results. This works effectively because if the cache is empty it must have been dropped recently and has not been repopulated.
The other thing you can do to help reduce this further is to make Magento remembers the time at which it dropped. Then have the query caches compare their last updated time against the the last cache drop time and if the update time is before or the same as the drop time don’t use the cache.
If this isn’t completely effective it is also possible to make it not use the query cache if the time of update and the time of drop are with in a minuet of each other to help reduce this further.

Users of Opera might find that mousing down menus makes them disappear from underneath the cursor, making for a very frustrating experience.

From searching round the internet I understand the problem to be around the onmousevent on the li elements. So instead of using these events to show and hide menus we can just use CSS (as it should be) to show and hide the menus.

Methods to add the CSS include a custom user stylesheet (Right-click Edit Site Preferences Display tab), or the Stylish extension. The CSS to add is very simple:

#nav li:hover > ul {
  left:auto;
  z-index:999999;
}

If for example you’re removing an extension and want to clear out its information from the database, you’ll need to establish the rows and tables it’s inserted, as well as some standard Magento table entries.

So you’ve removed everything, cleared your cache and now you go to the homepage to check everything is all good, and boom, PDOException:

Base table or view already exists: 1050 Table ‘*’ already exists

In my case it was `salesrule`, which made me question why it was trying to create the table afresh. The reason I got this is that I’d erroneously removed salesrule_setup from core_resource, and therefore Magento was reinstalling the module. Reinstating the row, and clearing my cache solved the issue

If you just want to get the Magento version on the command line quickly try this one liner:

php -r "require 'app/Mage.php'; echo Mage::getVersion(); "

Does exactly what you need

If you have a Magento site that is consistently erroring out and giving you the report screen with the file name, but the file does not exist in the reports folder then this could be your solution.

The most likely culprit in this scenario is that the filesystem has run out of space. If this happens, Magento will die because it literally can’t create any files and it needs to do this for caching, session etc.

You can easily check this by running this command:

df -h

If you see any filesystems with 100% usage then you have your answer, you have run out of hard drive space and need to free some space up by deleting files.

On occasion though you might run this and see that you still have plenty of space. This can be puzzling at first though you need to bear in mind that Linux filesystems don’t purely use space but also something called inodes.

An inode is like a file pointer, you need one for every file that is in the filesystem. Also there is a limit to the number of inodes in any file system. If something goes crazy and your system creates lots of small files then you might find that you run out of inodes before you run out of hard drive space.

To check if this is your issue run this command:

df -i

If you see any lines with 100% then you have run out of inodes and you need to delete some files. There are numerous possible causes of this and tactics that can be used to clear them out. When dealing with Magento though there are a few usual suspects.

Magento is a real culprit for this behaviour as it uses file system based sessions by default. Session files are very small and can be very numerous.

The quick fix is just to completely remove the sessions directory:

rm -rf /path/to/magento/var/session

Magento will recreate it on the next request.

If you would like to try to clear out just older sessions then you can do something like this:

find /path/to/magento/var/session -name 'sess_*' -type f -mtime +7 -exec rm {} \;

OK so you love Magento’s shell scripts! They are great for quickly putting together bulk processes that have full access to the Magento ORM.

These kinds of shell scripts will often require above normal amounts of RAM for the kind of heavy lifting they lend themselves well to. If you are finding your script is banging against some mysterious memory limit that really shouldn’t be there then perhaps this is your answer:

You might see an error message such as this:

Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20 bytes)

The reason this might be happening is that one of the things the abstract shell class does is parse the .htaccess file and apply any PHP configuration it finds. This is pretty slick and I can definitely see the value of it however if you are not aware its happening and you have a memory limit defined in a .htaccess file then it will be applied to your shell environment.

The solution is up to you, edit the htaccess file or override this method in your shell class so that it doesn’t do things you do not want:

    /**
     * Parse .htaccess file and apply php settings to shell script
     *
     */
    protected function _applyPhpVariables()
    {
        $htaccess = $this->_getRootPath() . '.htaccess';
        if (file_exists($htaccess)) {
            // parse htaccess file
            $data = file_get_contents($htaccess);
            $matches = array();
            preg_match_all('#^\s+?php_value\s+([a-z_]+)\s+(.+)$#siUm', $data, $matches, PREG_SET_ORDER);
            if ($matches) {
                foreach ($matches as $match) {
                    @ini_set($match[1], $match[2]);
                }
            }
            preg_match_all('#^\s+?php_flag\s+([a-z_]+)\s+(.+)$#siUm', $data, $matches, PREG_SET_ORDER);
            if ($matches) {
                foreach ($matches as $match) {
                    @ini_set($match[1], $match[2]);
                }
            }
        }
    }