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.

Textpattern CMS

Textpattern CMS support forum

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