In this post to his site Mark Baker has shared some "sending gotchas" when generators are used in you PHP code. The focus of the article is on the "sending" part, pushing data into the generator for evaluation and use.

If you’re reading this, you’re probably already aware of just how useful PHP’s Generators are for improving performance and/or reducing memory overheads while keeping your code clean and easy to read.

Unlike their equivalent in some programming languages, PHP’s Generators allow you to send data into the Generator itself; not simply at initialisation (the arguments that we pass to the Generator when instantiating it); but also between iterations. This has its own uses, and again, allows us to move code from our main blocks and methods into the Generator itself. [...] However, there are a few “gotchas” when we combine Generators that both return and accept data in this way, and it really helps to be aware of them when we’re developing, otherwise it can create problems.

He starts simple, showing a generator that uses integers passed in as the starting number and addition interval for each loop. He gets a bit more complex in his next example, having a method called inside the loop. While the first instance of this behaves as expected, the second (after minor modification) yields unexpected results. He walks you through what's happening to produce those results and one possibility on how to get it corrected.

Christian Weiske has posted a quick guide for those still dealing with PHP 4-style constructors in their code and how to upgrade them for PHP 7 (as it's completely deprecated now).

PHP 7 deprecates PHP4-style constructors. In PHP4, class constructor methods had the same name as the class. This was bad when switching base classes; you did not only have to change the class' extends declaration, but also calls to the parent constructor. PHP5 then introduced the generic __construct method name for class constructors, which solved the problem. ?

PHP7 will output a deprecation message when a class with a PHP4-style constructor is loaded

He suggests that a "quick fix" is to just rename the method to __construct and let PHP handle things as expected. However, dependencies in other classes (calling them in a PHP 4 way) could break because of this. He suggests a "real fix" that can be put in place until the remainder of the code is migrated - a method named the same as the old constructor but just calling __construct internally.

As Ruslan Yakushev points out in this new blog entry, the same security issue that's effecting ASP.NET pages running on IIS web servers can still open up PHP scripts running on the same server.

Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.

The issue allows attackers to access the contents of various files on the server and could allow them to tamper with the data inside. Ruslan notes that, while Microsoft is coming up with a fix, one of the safest things you can do is either completely disable ASP.NET in the IIS server or use this workaround.

On his blog, Pierre-Alain Joye talks about the ext/filter extension and how several developers just choose to "work around" it instead of using its features right out.

On the other hand, the same persons worked around ext/filter with ugly hacks. Edin pointed me to one of these horrible codes in Serendipity, as I saw this code in other applications like flyspray, I think it is time to raise your attention about what to do not do.

The code he's referencing is a snippet that manually filters each of the superglobals to get rid of any problems that might have been put in. He points out two security problems with the code too: only use PHP functions as a fallback when filter isn't available and never use the superglobals directly outside of the filtering.

Stefan Esser has his own comments on the topic too. He votes for the other way around (own functions over filter's methods) and expresses the opinion that the ext/filter extension is a bad idea similar to the impropper use of magic_quotes_gpc.

Pierre has also responded to these comments in an update to how own blog entry. Check it out for the full story...

On his blog, Pierre-Alain Joye talks about the ext/filter extension and how several developers just choose to "work around" it instead of using its features right out.

On the other hand, the same persons worked around ext/filter with ugly hacks. Edin pointed me to one of these horrible codes in Serendipity, as I saw this code in other applications like flyspray, I think it is time to raise your attention about what to do not do.

The code he's referencing is a snippet that manually filters each of the superglobals to get rid of any problems that might have been put in. He points out two security problems with the code too: only use PHP functions as a fallback when filter isn't available and never use the superglobals directly outside of the filtering.

Stefan Esser has his own comments on the topic too. He votes for the other way around (own functions over filter's methods) and expresses the opinion that the ext/filter extension is a bad idea similar to the impropper use of magic_quotes_gpc.

Pierre has also responded to these comments in an update to how own blog entry. Check it out for the full story...