How to install Composer inside WordPress
Sunday, March 26th, 2017 | Programming
WordPress has an ancient and ugly codebase. When you are writing plugins, you often want to make your code less horrible and use Composer to bring in dependencies as normal. How do these things fit together?
The first thing I tried was to create plugin-specific dependencies list. Inside the plugin directory, I created a composer.json> file, then ran the install and uploaded it.
This approach works fines when you only use a dependency once and no other plugin uses the same dependency. However, when I wanted to re-use a library in another plugin I had a problem. If I included it twice it would crash.
Installing Composer globally
The solution I came to was to do a global install of Composer. I created a composer.json file in the root and listed all of the dependencies I needed for my plugins in there.
Then, in each plugin, I checked for the file and included it.
if (file_exists(sprintf('%s/vendor/autoload.php', ABSPATH))) {
require_once sprintf('%s/vendor/autoload.php', ABSPATH);
add_filter('the_content', 'simple_related_posts', 30);
} else {
add_action('admin_notices', function() {
echo '<div class="notice notice-warning is-dismissible"><p><em>Simple Related Posts</em> plugin requires <strong>Composer</strong>.</p></div>';
});
}
Drawbacks to this approach
This means plugins are no longer self-contained. You have to install the plugin and add the dependencies to your central composer.json file. That is messy.
With the code above, it does not check if the _correct_ dependencies are there. This is something you could add in. However, given the problem above, it seems like it would require so much manual management anyway that I would know what was going on.
Optimise for performance
If you are using Composer on production, do not forget to optimise the autoloader before uploading your files.
composer dumpautoload -o
Conclusion
Personally, I would rather lose plugins being entirely self-contained and benefit from Composer libraries. This approach works well for me because they are purpose-written plugins for my blog.
However, this approach would not work well if you were publishing your plugins as most WordPress users would not know what was going on.
WordPress has an ancient and ugly codebase. When you are writing plugins, you often want to make your code less horrible and use Composer to bring in dependencies as normal. How do these things fit together?
The first thing I tried was to create plugin-specific dependencies list. Inside the plugin directory, I created a composer.json> file, then ran the install and uploaded it.
This approach works fines when you only use a dependency once and no other plugin uses the same dependency. However, when I wanted to re-use a library in another plugin I had a problem. If I included it twice it would crash.
Installing Composer globally
The solution I came to was to do a global install of Composer. I created a composer.json file in the root and listed all of the dependencies I needed for my plugins in there.
Then, in each plugin, I checked for the file and included it.
if (file_exists(sprintf('%s/vendor/autoload.php', ABSPATH))) {
require_once sprintf('%s/vendor/autoload.php', ABSPATH);
add_filter('the_content', 'simple_related_posts', 30);
} else {
add_action('admin_notices', function() {
echo '<div class="notice notice-warning is-dismissible"><p><em>Simple Related Posts</em> plugin requires <strong>Composer</strong>.</p></div>';
});
}
Drawbacks to this approach
This means plugins are no longer self-contained. You have to install the plugin and add the dependencies to your central composer.json file. That is messy.
With the code above, it does not check if the _correct_ dependencies are there. This is something you could add in. However, given the problem above, it seems like it would require so much manual management anyway that I would know what was going on.
Optimise for performance
If you are using Composer on production, do not forget to optimise the autoloader before uploading your files.
composer dumpautoload -o
Conclusion
Personally, I would rather lose plugins being entirely self-contained and benefit from Composer libraries. This approach works well for me because they are purpose-written plugins for my blog.
However, this approach would not work well if you were publishing your plugins as most WordPress users would not know what was going on.
