Anyone who has used VVV for local site development has probably taken some time to peek under the hood to see how it accomplishes its magic. If you haven’t, take a look at the bundled [cci]provision.sh[/cci] script.
I’ll wait.
One of the neatest parts of the script is how it manages custom Ubuntu repositories. First it adds the repositories’ certificate signatures, then it adds the repositories. Tools like PHP and Nginx are then downloaded from alternative locations that contain more up-to-date versions that the default.
Actually, this is a pattern often used within Linux to pull down alternative distributions of popular projects. Sometimes you want a more modern version. Other times you want to roll back to an earlier one for the sake of compatibility with other tools.
Whatever the reason, allowing alternate repositories to be registered with Ubuntu’s various package managers is a powerful feature.
It’s also something I’d like to see in WordPress.
Plugin Management
Right now, there is one and only one repository from which you can download and install plugins – WordPress.org. It’s limited to free plugins only, and that’s a hefty limitation for any package management system.
Some plugins and themes come with scripts that register alternative download locations, but these are often limited to just keeping the theme/plugin in question updated. There is no additional discovery feature built-in to allow discovery of new systems from different hosts.
I realize this will be a bit controversial, but I’d like to see the WordPress.org plugin API standardized, documented, and opened to the public. I’d also like to see WordPress extend a way to add alternative repository paths to the system – repositories that implement the same API as WordPress.org.
This would allow communities like Easy Digital Downloads or StudioPress or WPMU.dev to make their libraries discoverable and installable from within the WordPress admin the same way the core repository is.
Powerful for the community? Absolutely. Dangerous to the community? Potentially.
By placing discovery and update maintenance in the hands of people other than WordPress.org we do open the system to potential abuse. But I honestly see no more danger in this than open-sourcing WordPress to begin with.
I can see various potential implementations of a repo whitelisting system – as rough as adding a filter or as streamlined as an oAuth workflow embedded within the admin. However we do it, this would empower developers to easily distribute beta updates outside of the core updater. It would allow marketplaces to establish digital storefronts integrated with the smooth admin experience of WordPress itself.
It would bring us more inline with the goal of democratizing publishing by directly democratizing the publishing of WordPress extensions.
WordPress 4.0 is just around the corner, but it’s never too late (or early) to start brainstorming ideas for future versions. Do you see any value in open repository registration? Do you see any danger? Is this something we should pursue for a future version of WordPress?
