Update notifications for plugins

Aeyoun · 2016-07-08 14:20:46

Give plugin authors a way to provide a meta field for their plugins with a URL where Textpattern can check for new versions. As I understand it, it’s currently up to each plugin developer to provide this functionality and there is no unified way of doing it.

Not updating plugins can be bad for security, and Textpattern should encourage users to keep their plugins up to date and also encourage developers to keep making refinements and provide support for their plugins. (Who wants to work on code that no one will be updating to?)

bici · 2016-07-08 16:17:36

Ah plugins. the bane of our existence. I applaud some kind of mechanism that can check if there is an update. As i recall there are plugins with no creation date in them. this should be a mandatory requirement. i get queazy when i come across plugins that are >5 or more years old.

sacripant · 2016-07-08 16:45:52

Agree, plugins search, management and update (search if update exist, or get information) is painfull and very difficult with Textpattern.
It will find time and resources to this task.

Bloke · 2016-07-08 17:28:20

Aeyoun wrote #300236:

Give plugin authors a way to provide a meta field for their plugins with a URL where Textpattern can check for new versions.

Great idea in theory. How would the core know the API at that endpoint in order to make sense of the result? Think github vs bitbucket vs packagist vs an author’s own site.

bici wrote #300239:

I applaud some kind of mechanism that can check if there is an update.

All it needs is a central repository that can be automatically updated from a remote dev environment. Build one and I’ll link it to core no sweat. I’ve proved it works about six years ago. But without infrastructure it won’t see the light of day. By all means pool your resources and come up with a site and we’ll adopt it.

There are plugins with no creation date in them. this should be a mandatory requirement.

What good is a creation date at update time? Not being belligerent but there are probably ways to do this more intelligently than forcing the author to keep the field up to date.

I got blasted today for not providing licence info in my plugins. To me, there’s no value in explicitly setting one and wasting valuable docs/code space as the plugin runs inside txp. The assumption should be the same as txp’s licence unless stated otherwise. But I’m not very legal savvy so that might be a misguided view. That said, i do have a version of plugin composer lying around somewhere that supports licences. Not released yet.

jakob · 2016-07-08 19:56:41

Bloke wrote #300241:

I got blasted today for not providing licence info in my plugins. To me, there’s no value in explicitly setting one and wasting valuable docs/code space as the plugin runs inside txp.

Well, that seems pretty unnecessary (being blasted I mean)!

I’m no expert on licensing: do licences require one include a copy of the licence, or is it sufficient to link to it?

As you know, Jukka had ideas on that too. The plugins he has made installable with composer have a composer.json that describe dependencies, minimum txp and php version numbers etc. That provides a modicum of compatibility information and provides an update mechanism as new versions of plugins and dependencies come about – providing the plugin author keeps things up to date. But even jukka, for reasons it seems we shall never know, has not been able to do that, and I would count him among the most diligent plugin authors.

Speaking of that: some of jukka’s plugins are now no longer up-to-date. What does one do with stale repos on composer? Is there any way of hooking it to a new repo? Or doe one have to fork it, rename it and resubmit to composer?

His repos also have a licence, readme and contributing file.

i get queazy when i come across plugins that are >5 or more years old

It guess it depends on the plugin complexity. There are plenty of older plugins that still work fine.

gomedia · 2016-07-08 21:57:36

There’s an elephant in the room, or rather two elephants – textpattern.org & textpattern.org/trv3/plugins.

Wasn’t there a discussion, quite some time ago now, about turning this into a proper curated repository?

Which one are we meant to be updating? Maybe now’s the time to decide that V3 is the place for TXP 4.6 compatible plugins to live?

WRT notifications, if you’re subscribed to a plugin’s support thread and if the plugin author posts a post about an update … you’ll get a notification.

Bloke · 2016-07-08 22:13:46

jakob wrote #300242:

Well, that seems pretty unnecessary (being blasted I mean)!

Damn autocorrect / small screen. It was meant to be lambasted. Meh, either way.

I’m no expert on licensing: do licences require one include a copy of the licence, or is it sufficient to link to it?

No idea. Most projects include a file containing the wordage, which also has a link in it to read more detail. I’d have thought the link would be enough on its own — that was the route I was going with Plugin Composer, at least.

Using Composer seems like a nice way to help make sure plugins work — up to a point. But as you imply, a minimum version is all well and good until breaking changes come along, like some of those in the admin side of 4.6.0 compared with 4.5.7. I’d wager that no plugin author can predict the future with any certainty.

Incidentally — and sorry for the mild off-topic — that was the thinking behind my multi-tiered compatibility matrix proposition:

Author sticks stake in the ground: “Version a.b.c of my plugin is designed for Txp x.y.z”.
When a new version comes out, a new compatibility statement is effectively issued. This author (or maintainer) stamp takes precedence over anything anyone else says.
Plugin author drifts off.
New version of Txp comes out.
People test it and, for each test that’s performed, one of three outcomes ensues:
- Still works. So the tester tags it with a Yes, meaning that version a.b.c still works on Txp x.y.z.
- Doesn’t work. Tag it with a No.
- Does work IF something is modified. Tester details the changes that need to be made or offers a fork, and tags that plugin version as “can be made compatible with Txp x.y.x”.

The upshot of all that, over time, is that we have an ever-expanding knowledge base of information with a combination of definite statements from authors/maintainers, and a pool of user-submitted supporting info that give a “compatibility feeling” or a weighted likelihood of a plugin working. When searching for plugins — either by hand through a website that acts as an interface to the repo, or automatically from the admin side for updates — both then have all the information needed. In the automation case, this can be based on administrator criteria which helps determine whether to offer an upgrade of Plugin abc_whatever. For example, your txp install could be set — via a pref — to only suggest updates for:

Definite compatibility with your currently-installed version of Txp (via author/maintainer stamps).
Likely compatibility (via author stamps and number of community Yes stamps). This’d probably be default.
Probable compatibility (via number of community “Yes, if you change blah, blee, and bloo” stamps).

That way you retain control of your installation based on how much you trust the community to guide you. The more people that put in a vote for a plugin that works, the more entropy we have and the better the predictions become for all users.

I suggest such votes be castable only from the admin side of a Txp installation. That way, the results aren’t skewed by bots that might “vote” if the info is in a pubic wiki or some poll available in web land. Thus only installed plugins can be voted for compatibility, right from the Admin->Plugins panel. And thinking further, why not have the version in your site that you’ve hacked to get working be compilable and postable right to the official plugin page in the repo as a working version for Txp x.y.z? If the versions are actually hosted there, it’s game on. Security notwithstanding of course!

Curated content could also be maintained on a plugin support page at the repo, which might document key features, omissions, known bugs, or things you need to do to get a plugin working on particular versions, etc. Like a go-to page of edited highlights to save people wading through 20 pages of support posts in the forum (which in turn might help keep down the number of posts asking the same questions).

Shrug, just an idea. But it all hinges on having a repo that can adapt to the ways of working of a distributed author base and be kept up to date via feeds from an author’s official site — whether that’s a personal website or a third-party code repository like github or bitbucket. If some folk want to step up and help build it, I’ll offer all the support I can and also pledge to build functionality into Txp to use it.

What does one do with stale repos on composer?

Good question. Absolutely no idea. I’m not a massive Composer user.

Aeyoun · 2016-07-08 23:08:14

Bloke wrote #300241:

I got blasted today for not providing licence info in my plugins. To me, there’s no value in explicitly setting one and wasting valuable docs/code space as the plugin runs inside txp. The assumption should be the same as txp’s licence unless stated otherwise. But I’m not very legal savvy so that might be a misguided view. That said, i do have a version of plugin composer lying around somewhere that supports licences. Not released yet.

That was also me. :) Your assumption is dead wrong. Per international copyright agreements and law, you hold all the rights and must explicitly grant other’s rights to use your work (install, modify, redistribute) to use your work. This is done by choosing and applying an appropriate license. (Preferrably one of the aknowledged open source licenses, and one that is compatible with the license of Textpattern core.)

Bloke · 2016-07-09 08:56:39

Aeyoun wrote #300245:

Your assumption is dead wrong.

OK. Thanks for the clarification. Guess we’d better find a way to build licencing options into plugins then. Can’t afford to be sued by the FSF for not following protocol.

So do we need to include the entire text in every plugin or is a permlink to the appropriate licence sufficient? Makes a difference to the type of column we add to the plugins table!

phiw13 · 2016-07-09 09:37:40

Bloke wrote #300246:

So do we need to include the entire text in every plugin or is a permlink to the appropriate licence sufficient? Makes a difference to the type of column we add to the plugins table!

IANAL – I think including a text blurb similar to what is in the Textpattern readme is OK

Released under the GNU General Public License. See LICENSE.txt for terms and conditions.

or possibly even shorter (displayed on the plugins panel, in an additional column in the table):
‘Licence : license name’ with a link-to-page-with-license (which could be the GNU server, or the github-textpattern page).

Aeyoun · 2016-07-09 13:08:24

Plugins should be required to include `License: <url>` in their meta data. Should be enough, though I think it’s technically required to declare the copyright holder too (name of person or organization, traditionally along with the year). Though this varies by jurisdiction and license.

This should cover everything. Both field can have comma separated values (dual-licensing or multiple authors).

License: <url>,

Copyright: <year> <author>,

Last edited by Aeyoun (2016-07-09 13:09:26)

Aeyoun · 2016-07-09 13:12:01

Anyway, for auto-update purposes, a third field: `Update-URL: <url>` could be periodically cheeked. URL should contain a text/plain with: <plugin-name>;<version-number>;<download-url>. Textpattern could check these periodically and either download URL automatically or offer a download button. Very simple to implement and deploy on any webserver if it’s just a text-file with info about the current version. No giant infrastructure required and easy to get plugin authors to adopt.

Last edited by Aeyoun (2016-07-09 13:13:12)

Textpattern CMS

Textpattern CMS support forum

#1 2016-07-08 14:20:46