Improved Composer Support for PublishPress Plugins

Today we are pleased to announce much improved Composer support for PublishPress plugins.

Composer is a tool that developers can use to manage plugins or entire WordPress sites.

Previously, it was possible to install the free version of our plugins with Composer. But it was more difficult to install the Pro versions of the plugins.

If you're using pure Composer, or a boilerplate such as WPStarter or Bedrock, you'll be able to use PublishPress Pro plugins. If you're not using Composer, this change likely will not impact you at all.

In order to provide better support for Composer, we made two key changes:

  • PublishPress libraries are now prefixed.
  • We're using a different /vendor/ directory.

I'm going to give you a high-level overview of the changes. For specific instructions on how to use PublishPress plugins with Composer, please see this guide.


PublishPress libraries are now prefixed

We often ran into conflicts with other plugins that were using the same libraries.

A common example was with the Psr/Container library. Some other plugins were loading version 1 and we needed version 2. Some libraries will detect and solve these version conflicts, but many will not. If a library didn't have this safeguard, we would see fatal errors because you can’t have different versions of classes on the same namespace.

Our solution was to clone these libraries, and prefix them with our own namespace. We refactored the code and used our cloned versions inside the PublishPress plugins.


We're using different /vendor/ directories

In this section, I'm going to show how the folder structure of PublishPress plugins has change. First, I'll give examples using vanilla WordPress. These are mostly just for background information and they probably won't make a material difference to your site. Second, I'll show changes using Bedrock and these are important changes that will have an impact for anyone using Composer.

Changes for vanilla WordPress

First, let's take a look at an example using a regular WordPress site. This screenshot below shows our old folder structure, using PublishPress Future, which is in the /post-expirator/ folder. The dependencies are in the /vendor/ folder.

Our old folder structure, using PublishPress Future

This next screenshot shows the new folder structure. All of the libraries used by PublishPress plugins have been moved from the /vendor/ folder to the /lib/vendor/ folder.

Our new folder structure, using PublishPress Future

Changes for Composer sites

Now let's see some examples using Bedrock. The folder structure will now be different. This screenshot below shows the old site structure. Some key PublishPress dependencies were inside the top-level /vendor/ folder so they were not publicly accessible.

Our old folder structure, using Bedrock and PublishPress Future

The next screenshot shows the new folder structure. the PublishPress plugins’ dependencies are now under the /web/ folder so they are publicly accessible.

Our new folder structure, using Bedrock and PublishPress Future

Let me add a quick note about folder names before we move on. You may notice that the screenshots above are from vanilla WordPress and show the /post-expirator/ folder, while the screenshots below for Bedrock show /publishpress-future/. This is a legacy settings for WordPress.org support.


Over to you for feedback

We've worked with a good number of very helpful PublishPress customers to complete this refactoring.

This solution may not be to everyone‘s liking. For example, some developers don't like exposing the libraries in the /web/ folder.

However, our new approach is definitely better than the previous situation. And this new approach works for the customers who have tested so far.

If you have any feedback, we'd love to hear from you. Please leave a comment below, or open a support ticket.

Leave a Reply

Your email address will not be published. Required fields are marked *