I created a small Magento 1 module that simulates sales activity on the site. It will loop through last 20 orders and show little popups on the bottom of the page notifying shopping customers about a purchase by another customer. You can configure duration, frequency and content of the popup.
One of my clients was facing another five figure licencing fee for Magento EE when we got talking about the actual benefits of Magento EE over CE. The main reason the client was using EE was to have access to EE support. The site is a major retailer and any kind of downtime would cause substantial financial loss. In the 3 years of using EE we had contacted the support twice, both times with less than stellar results.
One of my Magento clients ran into a bit of trouble with their current hosting provider. Stability was not up to what it was supposed to be, there were security issues that raised concern, and support was slow and indifferent at times. The client is a retailer that gets significant traffic spikes during shopping season and when doing promotions. The infrastructure of the current hoster was not flexible enough to deal with huge traffic spikes in an automated fashion.
We decided to switch to a different hosting company to improve the situation. We looked into a bunch of companies and ended up giving Rackspace Magento Hosting a go.
This post is a post-mortem of a failed attempt to switch our hosting provider.
Magento is a complex beast and tracking down the source of a database query can be a huge pain. Recently I had to track down the source of a set of queries. I could see the queries in the SQL query logs but wasn’t able to figure out which particular piece of code would execute them because the functionality that triggered these was used all over the place.
I ended up adding the PHP stack trace that executed a SQL query to each query as a comment before the query. That way the full stack trace would show up in the MySQL query logs.
Continue reading “Tracking Magento Database Queries”
One of Magento’s weaknesses is that there often different ways to customize your installation. When several developers work on a site this often leads to inconsistencies and some ways of customizing are better than others. I was doing some research on adding a custom category template for an individual category and all solutions I found were centered around Magentos “Custom Layout Update” option which allows to overwrite the layout structure via a XML snippet in the Magento admin (Catalog > Manage Categories).
This option has several disadvantages:
- It’s a pain to write XML in a textarea
- There is no way of keeping track of the change in source control
- You have to deploy this change by writing custom SQL queries or manually in your dev and staging instances
A much cleaner option is to simply do your overwrites in your themes catalog layout file catalog.xml (app/design/frontend/[package]/[theme]/layout/catalog.xml).
<!-- Category id goes here --> <CATEGORY_[category id]> <reference name="root"> <!-- Switch to 1 column layout --> <action method="setTemplate"><template>page/1column.phtml</template></action> </reference> <reference name="content"> <!-- Overwrite the view template --> <block type="catalog/category_view" name="category.products" template="catalog/category/[template name].phtml" /> </reference> </CATEGORY_[category id]>
This approach offers the same flexibility and is much easier to deploy and maintain.