SitePoint PHPWhat to Expect from Yii 2.0 (20.9.2014, 16:00 UTC)

Yii 2.0 was released into beta last April and the goal for a first stable release was set for the middle of 2014. The GitHub issue list has 300 open issues and 2913 closed while I’m writing this and both numbers are still increasing. The progress to the 2.0RC milestone was at 99%. My guess is that the team is close, but we’ll probably have to wait just a little bit longer. While we’re all waiting, lets take a look at what we can expect by looking at an already available example.

A tiny bit of history

The first version of Yii became popular quite fast after it was released in 2008. It’s founder, Qiang Xue, previously worked on the Prado framework and used experience and feedback from that to build Yii.

Yii uses many ideas from other frameworks, languages and libraries: Prado, Ruby, jQuery, Symfony and Joomla are all acknowledged as sources of inspiration.

The first commits for Yii 2.0 date back to 2011 but the development picked up last year. The team did a rewrite with an aim to become the state of the art new generation PHP framework. It adopts the latest technologies and features, such as Composer, PSR, namespaces, traits, and more.

Something worth mentioning is that according to the download page Yii version 1.1 support will end on December 31, 2015, so we do get some time to start thinking about making the transition.

Requirements

Continue reading %What to Expect from Yii 2.0%

Link
Thomas WeinertFluentDOM 5.1 - New Features (20.9.2014, 13:18 UTC)
FluentDOM 5.1 is now available. Here are some of the highlights:

Functors 

The classes can now be called as functions to navigate in a DOM with XPath expressions. The following example fetches all link hrefs attributes from an HTML page:
$dom = new \FluentDOM\Document();
$dom->loadHTMLFile('http://fluentdom.org/');

$links = [];
foreach ($dom('//a[@href]/@href') as $href) {
  $links[] = (string)$href;
}


This works for most of the nodes in a DOM. 

Creator

The new Creator class provides short syntax to create DOM nodes. More detailed information can be found in the wiki.
$_ = FluentDOM::create();
echo $_(
  'ul',
  ['class' => 'navigation'],
  $_('li', 'FluentDOM')
);

XML To JSON

Several serializers/loaders for JSON where added. JSONML, Rayfish, BadgerFish and RabbitFish are supported.
echo "XML -> JsonML\n\n";
$json = json_encode(
  new FluentDOM\Serializer\Json\JsonML($dom), 
  JSON_PRETTY_PRINT);
echo $json;

echo "\n\nJsonML -> XML\n\n";
echo FluentDOM(
  $json, 'application/jsonml+json')->formatOutput();

The Release

Link
SitePoint PHPHow to Deploy Symfony Apps with Capifony (19.9.2014, 16:00 UTC)

Say you have a Symfony application. At some point, you would like to deploy it to your server and show it to the world. Of course, you can do it all manually, but these days you can also choose to use a tool like Capifony.

If you have developed Ruby applications in the past, you are perhaps familiar with Capistrano. Capistrano is a tool to deploy your Ruby application to your server. Capifony has been created on top op Capistrano is basically a collection of deployment recipes.

In this article, we are going to deploy a Symfony application to a server with Capifony.

How does Capifony work?

Before we start, it’s important to understand how Capifony works. By running the deploy command, Capifony runs certain commands performing different tasks. For example, it will download composer, install the dependencies and clear the cache.

The directory structure is very important. Capifony needs two directories and one symlink. The first directory it needs is called releases. Every time you deploy, a new directory is created within this directory. Capifony pulls in your git repository and runs all commands on this newly created directory.

The second directory is named shared. You can imagine that some directories are shared between releases. For instance, if you allow people to upload images, you want to make sure that these files are shared between releases. These directories and files are typically stored in the shared directory.

Next to these two directories, we have a symlink called current. This symlink points to the latest successful release. So, when you deploy a new version, a new directory will be created within the releases directory. If all tasks succeed on this directory, the current symlink will point to this new version.
You should point your web server to read from this symlink so it always uses the correct, latest version.

Continue reading %How to Deploy Symfony Apps with Capifony%

Link
SitePoint PHPPhpStorm 8 Released – See What’s New and Grab a Free License (19.9.2014, 16:00 UTC)

This week marks the release of PhpStorm 8. It’s no secret PhpStorm has been a long personal favorite of mine after having won me over from Zend Studio, Netbeans and Sublime Text, and we’ve covered the tool extensively before, most notably with the shortcuts guide by yours truly. By following the EAPs, we also taken a look at the new features in PhpStorm 8 before it even came out. Now that the day has finally come, let’s see what else is included, and finish up with a giveaway of free licenses.

Continue reading %PhpStorm 8 Released – See What’s New and Grab a Free License%

Link
Nomad PHPDecember 2014 – US (19.9.2014, 00:01 UTC)

Tuning Nginx and PHP-FPM... The Right Way.

Presented By
Evan Coury
December 18, 2014 20:00 CST

The post December 2014 – US appeared first on Nomad PHP.

Link
Nomad PHPDecember 2014 – EU (19.9.2014, 00:01 UTC)

Practical Message Queueing Using RabbitMQ

Presented By
James Titcumb
December 18, 2014 20:00 CET

The post December 2014 – EU appeared first on Nomad PHP.

Link
SitePoint PHPArdent: Laravel Models on Steroids (18.9.2014, 16:00 UTC)

One of the (few) things I don’t like about Laravel is that you cannot move the validation code from your controller to your models easily. When I write software I like to apply the “fat models, skinny controllers” principle. So, for me, writing the validation code in the controller is not a good thing.

To solve this, I’d like to introduce Ardent, a great package for Laravel 4. To be more precise, Ardent presents itself as “Self-validating smart models for Laravel Framework 4’s Eloquent ORM.” In other words: exactly what we need!

As you can imagine, it’s an extension of the Eloquent Model class, basically. This package comes with some new functionality, utilities and methods dedicated to input validation and other little things.

Our Test Application

For a better understanding of the advantages you can enjoy while using Ardent, we will set up a little test application. Nothing complicated: a simple To-Do List app.

Of course, I’m not going to implement a complete application: I just want to explain some principles, so I will make some controllers and models - no views. After that, I will “translate” the code using Ardent.

Our To-Do List will count two different entities:

  • User

    • id
    • first_name
    • last_name
    • email
    • password
  • Task

    • id
    • name
    • status (done / not done)

A really basic project. However, if you don’t want to write code, don’t worry: I have already prepared a migration that you can use to generate the database. Use it!

Continue reading %Ardent: Laravel Models on Steroids%

Link
labs @ Qandidate.comUsing HAProxy to offload SSL (18.9.2014, 14:01 UTC)

At Qandidate.com we started to use Docker containers to run our apps and REST APIs. Some of them are publicly exposed and should communicate over a secure connection. Of course we can config nginx in our containers to accept secure connections, but I want to show you how easy it is to use HAProxy to do the SSL offloading.

∞ labs @ Qandidate.com Permalink

Link
Matthew Weier O'PhinneyDeployment with Zend Server (Part 1 of 8) (18.9.2014, 13:30 UTC)

I manage a number of websites running on Zend Server, Zend's PHP application platform. I've started accumulating a number of patterns and tricks that make the deployments more successful, and which also allow me to do more advanced things such as setting up recurring jobs for the application, clearing page caches, and more.

Yes, YOU can afford Zend Server

"But, wait, Zend Server is uber-expensive!" I hear some folks saying.

Well, yes and no.

With the release of Zend Server 7, Zend now offers a "Development Edition" that contains all the features I've covered here, and which runs $195. This makes it affordable for small shops and freelancers, but potentially out of the reach of individuals.

But there's another option, which I'm using, which is even more intriguing: Zend Server on the Amazon Web Services (AWS) Marketplace. On AWS, you can try out Zend Server free for 30 days. After that, you get charged a fee on top of your normal AWS EC2 usage. Depending on the EC2 instance you choose, this can run as low as ~$24/month (this is on the t1.micro, and that's the total per month for both AWS and Zend Server usage). That's cheaper than most VPS hosting or PaaS providers, and gives you a full license for Zend Server.

Considering Zend Server is available on almost every PaaS and IaaS offering available, this is a great way to try it out, as well as to setup staging and testing servers cheaply; you can then choose the provider you want based on its other features. For those of you running low traffic or small, personal or hobbyist sites, it's an inexpensive alternative to VPS hosting.

So... onwards with my first tip.

Tip 1: zf-deploy

My first trick is to use zf-deploy. This is a tool Enrico and I wrote when prepping Apigility for its initial stable release. It allows you to create deployment packages from your application, including zip, tarball, and ZPKs (Zend Server deployment packages). We designed it to simplify packaging Zend Framework 2 and Apigility applications, but with a small amount of work, it could likely be used for a greater variety of PHP applications.

zf-deploy takes the current state of your working directory, and clones it to a working path. It then runs Composer (though you can disable this), and strips out anything configured in your .gitignore file (again, you can disable this). From there, it creates your package.

One optional piece is that, when creating a ZPK, you can tell it which deployment.xml you want to use and/or specify a directory containing the deployment.xml and any install scripts you want to include in the package. This latter is incredibly useful, as you can use this to shape your deployment.

As an example, on my own website, I have a CLI job that will fetch my latest GitHub activity. I can invoke that in my post_stage.php script:


if (! chdir(getenv('ZS_APPLICATION_BASE_DIR'))) {
  throw new Exception('Unable to change to application directory');
}

$php = '/usr/local/zend/bin/php';

$command = $php . ' public/index.php githubfeed fetch';
echo "\nExecuting `$command`\n";
system($command);

One task I always do is make sure my application data directory is writable by the web server. This next line builds on the above, in that it assumes you've changed to your application directory first:


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

Yes, PHP has a built-in for chmod, but it doesn't act recursively.

For ZF2 and Apigility applications, zf-deploy also allows you to specify a directory that contains the *local.php config scripts for your config/autoload/ directory, allowing you to merge in configuration specific for the deployment environment. This is a fantastic capability, as I can keep any private configuration separate from my main repository.

Deployment now becomes:


$ vendor/bin/zfdeploy.php mwop.net.zpk --configs=../mwop.net-config --zpk=zpk

and I now have a ZPK ready to push to Zend Server.

In sum: zf-deploy simplifies ZPK creation, and allows

Truncated by Planet PHP, read more at the original (another 933 bytes)

Link
Matthew Weier O'PhinneyDeployment with Zend Server (Part 2 of 8) (18.9.2014, 13:30 UTC)

This is the second in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed getting started with Zend Server on the AWS marketplace and using zf-deploy to create ZPK packages to deploy to Zend Server.

Today, I'm looking at how to created scheduled/recurring jobs using Zend Server's Job Queue; think of this as application-level cronjobs.

Tip 2: Recurring Jobs

I needed to define a few recurring jobs on the server. In the past, I've used cron for this, but I've recently had a slight change of mind on this: if I use cron, I have to assume I'm running on a unix-like system, and have some sort of system access to the server. If I have multiple servers running, that means ensuring they're setup on each server. It seems better to be able to define these jobs at the applicaton level.

Since Zend Server comes with Job Queue, I decided to try it out for scheduling recurring jobs. This is not terribly intuitive, however. The UI allows you to define scheduled jobs... but only gives options for every minute, hour, day, week, and month, without allowing you to specify the exact interval (e.g., every day at 20:00).

The PHP API, however, makes this easy. I can create a job as follows:


$queue = new ZendJobQueue();
$queue->createHttpJob('/jobs/github-feed.php', [], [
  'name'       => 'github-feed',
  'persistent' => false,
  'schedule'   => '5,20,35,40 * * * *',
]);

Essentially, you provide a URL to the script to execute (Job Queue "runs" a job by accessing a URL on the server), and provide a schedule in crontab format. I like to give my jobs names as well, as it allows me to search for them in the UI, and also enables linking between the rules and the logs in the UI. Marking them as not persistent ensures that if the job is successful, it will be removed from the events list.

The question is, where do you define this? I decided to do this in my post_activate.php deployment script. However, this raises two new problems:

  • Rules need not just a path to the script, but also the scheme and host. You _can_ omit those, but only if the script can resolve them via $_SERVER... which it cannot due during deployment.
  • Each deployment adds the jobs you define... but this does not overwrite or remove the jobs you added in previous deployments.

I solved these as follows:


$server = 'http://mwop.net';

// Remove previously scheduled jobs:
$queue = new ZendJobQueue();
foreach ($queue->getSchedulingRules() as $job) {
    if (0 !== strpos($job['script'], $server)) {
        // not one we're interested in
        continue;
    }

    // Remove previously scheduled job
    $queue->deleteSchedulingRule($job['id']);
}

$queue->createHttpJob($server . '/jobs/github-feed.php', [], [
  'name'       => 'github-feed',
  'persistent' => false,
  'schedule'   => '5,20,35,40 * * * *',
]);

So, in summary:

  • Define your rules with names.
  • Define recurring rules using the schedule option.
  • Define recurring rules in your deployment script, during post_activate.
  • Remove previously defined rules in your deployment script, prior to defining them.

Next time...

The next tip in the series is a short one, perfect for following the US Labor Day weekend, and details something I learned the hard way from Tip 1 when setting up deployment tasks.

Other articles in the series

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP