Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2015-09-10 19:27:24

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Altering the Plugin Template

maverick wrote #294691:

If we used the current format, am I correct we add to the fields here?

$plugin['version'] = 'x.x';...

Something like:

$plugin['min_txp_version']="4.1"...

Yes. or something like (although that’s probably too much work for plugin authors):

$plugin['compatible'] = array('4.0', '4.0.1', ... '4.5', 4.5.1', ... '4.5.7');

Can this format handle nested information?

Do you mean info about multiple plugin versions? No, nor should it, because you’d add it to a single plugin version.

The benefit of keeping it all contained in a single file for one version of a plugin is that you can generate all the other suggested files from that single file instead of having to maintain separate files manually. I can imagine textpattern.org taking advantage of that, by periodically scanning all known GIT repositories (or we simply fork each plugin into a central repository), collecting the raw plugin.php files, so TXP.org then knows about compatibility, can show source code, can create the .txt files for copy/pasting and can show you the plugin help on the website.

What Jukka does with his plugins and Composer is interesting. I wonder how well that integrates with the way users typically install plugins (via the TXP admin interface).

Offline

#12 2015-09-10 19:52:36

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 960
Website

Re: Altering the Plugin Template

ruud wrote #294694:

Or something like

$plugin['compatible'] = array('4.0', '4.0.1', ... '4.5', 4.5.1', ... '4.5.7');...

That makes sense.

Do you mean info about multiple plugin versions? No, nor should it, because you’d add it to a single plugin version.

Yes, I was picturing sort of a master “release” history. But that would be working from a model with a separate file, and it tracks with various repo updates. From a single file model, that would not make sense, as you point out.

Stef also mentioned Jukka’s use of Composer in the thread where we are discussing a curated list of plugins.

Ruud — are you familiar with Composer and it’s use? If so, is the current plugin format something that we would use with Composer (both/and), or is it an alternative format (either this format or that format)?

Offline

#13 2015-09-10 19:58:32

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Altering the Plugin Template

Yes, I noticed. I haven’t used composer yet and as I said in my previous message:

What Jukka does with his plugins and Composer is interesting. I wonder how well that integrates with the way users typically install plugins (via the TXP admin interface).

Offline

#14 2015-09-10 20:06:25

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: Altering the Plugin Template

ruud wrote #294694:

The benefit of keeping it all contained in a single file for one version of a plugin is that you can generate all the other suggested files from that single file instead of having to maintain separate files manually.

And I like this approach. Although I’ve not got round to finishing it yet, I was planning to make myself a glue shell script for releasing a plugin. It’d take the plugin’s .php template file —slightly modified from its current format — and:

  • split it into code and docs segments;
  • squirt the docs into a separate .textile file (or at a push, funnel it through Pandoc to make github-flavoured markdown);
  • extract the history info and make a changelog file;
  • extract meta data including the licence version, grab the relevant licence wording in .txt format from the GNU website and make a licence file for the repo if necessary;
  • compile the plugin into .txt and .txt.zip files;
  • bundle the lot up into a commit;
  • commit;
  • tag with the version number;
  • push to github;
  • release;
  • upload to my website;
  • make toast.

Quite how things like Composer and the central repo would factor in I don’t know, but for my own sanity, having a single file that acts as a master from which the various pieces can be extracted and farmed out to wherever they are needed makes a lot of sense to me, with my developer hat on.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#15 2015-09-10 20:11:10

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 960
Website

Re: Altering the Plugin Template

In reply to ruud #294698:

Sorry about that Ruud. I thought I had read the whole message, but overlooked that part on Jukka.

When I first saw Composer, and read about it, I thought “nice in theory, but one more complicated thing to learn. I don’t see most people installing composer in order to install a plugin.” That said, perhaps that is a rash judgement and it is not complicated once I take a bit of time to learn it.

Perhaps it would require a Composer plugin that then allows the rest of the plugins to be installed? Jukka might have that very plugin – I saw something that sounds like it might do that, but haven’t had the chance to try it out.

Offline

#16 2015-09-10 20:22:08

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Altering the Plugin Template

maverick wrote #294701:

Sorry about that Ruud. I thought I had read the whole message, but overlooked that part on Jukka.

Oh no. I suspect your message was written while I was editing my post (I often do that instead of creating a new one if nobody responded yet).

Offline

Board footer

Powered by FluxBB