Posts Tagged ‘patch’

Magento ‘Can’t get filling percentage’ memcache issue

May 30th, 2014

This is a known problem for anyone who runs Magento and uses memcache as a caching backend. But it’s actually not a Magento issue, it’s a Zend Framework problem, and it seems that even newer versions of ZF still have the same approach. I suspect this is actually a memcache problem, but even so, one should be able to handle things better in the code.

The idea is that memcached sometimes fails to report its extended stats, thus the “getExtendedStats” method returns false, when in fact it should return an array with all the servers. This should not be a problem though, instead of throwing an exception, why not retry with getStats and then just return 100 (which I guess it means the server is full). Here’s the revised code:

if ($memSize === null || $memUsed === null) {
    $mem = $this->_memcache->getstats();
    if (isset($mem['limit_maxbytes']) && $mem['limit_maxbytes'] > 0) {
        return ((int) (100 * ($mem['bytes'] / $mem['limit_maxbytes'])));
    } else {
        return 100;
    //Zend_Cache::throwException('Can\'t get filling percentage');

You can get the entire file on github, but please note that this file corresponds to ZF v1.11.1 and Magento CE v1.5.1.0. It can definitely be adapted to any Magento version.

The easiest way to patch this without changing a core file (ie lib/Zend/Cache/Backend/Memcached.php) is to put the modified file in your app/code/local folder:
app/code/local/Zend/Cache/Backend/Memcached.php. since app/code/local comes first in the include path, the patched file will get included before the default one.

Disclaimer: This hasn’t been used in production, use at your own risk. In theory, it should be fine, but since it hasn’t passed any real testing, I don’t recommend doing so.

Magento , ,

Prototype 1.6, Event.stop and IE9 – Quick patch

November 30th, 2011

For those of you using Prototype 1.6 (or Magento prior 1.6), you might wonder why event.stop() or Event.stop(event) doesn’t work in Internet Explorer 9. Here’s a quick explanation:

IE 9 makes major changes to the event system. We had to rewrite the
event code in 1.7 to support it. You can either (a) upgrade to 1.7;
(b) force your site into compatibility mode [1].

So it’s been fixed in 1.7, but what if I can’t upgrade to 1.7 and don’t want to render my website in compatibility mode? Well, after a couple of hours trying to sort this out, here’s quick (and dirty) patch for Prototype Prototype Event.stop IE9 fix (1308 downloads)

Also, for further reading, here are two external links that you might find useful for this issue.

Note/Disclaimer: This has only been tested on Prototype Use it at your own risk.

Javascript , ,

Patching the Magento USPS module

January 20th, 2011

Since their last update on Jan 3rd, 2011 USPS has stopped working on all of my Magento distro’s. The reason for that is a change in USPS’ response XML values. Magento has its part of blame here, first for not patching it immediately (which again shows how much they care about the CE users) and second for not coding it properly in the first place – they’re using the method name (i.e. Express Mail) to see if that method is allowed from the admin, instead of using the CLASSID attribute.

This issue has been reported on bug tracking system and it’s also discussed in the forum. USPS makes it clear that they’ll discontinue all API versions prior RateV4 ad IntlRateV2:
“All Rate Calculator API integrators are encouraged to migrate to the latest API versions (RateV4, IntlRateV2):
RateV4 and IntlRateV2 will be the only Rate Calculator API versions to offer the full range of new products and functionality
Rate, RateV2, RateV3 and IntlRate will be retired in May 2011, requiring all integrators to migrate to the latest versions”

As explained on the forums, the fix is quite simple, as USPS only added the <sup>®</sup> which is the encoded (twice 🙂 ) version of the registered sign in a sup tag. Magento values are defined without those so when the code tries to match them it fails. All you have to do is clean that string and you’re good to go. I don’t like to modify core files so the fix involves copying app/code/core/Mage/Usa/Model/Shipping/Carrier/Usps.php to app/code/local/Mage/Usa/Model/Shipping/Carrier/ and working on the local version of Usps.php. Strip the special chars:

$mailService = str_replace('®', '', strip_tags(htmlspecialchars_decode(htmlspecialchars_decode((string)$postage->MailService))));


$svcDescription = str_replace('®', '', strip_tags(htmlspecialchars_decode(htmlspecialchars_decode((string)$service->SvcDescription))));


Here’s the archive with the patch. Just download it and unzip it in the root of your Magento distribution. USPS patch for Magento (987 downloads)


Note: This patch applies to Magento CE For all other versions you will have to do it manually as explained above.


Magento, PHP , ,