PHP Directory

Blogs

  • PHP 5.5.17 is available

    The PHP development team announces the immediate availability of PHP 5.5.17. Several bugs were fixed in this release. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.17 please visit our downloads page, Windows binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
  • Learning a New Codebase

  • ZgPHP Conference 2014 – Free Entry

    For almost three years now, there has been a regular and well attended monthly PHP meetup in Zagreb, Croatia. October 2nd 2014 marks the third anniversary of this meetup, and in the spirit of last year, a one-day conference has been organized to commemorate the event.

    This year’s conference, however, will be a bit different.

    Continue reading %ZgPHP Conference 2014 – Free Entry%

  • There is a microservice for that

    At Qandidate.com we recently shifted our development process towards building microservices. We’re constantly looking to improve our way of writing software. For example, moving from CRUD applications to event-sourced applications and using Kanban to manage our process. Microservices seem to be the next step.

    So far we encountered a number of advantages of working with microservices, and we would like to share our findings with you. Note that we don't run many microservices in our production environment yet. Who knows how we will be developing software in six months!

    ∞ labs @ Qandidate.com Permalink

  • Deployment with Zend Server (Part 6 of 8)

  • Deployment with Zend Server (Part 5 of 8)

    This is the fifth in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed how to secure your Job Queue job scripts.

    Today, I'm sharing some best practices around writing job scripts, particularly around how to indicate execution status.

    Tip 5: Set your job status

    You should always set your job script status, and exit with an appropriate return status. This ensures that Job Queue knows for sure if the job completed successfully, which can help you better identify failed jobs in the UI. I use the following:

    
    // for failure:
    ZendJobQueue::setCurrentJobStatus(ZendJobQueue::FAILED);
    exit(1);
    
    // for success:
    ZendJobQueue::setCurrentJobStatus(ZendJobQueue::OK);
    exit(0);
    

    I also have started returning relevant messages. Since Job Queue aggregates these in the UI panel, that allows you to examine the output, which often helps in debugging.

    
    exec($command, $output, $return);
    header('Content-Type: text/plain');
    if ($return != 0) {
        ZendJobQueue::setCurrentJobStatus(ZendJobQueue::FAILED);
        echo implode("\n", $output);
        exit(1);
    }
    
    ZendJobQueue::setCurrentJobStatus(ZendJobQueue::OK);
    echo implode("\n", $output);
    exit(0);
    

    Here's sample output:

    (The [0;34m]-style codes are colorization codes; terminals capable of color would display the output in color, but Zend Server, of course, is seeing plain text.)

    In sum: return appropriate job status via the ZendJobQueue::setCurrentJobStatus() static method and the exit() code, and send output to help diagnose issues later.

    Next time...

    The next tip in the series discusses setting up page caching in Zend Server, as well as creating jobs to clear page caches.

    Other articles in the series

    I will update this post to link to each article as it releases.

  • Deployment with Zend Server (Part 4 of 8)

    This is the fourth in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed a trick I learned about when to execute a chmod statement during deployment.

    Today, I'm sharing a tip about securing your Job Queue job scripts.

    Tip 4: Secure your job scripts

    In the second tip, I detailed when to register job scripts, but not how to write them. As it turns out, there's one very important facet to consider when writing job scripts: security.

    One issue with Job Queue is that jobs are triggered... via the web. This means that they are exposed via the web, which makes them potential attack vectors. However, there's a simple trick to prevent access other than from Job Queue; add this at the top of your job scripts:

    
    if (! ZendJobQueue::getCurrentJobId()) {
        header('HTTP/1.1 403 Forbidden');
        exit(1);
    }
    

    While the jobs are invoked via HTTP, Zend Server has ways of tracking whether or not they are being executed in the context of Job Queue, and for which job. If the ZendJobQueue::getCurrentJobId() returns a falsy value, then it was not invoked via Job Queue, and you can exit immediately. I like to set a 403 status in these situations as well, but that's just a personal preference.

    Next time...

    The next tip in the series is builds on this one, and gives some best practices to follow when writing your job scripts.

    Other articles in the series

    I will update this post to link to each article as it releases.

  • Deployment with Zend Server (Part 3 of 8)

    This is the third in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed creating recurring jobs via Zend Job Queue, à la cronjobs.

    Today, I'm sharing a very short deployment script tip learned by experience.

    Tip 3: chmod

    In the first tip, I detailed writing deployment scripts. One of the snippets I shared was a chmod routine:

    
    $command = 'chmod -R a+rwX ./data';
    echo "\nExecuting `$command`\n";
    system($command);
    

    The code is fine; what I did not share is where in the deployment script you should invoke it. As I discovered from experience, this is key.

    Zend Server's deployment scripts run as the zend user. If they are writing any data to the data directory, that data is owned by the zend user and group -- and often will not be writable by the web server user. If you have scheduled jobs that need to write to the same files, they will fail... unless you have done the chmod after your deployment tasks are done.

    So, that's today's tip: if you need any directory in your application to be writable by scheduled jobs, which will run as the web server user, make sure you do your chmod as the last step of your deployment script.

    Next time...

    The next tip in the series is another short one, and will detail how to secure your Job Queue job scripts.

    Other articles in the series

    I will update this post to link to each article as it releases.

  • Deployment with Zend Server (Part 2 of 8)

  • Deployment with Zend Server (Part 1 of 8)

:: Our Favorites

Featured Sites Using PHP

>Atlanta Real Estate