Tag: composer

Semantic Versioning : Version 0 is unstable

We’ve been using Semantic Versioning for quite a while at work now.  It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.

Turns out, however, that I missed a small, but important part of the standard.  All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1.  Here’s the relevant quote:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly.  Gladly, for us, composer does the job:

The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.

 

composer-plugin-qa – Composer Plugin for PHP Quality Assurance Tools

composer-plugin-qa is a Composer plugin which adds all the most popular PHP quality assurance tools as composer scripts, so that you don’t have to install and set them up one by one.  The list of tools includes the following:

  • PHPUnit: Testing Framework
  • PHPCOV: CLI frontend for the PHP_CodeCoverage
  • Paratest: Parallel testing for PHPUnit
  • DbUnit: Puts your database into a known state between test runs
  • PHPLOC: A tool for quickly measuring the size of a PHP project
  • PHPCPD: Copy/Paste Detector
  • PHP_Depend: Quality of your design in the terms of extensibility, reusability and maintainability
  • PHPMD: User friendly frontend application for the raw metrics stream measured by PHP Depend
  • PhpMetrics: Static analysis tool, gives metrics about PHP project and classes
  • PHP_CodeSniffer: Detects violations of a defined set of coding standards
  • PHP-CS-Fixer: A tool to automatically fix coding standards issues
  • Security-Checker: Checks if your application uses dependencies with known security vulnerabilities

This list is very similar to the one in my other recent post.

Have you tried Composer Scripts? You DO not need Phing.

“Have you tried Composer Scripts? You may not need Phing.” is a nice blog post showing how to use Composer scripts to solve simple build and deployment automation.  There’s plenty of good advice in there.

However I have one issue with it.  It’s the “You may not need Phing.” part.  Irrelevant of your use of Composer scripts, you DON’T need Phing.  Phing had its time.  It was one of the first build and deployment tools for PHP and it was better than all the alternatives at the time (manual builds, custom shell scripts, or tools from other programming languages).

Those days are long gone and we have better tools now.  If you are still using (or even considering using Phing), I beg you to look another way.  Check out Deployer.  Check out Robo.li.  Check other alternatives.  Don’t use Phing.

What’s wrong with Phing? Well, I can sum it up in one and one reason only.  It’s XML-based.  Yeah, that’s right.  Phing routes come from Apache Ant, which is a very common build tool for the Java world.  And Java world is full of XML.

In the year of 2018, we’ve figured out better ways.  Both JSON and YAML are better alternatives to XML for both humans and machines.  JSON and YAML are easier to read and generate.

Furthermore, even XML is not the most appropriate format for what Phing is working with.  Sure, as long as you can stick with the basic configuration of existing tasks and options – it doesn’t make much difference.  But at some point, you’ll need to extend and customize your build and deployment process.  And you’ll eventually end up writing PHP code using XML syntax.  And trust me, there is no fun in that at all.

Use PHP to write PHP code.  Use PHP tools for your PHP projects.  We have these now and they are great.  At work we are using Robo.li very extensively and it works amazing!  You don’t have to use it.  Pick whatever works for you.  But if Phing works for you, you’re probably doing something wrong.

Oh, and yes, Composer scripts are awesome too.  Try them out, if you haven’t already.

Updating WordPress with Composer and WP-CLI

The other day I came across this blog post by Mark Jaquith, who is one of the lead contributors to WordPress, in which he describes his process of updating WordPress plugins with WP-CLI and Git.  I think a lot of people these days are trying to use Git for version control and automate their deployments, so WordPress developers aren’t an exception, and Mark’s post is a useful resource for that.

With that said, however, I think there is a better.  At work, we’ve been dealing with quite a few WordPress-based projects, and automation of builds and deploys is very important to us.  So we’ve taken a different approach.

The initial inspiration for our approach was taken from this blog post by Scott Walkinshaw of the amazing Roots team.

Yes, that’s right, we use Composer to manage the WordPress, plugins and themes, both during the initial installation and the upgrades later.  But we’ve taken it a step further by also integrating the WP-CLI to our setup, which you can find in our project-template-wordpress GitHub repository.

I have oversimplified both the development and deployment process below, mostly for clarity.   (We do a lot more automation for our needs.)

During the development:

  1. Configure Composer to install WordPress into the webroot/wp folder.
  2. Configure Composer to install plugins and themes into webroot/wp-content folder. (Notice: we use a different wp-content folder location from the default WordPress one).
  3. Adjust wp-config.php for the new paths and drop it into the webroot/ folder.
  4. Add Composer’s vendor/ folder, and both webroot/wp and webroot/wp-content to .gitignore.
  5. Add all required themes and plugins to the composer.json.
  6. Run composer update to create or update the composer.lock file.
  7. Commit both composer.json and composer.lock, as well as .gitignore and any other files you modified.
  8. Add a WP-CLI script that automates activation of plugins and sets the current theme.
  9. Push your changes to the git repository.

During the deployment:

  1. Clone or pull the changes from the git repository.
  2. Run composer install to fetch and install specific versions of WordPress, plugins, and themes, from the composer.lock file.
  3. Run the WP-CLI script to finalize the installation or update with the plugin activation, theme selection, etc.

While it might look a little bit more complicated than what Mark and Scott described in their respective blog posts, I think this is a better approach for the following reasons:

  1. Use a specialized tool to solve each problem.   Git is great for version control, so that’s what it should do.  Composer is great for managing dependencies, and that’s what WordPress and its themes and plugins are for your project.  WP-CLI is great for automating WordPress tasks.
  2. Keep the git repository clean and simple.  When working on a project, we never ever modify the code of the WordPress or any of its themes or plugins.  And our setup enforces this approach.  If you need to change the WordPress source code for a particular project, you are probably doing something wrong.  If you need to change the plugin’s source code or the theme’s source code, you are probably doing something wrong again.  Instead create child theme or your own version of the plugin and install those with Composer, keeping the plugin or theme related code changes in a separate repository.
  3. Easily extendable and customizeable.  Git, composer, and WP-CLI are great tools and we love using them.  But the world is moving forward and there are constantly more and better tools to help with the complexities of the web development.  Our setup expands and extends to welcome any tools that we find useful.  For example, we have integrated with Robo, PHPUnit and PHP Code Sniffer, TravisCI, BitBucket Pipelines, and many other tools over time.  We’ve also said good bye to a few that became obsolete or to which we found better alternatives.

Anyways, project-template-wordpress works quite well for us and I hope you’ll find it useful.  Give it a try and let us know if you find any issues or improvements.   Pull Requests are welcome. :)

Composer Local Packages for Dummies

Composer (in combination with Packagist) is one technology that has significantly changed the ecosystem of the PHP programming language.  Anybody working with PHP in this day and age MUST know how to use composer.  However, not everyone does.  So here is a nice tutorial on how to get started with Composer if you already have a large legacy application that you want to split into packages and use composer to manage them – Composer Local Packages for Dummies.