Trap events

If you have cronjobs running to trigger a queue, you probably would like to take care that queue is not triggered multiple times, e.g. when the previous run is not finished yet. This can easily be done using a lock file which is written upon the next queue run and removed when it is done. So far, so good.

But what happens if the server crashed, or some Admins are restarting the VMs once a week to “solve strange problems”? Then you have to take care that the lock file is removed, otherwise your queue might not run again upon restart.

On Linux, this is very easy due to the handy “trap” command:

trap 'rm -f "my_lock_file.lock" >/dev/null 2>&1' EXIT HUP KILL INT QUIT TERM

The rm command that removes the log file is executed when either the EXIT, HUP, KILL, INT, QUIT or TERM signal is send. Now we don’t have to delete the file manually after a shutdown.

Accessing the ServiceManager from the ViewHelperManager in ZF2

Sometimes the new ServiceManager(s) in Zend Framework 2 are a bit confusing. We don’t have one, we have several instances.

So recently I was writing a factory for a ViewHelper and wanted to access the application configuration from there. As usual, I was attempting it like this

    /**
     * @param ServiceLocatorInterface $serviceLocator
     * @return MyConfiguration
     */
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        $instance       = new MyConfiguration();
        $configuration  = $serviceLocator->get('configuration');

        // haha - nope!

        if(!empty($configuration['whatever'])) {
            $instance->setConfiguration($configuration['whatever']);
        }

        return $instance;
    }

It ended up throwing an exception, saying the configuration could not be found. To make it short, after some searching I found this one

$serviceManager = $serviceLocator->getServiceLocator();

Intuitive, isn’t it? But it seems to work, so the factory looks like this now:

     /**
     * @param ServiceLocatorInterface $serviceLocator
     * @return MyConfiguration
     */
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        $serviceManager = $serviceLocator->getServiceLocator();
        $instance       = new MyConfiguration();
        $configuration  = $serviceManager->get('configuration');

        if(!empty($configuration['whatever'])) {
            $instance->setConfiguration($configuration['whatever']);
        }

        return $instance;
    }

Pitfall: php_admin_flag vs. php_flag

Today I was almost going crazy about the PHP ini setting “display_errors”, which just couldn’t be convinced to be “On”. After some searching on the Internet without a result (“Must be an undiscovered bug … dammit”) I was about to give up. Hey, what do we have an error log for? But then good-old intuition stroke again – how about the vhost configuration?

Bingo:

php_admin_flag display_errors off

Who the f…? Well, me of course! I copied a bunch of these statements when taking another vhost configuration file as template, without having a closer look.

“php_admin_flag” is surely nice for hosters etc., because it sets the PHP ini value once and for all. That’s probably tricky, because ini_set() will simply return false, with no more information.

Note to myself: if setting ini values via vhost is really needed, better use “php_flag” instead. This way the value can still be overwritten.