A library to update a CMS plugin led the path to explore what Composer is, the classic use cases where it shines, its limitations, and the suitable solutions for naming conflicts.

A few years ago, when I was updating one of my plugins for a CMS, I needed a library to complete the update. This library was available on Packagist, the default Composer package repository.

The components and modules used in the library worked with my plugin. However, I encountered a problem. The library version I wanted to use didn’t match the other developer’s version. Their version was incompatible with my requirements.

I was facing naming conflicts and differences in the functions between versions with “my version.”
This problem led to the exploration of what Composer is, the classic use cases where it shines, its limitations, and the solutions you can apply.

Let’s start with some context 

Over the years, the development of plugins or extensions for a CMS (Content Management System, such as WordPress, Joomla, PrestaShop, etc.) has been using the CMS-centered solution that defines components, modules, and plugins and uses the CMS framework.

Rather than using a solution centered on a CMS, you can use a modern solution centered on a library.
When you change your way of designing software, everything lies in the package library. This library is independent and can be developed and tested separately.

Therefore, the Components and modules are the entry points of the user interface. You can separate them from the package library. At the same time, you can define the calls from the library to the CMS Framework.

This is where Composer comes in.

What is Composer?

Composer is a dependency manager.

You declare what libraries you need to use in your project in a schema definition. Composer then downloads the libraries in the project and manages the libraries’ versions and dependencies between libraries.

The package library that the project installs has all the domain source code and associated Composer libraries.

Why use Composer?

There are many reasons to use Composer. Some of them are:

• Explore libraries from different areas of expertise, choose which packages are necessary for your project and control the versions of files you install.
• Support a product on different platforms using a neutral technology stack.
• Focus on the software definition and the business rules of the domain instead of solving everything.

Can I use Composer in a CMS?

Yes, you can include Composer in a plugin for a CMS. Think of Composer as a “Utility.” An example of the benefit of using Composer is replacing the usage of the classic autoloader.

The autoloader is the mechanism that helps PHP find where the source code is.

Using Composer, you can declare a single autoloader, and it will automatically load the source code.

A perfect world?

Until now, your project architecture is correct, Composer is fantastic, and thousands of PHP developers are using it.

So, it looks like a perfect world.

However, there’s an issue.

Composer works perfectly as a standalone tool. It’s designed to work only on the developer’s computer and cannot work on a live site. Also, it’s a tool that you can use at development time.

If you have two separate developers using the same libraries, it is a win-win situation. But, if they don’t have standard definitions or libraries, conflict arises.

If you plan to use Composer libraries in an extension, you must find a way to solve the potential problems.

An Example: Two developers – One conflict

Let’s look at this XT Laravel Starter example with library definitions. In particular, this project uses the Guzzle library v7.

If we have another developer using version 5 of Guzzle, installing the package and simultaneously executing the extension can result in conflicts.

For instance, an asynchronous request is sent differently in Guzzle v7 than in v5. You need a solution to prevent these differences from cropping up.

Prefixing PHP

The most common way to solve the Composer conflicts between teams is prefixing PHP. Change the source code and add a prefix wherever the conflict appears.

For instance, this is a piece of code from the Carbon Datetime Library.

I added “MyLibrary” to the namespace to identify the library in my extensions.

There are many cases/examples, but the general idea is to add a prefix to identify objects uniquely.

Can you prefix entire projects?

Yes, you can prefix entire projects, and the results are astounding!

After using Composer and manually prefixing entire libraries, it’s time to automate the prefixing. To overcome conflicts between installed libraries and prefix entire projects, you can use PHP prefixing online services. The prefixing service is a computing-intensive task.

The prefixing engine parses all files, analyzes the dependencies of all libraries, and performs several phases of processing. It runs on hardware and multi-core servers, taking advantage of parallel processing. This helps in processing the projects quickly.

Wrapping up

In this article, you’ve learned about the rationale behind the usage of Composer for plugin development.

Composer changes the design of the software. When using Composer, the main roadblock is analyzing the requirements based on your package’s available libraries and architecture. Even with such a challenge, the potential benefits of Composer far outweigh the initial difficulties (time spent on the initial learning process, integrating and installing dependencies).

Composer is a game-changer for developing a plugin, and the evolution of PHP is currently linked to Composer. The benefit is enormous. You can use the latest innovations of the PHP ecosystems and, at the same time, focus on your business.

Next

In upcoming articles, I will present three projects that illustrate the benefit of using Composer with a CMS.

1. An extension to publish from a CMS to social networks. The extension has more than +30 Social Media Integrations and uses more than +60 Composer Libraries. Since all social networks have libraries to integrate their APIs, this project has been our early encounter with PHP libraries.
2. An extension to integrate Algolia with two CMS: We took the official Algolia library, designed the business library to index different content types, and published the solution for Joomla and PrestaShop. This project has been our success case to prove that we can target several platforms in the same package with Composer.
3. A newspaper website built with Joomla in a cluster of web servers behind a load balancer. In this case, we created a distributed solution based on Redis and Laravel to coordinate the activities.

Stay tuned!

The post Using Composer in a CMS: A practical approach first appeared on PHP Prefixer Blog.

The Laravel Translations Checker package finds missing translations in the languages you support.

The post Find Missing Translations with the Laravel Translations Checker appeared first on Laravel News.

---

Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Given-When-Then (GWT) is a plugin that brings behavioral style testing to Pest.

The post Given-When-Then Plugin for Pest appeared first on Laravel News.

---

Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

Laravel Husk is a thin, light scaffolded Laravel Dusk environment that allows you to test JavaScript applications with Pest and PHP.

The post Use Laravel Dusk to Test JS-Based Applications appeared first on Laravel News.

---

Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.