New plugins site - what do you want to see?

philwareham · 2019-04-19 12:25:42

I’ve made a start on the plugins site that will eventually replace Textpattern.org. It’ll probably run as a beta side by side with the old site while we tidy any rough edges.

I have some fairly good ideas about how and what to provide, functionality wise. But what do you all want to see?

Cheers!

colak · 2019-04-19 13:30:16

Hi phil,
here’s my penny.

descriptions of the plugins and version enhancements (ie history)
compatibility tpo txp versions (I know it was discussed in another thread)
downloads of all versions of the .zip.txt files
plugin version based examples of how to use them

uli · 2019-04-19 15:30:46

It could be useful to have the help texts available so one could see whether a particular plugin offers a use case for the issue one tries to solve.

Plugin dependencies should be mentioned, like for the contact_cleaner plugins depending on the respective form plugins, Adi offers another one for the form plugins, some jsoo plugin needs a lib, same for one(?) of Stef’s plugins, IIRC some mem ones depend on each other, and probably some more.

A random plugin link or random “plugin of the day” page section could turn up plugins one never would have discovered otherwise.

Thanks for your work on this site!

philwareham · 2019-04-19 15:47:50

Plugin help is going to be a stretch, as it would be impossible to keep up to date. Thanks for the other suggestions though, it all helps formulate what a plugin page will look like.

uli · 2019-04-19 16:21:56

philwareham wrote #317694:

Plugin help is going to be a stretch, as it would be impossible to keep up to date.

I hoped it could be read from the file uploaded.

One thing I’ve forgotten: I often wish for instructions on how to turn a plugin saved as .php into an installable one. There are countless of them hanging out on Github. Or maybe it’s also possible to have an online converter for those on the plugins website.

colak · 2019-04-19 17:00:49

I remember one plugin, Jukka’s I think, which published the ~~help~~ title? of the plugins on the front end. I can no longer find it in his site, so my memory might be failing me regarding the author.

Last edited by colak (2019-04-19 17:02:33)

bici · 2019-04-19 17:22:40

colak wrote #317692:

Hi phil,
here’s my penny.

descriptions of the plugins and version enhancements (ie history)

And i really would like to see MANDATORY dates included: when a plugin was developed, and revision dates after that.

Sometimes it seems impossible to determine how old a plugin is?

philwareham · 2019-04-19 18:31:52

colak wrote #317696:

I remember one plugin, Jukka’s I think, which published the ~~help~~ title? of the plugins on the front end. I can no longer find it in his site, so my memory might be failing me regarding the author.

That assumes the plugins will be loaded into Textpattern doesn’t it, which they won’t be. I’ll also probably weed out any really old plugins that are I maintained and don’t work or whatever.

Gocom · 2019-04-19 23:20:09

I would wish the site was automated and synced itself with plug-in source repositories. I know I’m not personally going to build installer files, or upload them to the site at least. I don’t have personal need (due to composer), time or interest for that.

colak wrote #317696:

I remember one plugin, Jukka’s I think, which published the ~~help~~ title? of the plugins on the front end. I can no longer find it in his site, so my memory might be failing me regarding the author.

You could be meaning rah_plugin or soo_plugin_display. They both used to display details from installed plugins.

uli wrote #317695:

I hoped it could be read from the file uploaded.

Technically they could be.

philwareham · 2019-04-20 06:21:07

One of the routes is to use GitHub’s GraphQL API to bring in all the info directly from a repo (and this could be expanded to Gitlab and Bitbucket REST APIs too eventually). Of course that relies on the plugin being on that platform to start with.

But with that method all we would need to do manually is create a plugin article, name it and put a short description in, add a target repo and use the API to grab releases, README, etc. Plus maybe do a few other minor manual things like compatibility tags.

This is my preferred option but is the GitHub reliance too much?

colak · 2019-04-20 07:20:18

philwareham wrote #317700:

This is my preferred option but is the GitHub reliance too much?

I think that it is. It is one thing relying on video hosting sites (bandwidth, space quota,speed, etc), and it is another one relying on 3rd parties for content we can easily host. There are so many heated discussions here regarding our depentance to giant providers but we are still addicted to them.

Is there a way to have github, send it to an install of something like git-scm, and then parse that info in the plugins site?

I understand that github can provide visibility, but it would also be good if we can mediate it through an independent system which we could control and maybe migrate to, once github becomes unacceptable – especially when censorship filters are put in place.

philwareham · 2019-04-20 07:41:02

It’s not about visibility, it’s about automating the site as much as possible. Self hosting everything is going to be impossible to maintain.

towndock · 2019-04-20 12:15:26

philwareham wrote #317702:

It’s not about visibility, it’s about automating the site as much as possible. Self hosting everything is going to be impossible to maintain.

This really makes sense. The more that is automated, the more the small group of Textpattern volunteers can actually support a quality product going into the future. If plugins are to be hosted on dozens (hundreds) of diverse platforms, you end up with broken links and no consistency. We already have that now.

Bloke · 2019-04-20 14:37:42

Gocom wrote #317699:

I would wish the site was automated and synced itself with plug-in source repositories.

+1000

We need a way of a (one-time) registered or authorised plugin writer to be able to nominate their third-party repo instead of manually handling plugins directly on the textpattern.org site. From the third party link, we should be able to extract all the metadata we require to populate internal metadata for search purposes. This could be done on a schedule or perhaps via some post-publish hook that somehow triggered textpattern.org to refresh that author’s content.

In addition – as a separate future phase once we have the base set up – I would like to provide a feed to facilitate update flagging in the admin interface, as follows:

When visiting the Plugins panel of any installed Textpattern, it initiates a call to a textpattern.org feed URL, and passes the list of currently installed plugins and installed version of Txp along. The plugins site generates a feed, for those plugins only, that lists:

The plugin name
Its latest recorded version compatible with the given Txp version.
Its textpattern.org direct download URL or endpoint where the compiled (zipped) file is available.

The results are cached somewhere in the DB with an expiry of, e.g. 24 hours.

Subsequent visits to the Plugins panel will check the cache first, although a manual ‘Check for Updates’ button on the Plugins panel can force a refresh.

When rendering the table, any installed plugins that have a version number less than the latest compatible version returned from textpattern.org will have their version number highlighted in a different colour. The version number could become a hyperlink to the plugin’s page – on textpattern.org or the third party site – allowing an admin to directly visit the site and get the latest download. Alternatively (or in addition) a one-click process could – subject to the abilities of the hosting environment – issue a file_get_contents() of the actual plugin and pass it to the plugin install() routine so the admin can verify its contents and click the Install button to upgrade it.

philwareham · 2019-04-20 15:21:38

Providing a feed of plugin values would be easy if we had a GraphQL core plugin. ;)

My test code on my local machine is currently set up this way:

The system stores our GitHub API key in a global variable. Articles (plugin articles) have a custom field for GitHub repo target. Using this I pull in GraphQL data for that repo using GitHubs API.

There is a ton of info supplied by that request, which I can decide to cherry pick the important bits and display it in the article.

Alongside that there are the following manual bits to set up per plugin:

Title
Excerpt (or body)
Custom field for earliest Textpattern version supported (by any release of the plugin)
Custom field for final Textpattern version supported by plugin (If left blank assumes plugin works with all versions above earliest stated above).
Category of plugin
‘Promoted’ category so we can feature plugins on the homepage.

I’d imagine we will need to use smd_bio of similar to give author info – or pull user info from GitHub (not worked that out yet).

Textpattern CMS support forum

#1 2019-04-19 12:25:42