Michael KimsalWordPress security woes and plan of attack (31.7.2015, 19:33 UTC)

I’ve been involved in a few wordpress security snafus over the last 3-4 months – almost none of which were my doing directly, but I’ve still gotten involved anyway.  I’ve been disappointed, but not surprised, that even some commercial security and scanning services seem to miss rather obvious issues, and this sours me even more on the entire idea of using those commercial services in the first place.  A friend found the ‘social.png‘ issue on a server, and had scanned with maldet, clamav, bitdefender, and … I think.. sitelock.com service (not 100% sure on that one).  All of them failed to notice that a .png file had “eval(‘foo’)” PHP code in it.

To that end, I’m putting some restrictions/requirements on new wordpress projects that I get involved with:

  • fail2ban has to be installed and running
  • maldet/clamav (they have found some issues in the past)
  • all files and directories are not writeable – small shell script will make them writeable on demand for a few minutes, then revert all files/directories back to unwriteable shortly thereafter
  • blocking all outbound port 80 and 443 traffic via iptables, with a specific whitelist of exceptions.  I can’t think of but a handful of reasons why PHP code needs to initiate unrestricted outbound traffic (maybe I’m wrong?)


I’m picking on wordpress mostly because it’s the cleanup I’ve had to wrestle with the last few months, but there’s little reason that these don’t really apply to any web projects, really.  The one that came up this week is on a managed server (“you can’t have root because you might do something to compromise security… but go ahead and install wordpress and do whatever you want”), and they called out and said “hey, you’re infected”.  but… as a managed service that I don’t even have shell access to, doesn’t the managed server company bear some responsibility for preventing these sorts of situations in the first place?  At >$500/month, I expected better service (wasn’t my client, wasn’t my hosting company choice, I’m just now being looped in because of the exploits).

There’s 2 main issues at play:

1.  bad code allows PHP code to be written in to world-accessible URLs to be executed

2.  the executed code can then talk to other servers on the internet, typically over ports 80 or 443

Stopping public folders from being writeable and stopping unrestricted outbound traffic both seem to go a long way to preventing these two issues.

Am I missing something?  Don’t say “go get wordfence” or something similar.  Well, you can say it, but… that is really only addressing a subset of potential issues.  I wouldn’t say no to something like wordfence on top of these other steps, but .. that doesn’t address a joomla project, or drupal projects, or whatever.

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

SitePoint PHPThe State of Accessibility in PHP Tools (31.7.2015, 16:00 UTC)

Usually when I tell people that I’m blind, many people ask me how I can use the computer. “Is someone reading you my messages?” I remember someone asking. Many people imagine that I have this super-nifty speech recognition software that I can just talk to, and it would do anything, even write code. Imagine dictating code to a speech recognition system!

I gave an answer on Quora, to someone who had asked How does a visually impaired computer programmer do programming? I recommend you go through that answer to have a better context on what I’ll be talking about in this post. As is my habit, though, I’ll still point out the important bits here, so if you don’t feel like clicking on that link, don’t worry!

Before I get to the comparison, allow me to give you a few facts so that we are all on the same page. Feel free to skip forward if you already know these points, but I’ve found that a lot of people don’t, and I’m going to start with those.

How do the blind use computers?

They use screen readers. As the name implies, these applications read the screen through synthesized speech, and they also have an optional Braille output through a Braille display. Both of these options (speech and Braille) have to go through the screen reader, though, so if the screen reader can’t see the content, it can’t display it through either of these outputs.

How do you type? How do you use the mouse?

The answer to both these questions is, “through the keyboard”. Our screen readers have very specialized keystrokes that allow us to move the mouse, click, hover on an item, and jump around in web documents (by links, h1-6 headings, lists and list items, form fields and many more).

Continue reading %The State of Accessibility in PHP Tools%

Ilia AlshanetskyKitchener - FrontEdge - Browser Performance Slides (31.7.2015, 03:25 UTC)
My slides from the FrontEdge user group talk on Browser Performance are available here. Thanks to everyone who attended and I especially enjoyed the many engaging questions ;-)
Davey ShafikAn Exceptional Change in PHP 7.0 (31.7.2015, 01:53 UTC)

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch.

But with this change, comes a whole new exception hierarchy:

View this code snippet on GitHub.

At the top we now have an interface, \Throwable, which the original \Exception implements. Earlier versions did not have the interface and the root of the hierarchy was \Exception. We then have the new \Error exception, which is a sibling of \Exception as opposed to extending it, which also implements the new interface.

The reason \Error does not extend \Exception is so that the new exceptions will not get accidentally caught by legacy catch-all statements (catch (\Exception $e) { }) — and just like in older PHP versions, an uncaught exception is still a regular fatal error, preserving backwards compatibility.

If the ability to create a real catch-all is desired, you can catch the \Throwable interface. This means that to catch both regular exceptions, and engine exceptions, you would use catch (\Throwable $e) { } instead.

Error Exceptions

As you can see above, there are four new error exceptions, each one used for a different purpose:


Standard PHP fatal, and catchable-fatal are now thrown as \Error exceptions. These will continue to cause a “traditional” fatal error if they are uncaught.


With PHP 7, we also have enhancements to assertions, using the assert() function, with the addition of zero-cost assertions, and the ability to have them throw exceptions. To enable this, you should simply set assert.exception to 1 in your php.ini (or via ini_set()).

These exceptions are (you guessed it) \AssertionError exceptions.


Thanks to error exceptions, you can now handle includes with parse errors, and eval() parse errors, as both now throw \ParseError exceptions:

View this code snippet on GitHub.


With the introduction of scalar, and (especially) strict types in PHP 7, these will also throw exceptions when a type mis-match occurs. It is important to understand that this does not apply only to scalar type hints, but to traditional type hints such as class/interface names, callable and array.

Catchable Fatal Errors

Another important change in PHP 7 is with catchable fatal errors. Previously, these would have been caught and handled using set_error_handler(). However, with PHP 7, they are now \Error exceptions, which, because an uncaught exception is now a real fatal error, will no-longer be catchable in set_error_handler().

This is a backwards compatibility break and means that to work in both PHP 5.x and 7, you need to use both set_error_handler() and try... catch.

This is considered a minor BC break due to limited usage.

\Throwable and Userland

It would not be a big jump to conclude that now we have a common interface, we could create our own branches in the exception hierarchy for completely custom exceptions by simply implementing the \Throwable interface. Unfortunately, due to the fact that exceptions are magical under the hood, to be able to do things like capture line/file and stack trace information — this means that you still must still extend either \Exception or \Error, and cannot directly implement \Throwable alone.

Trying to implement \Throwable results in the following:

View this code snippet on GitHub.

However, this is not the full story. You can extend \Throwable and then — while still extending \Error or \Exception — you can implement your extended interface:

View this code snippet on GitHub.


As alluded to in the (pun intended) title of this post, these changes are actually quite big, allowing us to gracefully handle almost all previously fatal errors. The fact that the core team were able to maintain almost complete backwards compatibility while doing so is astounding. Kudos to them!

PHP ClassesReview: MongoDB and PHP (30.7.2015, 02:14 UTC)
MongoDB and PHP
Jose Gomez
PHP books
Steve Francia
MongoDB and PHP is a great book that obviously describes how to use MongoDB with PHP. The target readers of this book are PHP programmers. It introduces MongoDB as document based database, how to install MongoDB drivers, perform simple queries and aggregation like MapReduce. This book also enumerates mappers, tools and frameworks.

So it is well recommended to all those that want or need to learn about how to use MongoDB with PHP.
SitePoint PHPUsing Selenium with PHPUnit (29.7.2015, 16:00 UTC)

Testing is a really wide subject, whether it be unit testing, functional testing, acceptance testing, etc. In this article, we’re going to see how you can do acceptance testing using Selenium. I will use a practical example to illustrate a real use case. I will assume that you already know how to do unit testing using PHPUnit, or that you at least have a grasp of what it’s all about. Let’s get started.

Image of some checkboxes being checked

What Is Acceptance Testing?

Acceptance testing is the process of telling user stories through tests, and I love this quote to describe it:

A formal test conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

What Is Selenium?

Selenium is a tool to automate user interface testing. It helps with testing your application against the browser. The process could be described like so:

  • Go to the page http://myapp.dev/videos.
  • Assert the page contains a list of 20 videos.
  • Click number two on the pagination.
  • Assert the page contains a list of 20 videos.
  • Quit the browser.

You may be wondering: “How does it manipulate the web page using the described tests?”

The answer is “it depends”. If you’re using Selenium RC (previously named Selenium 1), it will inject auto generated JavaScript code to the page to perform the desired actions. Selenium RC is deprecated and is only supported in maintenance mode; you should be using Selenium WebDriver.

When using Selenium WebDriver (Selenium 2), the tests are translated into commands and passed to the Selenium server (more about that in a moment), then passed to the browser using the web browser native API.

Continue reading %Using Selenium with PHPUnit%

Matthias NobackBehind the scenes at Coolblue (29.7.2015, 08:57 UTC)

Leaving Qandidate, off to Coolblue

After I had a very interesting conversation with the developers behind the Broadway framework for CQRS and event sourcing the day wasn't over for me yet. I walked about one kilometer to the north to meet Paul de Raaij, who is a senior developer at Coolblue, a company which sells and delivers all kinds of - mostly - electrical consumer devices. Their headquarters are very close to the new and shiny Rotterdam Central station. The company itself is doing quite well. With 1000+ employees they keep needing more office space.

Paul showed me around all departments and offices, which nowadays span three floors. There's developer teams everywhere. It's not a PHP-only company. Though PHP is well represented, there are also .NET and Delphi developers. Coolblue runs on quite a lot of software and hardware.


Developers at Coolblue have learnt to call the legacy software they maintain "heritage". "Legacy software" often has a negative sound to it, while in fact, it's what enables the company itself to be so successful, so it doesn't really deserve that negative image. I don't fully agree with this approach since most of the relevant literature about this subject speaks of "legacy software", which, to me personally, doesn't mean anything bad. I'm well aware that anything I write today will be "legacy" tomorrow, because, literally, other people inherit that piece of code and need to maintain it. In my dictionary, "legacy software" isn't a bad thing (though I know that it often is, so I understand this little play of words).

New things: microservices

Paul mentioned that there is an ongoing struggle amongst developers who rather want to try "new" things, while they feel stuck in the "old" way of doing things. Paul argues that it's always possible to try something "new" in an older project as well. The infrastructure may not be there for it yet, but introducing it might therefore be even more challenging, as well as more satisfying. I fully agree with Paul on this, and I also like to work on an older code-base and introduce new concepts to it. Anyway, in my personal experience, thinking that you're better off working on a green-field application, because you can do everything "the right way", often turns out to be quite a fallacy. I'm sure you'll recognize this sentiment as well.

At Coolblue, "new things" currently means event sourcing and microservices. They have introduced several microservices so far. Microservices are one of these things Coolblue developers have been wanting to introduce for quite some time. It turned out to be not that hard, but, according to Paul, the key was to keep it small at first. They started by extracting several smaller and less crucial parts from the main application into microservices. You can read about some of their experiences on devblog.coolblue.nl.

New things: event sourcing

Paul and others have done quite some research with regard to event sourcing as well. They haven't taken the step yet to implement it in their software. Take a look at this slide deck to get an impression of what it might look like for them when they do.

Paul made an interesting observation with regard to "new things": there is often a mismatch between what a developer thinks of themselves, and what that same developer thinks of other developers. When listening to meetup or conference talks, you may start thinking that you're way behind on current developments in the world of (PHP) software development. Paul at first felt the same, but noticed that when you actually talk to developers about what you're doing, it might just as well turn out that you're doing fine.


Developer teams at Coolblue are separated based on the features they work on. There is a team working on "pre-cart", i.e. everything related to the presentation of the products, their categories, etc. Then there's a "post-cart" team, which works on actually making the sale, payment, etc. Paul himself is moving from team to team mostly, helping everyone solve any issues that they may be facing. This way, he gets a nice overview which enables him to take knowledge from each team to other teams. This also helps preventing the same mistakes from being made in different teams.

Walking through the corridors, we pass a lot of "team rooms". Walls are made of glass, but each team is still nicely separated from the others. They can see, but not hear each other, meaning that they can focus on what they're working on, while still feeling part of the organization. It appears that each team consists of about

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

PHP ClassesWhat You Should Do Before Pushing PHP Code to your Production GIT Repository (29.7.2015, 04:31 UTC)
By Suresh Kumar
Every time you commit new code to a Git repository, there is a great chance that the code has problems that were not detected with your usual batch of tests.

Read this article to learn how to integrate PHP Code Sniffer with your project Git commit process to inspect your PHP code automatically and prevent that code with problems is committed.
Cees-Jan KiewietComposer cache on Travis (28.7.2015, 22:00 UTC)

Ever since the Test lowest, current, and highest possible on Travis post I wanted to dive into caching composers cache and vendor on Travis. My experiments started the day after that post.

Docker Composer Packagist Travis Hybrid

Matthew Weier O'PhinneyOn PSR7 and HTTP Headers (28.7.2015, 14:00 UTC)

Yesterday, a question tagged #psr7 on Twitter caught my eye:

#psr7 Request::getHeader($name) return array of single string instead of strings in #Slim3? cc: @codeguy pic.twitter.com/ifA9hCKAPs

@feryardiant (tweet)

The image linked provides the following details:

When I call $request->getHeader('Accept') for example, I was expected that I'll get something like this:

    [0] => text/html,
    [1] => application/xhtml+xml,
    [2] => application/xml,

but, in reallity I got this:

    [0] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Is it correct?

In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.

Headers in PSR-7

When creating the PSR-7 specification, we had to juggle a fair number of details from the various HTTP specifications. Headers are one area that is particularly difficult, due to the flexibility and ambiguity in the specification.

The root of the ambiguity is that headers are allowed to have multiple values. Headers may have multiple values, but it's up to the specification for any given header.

Additionally how multiple values are represented is up to the given header. The HTTP specifications allow using multiple invocations for the same header:

X-Foo-Bar: baz
X-Foo-Bar: bat

The above would mean that the X-Foo-Bar header has two values, baz and bat. Assuming the header allows multiple values at all; if it doesn't, then it has a single value, and the last representation wins (bat, if you're paying attention).

The other way to represent multiple values is using a separator. The specifications indicate that if you want to have multiple values in the same header line, you should use a comma (,) as a separator. However, you may use any other separator you want. The SetCookie header is a prime example of a header allowing multiple values that uses a completely different separator (semicolon)!

So, to summarize:

  • A header may or may not allow multiple values.
  • Headers may be emitted more than once. If a header allows multiple values, then its value is the aggregate of each representation. If the header only allows one value, the last representation is the canonical value for that header.
  • Headers may use a separator character in a single line in order to separate multiple values. That character is suggested to be a comma, but it can vary per-header.

The other big ambiguity in the specification is that the specification is extensible, and specifically allows for custom headers.

This means that any general-purpose code representing HTTP, such as PSR-7, cannot possibly know the entire ruleset governing all possible HTTP messages, as it cannot know all potential header types, including whether they allow multiple values or not.

With these two facts in mind — headers may have multiple values, and custom headers are allowed — we made the following decisions with PSR-7:

All headers are collections

All headers are assumed to have multiple values. This gives consistency of usage, and puts the onus of knowing the semantics of any given header to the consumer.

For that reason, the most basic access for a given header, getHeader($name), returns an array. That array can have the following values:

  • It can be empty; this means the header was not, or will not be, present in the representation.
  • A single string value.
  • More than one string value.

Naive Concatenation

Since the majority of headers only allow single values, and since most existing libraries that parse headers only accept strings, we provided another method, getHeaderLine($name). This method guarantees return of a string:

  • If the header has no values, the string will be empty.
  • Otherwise, it concatenates the values using a comma.

We chose not to provide an argument indicating the separator to use, as the specifica

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

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