Evert PotAn XML library for PHP you may not hate. (1.4.2015, 20:29 UTC)

If you are a PHP programmer, chances are that you will need to write and parse XML from time to time. You may even consider this a good thing. Chances are though that dealing with XML has caused you to flock to JSON.

But XML has advantages, and sometimes you simply don't have an option.

I myself have gone through several stages of this. Back in the day everybody used expat because it was fast. I switched to simplexml because it had a friendlier API, and I used the DOM when I needed access to a wider range of XML features. I've also simply created XML output by concatenating strings.

But ever since PHP shipped with XMLReader and XMLWriter I've wondered if it was a better fit. Early on I was deterted several times due to these objects not being very stable.

The XMLReader and XMLWriter objects are nice, but in order to effectively use them, they need a sort of design pattern. I've experimented with this concept off and on since 2009, and finally landed on something I'm reasonably happy with.

A few people have randomly stumbled upon this experiment and I got mostly positive feedback. Today I wanted to show it off to everyone. I've iterated on the base concept for several years, and tweaked it every time to get a sort of 'good enough' api that behaves reasonably sane in various scenarios.

The library is called sabre/xml, and I hope people are willing to kick its tires and give some feedback.

How it works

sabre/xml extends the XMLReader and XMLWriter class and adds a bunch of functionality that makes it quick to generate and parse xml.

By default it parses from/to PHP arrays, which is great for quick one-shot parsers/writers, but the biggest feature is that it allows you to intuitively map XML to PHP objects and vice-versa.

This gives this XML library a distinct advantage. It's very easy to get started, but its design pattern still works for more complex XML application.

The one caveat is that reading and writing are single-pass by design. Unlike the DOM, you can't load in a document, make a small modification and save it again.

Writing XML in a nutshell


$xmlWriter = new Sabre\Xml\Writer();
$xmlWriter->namespaceMap = ['http://example.org' => 'b'];

$xmlWriter->write(['{http://example.org}book' => [
    '{http://example.org}title' => 'Cryptonomicon',
    '{http://example.org}author' => 'Neil Stephenson',



<?xml version="1.0"?>
<b:book xmlns:b="http://example.org">
 <b:author>Neil Stephenson</b:author>

As you can see, you can quickly generate complex xml from simple array structures.

Instead of serializing strings, you can also serialize objects. There's a

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

SitePoint PHP7 Ways to Optimize Jenkins (1.4.2015, 19:30 UTC)

This article was sponsored by *CloudBee*s. Thank you for supporting the sponsors who make SitePoint possible!

The Jenkins Logo

Jenkins is a great tool for continuous integration and continuous delivery. In previous articles we’ve learned how to set up Jenkins for quality assurance and looked at one particularly useful plugin for supercharging your processes. In this article, we’ll guide you through seven ways to make sure you use Jenkins efficiently.

This article is based on a presentation given by Jenkins contributor Andrew Bayer at a 2014 Jenkins User Conference and is adapted here with permission.

1. Make sure Jenkins is stable and working correctly

Jenkins releases new versions frequently. It’s recommended to always use the latest Long-Term Support (LTS) release and avoid the updates in-between. The LTS release is tested by the Jenkins project.

The same kind of rule also applies to plugins. They don’t have LTS releases, but many updates can occur. In general you should stick to the rule: If it’s working, don’t update it. New updates can make features unstable. Furthermore, any given plugin may behave differently than expected.

Also make sure you create backups of your Jenkins server. You could back-up all data, but that will cost you a lot of time and resources. Instead, you could decide to only back-up your config files through scripts like this.

2. Don’t fill Jenkins with bloat

There are a couple of simple things you can do to avoid being the owner of a bloated Jenkins installation:

  1. If you have a lot of teams or projects, you might create multiple Jenkins masters. For example, you could create a master for PHP projects and a separate one for Android projects. Doing this will ensure that changes don’t affect all projects and that you have only the plugins needed on a specific master for each project.

  2. Break your jobs into multiple smaller jobs. Nothing is more annoying than a long build failing somewhere at the end. If you break your jobs into smaller jobs, you can easily restart one if it fails. The Workflow plugin is useful for this purpose. If you’re interested in a more in-depth explanation of the Workflow plugin, have a look at our recent product review.

3. Automate Jenkins

Jenkins comes with an integrated script console, allowing you to execute commands on the server. It’s a handy tool to debug Jenkins or to find information you need.

An interesting plugin is the Scriptler plugin. With this plugin, you can save your favorite scripts for later reuse. You can also find an online script catalog here with predefined scripts like clearing the job queue.

For each build, you can also write your own build steps in the Groovy language. This gives you more flexibility within your job, but it also means you’ll need to be more careful, because it gives you more control. You can also run scripts from the Scriptler catalog as a build step.

If you have a lot of projects, consider generating jobs automatically. Jenkins comes with a great REST API and a CLI tool to create new jobs. You can also dive into plugins like Workflow which we discussed recently to automate certain parts of the process, or the Cloudbees Temp

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

SitePoint PHPLaravel Blade Recursive Partials with @each (1.4.2015, 16:00 UTC)

In this tutorial, we’ll go through the process of implementing recursive partials in Laravel’s Blade templating engine by means of the @each command. This will allow us to render data structures with an arbitrary number of nested children without needing to know the maximum depth of the array.

The Data

The data I’m talking about is data like folder structures which can go deep into many levels. For our case, let’s imagine we’re dealing with a predefined data set of “Projects” in a todo application like Todoist. Feel free to grab the sample data from this gist or the code embed below:

Continue reading %Laravel Blade Recursive Partials with @each%

Davey Shafik[Slides] PHP: Under The Hood (ConFoo 2015) (1.4.2015, 15:00 UTC)

Presented 2/20/2015 at ConFoo 2015 in Montreal, Canada

Zeev SuraskiNightly builds for PHP 7.0 now available! (1.4.2015, 10:12 UTC)
For the many people that are interested in testing PHP 7 themselves - I have some good news.

We're now building the latest source snapshot of PHP 7 every night and posting it on http://php7.zend.com/.  Currently we're building tarballs for RHEL/CentOS and Debian/Ubuntu, but we'd be looking to add both .rpm and .deb installable packages as well as Mac and Windows builds.

Feedback welcome!

Paul M. JonesSeparate The User Interface Repository From The Core Application Repository (31.3.2015, 16:26 UTC)

tl;dr: Keep the core application (“model”, “domain”) code repository separate from the user interface (“controller/view”, “action/responder”) code repository; use a dependency manager in the user-interface repo to bring in the core-application repo.

Nihal Sahu asked on Twitter, “How do you ‘personally’ go about building an application? What Structure?” This post is my longer-than-140-characters response.

Obviously I’m a fan of Action-Domain-Responder as a pattern for web-based user interfaces. (ADR treats the request/response cycle itself as a user interface. The HTML/CSS/JS/etc that goes into the HTTP body is just one part of the presentation half of the user interface; ADR reminds us that the HTTP headers are part of the presentation, too.)

But ADR, and MVC, and the other user-interface patterns – they are not an application architecture in and of themselves. The “Domain” in ADR and the “Model” in MVC are just entry points into the underlying core of the overall application architecture. In a way, the “Action/Responder” and “Controller/View” portions of the UI are not the big deal in the application; the big deal is the underlying core. That’s where the real work happens.

With that in mind, one first thinks the right approach would be to separate the User Interface from the Core Application. This is obvious and uncontroversial; separation of concerns is a central tenet of good architecture.

What might be controversial is my extended advice regarding that approach. I don’t suggest a merely “logical” separation of concerns so that Action/Controller classes don’t have Domain/Model code in them. I suggest a “physical” separation. In other words:

Separate the User Interface repository from the Core Application repository.

Yes, I mean that you should have two code repositories for your application. Let’s explore that idea for a minute.

The first repository, the Core Application one, contains no user-interface code at all. No HTTP, no standard input/output, nothing. It expects to receive input in an interface-independent way, and it delivers output in an interface-independent way. Note that it receives the input. It has to be sent to the Core Application in some way, not read from the interface (no superglobals!). The injected input could be via method parameters, a plain old PHP array, an input object provided by the Core Application, a Command object provided by the Core application, etc. Likewise, the output could be via anything provided by the Core Application, such as a Model object, a Domain Payload, or something else. It is completely independent from any user interface code and can be tested on its own.

The other repository, the User Interface one, contains your “Action/Responder” or “Controller/View” (or “Command/Stdout”) code. There is no business logic at all. All it does it reformat the user input to something the Core Application will recognize, pass it to the Core Application, and receive back some output from the Core Application, which it reformats for presentation to the user.

But if the two repositores are “physically” separated, how can the User Interface get access to the Core Application? Composer becomes your best friend in this case. In the User Interface codebase, add "require": { "project-name/core-application": "dev-develop" } to composer.json. Issue composer update and voila: your Core Application is now available to the User Interface. The User Interface depends on the Core Applicatiion, but the Core Application has no dependency on the User Interface.

What’s great about keeping the repositories fully separated from each other is that it enforces developer discipline. It becomes difficult to put Core Application code in the User Interface code. Any attempts to do so are immediately obvious, and everyone watching can see it happening. It becomes harder to justify to yourself “I’ll add it just this one time” (and thus keeping off that particular slippery slope).

The tradeoff is that you now have to coordinate changes across two code repos. Breaks in the Core Application will break the User Interface. The disconnection can be a positive overall, since you can version the Core Application separately from the User Interface, but in practice it does mean you have to be more attentive to change management.

One more thing about keeping the User Interface “physically” separate from the User Interface in this way is that you start thinking differently about frameworks. I have begun to think that our vocabulary for describing frameworks in PHP land is insufficiently varied. MVC and ADR do not describe “application frameworks” – they might describe User Interface frameworks, but there’s no word for Core Application frameworks. Maybe they need their own separate framework term.

Davey Shafik[Slides] PHP 5.NEW: The Best Bits (ConFoo 2015) (31.3.2015, 14:00 UTC)

Presented 2/20/2015 at ConFoo 2015 in Montreal, Canada

Derick RethansXdebug 2.3: Improvements to Tracing (31.3.2015, 08:12 UTC)

Xdebug 2.3: Improvements to Tracing

This is the fifth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

In this instalment we are going to have a look at the additions to the trace file functionality. Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit).

Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting. Existing options are 1/2 for just the variable type, 3 for a string description, and 4 for a string description and a variable name. Xdebug 2.3 now also features a base64 encoded serialized representation of the variable's contents (option 5). Which means that the following lines:

$a = array(1, "foo", M_PI);

show up in the following 5 ways with different variations of the xdebug.collect_params setting:

  1. var_dump(array(3))

  2. var_dump(array(3))

  3. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  4. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  5. var_dump(YTozOntpOjA7aToxO2k6MTtzOjM6ImZvbyI7aToyO2Q6My4xNDE1OTI2NTM1ODk3OTMxO30=)

This is probably more useful with the computerized trace files that are easier to parse.

In Xdebug 2.3, normal (human readable) trace files now also show the time index and memory usage for function exit lines. Function exit lines are generated when xdebug.collect_return is set to 1. Which means that with with Xdebug 2.2 you would see:

TRACE START [2015-03-28 18:48:39]
  0.0008     275928   -> test1() …/closure-trace.phpt:27
  0.0008     276848     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     277168       -> strlen() …/closure-trace.phpt:21
                           >=> 3
                         >=> 3
                       >=> NULL
  0.0010     276056   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0010     276184
TRACE END   [2015-03-28 18:48:39]

But in Xdebug 2.3 you instead see:

TRACE START [2015-03-28 18:48:45]
  0.0008     269144   -> test1() …/closure-trace.phpt:27
  0.0009     270096     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     270336       -> strlen() …/closure-trace.phpt:21
  0.0010     270504        >=> 3
  0.0010     270216      >=> 3
  0.0010     269264    >=> NULL
  0.0011     269264   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0011     269384
TRACE END   [2015-03-28 18:48:45]

This makes it easier to see how much time and memory a specific function call took, similarly to what already was shown for "computerized" trace files.

And lastly, the computerized format (xdebug.trace_format=1), has now support for showing return values as well. The return value is part of a new "frame" for a function.

Take the following invocation of PHP:

php -dxdebug.collect_params=0 -dxdebug.collect_return=1 \
        -dxdebug.trace_format=1 \
        -r '$a = array(1, "foo", M_PI); xdebug_start_trace("/tmp/trace"); echo
        serialize($a);' \
>/dev/null && cat /tmp/trace.xt

In Xdebug 2.2 this shows:

TRACE START [2015-03-29 00:08:34]
2    1    1    0.000417    267192
2    2    0    0.000547    266848    serialize   0   Command line code   1   1 

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

Cal EvansInterview with David Stockton (31.3.2015, 05:00 UTC) Link
SitePoint PHPWelcoming New Authors: January – March 2015 (30.3.2015, 16:00 UTC)

With a new schedule and regime, we changed the author introduction post to a once per three months frequency rather than every other month like it was. As March is drawing to an end (already?!), let’s see which new souls joined us in this era of peer review. We’ll also use this opportunity to mention our newest regular authors.

Regular Authors

We’ve seen an influx of increased enthusiasm from our most prolific members. The first two who get to pin this medal to their chest are as follows:

Younes Rafie, Morocco

Younes has been with us for a while, and has been aiming for the regular author position since Q3 2014. When a man knows what he wants, there’s little that will stand in his way, and Younes grabbed the opportunity by the throat. In 2014, he was one of our most prolific authors and in 2015 he only increased his output, always keeping quality and interesting topics in mind. I take great pride in being able to welcome him into the regulars circle, and I feel like he’s just getting started.

So far (in 2015), Younes published a whopping six posts and two quick tips. Keep up the great work!

Daniel Sipos, Belgium

Danny has been our Drupal expert since the day he joined. If anything was going on in the Drupal world we should know about, he was right on top of it, keeping everyone up to date and preparing the readership for Drupal 8’s imminent release. Danny earned his “R” badge in March, and starting with April, he’ll be a part of the regular circle.

Danny’s contributions not only to our Drupal corprus but also to the peer review process have been invaluable. He reviewed countless articles, shot pull requests left and right, and even made important suggestions for improving the entire workflow.

Danny’s 2015 portfolio counts five posts with more incoming. Excellent work!

New Authors

Apart from the regulars increasing their output, we’ve also had room to welcome some new souls on board. They are, in order:

Continue reading %Welcoming New Authors: January – March 2015%

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