Check plugin compatibility before upgrading

rossharvey · 2013-04-25 22:40:35

Hi guys,

I’m running 4.4.1, and it’s all fine (except smd_thumbs isn’t working, hence trying the upgrade), is there any way to tell if my used plugins will fail, or is 4.5 hot on backwards compatibility?

tye · 2013-04-26 03:09:21

I think you just got to keep an eye on the plugins… some sort of system would be nice, maybe on txp resources – compatible with txp 4.x.x or something

Bloke · 2013-04-26 08:08:35

tye wrote:

maybe on txp resources – compatible with txp 4.x.x or something

fwiw I’ve put this exact system in place on the new .org. Just gotta get me and a few others some breathing space to tidy things, up, port the relevant parts of the old database over, upgrade stuff, fix the CSS, alter the site layout to make better use of screen real estate, make it responsive, improve the search, fix the tags, make it possible for people to securely report plugin compatibility,. and launch it.

All in a day’s work ;-)

Last edited by Bloke (2013-04-26 08:09:07)

philwareham · 2013-04-26 09:42:59

Lol. When things quiet down a bit for me with client work I’ll continue my rebuild of the Textpattern sites. Things would be a lot easier if I had no clients whatsoever :)

Gocom · 2013-04-26 12:31:19

If we and plugins used Composer, handling dependencies would be stupidly easy. One command and you exactly know what works with what version, and what depends to what. If there is a common set that can work together on a specific version, it will also be able to update to that – with that same single command.

I do strongly believe we shouldn’t do our own shit where possible, but use stuff that already exists. Newer method of handling libraries, plugins and their dependencies would be one. As an option at least.

That said, I (or we, I should say) actually are using Composer to install and handle plugins, or are trying to. You can find my latest releases as a composer packages. This makes handling plugins soooooooooooooooooooo easy, especially when working with VCS and larger teams.

If I wanted to install one of those plugins, I would just add its name to composer.json file. E.g.

{
    "require": {
        "rah_terminal_textile" : "0.1.*"
    }
}

And its done. That is there is no more to it. You don’t have to download anything, do anything, or commit third party dependencies to the VCS. That single line would automatically install rah_terminal_textile, all its dependencies (such as rah_terminal plugin or any library) and allow updating to any patch released within 0.1.x as dependencies allow.

This is possible due to that tiny rah_blobin which imports plugins from filesystem to the database, and runs updaters/installer conditionally. I do tho hope that this was supported by core, and that the core at least used PSR-0 and had API of sorts so I could build a installer for Composer. With Composer installer you wouldn’t even have to install that one extra plugin package the normal way, but could just fire up Composer. We use rah_blobin only because our whole codebase doesn’t yet use Composer (we need manual import runs).

Even better would be if Textpattern too was available as Composer package (as a meta-package/installer). Composer could that way even install Textpattern for you, and you could have Textpattern itself as your dependency.

Last edited by Gocom (2013-04-26 12:36:29)

philwareham · 2013-04-26 13:08:13

@Gocom

Sounds interesting, I’ll play around with Composer and rah_blobin. I know lots have people have been talking up Bower recently for front-end development so it seems these packaging systems are going to become really popular.

Bloke · 2013-04-26 13:08:39

Gocom wrote:

I do strongly believe we shouldn’t do our own shit where possible, but use stuff that already exists. Newer method of handling libraries, plugins and their dependencies would be one.

Fine by me. Anything that makes it easier is good in my book. But I don’t quite (yet) figure how Composer helps us to offer a compatibility matrix for future and backwards compatibility.

For example, rss_db_admin_manager. Handy plugin. No current maintainer. Version available from official download link delivers old version which needs patching to make it work in 4.0.6+. Trawling the forum to find the right code is a pain even if it is linked from the 1st post.

Sure, one option is to bundle the patched version on .org (and that system’s in place, iirc, on the new .org). Another option is for someone to adopt it (also done in new .org) but nobody has yet stepped up to take ownership of the plugin so that might never happen. How would Composer allow someone to obtain the correct version for, say, future Txp v7.4.2 if the plugin code is not maintained by anyone?

The plugin may still work under Txp v7.4.2. Or it may only work if someone adds a couple of lines to it as a patch. Or it might not work at all, and thus becomes a true orphan until someone adopts it, or writes a new comparable plugin.

This notion of “Works”, ‘Doesn’t work” and “Works if…” was what I started tinkering with on .org. So, for example, the author states “Works on 4.0.6” and that carries the most weight. People who download it and try it on v4.0.5 and v7.4.2 ought to be able to report that it either “works” on that version, “doesn’t work”, or “will work if you apply this patch”. The idea being that, over time (providing we can keep the bots out), .org becomes a knowledge base updated by the community that maintains a compatibility system so anyone can filter for plugins that “will work” or “might work” (i.e. will work, if… such and such is done to the code) on v7.4.2.

The upshot is that, prior to upgrade, people can use the knowledge and feedback of beta testers and early adopters and, over time, new users can use the community’s knowledge to give themselves a warm, fuzzy confidence that when they upgrade or try out Textpattern that they know which of their existing/planned plugins will work if they upgrade, and which will need attention, or where they need to rethink / shout for help.

If plugin code is kept up to date, the author’s (or official maintainer’s) word is final and always carries the most weight for any particular version — i.e. their vote is gospel. Anything else that is added by the community as supplemental information is still taken into account to give an overall picture of how compatible a plugin is with a particular version. The author/maintainer/admin have the ability to add or remove notes or votes that are simply due to someone hastily stating a plugin doesn’t work before reading the docs, or trying hard enough, or something.

I want search to be front and centre of .org, and the ability to search for the right plugin version that works on a particular Txp version is a key part of that vision.

Auto-updating of plugins (or at least, some kind of automatic “compatibility check” like Firefox does) via dependencies and version numbers, while a lovely utopia, only works if plugin code is maintained. At least, that’s my blinkered view. I may be wrong so please feel free to correct my short-sightedness if Composer can handle all this and more. I’d love to save myself some effort if it can!

Gocom · 2013-04-26 14:59:59

philwareham wrote:

Sounds interesting, I’ll play around with Composer and rah_blobin.

It is ;-) Getting hang of Composer is pretty easy too. Since you are on a Mac, and are already using git, you don’t have to do anything else than run a single command to get it installed. Plus it can update itself too, so you don’t have to worry about that either.

To get rah_blobin up and running you would have to initially install as a normal plugin (you can compile it with MassPlugCompiler, and then upload the package the old way through Plugins panel). After you have do that you can add it to Composer and update it through that. The normal install is just to get the plugin running, it can not install itself if its not installed first — chicken, egg issue so to speak.

I know lots have people have been talking up Bower recently for front-end development so it seems these packaging systems are going to become really popular.

Me included. Bower is one of the many package and dependency managers out there, Bower being the unopinionated one. One of the problems with it is that it expects that you commit dependencies to your repository. Which I don’t really like, I would much prefer if we didn’t have to.

That’s different with Composer. Composer on other hand uses lock files. In other words, you don’t commit dependencies, but everyone runs Composer alongside git. E.g. you don’t install plugins to the repo, but just add your composer.json (and composer.lock) file to it, and you have never again worry about updating code you have in your repositories or fight with submodules. Gives you time to worry about what actually matters; you and your stuff, and not others’. “uggh, is there update for it – ugh, I have 15 plugins to update… – ugh, I updated and this isn’t compatible with x…”

Bloke wrote:

For example, rss_db_admin_manager. Handy plugin. No current maintainer. Version available from official download link delivers old version which needs patching to make it work in 4.0.6+. Trawling the forum to find the right code is a pain even if it is linked from the 1st post.

Composer is dependency manager. This includes telling you the compatibility, your update path and doing updating. It of course doesn’t magically turn dead code back to living, after all it consumes its own packages but…

I understand you are worried about orphaned plugins, but they are what they are; orphaned. If something is needed, and cared about, then take care of the problem. Don’t try to go around it, but fix the issue; make the plugin living, or actually patched according to our guidelines. The steps would involve;

Fork the code base (can we make VCS mandatory in new TXP.org, pretty please?)
Patch it.
Send pull request to the orignal maintainer if possible…
…if not, release the plugin under your author prefix.

And there you have, you have updated plugin that works.

As I see it, people that are not affiliated with the orignal plugin and project should not be releasing updates or forks under the orignal name. The vendor needs to change. We should NOT endorse unofficial 3rd-party patches, but phase out old code with the newer one, forks for instance.

Having the patching type system, will cause a nightmare, where people don’t know what they are using. This doesn’t solve anything as far as I see it. Please don’t do that :( If TXP.org will have patch endorsing features, can I kindly ask that my plugins are removed from it? I don’t want to deal with and support mods and shit. Neither I want that people report missinformation about ‘compatibility’. I also don’t want ‘ratings’ since everything is always either 1 or 5 stars, and nothing between.

Back to the fork you have, while you release this updated plugin, you could also release it as a composer package. What is cool about composer, is that it allows you to set whether the package replaces something else. For instance you could say that your new abc_plugin replaces zdf_plugin (being its maintained, long-term fork), and composer will automatically resolve that incompatibility and update it for you. It will replace your old plugin with the new without you having to do anything else than tell it to include abc_plugin to your project.

Auto-updating of plugins (or at least, some kind of automatic “compatibility check” like Firefox does) via dependencies and version numbers, while a lovely utopia, only works if plugin code is maintained. At least, that’s my blinkered view.

I myself do not want some auto-updater, or graphical features for that matter as code management goes. We developers should manage our consumed packages via source control. We, not the system. Auto-updater is something that I don’t really want or need in Textpattern. The current plugin system is easy to start using, hard to manage and control. Our plugin system is just old school as hell, and limited.

As some dependency manager and updater goes, I really hope we didn’t do our own stuff, but used existing tools. If all plugins where available as Composer packages it would be so super fucking cool, and would make installing and maintaining (it’s a freaking dependency manger, that is what it freaking does) plugins super-simple.

Gocom · 2013-04-26 16:06:57

Dale, is it April first?

As you may sense from that alone, that’s not a good idea. As your defense, I can say that some crazy folks (WordPress…) actually do that, but that’s not something that is practical or even makes sense. If I can be honest, what you said makes me want to turn Caps-Lock on and impersonate Darth Vader for the next ten minutes (NOOOO…..).

First of all, lets start by saying, whether the code is under the same repository or multiple doesn’t help maintainability or discovering. It does create issue and makes everyones’ life a live living, but doesn’t make things easier.

I couldn’t use such system since I actually do use VCS in development. I for instance couldn’t use build scripts, unit test, or Composer – for starters. Seconds is that, that is not how you operate a VCS.

That pretty much goes against how you are supposed to use repositories. The ones meant for source control. For source control, for developing. Collecting plugins under a single repository doesn’t even make sense. They can just fine be different repositories, and they should be, especially, when using a distributed platform like git that encourages forking and merging.

There are other channels for publishing, building and all that, and you can tie that in to a VCS, but not as the final publishing platform, or by using a single repository.

Each plugin must be their own repository, and can easily be. If we wanted, we can collect, crawl and index those repositories and list them somewhere. Like for instance Bower, jQuery or Composer (Packagist) do. They just simply sync and index the repository contents to their ‘repository’ website using post-push hook. Don’t mix these ‘repositories’ to VCS.

Gocom · 2013-04-26 16:09:57

philwareham,

I’ve put up few builds (periodically compiled packages). You can use and a downlaod pre-packaged rah_blobin, instead of having to compile your own ;-)

springworks · 2013-04-26 17:03:24

Gocom wrote:

It is ;-) Getting hang of Composer is pretty easy too. Since you are on a Mac, and are already using git, you don’t have to do anything else than run a single command to get it installed. Plus it can update itself too, so you don’t have to worry about that either.

To get rah_blobin up and running you would have to initially install as a normal plugin (you can compile it with MassPlugCompiler, and then upload the package the old way through Plugins panel). After you have do that you can add it to Composer and update it through that. The normal install is just to get the plugin running, it can not install itself if its not installed first — chicken, egg issue so to speak.

Sounds very interesting.

As a complete beginner at such things (and someone who has never run a VCS) would you run Composer locally or on the webserver where your Textpattern site is hosted? Do you need to run it alongside a VCS or does it run on its own?

When a plugin is updated, presumably you need to manually run a Composer command from the command line to update it, or does it all happen automagically in the background somehow?

And am I right in assuming that the Composer packages sit on the Composer site and you don’t need to download them yourself as Composer takes care of that?

Do plugins installed in this fashion appear in the Admin > Plugins tab in the normal way (so that help files are accessible)?

So many questions! Apologies if these seem somewhat naive – I have had a look at the Composer site but I must confess I’m still a little clueless about how it is actually used, especially in relation to Textpattern.

Gocom · 2013-04-26 18:15:05

springworks wrote:

As a complete beginner at such things (and someone who has never run a VCS) would you run Composer locally or on the webserver where your Textpattern site is hosted? Do you need to run it alongside a VCS or does it run on its own?

Its a command line application. You run it when you want to install or update something, when you have something to do with it etc. Whether you run it on the server, depends how you do your deployments and what packages you use, and if they use custom installers, and whether you can easily deploy the installed end-results to the server, or if you would have to re-run those installers on there too.

But it’s not a server application or active one, so to speak. You run it locally, and depending on deployment process, on your build server, just locally or locally and on the production server (via ssh etc). Each time when and where you need to download/install/update packages.

The Composer documentation should give you more insight in that, including to what it requires and how you should use it. There can be a lot to read and take, but its must read before diving into Composer.

When a plugin is updated, presumably you need to manually run a Composer command from the command line to update it, or does it all happen automagically in the background somehow?

Yes. You would run a single command line command. Does updating for you as instructed, as dependencies allow. You can either update individual packages, or update all in one swipe. Either way, it handles dependencies and updates the plugin within the versions you have hoped, up to where dependencies allow.

And am I right in assuming that the Composer packages sit on the Composer site and you don’t need to download them yourself as Composer takes care of that?

Composer downloads everything for you; its a dependency manager. Composer itself uses centralized repository format for distribution. There is a centralized repository that keeps up where the actual sources for packages are located. It uses SVN, hg and git as its backend to get the actual sources to you.

After you have installed the plugins, you would invoke rah_blobin to import them to your Textpattern installation. You could also automate that process by using Composer’s script support. Rah_blobin has public callback URL that launches importing. Importing is also run when accessing your Preferences panel.

I’m also trying to see if I’m able to create a Composer installer that plugin could use. Not sure about that tho, since then you would definitely have to run Composer on your servers too, since its responsible of running the installers (unless you run rah_blobin on your servers).

Do plugins installed in this fashion appear in the Admin > Plugins tab in the normal way (so that help files are accessible)?

Yes, that is how rah_blobin works and initializes/imports the code to Textpattern. You can manage Plugins through the Plugins panel, read help documentations, change load orders or disable plugins. Rah_blobin of course requires that the plugins use the meta-file format that I personally use (the meta file is what makes the gears to run). Currently only my plugins use that format as far as I’m aware, and the forks I have created.

Textpattern CMS

Textpattern CMS support forum

#1 2013-04-25 22:40:35

Check plugin compatibility before upgrading

#2 2013-04-26 03:09:21

Re: Check plugin compatibility before upgrading

#3 2013-04-26 08:08:35

Re: Check plugin compatibility before upgrading

#4 2013-04-26 09:42:59

Re: Check plugin compatibility before upgrading

#5 2013-04-26 12:31:19

Re: Check plugin compatibility before upgrading

#6 2013-04-26 13:08:13

Re: Check plugin compatibility before upgrading

#7 2013-04-26 13:08:39

Re: Check plugin compatibility before upgrading

#8 2013-04-26 14:59:59

Re: Check plugin compatibility before upgrading

#9 2013-04-26 16:06:57

Re: Check plugin compatibility before upgrading

#10 2013-04-26 16:09:57

Re: Check plugin compatibility before upgrading

#11 2013-04-26 17:03:24

Re: Check plugin compatibility before upgrading

#12 2013-04-26 18:15:05

Re: Check plugin compatibility before upgrading

Board footer