The PHP development team would like to announce the immediate availability of PHP 5.3.8. This release fixes two issues introduced in the PHP 5.3.7 release: Fixed bug #55439 (crypt() returns only the salt for MD5), reverted a change in timeout handling restoring PHP 5.3.6 behavior, which caused mysqlnd SSL connections to hang (Bug #55283). All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.8.

As always you can download this latest release from the downloads page (Windows binaries here). This upgrade is highly recommended if you were running 5.3.7.

I Spent a little while yesterday investigating why memcached causes problems with multigets returning results and ended up comparing debian vs ubuntu. [...] A larger number of keys than 200 causes memcached to fail to return valid responses, additionally the key length greatly varies the number items you can pull back within a single multiget on Ubuntu, Debian implementation of memcached is able to handle all requests regardless of key length size.

He includes the code for his brief test and the output of the test runs on both Ubuntu and Debian systems. They clearly show the failures on the Ubunut side, with it throwing errors about "memcached_oi_read" and a zero length value returned to recv().

These are things in PHP which make me sad. They are real, objective issues which I have personally encountered in my normal day-to-day activites. Nothing on this site should be taken to be the view of my employer or is related to my employer in any way.

The page is split up into several different sections including:

• Lexer/Parser Issues
• Inconsistency
• Anti-functional Design
• Arbitrary Restrictions

Each of the for most of the things on the list, he's linked to a page showing some example code of the complaint and how significant of an impact it could have on your code. He's also set up a discussion board for those that want to talk about these issues further.

Now I didn't know it but is seems that php's session handling is blocking on a per request basis. Kinda makes sense if you think about it, that if two requests simultaneously try and change a session variable then you would get constancy issues. So php handles this by making session_start() a blocking action and will wait for any other request to either finish or close the session using session_write_close().

The only reliable fix he found for the issue was to only selectively use the session in certain circumstances (or on certain pages) and closing it out when you were done with it.

Character sets can be confusing at the best of times. This post aims to explain the potential problems and suggest solutions. Although this is applied to PHP and a typical LAMP stack you can apply the same principles to any multi-tier stack.

He includes a "boring history" session (and recommends skipping if you just want the good stuff) that talks a bit about character sets and their history in computer system handling. All that said, he recommends using UTF-8 to ease your character encoding woes. He talks about configuring your editor to support it, making sure your browsers understand it and setting up your MySQL database connection to use it.

The web site's default locale, language, is English. If the user has no locale in the session/cookie, she, or he, will get the English version of the web site. [...] But! If the user's first visit is on the http://example.com/vesti URL ("vesti" is "news" in Serbian), the router can't route that because it depends on the locale and the default locale is English and not Serbian, thus directing the user to the 404 page.

To get around this issue he created a front controller plugin that fires in the postDispatch hook to change the locale manually if the current request's isn't found to be English. It then redirects the user to the correct location for the new language and things proceed normally.

I migrated only our open issues, and comments (and the comments ended up a bit weirdly formatted on the other end but this was the best they could do). It was nothing pretty or clever but in case it's useful to someone else.

The script connects to the github API and pulls down the information for the open issues including their titles, user and body of the issue. This is then used to make another connection for each to fetch their comments. The whole thing is dumped out to a CSV file that can be easily imported by the Jira team.

We use Jira at Gravity for tracking issues and bugs. Since I'm not always on VPN or have access to our network managing my todos has been cumbersome. I've tried every Todo app out there and always fail to use them for more than 2 days. I finally saw a great article on just using a simple Todo.txt file in your Dropbox folder and working from that. It's been a dream and working out great.

His tool lets him use the Todo list example to push its contents out to the PHP script that connects to the Jira instance and make a new issue. The code is included in the post, ready for cut-and-pasting.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

If we take a look at our current job advertisement, these knowledge is still important, but also skills in JavaScript are asked and strongly desired. If you wonder why JavaScript is so popular at these times, my answer is quite simple: The browser is no longer a stupid instrument to view some static websites on the internet- the browser turned into an (Web-) Application Platform that provides more content then plain text.

They start by comparing some of the data types common between the two (with most things on the Javascript side ending up as an object). They also talk about the fact that arrays are not (technically) arrays like PHP developers think of them. They finish it off with two more common problems PHP devs have when making the move - looping through arrays and "the thing with the semicolon".