I entered a design for the PHP Community Spirit T-Shirt Design Competition. And it got approved today. It’s a simple design that uses the PHP logo colors and font. If you like it you can vote for it by following the design below.

After purchasing a new batch of the friendly blue guys. Damien Seguy was so friendly to send me an early Christmas present

I have some small versions left by the way. So if you are one of those people looking. Drop me a line or leave a comment.

When working in the admin environment of Magento i had to add a controller action that was called by an Ajax request. The problem however is that all layout data is returned as well when calling

$this->renderLayout();

from the controller. So my next attempt was to try to render the block separately and adding it to the layout.

$this->_initCustomer();
$this->getResponse()->setBody(
            $this->getLayout()->createBlock('block/location')
            ->setCustomerId(Mage::registry('current_customer')->getId())
            ->setData('list', $list)
            ->setUseAjax(true)
            ->toHtml()
);

This kinda worked. But now i had no more control over the template used. Or maybe i missed that part. But i don’t like to specify my Block anyway Magento should pick this up automatically.

Solving this issue is actually quite easy. The only thing we need to do is change the layout structure of the module. We change the name to root. And that’s it!

The name attribute tells Magento it is a root block so no need for the rest of the layout.

The last time i had to rewrite one of the core Magento blocks. And that turned out to be quite easy. My new challenge was to rewrite / overwrite one of the Core admin controllers. In this case the Mage_Adminhtml_CustomerController.

I had no idea where to start so i did some googling beforehand. And came to the conclusion that a lot of people are trying to do this. Because of this there is a long list of solutions to solve this. And in most cases developers just advice to drop the Core class in the local folder and work from there. But that doesn’t really make sense. First of all it code duplication in the worst form. And besides that all cool OO stuff like extending is gone.

And since Magento is such a flexible system. There must be a good clean way to solve this. One thread i found had some good info. And i used it as my starting point. There was one problem with this thread. The XML used seems to be an old form of rewriting in Magento.
I found a (lost it) post by one of the Magento devs that shows a new and more clean way of defining this in XML.

In the last post i already created the [Namespace]_All.xml module config. And we can use it for this as well. So we start by telling Magento we are using our own [Namespace_]_Adminhtml module.

<[namespace]_Adminhtml>
    true
    local
    
        
    

create local/Namespace/Adminhtml/controllers/CustomerController.php

The next thing to do is create the actual controller. And add an include line on top to the original file. Magento does not use autoloading for the controllers in this way.

include_once("Mage/Adminhtml/controllers/CustomerController.php");

class [namespace]_Adminhtml_CustomerController extends Mage_Adminhtml_CustomerController
{
	public function somenewAction()
	{

	}
}

Now the Core CustomerController is replaced by our own namespaced version. But it still retains all functionality of the parent.

The only thing left is to create the config file for this module. And tell it to rewrite to the new [namespace]

Create local/[namespace]/Adminhtml/etc/config.xml

	
        <[namespace]_Adminhtml>
            0.1.0
        <[namespace]_Adminhtml>
    

	
    	
    		
    			
    				
    					<[namespace]_Adminhtml before="Mage_Adminhtml">[namespace]_Adminhtml
    				
    			
    		
    	
    

The config section is placed inside the admin tags. because the controller in question is an admin controller. We basically tell Magento that we will be using our own Adminhtml module instead of the Core one. But it will of course fall back on the Core functionality when methods have not been overwritten.

The last few days i have been toying with Magento. and mainly trying to wrap my head around the file structure. It takes quite some time to find all files. So i will be making notes here to keep track of my own progress

Today i wanted to add a tab in the customer section of the admin. I am working on a new module and this should be configurable on a per user basis. There for i needed an extra tab to the customer > Manage customers > [customer x] page.

The first challenge was to figure out where Magento stores the tab menu data. I was hoping this came from a database. But after some searching i couldn’t find any reference. It seems to be hard coded in tab files. The customer tab in question can be found here:

app/code/core/Mage/Adminhtml/Block/Customer/Edit/tabs.php

We could of course edit this class. But that’s not according the Magento way. We need to create a local copy of this class. preferably under my own namespace.

To make this happen we first need to tell Magento we are rewriting core modules. So we start of by creating the following file

app/etc/modules/[namespace]_All.xml

And we add the following lines

    
        
            true
            local
            
                
            
        
    

This will tell Magento we have a Core folder under our own namespace. But it still depends on the Mage_Core classes if they are not available in the namespaced location.

Next we need to setup the [namespace]_Core module. We create the folder structure under our own namspace

app/code/local/[namespace]/Core/etc

And we create a new config file here (config.xml) where we will do the actual class rewriting.

    
        <[namespace]_Core>
            0.1.0
        
    
    
        
        	
        		
        			[namespace]_Adminhtml_Block_Customer_Edit_Tabs
        		
        	
        
    

We use the tag to tell Magento we are rewriting a Block class. And then we setup the actual rewrite.

Mage_Adminhtml_Block_Customer_Edit_Tabs is now rewritten too [namespace]_Adminhtml_Block_Customer_Edit_Tabs

The only thing left now is to create the Block class which is located in

app/code/local/[namespace]/Adminhtml/Block/Customer/Edit/Tabs.php

class [namespace]_Adminhtml_Block_Customer_Edit_Tabs extends Mage_Adminhtml_Block_Customer_Edit_Tabs
{
    protected function _beforeToHtml()
    {
	$this->addTab('modulename', array(
            'label'     => Mage::helper('customer')->__('Modulename'),
            'class'     => 'ajax',
            'url'       => $this->getUrl('*/*/modulename', array('_current' => true)),
        ));

        $this->_updateActiveTab();
        return parent::_beforeToHtml();
    }
}

Ok so i had nothing todo for a few minutes and found a link to this page. I am never really into this stuff. But it looked funny and i had nothing to do. So i walked through the questions… and the result

Supreme Nerd. Apply for a professorship at MIT now!!!.

Another nerdy thing i picked up was that Ilia Alshanetsky’s scalar type hints patch has been merged with the PHP trunk. Great stuff. Have been waiting for this for a while.

After a successful experiment a while back Month of the PHP Bugs. Stefan Esser and SektionEins is at it again. This time with Month of PHP Security. A gathering for PHP and security gurus a like. The call for papers is open for submission.

There are some nice prices to walk away with. So what you waiting for?

• New vulnerability in PHP [1] (not simple safe_mode, open_basedir bypass vulnerabilities)
• New vulnerability in PHP related software [1] (popular 3rd party PHP extensions/patches)
• Explain a single topic of PHP application security in detail (such as guidelines on how to store passwords)
• Explain a complicated vulnerability in/attack against a PHP widespread application [1]
• Explain a complicated topic of attacking PHP (e.g. explain how to exploit heap overflows in PHP’s heap implementation)
• Explain how to attack encrypted PHP applications
• Release of a new open source PHP security tool
• Other topics related to PHP or PHP application security

I am working on a small API for bluesignal and i wanted a modular architecture. I have done this before using the Zend Framework. But this time i wanted a bit more control while loading the modules. And adding a Bootstrap class would seem like a good option. The only example i could find involved loading all bootstraps on every request. Which doesn’t seem like a good idea. So after reading through the Manual and some blog posts. I decided to give it s shot my self.

The structure i want looks like this.

The application.ini file has the following contents:

includePaths.library = APPLICATION_PATH “/../library”
bootstrap.path = APPLICATION_PATH “/Bootstrap.php”
bootstrap.class = “Bootstrap”
resources.frontController.moduleDirectory = APPLICATION_PATH “/modules”
resources.modules[] = “default”
resources.modules[] = “admin”

includePaths
This sets the applications local library location. Any shared code for this application goes here.

bootstrap.path & class
Define the location and type of the Bootstrap class.

resources
Define the modules location and create a list of modules.

The main Bootstrap class

application/Bootstrap.php

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{

Load the config parameters for this application and set some debugging settings if needed.

    protected function _initConfiguration()
    {
    	$app = $this->getApplication();
    	$config = $app->getOptions();

    	if (APPLICATION_ENV == 'development') {
	    	    error_reporting(E_ALL & E_STRICT);
	    	    if (isset($config['phpsettings'])) {
		    	        foreach ($config['phpsettings'] as $setting => $value) {
		    		        ini_set($setting, $value);
		    	        }
	    	    }
    	}
    }

We need autoloading here because we are using a class from the application library. Right now this causes a problem. A notice is thrown

Warning: include_once(FrontController.php) [function.include-once]: failed to open stream: No such file or directory in Zend/Loader.php on line 147

The application responds fine. And this problem seems to be a recurring issue (ZF-7224, ZF-7550) for the framework. Until now i have not find a graceful fix for this. besides a small patch reversion.

    protected function _initAutoload()
    {
		    $autoloader = Zend_Loader_Autoloader::getInstance();
		    $autoloader->setFallbackAutoloader(true);

		    return $autoloader;
    }

Setup the controller to register the Bluess_Modules_Loader plug-in. And set the prefixDefaultModule parameter so we can prefix the default module controllers as well. Just for the sake of consistency. The Bluess_ namespace is part of my API. And can be changed at will.

   protected function _initController()
    {
    	$this->bootstrap('FrontController');
    	$controller = $this->getResource('FrontController');
       $modules = $controller->getControllerDirectory();
       $controller->setParam('prefixDefaultModule', true);

        $controller->registerPlugin(
               new Bluess_Modules_Loader($modules)
        );

        return $controller;
    }

Now the last method. which is a bit weird. And i am probably missing a key factor here. But if this method resource is not declared only the default module functions. When declared empty all modules function as they should. This would indicate that this method could be used to load the modules. But i haven’t found a way to achieve this yet. Except for loading all modules in a row. Which makes no sense for this purpose. So we leave it empty.

protected function _initModules()
    {
		// Call to prevent ZF from loading all modules
    }

The most important part here is the controller plug-in. This will be the place where module bootstraps are called from.

application/../library/Bluess/Modules/Loader.php

class Bluess_Modules_Loader extends Zend_Controller_Plugin_Abstract
{
	protected $_modules;

Setup the plug-in by passing the applications module list.

	public function __construct(array $modulesList)
	{
		$this->_modules = $modulesList;
	}

The dispatchLoopStartup method will be called on every request and will do the magic. Based on the current module name we create a new Zend_Application with the current modules config file module.ini. And we bootstrap it.

	public function dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
	{
		$module = $request->getModuleName();

		if (!isset($this->_modules[$module])) {
			throw new Exception("Module does not exist!");
		}

		$bootstrapPath = $this->_modules[$module];

		$bootstrapFile = dirname($bootstrapPath) . '/Bootstrap.php';
        $class         = ucfirst($module) . '_Bootstrap';
        $application   = new Zend_Application(
        	APPLICATION_ENV,
    		APPLICATION_PATH . '/modules/' . $module . '/configs/module.ini'
		);  

        if (Zend_Loader::loadFile('Bootstrap.php', dirname($bootstrapPath))
        	&& class_exists($class)) {
            $bootstrap = new $class($application);
            $bootstrap->bootstrap();
        }
	}
}

Now setup the default module. Once this is done it’s a nice example for further modules. Make sure the module has it’s own layout set.

application/modules/default/configs/module.ini

default.resources.layout.layout = “default”
default.resources.layout.layoutPath = APPLICATION_PATH “/modules/default/layout”

Setup the modules bootstrap and use it to set the modules model location.

application/modules/default/Bootstrap.php

class Default_Bootstrap extends Zend_Application_Module_Bootstrap
{
	protected $_moduleName = 'default';

	protected function _initConfiguration()
    {
		$options = $this->getApplication()->getOptions();

    	set_include_path(implode(PATH_SEPARATOR, array(
		    realpath(APPLICATION_PATH . '/modules/' . $this->_moduleName . '/models'),
		    get_include_path(),
		)));

		return $options;
    }
}

That’s all. Now make sure your layout is set correctly and the controllers are prefixed

application/modules/default/layout/default.phtml

echo $this->layout()->content;

application/modules/default/controllers/IndexController.php

class Default_IndexController extends Zend_Controller_Action
{

It took me a while to get this working like i had it in my mind. But it’s going the right way. If your interested in a working copy. You can download one here.

UPDATE

Matthew has a nice post about some do’s and don’ts concerning module based applications

Last Friday a friend approached me with a problem he was having. He was trying to setup a small webshop in a existing WordPress site. For the webshop he was using a plug-in called wp-e-commerce. He chose this plug-in because it is one of few that supports iDEAL payments. Because this shop only serves Holland the only payment option they need is iDEAL.

The iDEAL plug-in seemed to function properly. But the bank portal didn’t respond as expected. The first error i spotted was the mis configured referrer. The error code for this was.

unknown order/0/r

This didn’t solve the problem though. The message change from the previous to

unknown order/1/s

So i spend the next hours reading the manual he got from his bank. And came to the conclusion they do it just a bit different then for what this plug-in was written. The bank expects a hash to be send along each order made. This hash is build up from parts of the order and a secret string. This combined is hashed with the SHA-1 algorithm And added to the form as a hidden field. I wrote a small function to create hash and changed a few other small things in the order form.

The original form looks like this:

<script type="text/javascript">
var Amount = ;
var PSPID = "";
var AM;
if (isNaN(Amount)) {
	alert("Amount not a number: " + Amount + " !");
	AM = "";
} else {
	AM = Math.round(parseFloat(Amount)*100);
}
</script>
<form method='post' action='' id='ideal_form' name='ideal_form'>
<script type="text/javascript">
document.write("
");
document.write("
");
</script>
<INPUT TYPE="hidden" NAME="SHASign" VALUE="4FF8C2FB03B0AA45EA5DE9503AEACB6B603DCFCC">
<input type="hidden" NAME="orderID" value="" />
<input type="hidden" name="currency" value="" />
<input type="hidden" name="language" value="" />
<input type="hidden" name="accepturl" value="">
<input type="hidden" name="cancelurl" value="">
<!--customer information starts-->
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="ownerZIP" value="">
<input type="hidden" name="owneraddress" value="">
<input type="hidden" name="ownercty" value="">
<input type="hidden" name="ownertown" value="">
<input type="hidden" name="ownertelno" value="">
<!--customer information ends-->
<input type="hidden" name="PM" value="iDEAL" />

I didn’t really understand why some values were written by JavaScript. So i removed the JavaScript lines and added the fields to the form. And after adding the hash function statement it looks like this.

<form method='post' action='' id='ideal_form' name='ideal_form'>

<input type="hidden" NAME="PSPID" value="" />
<input type="hidden" NAME="orderID" value="" />
<input type="hidden" NAME="amount" value="" />
<input type="hidden" name="currency" value="" />
<input type="hidden" name="language" value="" />
<input type="hidden" name="accepturl" value="">
<input type="hidden" name="cancelurl" value="">
<!--customer information starts-->
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="ownerZIP" value="">
<input type="hidden" name="owneraddress" value="">
<input type="hidden" name="ownercty" value="">
<input type="hidden" name="ownertown" value="">
<input type="hidden" name="ownertelno" value="">
<!--customer information ends-->
<input type="hidden" name="PM" value="iDEAL" />

echo createSHA1Hash(array(
		$purchase_log[0]['id'],
		($amount*100),
		get_option('ideal_currency'),
		get_option('ideal_id'),
		'[SHA1-IN-HASH]'
	));

</form>

The function i can be placed anywhere in the page. Or a include file. Here’s the code. The only thing that has to be done is replace [SHA1-IN-HASH] with the Hash configured in the bank’s ideal admin.

function createSHA1Hash($hashOptions) {
        $str = implode('', $hashOptions);

        return '
';
    }

While doing some searches i noticed there are more people having issues with this plug-in. So maybe this will save somebody a bit of time.

Last week i had the chance to work with memcache. Something i hadn’t done before. For caching i mostly rely on APC for bytecode. And file based caching for content. Using memecache extension for PHP and de memcached service gives a whole range of features for caching data. And an easy way to manage all this cached data.

The project i am working on is based on Zend Framework. And there for this post will reflect working with memcache in ZF only. With ZF and memcache it’s possible to do frontend and backend caching. I will focuse on the backend side for now. But will setup the frontend as well.

If you don’t have memcache installed do it now. It’s not that hard. On my debian box it went somethign like this:

$ aptitude install memcached
$ aptitude install php5-memcache

Now a days evrything seems to go automatic. So no need to edit the php.ini or anyhting. To check if PHP loaded the memcache extension you can do:

$ php -m | grep memcache
memcache

Memached is automatically started after install. So let’s check if everything went ok.

$ ps -aux | grep memcached
nobody 20965 0.0 0.5 42900 23072 ? S Jan28 0:01 /usr/bin/memcached -m 64 -p 11211 -u nobody -l 127.0.0.1
root 22393 0.0 0.0 87940 776 pts/0 R+ 12:06 0:00 grep memcached

$ netstat -an | grep 11211
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN

Looking good. Now it’s time to do some configuration in ZF.

First of the frontend settings. With ‘type’ we set the cache method for the frontend. We chose the standard Core class for this. With ‘lifetime’ we set the time for which a cached entity is valid. The ‘cache_id_prefix’ is a nice way to group for instnace cache data by controller. So just give it a name.

cache.frontend.type = Core
cache.frontend.options.lifetime = 600
cache.frontend.options.automatic_serialization = true
cache.frontend.options.cache_id_prefix = [some string]
cache.frontend.options.cache = true

Now it’s the backends turn to get configured. For ‘type’ we choose Memcached. More types are available. For more info read the ZF manual. The rest of the settings are basic memcached settings like host, port and persitance.

cache.backend.type = Memcached
cache.backend.options.servers.1.host = 127.0.0.1
cache.backend.options.servers.1.port = 11211
cache.backend.options.servers.1.persistent = true
cache.backend.options.servers.1.weight = 1
cache.backend.options.servers.1.timeout = 5
cache.backend.options.servers.1.retry_interval = 15

Finally we can do some PHP code. To get the cache instance setup we add a _initCache() method to the bootstrap class. Inside this method we retrieve the config options by calling getOptions(). And setup the cache object. Which is then stored in the Registry for later use.

protected function _initCache()
{
        $options = $this->getOptions();

        if (isset($options['cache'])) {
            $cache = Zend_Cache::factory(
                $options['cache']['frontend']['type'],
                $options['cache']['backend']['type'],
                $options['cache']['frontend']['options'],
                $options['cache']['backend']['options']
            );

            Zend_Registry::set('cache', $cache);
            return $cache;
        }
}

That’s all set. I used the caching for some REST service responses. So i will stick to that in this post as well. The class has a method for adding a cache object.

public function setCache(Zend_Cache_Core $cache) {
    $this->cache = $cache;
}

So fetching the cache instance and passing it to the REST client will look something like this:

$cache = Zend_Registry::get('cache');
$cache->setLifetime(86400);

$client = new Client();
$client->setCache($cache);

The first thing we do inside the calling method is set a unique key for the cache entry.

$cache_id = 'getPage_' . $this->getDomain()
            . $this->getPageName()
            . $this->getCountry();

Then we check if the cache object is set. If that’s the case we check to see if the unique key is already available in the cache.

if (!isset($this->cache) || !($ret = $this->cache->load($cache_id))) {

If a value is returned from the cahce we will return it. If not then we will do the webservice call and store the return data in cache.

 $ret = $this->restClient->call('getPage', array());

if (isset($this->cache)) {
    $this->cache->save($ret, $cache_id);
}

The complete method looks something like this.

protected function getPageFromWebservice()
{
        $cache_id = 'getPage_' . $this->getDomain()
            . $this->getPageName()
            . $this->getCountry();

        if (!isset($this->cache) || !($ret = $this->cache->load($cache_id))) {
            $ret = $this->restClient->call('getPage', array());

            if (isset($this->cache)) {
                $this->cache->save($ret, $cache_id);
            }
        }
        return $ret;
}

That’s all. It’s pretty basic stuff. But so cool!