On the Jolicode.com blog, there's a tutorial they've posted showing how to "mix security and forms" in a Symfony application to show only certain form fields based on a user's roles.

In some applications, it could be required to disable some form fields depending on user’s roles.

In this article, we will see how to implement this feature thanks to a simple example: a blog engine.

For their example, they use a Symfony 4 application with the MakerBundle and create a basic blog with "article" entities and an "admin" entity for the user list. From there, the post includes the code needed to update the buildForm method in the ArticleType class to check the current user and be sure they have the "admin" role. To make this work, they also build out a SecurityExtension form extension class that performs the actual check. This is then hooked into the pre-submit event on the form to prevent other issues where an attacker might delete the "allowed" element and submit the data anyway. The post wraps up with an example of performing a similar check but hiding the field instead of just disabling it in the form.

In a new post to his site Colin O'Dell has shared a Composer "metapackage" that can help you avoid unsupported Symfony component versions with the help of Composer's own internal version checking system.

Using symfony/symfony makes Composer install all Symfony Components in the same version. But when using the standalone packages, Composer might install dependencies in a different major version - for example, symfony/validator v2.8 is compatible with symfony/translation v3.0.

This is fine if you don't want to stick strictly to Symfony LTS versions, but it does mean that you could end up using versions of components which no longer receive security updates.

Rather than having to specifically define (and manage) the versions of package you want to install, you could opt to install his package that will do the hard work for you. It uses the "conflict" handling in the Composer configuration to limit version numbers on many of the popular Symfony packages and requires them to be greater than or equal to certain versions.

In a new post to his site Woody Gilk showing how to use custom Composer hooks to run PHP style checks (using PHP_CodeSniffer) on your codebase and setting up the same configuration for all developers.

One of thing that has always bothered me about phpcs is that the lack of a local configuration file.

The official way to set the default standard for a project is [to set the standard on the command line]. This will write to a configuration file inside the vendor/ directory, which means that the configuration cannot be committed to version control. When a new team member is added they must also run this command or different style checks will be used.

Luckily, this can be solved with composer command events, namely the post-install-cmd and post-update-cmd events, which can be pointed to a PHP class that processes the event.

He includes the configuration changes showing how to set up the command in the Composer configuration to run post-install/update and the code required to set the phpcs standard to use. While this method works, he has also updated the post with an example of a single (XML) configuration file that accomplishes the same thing.

On the Laravel News site they've posted a tutorial showing you how to create custom Artisan commands making them available right along with the built-in framework commands.

I’ve written console commands in many different languages, including Node.js, Golang, PHP, and straight up bash. In my experience, the Symfony console component is one of the best-built console libraries in existence—in any language.

Laravel’s artisan command line interface (CLI) extends Symfony’s Console component, with some added conveniences and shortcuts. Follow along if you want to learn how to create some kick-butt custom commands for your Laravel applications.

The tutorial starts off with an overview of the current command structure and how a basic Symfony Console command is structured (code). They then get into the creation of their custom command - a "health check" command - by creating a new Laravel project and using the "make:command" command to build out the skeleton code for you. They add the command into the current config and show output of how it should now show in the "help" listing. From there the tutorial shows how to implement the HTTP checking with Goutte and how ot run it on a schedule, writing the result of the check to a log.

In this post to his site Joe Ferguson gives some advice on solidifying tests in your system that are a bit more fragile. Every test suite of any larger size has these kinds of tests - ones that usually pass but sometimes fail (and then pass just fine on the next run).

On my first week at the new job I was tasked to fix some tests that were logging data. While the fix was simple enough, by using `PsrLogNullLogger as Logger` instead of `MonologLogger` in the test, during the process I ran into another test that appeared quite fragile.

He gives an example of a fragile test, one based on a method that returns a "food" value, that would potentially fail if the data returned is not in the right order. He found the issue was with the use of the assertArraySubset check and how, thankfully, the fix was as easy as changing the assertion (and using an array_diff to help with the check).

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

• Using the PSR-2 sniffs for PHP_CodeSniffer
• Automating the checks with Phing
• Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

In a new post to his site Benjamin Eberlei takes a look at the idea of "feature flags" (settings to turn on and off major features) and how they can be used with Doctrine entities to handle sync issues between new properties and the database schema.

The problem of feature flags with Doctrine is easily explained: If you add properties for a new feature that is disabled in the Doctrine metadata, then you need to upgrade the database before deployment, even when the feature is not being rolled out for some days/weeks. Doctrine requires the database to look exactly like the metadata specifies it.

His solution was to use the "loadClassMetadata" event in the entity to dynamically append these new properties based on simple "if" checks of feature flags in the configuration object. Obviously using this is a bit of a hack until the new properties are in place, but once they are then the only change is removing this code.

The latest issue of the Web & PHP Magazine has been published - Issue #10. This issue can be downloaded for free and has articles about:

• Building an Identity Extraction Engine in PHP (Jonathan LeBlanc)
• 5 Deadly Programming Sins (Michael Stowe)
• Physical Security Fail (Arne Blankerts)
• Database Indexing (Cory Isaacson)

You can also download previous issues of the magazine for free after registering or logging in to your account.

On DesignAeon.com there's a recent tutorial posted showing you how to extract URLs from your database and determine which ones are "dead" automatically with the help of cURL.

Checking Deadlinks From the database manually is a Headache ,So why not use a script which return the http status of the particular link and tell us if the link is dead or not.So how do we check the dead links from the database ? How do we programatically check whether the link is dead or not ? To check broken or dead links from Database we will use curl .

Included in the post is a sample script that extracts the URLs from a field in the database (you'd need some extra smarts if you're pulling it from content) and running it though a "checklink" function. If the call to curl_getinfo returns false, the link is marked dead.

Joshua Thijssen has shared a handy tip for those using Zend Server on a pupptet-ed server - using a Facter plugin to check for the ZS install and only install what's needed (rather than end up with multiple PHP installs).

This means you should not install the default PHP package for your distribution when the distribution also runs on Zend Server. This Facter plugin will allow you to use the $zendserver fact inside your own manifests to check if Zend server is installed, so you can take measures against installing stuff that is taken care of by ZendServer itself.

You can download the plugin from his github account, https://github.com/jaytaph/puppet-facter-zendserver, and easily install it into your puppet setup.