On his blog, Mike Lively has posted a look at some of the work he's been doing on patches for the late static binding functionality to be included in PHP, including an example of the updates in action.
This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB.
His example shows how to override a static method and push that new method's execution to the parent class (in two ways - safe using forward_static_call and the not so safe calling itself with a parent:: override).
We're looking for a full-time onsite Web Developer with a focus in PHP. Alongside our Director of Technology, you will be driving a variety of web development projects combining front and back-end programming for national clients. We are a small design and interactive studio so there is tremendous opportunity for growth and diverse work for national clients and innovative brands.
Tech Details
You should be a person who constantly desires to stay up-to-date on development trends, technologies and innovations. You should be an expert in PHP/MySQL development in an MVC framework. You'll distinguish yourself if you have in-depth knowledge of multiple languages, platforms and technologies including:
ASP.NET (2.0+)
JAVA
MySQL
Javascript (AJAX)
XHTML / CSS
Actionscript
Version control (Subversion/Git)
Other capabilities and experiences that are desired include: eCommerce experience, a web design sensibility, Flash skills and comfort with the Adobe CS Suite.
Responsibilities
Develop, maintain and support large, high-availability, web based internal applications and reporting tools; support high-traffic commercial websites
Interest in creating the next generation of interactive media applications
Research new platforms and architecture to support current and future business requirements
Ensure consistency and adherence to MODE's standards, processes, and policies for all projects.
Required Skills
2+ years web development experience
experience in client facing communications
Computer Science degree or equivalent experience
Excellent analytical/problem solving skills, ability to think creatively and solve complex technical problems
Quality oral/written communication and interpersonal skills in order to effectively partner with the technologies and business communities
Ability to develop a clear understanding of client needs and plan applications to meet their needs.
Andrei Zmievski has posted an encouraging note on his blog about the progress of PHP6 concerning the number of functions that have been correctly converted to support Unicode.
Well, PHP boys and girls, this feels like quite a milestone: 50% of the 3084 functions that are bundled with PHP 6 have been upgraded to support and work safely with Unicode.
He includes a small chart beside the post as well showing where things are currently at like the safe vs unsafe functions.
Tobias Schlitt has a great (long) post responding to a proposal made on the php.internals mailing list for the inclusion of "taint mode" in upcoming PHP versions.
Tobias starts with an overview of what "taint mode" is so that everyone's on the same page. His example involves the incoming and outgoing data usually involved in an application and how the incoming can be the most problematic when it comes to the values inside. This is where taint mode can come to the rescue. At its most basic level, it's a method for, assuming everything coming in is "tainted", creating a mechanism to automatically clean the data before it's even touched.
With the basics down, Tobias looks back to the proposal for a few additional comments. He considers the proposal a great way to introduce the functionality to the language. There are some draw backs he mentions, though, including the additional overhead of working through every inputted value.
Overall, I think this whole thing would be a great addition to PHP and I hope this could come for 6.0. What do you think?
You can also check out some other opinions on the matter:
In an effort to get some thought going about ways to encourage security in PHP applications, Stas has posted an idea about a simplified php.ini setting - production=On.
His idea is that, with this setting on, the PHP installation would:
disable display errors
disable phpinfo()
turn expose_php off
make max_execution_time/memory_limit reasonable
and possibly a few others that some developers forget to set correctly
Comments on the post range from disagreement to suggestions on improvement and support.
On the PHP Security Blog, there's two new posts concerning their Suhosin patch for PHP - one talking about a remote code execution vulnerability found in the uploadprogressmeter extension (which as already been corrected) and the other dealing with the "stealth mode" of the patch to find compatibility problems.
As mentioned, the issue with the uploadprogress extension has been fixed and as been introduced into the PECL repository. The other post just mentions what the patch is doing to try to keep compatibility problems from happening due to back extensions and/or modules being loaded in an application.
More details about the Suhosin patch can be found here.
A new release of the Zip PECL package has been made according to this post on Pierre-Alain Joye's blog today. The main update in this release is to counteract a Windows bug that's interfering with binary file opens.
The issue is actually a windows bug. No matter if I give or not the "b" flag to fopen, the write operations are not binary safe. It seems to be a known issue as many projects use the same trick.
The problem comes up when PHP forces the binary mode in SAPI and CLI, making the binary writes to a file non-binary safe no matter what. Pierre is also asking for help from anyone out there with any information/bug reports/references about this issue that would yield something useful.
When John migrates, to me it means two things in particular;
If there is a performance hit vs. the older PHP version, it will be an acceptable one.
There are no show-stopping bugs.
Don't believe me? Well the short proof is John's company have their future riding on it. A longer proof is to take a deep look at the code in adodb which is a great way to grasp John's mindset / experience. Otherwise browse the phpeverywhere archives...
It's an interesting standard to set for the adoption of something as beneficial as the move from PHP4 to PHP5, but it is one way to judge the effectiveness. When you see the major applications tailoring their setups for PHP5 environments, it might be time to consider jumping ship yourself...
