In a recent article Théo Fidry covers a topic that's become common with the use of Composer and various PHP packages: managing dependencies.

When you are creating a PHP application or library, you usually have 3 kinds of dependencies:

• Hard dependencies: what your application/library needs to be able to run
• Optional dependencies: for example a PHP library can provide a bridge for different frameworks
• Development dependencies: debugging tools, test frameworks…

He then works through several of the issues involved with using each including having too many dependencies, untestable dependencies and conflicts. He then counters these with some helpful suggestions around them including the use of phars and using multiple repositories to break down the package and make it easier to manage their dependencies.

On the Delicious Blog Ian has written up a post with a proposal for WordPress suggesting that it introduce some functionality to help with dependency management and possible conflicts between the needs of plugins.

‘Dependency hell’ is a problem faced by all software, and it has been rearing its ugly head in the WordPress space over the last few years with more and more plugins using third-party libraries of code. [...] The most frustrating thing about this issue is that it’s caused by having the best of intentions! Developers use third-party code to be efficient and avoid reinventing the wheel. The code has been written by others and used and battled tested by many.

The WordPress community has a hard enough time already trying to get onboard with Composer (unlike the rest of the PHP world), without it getting tarred with the wrong brush!

He points out that, while this does have to do with packages installed through it, Composer itself isn't the issue. He offers a few suggestions and what he sees as an "ideal approach" to the problem based on some of the ideas presented here. He breaks it down into four types of code: third-party installed via Composer, Composer packages in core, custom Composer behavior and the idea of "package sandboxing". He includes some of the considerations to make this happen and plans on how the idea can move forward.

The Scotch.io site has a tutorial for the WordPress users out there needing an ecommerce solution and wanting to integrate it seamlessly into your site. They show you how to integrate Snipcart, part of a platform that handles a lot of the common ecommerce tasks for you.

Even though an exponential amount of online tools keep popping up, WordPress remains a domineering web behemoth. More than 25% of active sites run on the famous CMS. Quite a chunk of the whole world wide web.

[...] Many front-end developers I've met and talked to enjoy working with a lean, quick e-commerce solution like Snipcart. But, they also want to give more autonomy in familiar CMS to their merchant clients. Since many of them use WordPress, I thought I'd write this article to provide them with a useful resource.

The post then breaks the process down into a few different steps, each including code and screenshots as needed:

• Installing the required plugins
• Show products in the theme
• Integrate Snipcart's shopping cart
• Update inventory with webhooks
• Add Snipcart data to WordPress admin
• Quick edit of inventory

If you're interested in the full code required for the integration, you can see it over on this GitHub repository.

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.

In this post to his site Christian Mackeprang shares what he calls "Newton’s 3 Laws of Software Craftsmanship" - some guidelines to follow in your development to help make things a bit more sane.

Are there unbreakable laws ruling the process of software development? I asked myself this question while reflecting on a recent project, and the answer leads to many conclusions, some already known and some more revealing.

Scientific laws reflect reality and cannot be broken. They have strong implications onto how we build things. For instance, there is no point in building a car with vertical propulsion once you’ve observed that the law of gravity will prevent your car from drifting into space anyway. But software lives in the logical world. Does it really follow any laws?

He shares his three laws and provides a bit of background for each:

• "Under fixed circumstances, every solution will behave the same way, unless it has been modified."
• "The impact of a technical decision is directly proportional to the size of the project and to how much of it is affected."
• "Every technical decision comes with an implied tradeoff."

He also includes a "how to be mindful" section for each of the laws, giving you both practical and mental tips to help you follow it.

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.

The SitePoint PHP blog has a new post by Jeroen Meeus that wonders if MVC is a solution or a problem when it comes to developing web applications.

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I’ve had enough. Stop telling me what to do and show me those kittens instead. [...] When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don’t use it, but seldom lets those they’re frowning upon ask why. [...] MVC doesn’t solve the Code complexity problem. It doesn’t solve the code reuse or no-flexibility problem either. And it doesn’t guarantee decoupled code.

He goes on to talk about how design patterns don't "solve problems". Rather they help us as developers by providing a best practice we can follow to get the job done. He suggests, though, that MVC has become "the new Singleton" but it has been used so much in so many different ways, it's boarding on the point of being abused.

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them – if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.

On the Docnet.nu blog today they've kicked off a series looking at the use of streams and SSL in PHP and asking if you're doing it wrong in your current applications. The focus is more on the security aspect, breaking it down into a set of common problems (and how to work around them).

The upcoming PHP 5.6 release brings with it a number of improvements to encrypted PHP streams, both internally and externally. In these articles I will try to cover the most important changes, and how they affect your code. This article will focus on how to get the best security level in code that needs to be run on PHP versions below 5.6, and highlighting some of the gaps in the currently available functionality. Version 5.4.13 is the earliest version that supports all the options described below - and if you are running something earlier than this, then you really should consider upgrading to at least the latest version of the 5.4 series 1.

Their list is made up of six different problems:

• Problem 1: Peer Verification
• Problem 2: Cipher Lists
• Problem 3: Protocol Support
• Problem 4: TLS Compression Attack Vulnerability
• Problem 5: Cipher Order
• Problem 6: TLS Renegotiation Attacks

Each problem comes with a brief description of what it is and why it's an issues. Some also include code snippets showing how to correct the issue, usually relatively simply.

While not specifically related to PHP, this new post from Timoh looks at the idea of "aggressive password stretching" to help with a common problem in password-based systems - the poor choice of passwords from the application's users.

Practically speaking, “weak” means a user generated password will not contain enough guessing entropy to resist an adversary who managed to gain the user database dump, and who is able to run efficient offline attack against leaked hashes. Here comes in the need to make adversary’s job harder, which is achieved by using the above-named algorithms.

He doesn't talk much about the actual password hashing itself, instead focusing on how the password stretching - the addition of more information not from the user (usually an automated source) to increase it password entropy. He goes through some of the math about how much extra work is required for an attacker with this method and some of the problems that can come with it. He talks about how much time should be spent in the hashing of the passwords and suggests that it's "a matter of finding a sweet spot between you and attacker’s patience and the security gain" and not just about the security.

A bit more on the PHP-specific side, he briefly looks at the password_hash function and some of the defaults the more current frameworks use (hint: bcrypt all the things).

Proper password hashing is clearly not enough to make sure the password hashes are not weak. The other half of the job is a good password policy. No algorithm or setting will save passwords like “password” or “12345” etc. This is why we need to make sure the user’s password will initially contain enough entropy itself.

In this recent post to his site, Anthony Ferrara takes an the phrase "reinventing the wheel" and wonders if, maybe, it's not such a bad thing sometimes.

"Don't Reinvent The Wheel" is a phrase that we hear used all the time in software development. Usually it's used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can't stand the implication of the phrase. Therefore, I can't stand it when people use that phrase without understanding what it really means. Let me explain...

He notes that, while there might be things out there that do something well, it doesn't mean that the "wheel is perfect" and you shouldn't venture out and try something new. He points out two places where it could be good - when a general solution doesn't work and for education/research.

Even as a senior developer, if you never try to reinvent the wheel from time to time, you'll never push your capabilities. You'll never expand your conceptual model of problems. And if you never do that, the world will blow past you.