PHP Foreach Preserves Last Item

I thought I’d blog this because it’s something that comes as a surprise to me, so it may come as a surprise to you. Let’s consider this code:

The second time the loop runs it actually preserves the value of the “$app” variable, and thus triggers the if statement’s isset() function to true.

This issue caught me for a loop for a while, but I guess now I know…. interesting PHP….

Check if a website is running Magento Community or Enterprise Edition

To check if a website is running Magento the first thing you want to do is view the page source and search for “Varien”. If you find a match then the website is *probably* running Magento. If you do not match anything, next view the source of the JS files and look for “Varien”. Some websites merge their javascript files into one file, so that should be easy.

After you know if the website is running Magento, you can detect if a website is running Magento Enterprise Edition by hitting *website_base_url*/giftcard/customer in your browser. If you get a 404 Page Not Found error then that means they are NOT running MEE (Magento Enterprise Edition). If you get redirected to a login page that means they ARE most likely running MEE.

You can get browser extensions like Chrome Sniffer that will also tell you if they are running Magento, however the above method is great if you need to do it programmatically for some reason.

How to temporarily disable cache for Magento scripts

If you are running Magento scripts that are bootstrapped for reasons such as asynchronous processing, syncs, indexing, etc, then you’ll want to disable all Magento cache when Magento is loaded. This will avoid cases where old model data is being used, especially when you have two executions of the Magento script running at the same time.

To disable all Magento cache programmatically add the “global_ban_use_cache” option to your Mage::app initialization. Your Mage::app initialization would look like this:

Mage::app(‘admin’, ‘store’, array(‘global_ban_use_cache’=>true));

Any modules you have running that also use the native Magento cache system should also stop using cache when this flag is set.

Hope this helps some people!

Magento CMS Tutorial/Reference

I was helping someone learn how to use Magento CMS static blocks and pages and I couldn’t find a great reference. I’ve decided to write my own. 

Pages – Pages are what shows up in the front-end. The URL key is what you use to access the page ( and the content is what appears in the page. Title shows up in the title bar. Simple.

Static Blocks – These can be inserted into any page and repeated. For example, if you had a page that had a block of text that you want to appear on another page but you didn’t want to rewrite it and have to sync between both pages then you would want to create a static block and include that static block in each page’s content. The static block si referenced by the Identifier field. Here’s an example of how this would be used. Static blocks and contain other static blocks too. 

Page Content Codes

When working in the Magento CMS you can enter any HTML into the content box, but you can also put in these special things:

  1. Store URLs: {{store url=”path_to_your_media_file_goes_here”}}
  2. Skin Image URLs: {{skin url=”path_to_your_media_file_goes_here”}} 
  3. Media Image URLs: {{media url=”path_to_your_media_file_goes_here”}}
  4. Static Block Content: {{block type=”cms/block” block_id=”page_identifier_goes_here”}}
  5. Other Data Blocks (advanced): {{block type=”module/blockclass” block_id=”choose_a_name” template=”template_file_path”}}

Now I’ll go into a bit more detail:

1. Store URLs
{{store url=”path_to_your_media_file_goes_here“}}

If you want to link to a CMS page or some other page on your site you should use this code.

Example: Click here for customer service

2. Skin Image URLs
{{skin url=”path_to_your_media_file_goes_here“}} 

Skin image urls can be inserted into a page as paths to a skin image or file. These are relative to the skin/frontend/*package*/*theme*/ directory in your website.

Example: Here is a picture of our company logo: <img src=”{{skin url=’images/logo.png’}}” />

3. Media Image URLs
{{media url=”path_to_your_media_file_goes_here“}}

Skin image urls can be inserted into a page path to point to an uploaded image or file. These are relative to the media/ directory of your website.

Example: Here is a picture of a duck: <img src=”{{media url=’ducks/duckpicture.png’}}” /> and click here for a PDF that we created for you.

What’s the difference between skin images and media images?

Great question! Skin images are store layout/theme dependent and may change depending on the store view, but media images are static and don’t care about what theme is currently being displayed to the user. Media images are typically files that are very likely to change over time where skin images 

4. Static Block Content
{{block type=”cms/block” block_id=”page_identifier_goes_here“}}

Static block content can be inserted into the content of one or more pages. This allows you to have repeated content in your pages without having to manage multiple content page coppies every time you make an update.

Example: Here is your navigation menu: {{block type=’cms/block’ block_id=’my_navigation_menu’}}

5. Other Data Blocks (advanced)
{{block type=”module/blockclass” block_id=”choose_a_name” template=”template_file_path}}

If you are coding template files nad custom block classes, you can include any block class as a singleton using this method .The type attribute is the code to create the block class and the block ID is a custom name you can choose for the block. This block name is used in caching sometimes. Finally, the template file path is a reference to the template file from the app/design/frontend/*package*/*theme*/template directory.

TIP: You can also set the the blcok type to core/template to create a simple block that does not have a specific block class.

Example: Here is my footer block content: {{block type=’core/template’ block_id=’footer_block’ template=’page/html/footer.phtml’}}




Making Magento load a custom database depending on domain

We needed to make Magento to run a different database depending on the subdomain specified. Here’s how we did it VERY basically. doing so allows you to have separate Magento databases dynamically loaded depending on route. This also makes scaling a lot easier, and usage of systems like beanstalk from Amazon or PHP fog possible.


Keep in mind the following things:

  1. This is not a secure method mentioned below. You should have different passwords for each DB. doing so however will require you to store somewhere the passwords to access.
  2. This was tested on Magento 1.6 CE and 1.11 EE in a unix environment.
  3. This method assumes you don’t store any custom data in the config.xml. You should make your XMLs read-only to ensure this. 
  4. You should spend time with your own environment, so I’m not too specific in these instructions. 
  5. These require some core changes. If anyone has any suggestions on how to do it without the core changes, be my guest and comment below.

The Steps

Step 1: Edit the index.php. Somewhere before loading Magento, pull the subdomain using your favourite method. We used $_SERVER[‘SERVER_NAME’]. Set this to $subdomain.

Step 2: Within index.php, find Mage::run near the bottom. The last paramater allows you to specify custom directories. Make the media and var/ directories custom depending on the domain. We did something like this:

    Mage::run($mageRunCode, $mageRunType, array(
            ‘upload_dir’  => $dir.‘/media/upload’.$subdomain,
            ‘tmp_dir’     => $dir.‘/var/tmp’.$subdomain,
            ‘cache_dir’   => $dir.‘/var/cache’.$subdomain,
            ‘log_dir’     => $dir.‘/var/log’.$subdomain,
            ‘session_dir’ => $dir.‘/var/sessions/’.$subdomain,
            ‘export_dir’  => $dir.‘/var/export’.$subdomain,



Step 3: I know global variables are bad, but set global $subdomain; Now you can access it anywhere.

Step 4: Edit app/code/core/Mage/Core/Model/Config.php or move it to app/code/local/ After line 279, add something like:
     global $subdomain;
       $this->_xml->global->resources->default_setup->connection->dbname = $subdomain;

You may want to also add some checks here to see if the DB actually exists.

Step 5: Edit app/Mage.php and after line 689 add:
       global $subdomain;
       $localConfig->global->resources->default_setup->connection->dbname = $subdomain;
       $xml = $localConfig->global->resources->default_setup->connection->dbname;

Step 6:  Name each new database you create by the subdomain.

Try it out

Try it out. Assuming you’ve done everything correctly you should get Magento to load now depending on the subdomain. Definitely do your own tweaking, but I really hope this helps someone.