Natively Magento doesn’t have a direct method to nest menu items using the page/template_links->addLink() function, but we had some menus that will never change and are best set in the layout XML rather than in the database/CMS. There is a feature to addLinkBlock() – but this relies on the block outputting the wrapping <li> – but as we intended to nest addLink(), this wouldn’t quite work.

So we put together a tiny extension to offer this functionality,

The files

You’ll need to create the following files and directories first,

./app/code/community/Sonassi/TemplateLinks
./app/code/community/Sonassi/TemplateLinks/etc
./app/code/community/Sonassi/TemplateLinks/Block/Page/Template
./app/etc/modules/Sonassi_TemplateLinks.xml
./app/code/community/Sonassi/TemplateLinks/etc/config.xml
./app/code/community/Sonassi/TemplateLinks/Block/Page/Template/Links.php
./app/design/frontend/x/x/template/page/template/links_nested.phtml

Add this to ./app/etc/modules/Sonassi_TemplateLinks.xml

<?xml version="1.0"?>
<!--
/*
* @category    Module
* @package     Sonassi_TemplateLinks
* @copyright   Copyright (c) 2012 Sonassi
*/
-->
<config>
  <modules>
    <Sonassi_TemplateLinks>
      <active>true</active>
      <codePool>community</codePool>
    </Sonassi_TemplateLinks>
  </modules>
</config>

Add this to ./app/code/community/Sonassi/TemplateLinks/etc/config.xml

<?xml version="1.0"?>
<!--
/*
* @category    Module
* @package     Sonassi_TemplateLinks
* @copyright   Copyright (c) 2012 Sonassi
*/
-->
<config>
  <modules>
    <Sonassi_TemplateLinks>
      <version>1.0.0</version>
      <depends/>
    </Sonassi_TemplateLinks>
  </modules>
  <global>
    <blocks>
      <templatelinks>
        <class>Sonassi_TemplateLinks_Block</class>
      </templatelinks>
    </blocks>
  </global>
</config>

Add this to ./app/code/community/Sonassi/TemplateLinks/Block/Page/Template/Links.php

<?php
/*
 * @category    Module
 * @package     Sonassi_TemplateLinks
 * @copyright   Copyright (c) 2012 Sonassi
 */
class Sonassi_TemplateLinks_Block_Page_Template_Links extends Mage_Page_Block_Template_Links
{
    protected function _construct()
    {
        $this->setTemplate('page/template/links_nested.phtml');
    }
    public function addLink($label, $url = '', $title = '', $prepare = false, $urlParams = array(), $position = null, $liParams = null, $aParams = null, $beforeText = '', $afterText = '', $childMenu = false)
    {
        if (is_null($label) || false === $label) {
            return $this;
        }
        $link = new Varien_Object(array(
            'label' => $label,
            'url' => ($prepare ? $this->getUrl($url, (is_array($urlParams) ? $urlParams : array())) : $url),
            'title' => $title,
            'li_params' => $this->_prepareParams($liParams),
            'a_params' => $this->_prepareParams($aParams),
            'before_text' => $beforeText,
            'after_text' => $afterText,
            'child_menu' => ($childMenu ? $this->getLayout()->getBlock($childMenu) : '')
        ));
        $this->_links[$this->_getNewPosition($position)] = $link;
        if (intval($position) > 0) {
            ksort($this->_links);
        }
        return $this;
    }
}

And finally, put this code in ./app/design/frontend/x/x/template/page/template/links_nested.phtml

<?php
/*
* @category    Template
* @package     Sonassi_TemplateLinks
* @copyright   Copyright (c) 2012 Sonassi
*/
?>
<?php
/**
 * @see Mage_Page_Block_Template_Links
 */
?>
<?php $_links = $this->getLinks(); ?>
<?php if(count($_links)>0): ?>
<ul class="links"<?php if($this->getName()): ?> id="<?php echo $this->getName() ?>"<?php endif;?>>
    <?php foreach($_links as $count=>$_link): ?>
        <?php if ($_link instanceof Mage_Core_Block_Abstract):?>
            <?php echo $_link->toHtml() ?>
        <?php else: ?>
            <li<?php if($_link->getIsFirst()||$_link->getIsLast()||$count): ?> class="<?php if($_link->getIsFirst()): ?>first<?php endif; ?><?php if($_link->getIsLast()): ?> last<?php endif; ?> link-<?php echo $count ?>"<?php endif; ?> <?php echo $_link->getLiParams() ?>>
            	<?php echo $_link->getBeforeText() ?><a href="<?php echo $_link->getUrl() ?>" title="<?php echo $_link->getTitle() ?>" <?php echo $_link->getAParams() ?>><?php echo $_link->getLabel() ?></a><?php echo $_link->getAfterText() ?>
            	<?php echo ($_link->getChildMenu()) ? $_link->getChildMenu()->toHtml() : ''; ?>
            </li>
        <?php endif;?>
    <?php endforeach; ?>
</ul>
<?php endif; ?>

Making some nested menus

Now that the extension is in place, you can start creating some nested menus, it follows the same syntax and arguments as the built in addLink() function.

So first we create the main menu, the key is to set a new element in addLink called <childMenu/>

<reference name="mymainmenu.links">
    <action method="addLink" translate="label title before_text">
        <label>Information Centre</label>
        <url />
        <title>Information Centre</title>
        <prepare />
        <urlParams />
        <position>100</position>
        <liParams>id="mymainmenu-menu"</liParams>
        <aParams />
        <before_text />
        <after_text />
        <childMenu>mymainmenu.sublinks</childMenu>
    </action>
</reference>

Then we create the submenu,

<block type="page/template_links" name="mymainmenu.sublinks" as="mymainmenuSubLinks">
    <action method="setName">
        <name>mymainmenu-sublinks</name>
    </action>
    <action method="addLink" translate="label title before_text">
        <label>Contact Us</label>
        <url />
        <title>Contact Us</title>
        <prepare />
        <urlParams />
        <position>110</position>
        <liParams />
        <before_text />
        <after_text />
    </action>
    <action method="addLink" translate="label title before_text">
        <label>Shipping and Delivery</label>
        <url />
        <title>Shipping and Delivery</title>
        <prepare />
        <urlParams />
        <position>120</position>
        <liParams />
        <before_text />
        <after_text />
    </action>
</block>

And that is it. You can continue to nest as many levels as you want, just remember to make sure you declare the empty parameters (like aParams or liParams) even if you are not using them – as the core functionality isn’t forgiving if you miss out, or re-sequence the arguments.

The Magento support IPs

207.86.19.64/28
216.127.124.224/27
67.88.151.96/28
74.62.207.56/29
195.14.124.0/23
178.255.178.34
93.183.209.230
80.92.227.82
208.86.253.141
208.86.253.142
208.86.253.168
208.86.253.233
208.86.253.234
208.86.253.239

As we’re restricting Nginx to maintenance mode – we need to open access for their IP ranges. Magento have around 600 IP addresses that they need to you open up, which the majority of is within large subnet blocks; however, Nginx doesn’t support subnets for the type of matching we use for maintenance mode.

So first I tried just putting all 600 IPs in, subnet to individual IP conversion was courtesy of TechZoom.

if ($remote_addr ~ (67.88.151.96|67.88.151.97|67.88.151.98|67.88.151.99|67.88.151.100|67.88.151.101|67.88.151.102|6....

But Nginx didn’t like this …

Testing nginx configuration: nginx: [emerg] too long parameter "(67.88.151..."

So a more sensible approach was to use regular expressions for the IP range. No problem for a regex master like myself (eek!). So I converted the subnet blocks to regex.

67.88.151.(9[6-9]|10[0-9]|11[01])
74.62.207.(5[6-9]|6[0-9]|7[0-3])
195.14.12[45].([0-9]{1,2}|1[0-9]{2}|2[0-4][0-9]|25[0-5])
216.127.124.2(2[4-9]|[34][0-9]|5[0-5])

And to combine that with the other (non-contiguous) IPs, you get this,

if ($remote_addr ~ "(195.14.12[45].([0-9]{1,2}|1[0-9]{2}|2[0-4][0-9]|25[0-5])|67.88.151.(9[6-9]|10[0-9]|11[01])|74.62.207.(5[6-9]|6[0-9]|7[0-3])|216.127.124.2(2[4-9]|[34][0-9]|5[0-5])|178.255.178.34|93.183.209.230|80.92.227.82|208.86.253.141|208.86.253.142|208.86.253.168|208.86.253.233|208.86.253.234|208.86.253.239)") {
  set $maintenance off;
}

For this particular customer, they have a complex 3 server cluster running a single site with over 240,000 unique visitors per day, so Nginx was a more appropriate choice.

Going into maintenance

Putting up a maintenance page with a 503 header is required, but in addition to this, to make sure payment gateway IPNs can function correctly, we need to permit access to some URLs (where we do not know the source IP address), eg. PayPal or Ogone. Also, we’ll need to add our own IP address to the allow list.

In the Nginx vhost configuration file:

server {
..
 set $maintenance on;
 if ($remote_addr ~ (my.ip.add.ress|my.second.ipadd.ress|my.third.ipadd.ress)) {
  set $maintenance off;
 }
 if ($uri ~ ^/(index.php/)?(ogone|paypal)/(.*)$ ) {
  set $maintenance off;
 }
 if ($maintenance = on) {
  return 503;
 }
 location /maintenance {
 }
 error_page 503 @maintenance;
 location @maintenance {
  root $maintenance_root;
  rewrite ^(.*)$ /index.html break;
 }
..
}

A few years ago we wrote an installation script, but rudely forgot to share it with the community. You can find it here

http://sys.sonassi.com/install-magento.sh (full)
OR
http://s.onas.si/?installmage (shortened)

The features

• Using the script is really easy
• Support for CE/EE
• Supports installation with/without sample data
• Chooses the correct sample data for the version of Magento you are using
• Automatically re-indexes after installation
• Automatically completes the full installer (with en_GB defaults)
• Automatically creates an admin account
• Supports CE 1.3/1.4/1.5/1.6 EE 1.10/1.11

Using the installer for Community Edition

  First log into your SSH account and execute,

wget -O install-magento.sh http://sys.sonassi.com/install-magento.sh

  Then execute the script, it takes a minimum of 5 arguments and 2 optional arguments.

Required arguments
1. DB Host
2. DB User
3. DB Name
4. DB Pass
5. Magento version
Optional arguments (for auto install)
6. Store URL
7. Admin Email Address

  So for a full installation, that automatically installs Magento, adds sample data and completes the final install process, you would run.

install-magento.sh mydbhost myuser mydb "mypass" "1.6.2.0" "www.mystore.com" "info@mystore.com"

Which would show …

Do you really want to install in /home/mystore/public_html/ [y/N]: y
Do you want to install sample data? [y/N]: y
Starting installation, please wait ...
>> Downloading Magento 1.11 ... Done
>> Downloading sample data ... Done
>> Extracting files ... Done
>> Importing sample data ... Done
>> Setting up Mage ... Done
>> Cleaning up ... Done
>> Installing Magento ... SUCCESS
>> Re-indexing all indexes ... Done
>> Removing admin notifications ... Done
########################################
 INSTALLATION COMPLETE
 Admin Url     : www.mystore.comadmin
 Admin Username: info@mystore.com
 Admin Password: RfvDY-/l
########################################

Using the installer for Enterprise Edition

  If you wish to install Magento Enterprise edition – then you’ll need to download the tar.gz archive from your “My Account” section on MagentoCommerce.com.

  Upload the file to the base directory of where the installation will be

  Rename the tar.gz file to be latest-magento.tar.gz

  Continue with the instructions from CE above.

Ignoring any project specific pages/customisations, the following list is the minimum pages we must skin/satisfy for a Magento project. It is also the list of designs that we ask clients/agencies to supply if they are supplying their own design for us to skin/build.

So in no particular order …

cPanel has a brilliant backup facility built in, however it only keeps 1 backup per backup type. So if you have daily backups enabled running every day of the week, your previous day’s backup will be lost – the same applies to weekly and monthly backups.

This can be a bit of a nuisance if you need to restore a file deleted the day before a backup ran.

So using a simple script that hooks into cPanel’s backup script, you can retain backups for any number of days, weeks or months and it will only consume a very minimal amount of space – as the script uses hard links. So only the files that have changed will actually take up disk space.

Backup rotation script

Create a new file /scripts/postcpbackup.sh and put the following in it. You can customise the types of backups to be rotated and the retention period.

#!/bin/sh
# Simple backup directory rotation script for cPanel
#
# Allows daily, weekly and monthly backups to be kept for X number of days using
# hard links for retained backup copies, so disk space usage is extremely minimal
#
# Courtesy of www.SonassiHosting.com - The Magento Hosting experts
# Eg. /backup/cpbackup
BACKUP_ROOT_DIR=/backup/cpbackup
# Eg. daily weekly monthly
BACKUP_TYPES=( daily weekly )
# Eg. 1440 10080 40320 - the number of minutes for each respective backup type
BACKUP_AGE=( 1440 10080 )
# Eg. 7 4 1 - How many historical versions to keep of each backup
BACKUP_RETENTION=( 3 1 )
#######################################
# Do not edit anything below this line
#######################################
BACKUP_DATE=`date +%F`
for (( i = 0 ; i < ${#BACKUP_TYPES[@]} ; i++ )); do
  TYPE=${BACKUP_TYPES[$i]}
  AGE=${BACKUP_AGE[$i]}
  RETENTION=${BACKUP_RETENTION[$i]}
  MAX_AGE=`expr $RETENTION \\* $AGE`
  MIN_AGE=`expr $AGE + 60`
  if [ ! -d $BACKUP_ROOT_DIR/$TYPE ] || [[ ! `find $BACKUP_ROOT_DIR/$TYPE\_* -maxdepth 1 -mmin -$MIN_AGE -type d` == "" ]]; then
    echo "DIR '$TYPE' doesn't exist or previous backup too young ($AGE mins)"
    continue
  fi
  # Remove oldest backup
  find $BACKUP_ROOT_DIR/$TYPE\_* -maxdepth 1 -type d -mmin +$MAX_AGE -exec rm -rf {} \; > /dev/null 2>&1
  mkdir -p $BACKUP_ROOT_DIR/$TYPE\_$BACKUP_DATE
  # Synchronise files
  rsync -a --delete \
    --link-dest=$BACKUP_ROOT_DIR/$TYPE $TYPE/. $BACKUP_ROOT_DIR/$TYPE\_$BACKUP_DATE/
done

Backup restoration from rotation

Just bear in mind, this code does not integrate into the backup restoration aspect of cPanel – so if you do need to restore/find a file – you will have to rename the folders appropriately.

Eg. to restore a daily backup from 2012-04-03

cd /backups/cpbackup
mv daily{,.previous}
mv daily_2012-04-03 daily

Then use the standard restoration tool in WHM, after the restore is complete, just move the folders back to how they were

mv daily daily_2012-04-03
mv daily.previous daily

We have come across a somewhat critical core code error in Magento versions less than 1.5 when using the “Fixed Amount discount”. Any SKU that the respective rule applies to results in the final sale price of the product being £0. This seems to only occur in certain scenarios, but is easily replicated on a Magento 1.4.2.0 clean demo store.

The fix

Rather than posting the full code for an extension based override, we’re just going to post the code snippet and the simpler PHP autoloader priority based fix using the ./app/code/local directory.

Create ./app/code/local/Mage/CatalogRule/Helper/Data.php

And paste the following code inside:

class Mage_CatalogRule_Helper_Data extends Mage_Core_Helper_Abstract
{
 public function calcPriceRule ($actionOperator, $ruleAmount, $price)
 {
 $priceRule = 0;
 switch ($actionOperator) {
 case 'to_fixed':
 $priceRule = $ruleAmount;
 break;
 case 'to_percent':
 $priceRule= $price * $ruleAmount / 100;
 break;
 case 'by_fixed':
 $priceRule = $price - $ruleAmount;
 break;
 case 'by_percent':
 $priceRule = $price * (1 - $ruleAmount / 100);
 break;
 }
 return $priceRule;
 }
}

Save your file, flush your cache and re-apply your catalogue price rule.

We have watched the Magento community has grow rapidly over the past 4 years, with new companies adopting the platform by the day; as a very early adopter, this is great to see.

What prompted this article was an email from Phil Robinson at Magento, inviting us to be part of the Magento Trusted extension program for our excellent Magento/Wordpress Integration Extension. Finally, I thought, validation of Magento extension quality and the overall improvement of Magento connect – unfortunately I was misunderstood. My interest was soon followed up with an email outlining all the fees involved to be an Industry Partner.

This got me thinking, as we’re not currently an “official” partner, what are the real benefits of the Magento partnership program, specifically the Solution Partner Program. What does it offer the consumer, what does it offer the agency?.

Our community grew Magento

During the early stages of Magento’s birth; documentation, guides, blogs and other information were completely non-existant; and it required heavy participation from development firms (like ourselves) to be the ones to write guides, books, articles & blog posts and even help others on the Magento Commerce forums. These early community members put in place the groundwork for most of the development of extensions and stores you see today.

But back in early 2008, those who frequently contributed weren’t really given any type of formal accreditation or reward. But if you were willing to pay a little – you could get a little badge under your forum avatar – “Community Partner”.

So what partnership level means what then

Buried in a PDF, the Finding Magento Solution Partners documentation classifies the different levels as follows, (which would make Sonassi a Gold partner).

The dawn of the partner age

Later, in 2008, the partner age begun and the Magento Partner Pricing (2008) was released. You could now be part of the Magento elite and partner your way to success, with a nominal annual fee, varying from a fractional $800 to $3,800.

The strategy of the partner program has been very similar in structure since 2008; more revenue for Magento – either through annual membership, partner revenue commitment – commission through sales of support/product licenses (Pro/EE).

In 2012, membership pricing has increased slightly, ranging from $2,500 to $10,000 + revenue commitment.

Our understanding is that Magento partner program consists of best-of-breed agencies to showcase Magento and how good it really is, which to some degree it does.

Are Magento partners, Magento experts?

Perhaps. The requirements to be a Silver solution partner (and above) would imply that. But the truth is, we cannot answer this accurately – and that is our concern.

The Bronze level is the gateway to the program, allowing agencies to enter the ecosystem; there is no barrier to entry in terms of qualification or ability. Bronze partners are those considered to develop primarily on CE with a future interest in EE. Bear in mind that unless you frequently develop EE stores, anything above Bronze isn’t for you.

Next up are your Silver partners, which admittedly is slightly harder to obtain. You are required to have a minimum of 2 Magento certified developers, but more importantly, you are expected to be using EE, taking on a minimum of 3 new EE clients every year (to satisfy the minimum annual commitment revenue of $50,000).

Gold level is much the same, a requirement for 4 certified developers and minimum commitment revenue of $100,000.

After speaking to Magento, one simply can’t choose to be a Silver/Gold partner, but rather are subject to approval by Magento; both for financial targets but also their general attitude towards EE and Magento as a whole. They have to earn it.

Bigger is better, or is it?

The partner program exists as a way to prove to the world that you are a capable Magento agency, but Magento appear to have neglected to differentiate the levels to the end user. Before researching this article, even I didn’t know the differences between entering at Bronze level and earning your Silver level – you can’t just pay for it, but have to instead prove your dedication and worth to Magento.

But does the SME know the difference between what each level means? Do they know a Bronze partner is likely unfamiliar with Magento but a Silver partner is not just familiar, but has earned the development certification to prove their knowledge of Magento. This is a real weakness of the program, simply because Magento have neglected to properly explain the differences to end users.

So those boutique Magento agencies looking to take the next step might consider entering the partner program, starting at the lowest level, a Bronze partner. But we wonder if this gives them any edge over a non-partner. After all, Magento’s definition of a Bronze partner (below), is that of a company likely unfamiliar with Magento and usually only familiar of working with small businesses.

This shows a gap, wherein an agency can be very proficient with Magento, but either continues to develop on CE or doesn’t have the volume of EE clients to satisfy the minimum commitment revenue. This would position them between Bronze and Silver, perhaps a new partner level should be added to satisfy this, Bronze+.

We want to join, but could it hurt us

Sonassi has wanted to join the partner program since day 1, but we would aim to immediately be a Gold partner (who wouldn’t), paying the membership fee of $10,000 each year isn’t an issue, but paying a revenue commitment and having to promote the commission-based Enterprise Edition over Community Edition could be. We don’t like the idea of having to launch a minimum of 8 EE stores per year, how could we give each project the care and attention it needs, if we are focused on hitting targets.

It would likely be that we would only qualify to be a Bronze partner (simply due to the fact only 10% of the stores we develop use EE) – which we fear would cost us more than it would gain. We would be grouped with companies, who by Magento’s definition, are new to Magento. Our biggest fear would be losing a potential lead just because of our lesser partner status before we even get the chance to bid.

For development, we look to target medium sized business; for hosting, we look to target enterprise sized business. But by only being a Bronze partner – we’ve immediately branded ourselves less capable than a Silver/Gold partner – even though we know we have a far better understanding of Magento than a lot of Silver and Gold partners.

The partner program currently devalues Magento

The ambiguity and lack of distinction between levels does the program and its partners an injustice. It isn’t clear how hard a Gold partner has had to work to earn their stripes, similarly, how easy it has been for a Bronze partner to enter.

It also needs an intermediary step for those between Silver and Bronze. Agencies who are Magento experts, but primarily use CE – Bronze+.

For anyone looking at the program for the first time, it would be easy to misunderstand what it means to be a partner (even I am guilty of this).

•  It is revenue based, pay more, rank higher
•  There is no formal distinction between what each level means to an end-user
•  An agency, can still be a partner without even having worked with Magento

So, are Sonassi going to partner up?

We want to, but at the moment find ourselves with a lot of questions. We believe CE is not only a viable option for production Magento stores, but an enterprise option in itself. Many of our clients would not benefit from the minor benefits of EE and unless there was a specific feature in EE that was not cost-effective for us to build ourselves – I would certainly struggle (morally and ethically) to tell a client that they needed EE, just so that could hit our revenue commitment.

Will we see success with the partner program? Time will tell.

But there may be hope yet, Magento Certified Developers

So it begs the question, how do you know if a Magento agency is as good as they say they are? Thankfully, there is now a recognised accreditation that developers can obtain. Not just in exchange for money, but a formal examination that can both be passed and failed.

Most agencies, that truly specialise in Magento, are making sure that all their developers have the appropriate training to obtain this valuable qualification – we’re in the middle of it at the moment, with the goal of 100% of our development workforce being Magento Certified.

Developer Certification is what any business/individual looking for a Magento agency should use to judge their competency – in addition to any other standard vetting procedures.

But what about judging Magento Hosting

In the absence of any formal Magento hosting accreditation, ignoring the value-less partner program, MageBenchmark stands to be the original and most accurate Magento performance benchmarking and comparison website, find it at http://magebenchmark.sonassi.com/

Whenever granted root access to a server, we normally carry out the following, to rule out any future permissions headaches. Please bear in mind, this practice is secure for dedicated hosting but may present security issues with shared hosting if the Apache process isn’t chroot’ed per user.

In our example, the user is sonassi and the group is apache

Add the FTP/SSH user to the Apache group

Most importantly, we need to make sure that the FTP/SSH user is part of the Apache group, in our example, its apache (but is also commonly www-data)

usermod -a -G apache sonassi

Keep adding as many users to the group as you have for FTP/SSH.

Reset original permissions

So before we start, lets make sure all the permissions are correct.

chown -R sonassi:apache /home/sonassi/public_html
chmod -R 775 /home/sonassi/public_html

ACLs and Sticky Bits

ACLs in Linux allow us to define specific rules, in our case, what permissions files should inherit upon creation. A sticky bit (mentioned later) takes care of group inheritance, but does not help with the permissions, which is why we use ACLs.

Start by enabling ACL support on the active partition, please ensure your Kernel was compiled with ACL support

mount -o remount,acl /home

Now ACLs are enabled, we can set the ACL rules and group sticky bits:

setfacl -d -m u::rwx,g::rwx,o::rx /home/sonassi/public_html
chmod g+s /home/sonassi/public_html

But I don’t have ACL support

If your Kernel doesn’t support ACLs you can also use umask (which is a run time setting for BASH, FTP and PHP) to set the default file permissions. Magento usually sets umask(0) in index.php, however, it would be in your interests to change this.

In your index.php change the umask line to be

umask(022);

And in your BASH environment for SSH, set this in either you .bashrc or .bash_profile

umask 022

For your FTP server, you’ll need to read the documentation for it, but the principal is the same.

All done

Now, whenever a new file is created, it will be created with the correct permissions and group, allowing your FTP/SSH user to create files and the web server will still be able to write and vice-versa.

Now sit back and relax knowing you’ll never be recursively setting permissions again, or never experience the issue by changing your hosting to the UKs best Magento specialist host, Sonassi Hosting.

We found a bug recently where PHP processes were being abandoned and left to continually consume memory and accumulate. This seems to be prevalent with Apache 2.2.x and mod_fcgid 2.3.5. Whilst we await an actual fix, we’ve wrote a quick script to help “clean up” these zombie processes to prevent the machine eventually swapping.

This works for cPanel and any other server running mod_fcgid. It isn’t meant to be a permanent solution, but a means to help the issue temporarily.

Firstly, create the following file, /scripts/phpcleanup.sh, then add the following line to your root crontab

5 2 * * * /scripts/phpcleanup.sh

#!/bin/sh
# PHP Cleanup script for abandoned PHP processes as a bug fix to issue in EasyApache,
# See http://forums.cpanel.net/f189/lost-abandoned-php-processes-apache-2-2-17-mod_fcgid-2-3-5-suexec-180571.html
#
# Courtesy of www.SonassiHosting.com - The Magento Hosting experts
phpbin='/usr/bin/php'
membefore=`cat /proc/meminfo | grep Committed_AS | awk '{print $2}'`
procsbefore=`ps ax | grep "$phpbin" | grep -v grep | wc -l`
killolderthan=`date -d "-1 day" +%s`
for pid in `ps auxwwwf | grep "$phpbin" | grep -v grep | awk '{print $2}'`; do
  starttime=`ps -F $pid | awk 'NR==2 {print $8}'`
  startdate=`date -d "$starttime" +%s`
  if [ $startdate -lt $killolderthan ]; then
   #echo "$pid is a Zombie ($starttime), killing ..."
   kill $pid >/dev/null 2>&1
  fi
done
memafter=`cat /proc/meminfo | grep Committed_AS | awk '{print $2}'`
procsafter=`ps ax | grep "$phpbin" | grep -v grep | wc -l`
procskilled=`expr $procsbefore - $procsafter`
if [ $procskilled -gt 0 ]; then
  echo `expr $membefore - $memafter`"MB RAM has been freed"
  echo "$procskilled processes were killed"
else
  echo "No processes were killed"
fi