Alex Vanderbist has a recent post to his site showing how to fix an issue with Imagick and the "not authorized" exception that can happen when processing PDF files.

Over the last few days we've had a couple of issues with Imagick and processing PDFs on our servers. As it turns out, these issues are caused by automatic security updates. Let's look into the issue and its solution.

The post starts with an example of the errors they've been seeing with the "not authorized" message in their Bugsnag logs. As they traced the problem they saw it was happening on older codebases too, not just new ones. Finally they tracked down the culprit: a recent security update to Imagick that added extra policies for PDFs that need to be configured for it to work as before. They provide an example of what should be added to your policy.xml file and how to bulk-patch your systems via Ansible.

On the SitePoint PHP blog there's a new tutorial posted showing how to fix Magento login issue with cookies and sessions. This issue can cause a redirect loop but can be fixed.

In this article are looking at how Magento cookies can create issues with the login functionality of both the customer-facing front-end and admin back-end, the reason it occurs and how it should be resolved.

This is also known as the looping issue, as the screen redirects itself to the same screen, even though the username and password is correct.

The post starts with some basic definitions of "cookie" and "session" and gets into more detail on how Magento stores sessions and the places it can store them. The tutorial then covers each of the cookies used and three reasons the login issues might be happening:

• Cookie domain does not match server domain
• Multiple subdomains used and Magento’s cookie configuration is incorrect
• Double front-end cookies causing intermittent login issues

For each several solutions are included with any code or SQL changes that need to happen to correct it.

Composer, the de-facto standard way to install PHP packages, has published a new release that includes a major security update. Jordi Boggiano made this comment about the release on Twitter:

After triaging/merging/fixing almost 200 issues in the last couple days, Composer v1.6.4 is out! ???? It contains a security fix and is therefore a much recommended update for all.

Other changes include fixes for:

• a regression in version guessing of path repositories
• the updating of package URLs for GitLab
• init command not respecting the current php version when selecting package versions
• exclude-from-classmap symlink handling

You can grab the latest version from the Composer site or you can use it's own self-update command.

Tomas Vortuba has continued his series covering the changes in the Easy Coding Standard for Symfony-based applications and the changes in version 4. In this new article he covers the updates around line breaks and legacy fixes.

Legacy code prevention, lines automated and clear naming of classes in huge projects. That all is coming to Coding Standard 4 (still in alpha).

Are you curious what work will now these 4 news fixers handle for you? Look inside.

He then goes through each of the changes and includes both the configuration changes to use it and what code changes it will make:

• Let Coding Standard handle Line Length for You
• Choose Line Length to Match Your Display
• Keep Legacy Far Away with New ForbiddenStaticFunctionSniff
• Prevent & references with ForbiddenStaticFunctionSniff
• Clear Child Class Naming Once and For All with ClassNameSuffixByParentFixer

You can find out more about the standard in this project on GitHub.

Alison Gianotto has an article posted to her since basically answering the "now what?" question resulting from you running Composer as root on your system.

Composer is a PHP dependency manager that’s used in just about any modern PHP application, and it works similarly to how Bundler works for Ruby.

Even though Composer itself gives you a warning about not running it as root, lots of people disregard this warning and run it as root anyway. We run into this issue a lot on my open source asset management project, Snipe-IT, so I figured I’d write up how to fix this if you inadvertently (or advertently) ran composer as root.

She starts by describing the difference between "installing Composer as root" and "running the Composer install as root" (two very different things). She points out that, while Composer tries to prevent the second but permissions errors sometimes cause people to move forward as root anyway, despite the warning. She then shows how to fix the permissions issues so it can be run as a normal user, updating the files in .composer for the root account and re-running the install.

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.

On the SitePoint PHP blog Thomas Punt continues his series about how you can contribute back to the PHP language. In his previous post he talked about contributing to the PHP manual. In this latest part of the series he moves into something with a bit more complexity: contributing to the core of the language itself.

Previously, we covered contributing to PHP’s documentation. Now, we will be covering how to get involved with PHP’s core. To do this, we will be looking at the workflow for fixing a simple bug in the core.

Since submitting new features to PHP has already been explained pretty well, we will not be covering that here. Also, this article does not seek to teach PHP’s internals. For more information on that, please see my previous posts on adding features to PHP.

In this article he assumes you at least already have a working knowledge of the PHP source and how to locate/update code and execute it. He focuses instead on the bugfix process and workflow needed to:

• find a bug to fix
• create a test to reproduce the issue
• use a debugger to find the exact spot where the problem is
• and create a simple fix

In this case it's a pretty simple issue to correct, but there are much more complex things that would require more work than just a simple "if" check. This guide can help you get started on the correct workflow, however, and be sure you're handling things as the project expects.

On the Ethode.com blog they've shared some hints for working with legacy code to help you more effectively refactor your way out of the "spaghetti code" you might have right now. These are more general tips and aren't really PHP (or even really web application) specific but they're a good starting place for any refactoring effort.

Legacy code is software that generates value for a business but is difficult for developers to change. [...] The longer this goes on, the more frustrated customers get with the software due to quirky defects, bad user experiences and long lead times for changes. Developers are afraid to make changes due to the "Jenga effect" -- as one piece of code is changed or removed, it often leads to new defects being introduced in the system in sometimes seemingly unrelated places. This compounds into what is known as "technical debt".

They continue on talking about what "spaghetti code" is, how it can happen and some of the warning signs you can use to determine just how far down the rabbit hole you and your code are. They talk about "The Big Rewrite" everyone dreams of but points out that this is almost never a practical path. Instead they offer some good things you can do to help fix the problem: quarantining the problem, refactoring relentlessly, keeping it simple and "doing the dishes" as you go rather than letting the changes pile up.

Lorna Mitchell has a post on her site that wants to help you out when Composer reports a "lock file out of date" warning when you try to update your Composer dependencies. She provides three options to help resolve this issue.

Composer is dependency management for PHP, and it consists of two main files: [composer.json and composer.lock]. Crucially, the composer.lock also includes a hash of the current composer.json when it updates, so you can always tell if you've added a requirement to the composer.json file and forgotten to install it.

The post includes three different ways to correct the warning message:

• Option one: upgrade all of the things
• Option two: try to work out which composer.json change caused this
• Option three: do nothing, safely

The first two options are preferable to the last one (essentially overriding the error) but it could be used in cases where you think Composer is just getting things wrong.

In a post on the Zend Developer Zone they've introduced a new offering from Zend as a part of their Zend Studio IDE - PHP 7 Express. This tool makes it easy to migrate your code to a working state with the upcoming PHP 7 release.

The PHP 7 revolution is well upon us and at the end of the year we should be seeing an official release. To help you prepare for the expected changes, the upcoming version of Zend Studio – Zend Studio 13, includes a new migration tool called PHP 7 Express. PHP 7 Express scans your PHP code for potential compatibility issues with PHP 7 and supplies you with all the information you need to get your projects ready for migration to PHP 7.

They give an example of refactoring as it relates to the uniform variable syntax changes and removing deprecated function calls. They walk you through the use of the tool (inside the IDE) and show an example of the results, how you can jump to the code for each of the issues listed and the recommendations it provides to correct it.