Lorna MitchellSOAPFault When Switching PHP Versions (4.8.2015, 07:37 UTC)

I'm working on an update to my PHP Web Services book and with PHP 7 likely to release before the book even makes it into print, I'm testing all my example code across PHP 5.6 and PHP 7 ... which today gave me a weird problem with a very, very simple SOAP example.


$client = new SoapClient('http://api.radioreference.com/soap2/?wsdl&v=latest');

$countries = $client->getCountryList();

This example works fine with PHP 5 but when I ran it with PHP 7 (after realising I needed to recompile with --enable-soap), I got this error:

Fatal error: Uncaught SoapFault exception: [Client] Function ("getCountryList") is not a valid method for this service ...

Hmm. So I complained about it on IRC and someone else tried it on 7 and said it worked fine (thanks @akrabat) but that it didn't work under 5.6 for him.

I can only speculate about what changed between versions and it's probably a good thing, whatever it is, but it seems like once the WSDL is cached locally from one version of PHP, it makes no sense with the other version. To fix it, disable the WSDL cache:

ini_set("soap.wsdl_cache_enabled", "0");

This worked for me, and I am not sure how I would have found a strange SOAP fault between PHP versions other than by a lucky help from someone else, so it's here in the hope that it saves time for someone else too!

SOAPFault When Switching PHP Versions was originally published on LornaJane by Lorna. Lorna is a web development consultant, tech lead, author, trainer, and open source maintainer, and she is occasionally available for freelance work.

Henrik SarvellFunctional HTML Rendering with PHP (4.8.2015, 05:20 UTC)

When you’re working with a programming language that doesn’t have templating per default and you’re not in the mood - or don’t see the need - for templating your first course of actions is to write something to obviate having to print and concatenate everything.... Read More

Cal EvansInterview with Heather White (4.8.2015, 05:00 UTC) Link
PHP ClassesTop 10 PHP Tips Every Developer Should Know (4.8.2015, 03:09 UTC)
By Josh
Being a good PHP developer means that you apply many good practices that show that you know what you are doing and that reflects in the quality of the PHP projects that you work on.

You may give more importance to some practices than others because your criteria may be different from other developers.

Read this article to learn and see an infographic about what are the top 10 good practices that every PHP developer should know (IMHO of course).
SitePoint PHPVideo: Shorthand if-else Conditionals with PHP (3.8.2015, 17:30 UTC)

In this screencast I'll show you how to make your code more succinct by using the ternary operator to write shorthand if-else conditional statements in PHP.

<script src="http://jwpsrv.com/library/fhG4YvqNEeSK7Ap+lcGdIw.js">

Loading the player...

<script type="text/javascript"> jwplayer("video-5663").setup({ image: "https://d3rj1gznkm47xj.cloudfront.net/ec193aec-5bbc-43a7-b6bf-66ca9aad54f6.png", sources: [ { file: "https://d3rj1gznkm47xj.cloudfront.net/c2356cd330b0a7c9101cc9d3b6c6682f.mp4", label: "SD" }, { file: "https://d3rj1gznkm47xj.cloudfront.net/96a8b8c416766309d3c83ac28034b9d1.mp4", label: "HD" }, ], tracks: [ { file: "https://djdvv9xnh2mt5.cloudfront.net/4b545928-27e7-436e-bd0f-aa4cae94daf8.srt", "default": true } ], aspectratio: "16:9", width: "100%", height: "480px", fallback: true, primary: "flash", streaming: false, analytics: { enabled: false, cookies: false }, captions: { back: false, fontsize: 12 }, advertising: { client: "googima", schedule: { "myAds": { "offset": "pre", "tag": "https://pubads.g.doubleclick.net/gampad/ads?sz=855x483\u0026iu=/7448792/Video\u0026cust_params=[post_id]%3Dstaging%26channel%3D[channel]\u0026impl=s\u0026gdfp_req=1\u0026env=vp\u0026output=xml_vast2\u0026unviewed_position_start=1\u0026url=[url]/\u0026description_url=[description_url]\u0026correlator=[timestamp]" } } } });

Continue reading %Video: Shorthand if-else Conditionals with PHP%

SitePoint PHPIntroduction to Elasticsearch in PHP (3.8.2015, 16:00 UTC)

In this tutorial, we’re going to take a look at Elasticsearch and how we can use it in PHP. Elasticsearch is an open-source search server based on Apache Lucene. We can use it to perform super fast full-text and other complex searches. It also includes a REST API which allows us to easily issue requests for creating, deleting, updating and retrieving of data.

ElasticSearch Logo

Installing Elasticsearch

To install Elasticsearch we first need to install Java. By default, it is not available in the repositories that Ubuntu uses so we need to add one.

sudo add-apt-repository ppa:webupd8team/java

Next, we execute the following to update the sources.

sudo apt-get update

Once that’s done, we can install Java.

sudo apt-get install oracle-java8-installer

Next, let’s download Elasticsearch using wget.

wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.5.2.tar.gz

Currently, the most recent stable version is 1.5.2 so that is what we used above. If you want to make sure you get the most recent version, take a look at the Elasticsearch downloads page.

Then, we extract and install.

mkdir es
tar -xf elasticsearch-1.5.2.tar.gz -C es
cd es

When we access http://localhost:9200 in the browser, we get something similar to the following:

  "status" : 200,
  "name" : "Rumiko Fujikawa",
  "cluster_name" : "elasticsearch",
  "version" : {
    "number" : "1.5.2",
    "build_hash" : "62ff9868b4c8a0c45860bebb259e21980778ab1c",
    "build_timestamp" : "2015-04-27T09:21:06Z",
    "build_snapshot" : false,
    "lucene_version" : "4.10.4"
  "tagline" : "You Know, for Search"

Continue reading %Introduction to Elasticsearch in PHP%

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!

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