I'm on the Internet
I recently had a chat with Dave from Developer On Fire. We talked about a bunch of things – what I work on, how I got started in programming, as well as some thoughts on remote working and maintaining a healthy work/life balance.
The post is here, or you can listen to the audio below.
Earlier in the week, I joined Jeff from WPTavern to chat about WordPress Security, the recent WordPress 4.2.3 release, and my favourite food.
Check out the full article here.
lol, I wouldn’t1.
1. If I absolutely had to, I wouldn’t do it the same as Ryan.
ZYpp is the dependency solver used by OpenSUSE (and its PHP port in Composer), it was born of the need to solve complex dependency trees. The good news is, WordPress doesn’t have the same problem, and we shouldn’t create that problem for ourselves.
One of the most common-yet-complex issues is determining how to handle different version requirements by different packages. If My Amazing Plugin requires WP-API 1.9, but Your Wonderful Plugin requires WP-API 2.0, we have a problem. There are two ways to solve it – Windows solves it by installing multiple versions of the dependency, and loading the correct version for each package. This isn’t a particularly viable option in PHP, because trying to load two different versions of the same code in the same process is not my idea of a fun time.
The second option, which ZYpp solves, is to try and find a mutually compatible version of the dependency that each plugin can use. The biggest problem with this method is that it can’t always find a solution. If there’s no compatible way of installing the libraries, it has to throw back to the user to make the decision. This isn’t a viable option, as 99.999*% worth of users wouldn’t be able to tell the difference between WP-API versions 1.9 and 2.0, and nor should they.
But there’s a third option.
Code libraries are, by their nature, developer facing. A user never really needs to know that they exist, in the same way that they don’t need to know about WP_Query. In WordPress Core, we strive for (and often achieve) 100% backwards compatibility between major versions. If we were going to implement plugin dependencies, I would make it a requirement that the code libraries shoulder the same burden: don’t make a user choose between upgrades, just always keep the code backwards compatible. If you need to make architectural changes, include a backwards compatible shim to keep things working nicely.
This intentionally moves the burden of upgrading to the developer, rather than the end user.
If we’re going to require library developers to maintain backwards compatibility, we can do away with version requirements (and thus, removing the need for a dependency solver). If a plugin needs a library, it can just specify the library slug.
If we were to implement plugin dependencies, I think it’d be a great place to introduce auto updates being enable by default. There’s no existing architecture for us to take into account, so we can have this use the current WordPress best practices. On top of that, it’s a step towards enabling auto updates for all Core releases, and it encourages developers to create backwards compatible libraries, because their library will almost certainly be updated before a plugin using it is.
I’m still not convinced plugin dependencies is a good thing to put in Core – it introduces significant complexities to plugin updates, as well as adding another dependency on WordPress.org to Core. But it’s definitely a conversation worth having.
Rohan Victor Pendergast, born 18:33 on 10/5/15.
Boy and Bear seemed to be what got him moving, so here they are now.
(PS: Should you ever find yourself in such a position, I highly recommend finding a hospital that gives the parents champagne for having a babby on Mother’s Day.)
Dear Diary,
Today I went skydiving, whilst barely leaving the ground. It was a bunch of fun.
<3, Gary.
