On the Zaengle blog there's a post spotlighting the custom Blade directive functionality that comes with using the Blade templating engine of the Laravel framework. These allow the definition of custom functionality available directly from the templating layer.

Earlier today, I was working on coding up a design that displays a varying number of cards - each with a unique title and description… think Masonry/Pinterest-esque. I’ve been using Model Factories to stub out a bunch of cards, all with different content. Once I’d hooked up the dummy data to the card templates, I realized that the design didn’t work as well with titles that had more than 20 or so characters.

A common solution to this would be to use CSS to break the line and automatically add an ellipsis. [...] However, this wouldn’t work well in my situation because the design allows titles to be two lines long. Another solution would be to chop off the title at a given length and add an ellipsis using a php snippet. [...] However, adding this much PHP to my Blade templates would have really mucked up my otherwise-clean templates. So I decided to drop this functionality into a custom Blade directive that I could reuse where necessary.

He shows how to define the custom Blade directive in the AppServiceProvider class (autoloaded with every request) for a simple "Hello World" example. He also shows how to use this in the template code, making a simple call to its matching helloWorld tag. He then implements his custom truncate handling, returning some simple PHP code that automatically reduces the content down to a given length and echoes out the result.

If you're a Codeception user, you'll find Matthew Turland's latest post interesting. In it he shares a way to customize database cleanup between the tests. Codeception handles it a bit differently that how PHPUnit's Db module does.

Recently, I was looking into ways to speed up the runtime of the test suite at Blopboard. We use the Codeception framework to write functional tests for our REST API, part of which entails putting the database into a known state using Codeception’s Db module. The behavior of this module is similar to that of the PHPUnit Database extension with one exception: where PHPUnit only truncates tables and leaves their schemas intact, Codeception removes the database structure and expects the SQL dump it uses to recreate it between tests. I must admit to not understanding this design decision of Codeception, nor attempts to clarify it.

He admits that his solution is "a bit hacky" but it does work to truncate the table rather than drop the entire schema and wait for a rebuild. His "DbHelper" class is used in place of the Db module. He traced through the execution path of the Db module and found a "hook" where he could override the "cleanup" method to prevent the schema drop and replace it with a truncate. He also includes code for a suggested addition to Codception that would handle the same thing in a more integrated way.

Jeremy Cook has put together a new post showing how he got PUPUnit, Doctrine and MySQL to "play nicely" together when he was writing up some of his tests in a current application.

One of the pain points for me though has been in getting Doctrine setup with PHPUnit for testing. One of the main Doctrine contributors, Benjamin Beberlei, has written a package called DoctrineExtensions which amongst other things adds a class called DoctrineExtensionsPHPUnitOrmTestCase which extends PHPUnit’s DbUnit database test case class. This all works well in principle but hits a major snag in reality: MySQL doesn’t allow InnoDb tables with foreign keys to be truncated. PHUnit’s database extension truncates the database tables before each test run and inserts a fresh set of data to work with.

To work around this issue Jeremy by porting over a method posted by Mike Lively over to Doctrine as a custom "MySQLTruncate" class (code included in the post). He also includes some sample code showing it in use - a basic ORM test case that calls the truncate method when its set up.

Secunia has posted this new advisory today about an issue with the GD graphics library functionality in PHP that could be used to cause a Denial of Service via a truncated PNG image.

The vulnerability is caused due to the incorrect use of libpng within the function "gdPngReadData()" in ext/gd/libgd/gd_png.c of the GD extension when processing truncated data. This can be exploited to cause an infinite loop by e.g. tricking an application to process a specially crafted file. (reported by Xavier Roche)

This issue has been confirmed in PHP versions 4.4.7 and 5.2.2 but may affect others. The issue has already been corrected, however, and can be fetched from the PHP CVS system to protect your system.

Secunia has posted this new advisory today about an issue with the GD graphics library functionality in PHP that could be used to cause a Denial of Service via a truncated PNG image.

The vulnerability is caused due to the incorrect use of libpng within the function "gdPngReadData()" in ext/gd/libgd/gd_png.c of the GD extension when processing truncated data. This can be exploited to cause an infinite loop by e.g. tricking an application to process a specially crafted file. (reported by Xavier Roche)

This issue has been confirmed in PHP versions 4.4.7 and 5.2.2 but may affect others. The issue has already been corrected, however, and can be fetched from the PHP CVS system to protect your system.