In a new post to their blog, Exakat looks at the use of eval in PHP applications and how, despite all of the warnings against using it, it's still found in quite a few codebases (based on their scans).

It is 2018, and we can still find eval() being used in more than 28% of every PHP code source. It is repeatedly reported as a security issue and a performance bottleneck, and a memory hazard. Yet, we can’t get rid of it.

It seems reasonable to think that most of eval capabilities are available as a PHP features. So, we took examples from 2000 PHP open source projects, and reviewed the situation. Here are real-life examples of eval usage : for each of them, we’ll discuss the actual replacement.

Their examples include the use of eval for:

• JSON decode replacement
• Creating missing classes
• Rewriting classes on the fly
• Code compatibility
• Dynamic variabling

...and several more. Each comes with a summary of the method and code showing how it's being used. While some of the suggested replacements are built-in features of the language, others are recommended packages that can provide the same or similar functionality to what the original author was trying to accomplish.

On the Tuleap blog there's an article posted showing how they made the switch from RabbitMQ to Redis in their PHP application.

There are various places in Tuleap were message queues are needed but the primary one is to run jobs in background. Historically it was for all system related stuff (creating users, git/svn repositories, etc) that required special unix permissions that we were not eager to grant to a web app.

[...] More recently we add a need to share events across servers, for distributed Tuleap setup for instance. Our good old system was no longer able to deal with that because we needed a real queue management that works across servers. We choose RabbitMQ because we were looking for a queue system, PHP support quite decent and tutorials were good. However, we had to setup a quite complicated queue system.

The post outlines the exchange to exchange binding system they created and includes the code use to make the RabbitMQ-based system work. Then they introduce Redis and how, when they learned about RPOPLPUSH, decided to make the switch. The code for this replacement is also included.

On the Laravel News site there's a post about an upcoming feature in the Laravel framework's Blade templating functionality: components and slots.

A new feature coming to Laravel 5.4 is the ability for you to add Components and Slots to Blade templates. This feature was inspired by Vue.js and allows you to simplify building HTML elements into reusable areas.

In most applications you have a master layout and then sub views that extend it. [...] Using the new Laravel Blade Components you can create [a template] with a special variable [for easy replacement].

The post then shows how to "reimagine" views using this slots and components functionality in a simple template/view example, replacing data based on names rather than it having to be passed to the view as data.

In this recent post to the In2it blog Michelangelo van Dam makes a recommendation to decouple your logic from your framework to make it easier in the future if you need to replace it.

Decouple your framework or library from your business logic for future upgrades or replacements through usage of interfaces. By separating your business logic completely from the tool used to glue all things together, you can replace your framework or upgrade to a newer version without much problems.

He talks about how it's common for applications to quickly become "good application turns into a cluster of code on top of a cluster of code". While the title suggests completely swapping out the underlying framework, he shifts it to talk more about updates to the current framework, especially ones that would break non-decoupled functionality. He then covers the ideals of "interoperability" between PHP packages based on common interfaces (like the PSRs) and how following a similar idea can help decouple your code to prevent hard work for future potentially breaking changes.

David Sklar has a post to his site showing you how to fix broken UTF-8 characters in content being passed through the normal string functions.

When working on the i18n bits of Learning PHP 7, I had a problem. My example showing how plain string functions such as strtolower() and strtoupper() mangle multibyte UTF-8 characters was making the book formatting/rendering pipeline barf. The processing tools are expecing nicely formatted, valid, UTF-8 encoded HTMLBook files. It didn’t like the mangled invalid UTF-8 characters in my example output.

To fix this, I wrote the following function to replace invalid UTF-8 sequences with the Unicode Replacement Character (U+FFFD).

He includes the code for this method that walks through the string, character by character, and checks the bytes it contains to see how it needs to be translated. There's plenty of comments in it too, explaining what it's doing as it goes along.

Dracony has a new post to his site that suggests replacing controllers with middleware and how it relates to some of the current controller practices.

Middleware is now a very popular topic in the PHP community, here are some of my thoughts on the subject. [...] The idea behind it is “wrapping” your application logic with additional request processing logic, and then chaining as much of those wrappers as you like. So when your server receives a request, it would be first processed by your middlewares, and then after you generate a response it will also be processed by the same set.

After giving a few examples of what could be a good fit for use as middleware, he makes the suggestion to replace controllers. He talks about some of the problems that middleware brings with it and how to turn things around and write controllers as middleware (and not wrap them in it). He finishes with a mention of the work being done on PSR-7 (the HTTP Request proposal) and some thoughts on how it could fit into his middleware ideas.

In an interesting new post to his site Matthew Setter wonders if an IDE like PHPStorm can be replaced by VIM, a standard in the editor community for decades.

Is it reasonable, even practical, to expect that a 30 year old application can match a modern one? Is it conceivable to be able to code as well using VIM, said 30 year old application, as I can in PhpStorm, with all the IntelliSense-lead functionality PhpStorm offers?

He starts with some of his recent experience with the editor and some of the things he's (happily) found it can do he didn't know before. He includes a screenshot of a multi-pane view, explains what each is and what he can do with them. He points out that this example is Markdown documents but it can just as easily be used for code too. Finally he talks about the subject any PHPStorm user wants to know about, the IntelliSense functionality. Unfortunately, while there are some tools he mentions that can do similar things, they don't provide the context PHPStorm can deliver.

He ends the post with an interesting question: is IntelliSense the right approach? He wonders if having more context is a better answer rather than just the auto-complete handling IntelliSense offers.

On the SitePoint PHP blog today Victor Berchet introduces HACK, the "replacement" for PHP inside the HHVM (HipHop Virtual Machine) from Facebook's development group. This is part two in the HACK/HHVM series.

HACK is an evolution of the PHP language designed to be safer, to enable better performance and to improve developer efficiency. Note that both HACK and PHP are equally supported by the HHVM. Despite the fact that HACK is in use at Facebook on all the production servers, only little info has leaked for now. In a nutshell, HACK is Facebook's PHP6 – it proposes to fix most of what's wrong with PHP today, while adding some new features like static typing along the way.

He starts with a look at typing and the static typing HACK uses instead of the dynamic typing of the normal PHP language. He mentions the "gradual typing" functionality, strict mode and the use of annotations. He also talks about XHP, the PHP extension that allows XML fragments to be translated into valid PHP (example included). He finishes off the post looking at a few other topics including asynchronous code execution, FastCGI support and the integrated debugger.

Matt Farina has a new post today looking at an "underutilized gem" he's found in the offerings of the Standard PHP Library (SPL) - the SplFixedArray.

Arrays in PHP are not arrays per the typical array data type. Instead, as Matt Butcher recently pointed out arrays in PHP are similar to hashes in other languages. This can be a very important point to know when tracking down bugs in code and to programmers coming to PHP from other languages. But, what if we wanted something like a traditional array data type? Maybe something that preserved numeric order. Enter SplFixedArray.

He gives an example of using the SplFixedArray object versus the normal array variables in a simple PHP snippet showing the preservation of numbering order. He also touches on the memory consumption difference between the two, with the fixed array coming in quite a bit lower than the normal array data type (around 25% based on his basic testing). There are some catches to using it, though including incompatibility with array methods and the fact that it doesn't implement things like Iterator or Countable interfaces.

On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

• passing values in through the constructor
• using the "Information Architect" pattern to have the most responsible method handle the value setting
• the "Double Dispatch" method that uses dependency injection
• using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.