On the DotDev.co site Eric Barnes has written up a post talking about a recently announced vulnerability (and 0-day exploit) for WordPress allowing for password reset emails to be delivered to a user-specified address instead of the correct one on the account:

On the Exploitbox site Dawid Golunski shares a 0 day vulnerability in the WordPress core affecting all versions:

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner’s account.

The post includes a snippet of code from the WordPress core where the issue lies, relying on the value from PHP's $_SERVER['SERVER_NAME'] variable for the domain in the address the reset email is sent to. Unfortunately this value is pulled from the Host header in the request and is user-controllable. There's a solution offered using an Apache setting and it's noted that this exploit only seems to work against the default VirtualHost as it will act as a fallback if the Host does not reference a configured domain.

The QaFoo blog has a new tutorial posted showing you how to work with PHPUnit and database testing for acceptance testing of your application. Acceptance testing (or integration testing) generally exercises the tests with live data from a database rather that stubbed or mocked data in true unit testing.

Most of us do not use PHPUnit solely for Unit Tests but we also write Integration or Acceptance Tests with PHPUnit. One very common question then is how to interact with the database correctly in those tests. Let me show you the different options and their trade offs...

There are multiple aspects of database tests where our decision has impact on test atomicity and test runtime. All decisions boil down to: More test atomicity leads to longer test runs, and we can buy test speed by omitting test atomicity.

They talk more about the time added for testing with database functionality included and where running them might be most appropriate (local vs on the CI server). The article then talks about one of the main decisions around doing a full data/schema reset or just removing data when the tests start or end. They then get into this last point - where the reset should happen, before or after the tests are executed. They talk in detail about each option, breaking it down into a few options: before each test, before each test class or before the whole test run. The post ends with a section talking about "mocking the database away", a method usually used in traditional unit testing but points out that this can be highly prone to errors, especially if you attempt to replace one database system with another (like replacing MySQL with SQLite).

On the Acquia blog there's a new post today with another of Jeffrey A. "jam" McGuire's interviews with a member of the PHP community. In this latest interview he talks with Jordi Boggiano, a lead developer on the Composer project that's changed the way people use and install PHP packages.

It was great to get the chance to sit down and talk with Jordi Boggiano at SymfonyCon Madrid 2014. Jordi is responsible for Composer, one of the most important pieces of technology that is driving PHP interoperability and the PHP "renaissance" of the last couple of years. He's also on the Symfony2 core team.

Jeffrey gives a brief overview of some of the main points that Jordi makes in his interview including the suggestion of "using what you know" and thinking of the people/users of the tool, not just the technology of it. He also mentions Jordi's response to the "PHP Renaissance" (and note that he sees it as more of a PHP Reset instead). You can watch the full interview video either through the embedded player or on YouTube, You can also use the in-page audio player or download the mp3 if you'd like an audio-only version.

On LWN.net there's a new article written up by Jonathan Corbet about the state of PHP6, what it was supposed to be and what it might be in the future.

Rightly or wrongly, many in our community see Perl 6 as the definitive example of vaporware. But what about PHP 6? This release was first discussed by the PHP core developers back in 2005. There have been books on the shelves purporting to cover PHP 6 since at least 2008. But, in March 2010, the PHP 6 release is not out - in fact, it is not even close to out. Recent events suggest that PHP 6 will not be released before 2011 - if, indeed, it is released at all.

He talks about features that were supposed to disappear in PHP6 (with some of them making their way into PHP 5.3) including the Unicode support the language needs more and more. He mentions how the development has stalled out a bit recently but has been spurred back to life when major decisions were made to get away from a PHP 5.4 branch and move back to PHP6.

Be sure to check out the great comments on the post from other PHP developers from all around the web.

If you enjoy this post, please consider subscribing to LWN for more great articles.

In the latest post to the SitePoint PHP Blog, Harry Fuecks takes a look at what he considers the real difference between PHP and Python.

Posting in the full realization of the futility of doing so, there's some PHP bashing (as usual) happening on reddit at the moment: PHP vs Python - the real difference, brought on by this mildly amusing image. While I can accept the points - technically it's actually much harder in handle errors uniformly in PHP and the community is less rich in computer scientists than Python - the corresponding flame war on reddit manages to miss a different point, which is easiest expressed in code.

He gives two sample scripts and asks what the real differences are. He answers his own question by way of saying that what matters between the two is how they're deployed (when it comes to error reporting):

Because PHP "resets" after each request ( see here or for much more detail here ) it's actually not always necessary to handle errors explicitly—assuming there’s not something fundamentally "broke" about your code and it's some kind of runtime error (e.g. db is down), it's often enough to just ignore the problem and wait for the system to "right itself" - nothing is going to leave PHP in a state it can't recover from.

In the latest post to the SitePoint PHP Blog, Harry Fuecks takes a look at what he considers the real difference between PHP and Python.

Posting in the full realization of the futility of doing so, there's some PHP bashing (as usual) happening on reddit at the moment: PHP vs Python - the real difference, brought on by this mildly amusing image. While I can accept the points - technically it's actually much harder in handle errors uniformly in PHP and the community is less rich in computer scientists than Python - the corresponding flame war on reddit manages to miss a different point, which is easiest expressed in code.

He gives two sample scripts and asks what the real differences are. He answers his own question by way of saying that what matters between the two is how they're deployed (when it comes to error reporting):

Because PHP "resets" after each request ( see here or for much more detail here ) it's actually not always necessary to handle errors explicitly—assuming there’s not something fundamentally "broke" about your code and it's some kind of runtime error (e.g. db is down), it's often enough to just ignore the problem and wait for the system to "right itself" - nothing is going to leave PHP in a state it can't recover from.