This is the story about how I wasted 3 days, but also, which is more important, how I set up continuous integration for WP Pusher with CircleCi. With a continuous integration service, you can have your tests run on every commit and ensure that nothing is broken. That is, if you have some tests to run of course.
TL;DR You can now include a wppusher.php file in your WordPress packages with all the shell commands you wish to run after WP Pusher has installed or updated a plugin or theme. That includes running Composer. Also, WP Pusher now supports GitLab!
Composer seems to be something everyone is talking about in the WordPress community these days. It is a great tool for developer productivity and code reuse. However, if you are trying to use Composer to distribute your WordPress product to end users, you might be doing it wrong ™.
During the beta testing of WP Pusher, I have seen numerous examples as to how WordPress developers use Git to manage their projects. WP Pusher is opinionated in terms of how your Git setup needs to look, in order to use the service. In this post, I will try to explain why.
These days, I’m working on the plugin that makes WP Pusher update themes and plugins directly from GitHub. Having been away from serious WordPress development for quite a while, I thought it would be interesting to highlight a few of the approaches I have been using during the development of the plugin.
I think most people can agree that WordPress seen from a user perspective is pretty good. It’s easy for users to create and publish content, and plugins and themes can easily be installed from the official repositories. If you can use Microsoft Word, you can pretty much use WordPress.