Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Supported community plugins "list" on Github
maverick wrote #294699:
Thinking aloud: is a rating system preferable, or in principle, any different, than having the community able to commit updates to a manifest? Or other meta data paradigm we might use?
No. It’s better! As long as it’s simple enough to understand for non-devs. And if you’ve ever seen the hieroglyphics in the dependency string of a manifest.json file you’ll know it’s not exactly non-dev friendly!
Is Composer going to be an official part of Textpattern development going forward?
Don’t think so. In the same way that we don’t mandate Github. Some people prefer to develop in private or use their own sites. And that’s why I like the idea of having our own central repo that has a common API for pushing/pulling plugin meta info (or that the repo knows the APIs of commonly used third party systems such as Github so it can scan for them and update them from trusted authors/maintainers).
Although dictating a particular system has its benefits insofar as a convention makes integration simpler, being at the whim of one particular external system that might vanish overnight if the donations stop coming in isn’t my idea of stability.
Is it an something where we do both our current plugin format AND a Composer formate (they compliment each other)
I think taking the best bits of all these disparate systems and conjuring up a file format for Txp plugins that can be used to generate the required files for such systems has merit. For starters, it keeps our options open.
Taking it to its logical conclusion, why not have a central, standard file format with code, docs, history info, meta data, links, dependencies, blah blah in it. Then you register various compilation filters: one for Github, one for Packagist, one for your own site — so it’s extensible, like we do with the current callback system. A developer then hits the “Compile” button and the central file is run through each registered filter in turn to generate the relevant files and do something with them, e.g. publish, commit, notify, ftp, or just leave in a local folder ready for the author to take the next steps.
If another world-beating rootin’ tootin’ code repository comes online, just write a filter for it and register it.
Too simplistic? Undoubtedly. But there might be something in it that can actually turn into something workable without being too dictatorial about what developers should use, but allowing them to plug into the Txp ecosystem with a bit of code twiddling, and allow the community to help with the upkeep should development of the plugin stall.
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
Re: Supported community plugins "list" on Github
maverick wrote #294707:
Is it considered in good taste to upload copies?
A copy of (at least) the current version of compiled plugins is something I’m keen to explore in a central repo of our own choosing, if only so it is always available should third party systems or an author’s website go away (or get redesigned, as happens from time to time). Having the files hosted centrally isn’t too onerous from a disk perspective, and also means that we can base Txp’s back-end around that.
I’d rather that Txp’s Admin->Plugins panel has a “check for new version” facility built on the back of something we control. The ability to easily grab and install the latest copy subject to meeting the compatibility constraints is then simpler. The trick is to keep our central repo up-to-date with the many disparate systems that developers might choose to employ, without having authors jump through the ridiculous number of hoops that they currently do. Hence, a published, standard API or interchange file format that allows the repo to either automatically Pull from an author’s sanctioned external development environment, or a one-click Push system from the external environment to the repo.
I don’t really have a preference either way: Push or Pull is fine for me, as long as it takes less than a few seconds to do it :-)
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
Re: Supported community plugins "list" on Github
Bloke wrote #294709:
The trick is to keep our central repo up-to-date with the many disparate systems that developers might choose to employ, without having authors jump through the ridiculous number of hoops that they currently do.
All the author would have to supply is an URL where the .php (raw or compiled) can be retrieved, the topic number of the corresponding support thread here on the forum and perhaps a category (or two) where the plugin should be grouped under. The rest can be retrieved from the plugin itself.
Offline