Today I published the pre launch page for my side project Lapisense. In case you missed it, it’s a hosted activation and updates API for WordPress based products. If you don’t like running a plugin that does this for you, Lapisense might be a nice fit for your products.
I got a ton of great feedback already, but one of the questions really stood out to me. Why did I launch a product in such a crowded market? There are competitors out there, WP Updates and Freemius to name a couple. Both are really solid services already. But still, I wanted to explore this market, because I think there is more to achieve. Continue reading Launching a product in a crowded WordPress market
There is a lot of confusion in the WordPress ecosystem when it comes to the issues around bundling dependencies. Peter Suhm has published a detailed post about this exact issue: A Warning About Using Composer With WordPress, where I have left the following (partial) comment:
So imagine both of us loading library x in our plugins, both requiring a version that’s incompatible with each other. No matter how well tested your plugin is, if I get a chance to load my autoloader before yours, I can load a version of the library that is not compatible with yours and your plugin will break (at least, the end user will see it like that and the horror of finding the culprit begins)…
This obviously is not a Composer issue, but related to the way WordPress loads its plugins. It’s also not a well known issue, since Composer isn’t used a lot in the WordPress ecosystem (yet!), especially not in distributed plugins. But as Composer becomes more used, more collisions like this will happen. Without a proper dependency management system in place, this is really hard to solve.
My WordPress Composer Installer proof of concept is as close to solving this issue as I’ve ever been. If there is anyone more experienced with the plugins installer in WordPress and maybe knows their way around Composer as well, I could use some help.
I’ve been working on a proof of concept for solving dependency management in WordPress plugins for a while now. It was in a private repository on GitHub, where I would invite some people in to work out the most obvious issues, while keeping it a bit on the down-low (this is a big change, potentially, after all).
Now it’s time though. The WordPress Composer Installer repository is now open to the public. Note that this is not more than a proof of concept, albeit it a working one. There are some hoops to jump through to get this working, but all these steps can be automated once I make this a fully featured plugin.
Recent blog posts like Ryan McCue’s take on solving dependencies and Gary Pendergast’s response to that are likely to fire this discussion up again. I will publish a more detailed post about why I think this is important, but I’m on a short vacation while I’m typing this and should probably be out enjoying sunny London. ☀️