Plugin Repository

[cmb]

Hello Community,

there are a lot of plugins for CMSimple(...), but it's hard for users to get a good overview. In the CMSimple_XH Wiki there is merely a list of links to the descriptions (some of the links point to external websites), and in the CMSimple Wiki the situation is only slightly better, as the plugins are only partially categorized. Furthermore quite a few plugins are not listed in either Wiki, and some of the descriptions are not up to date.

The main problem seems to me that it's a lot of work for plugin developers to present new plugins and keep the information up-to-date. The developers are most likely interested in putting up a description on their own websites, and to keep that up-to-date. Additionally informing users in this forum about new plugins resp. updates, plus maintaining the descriptions in both Wiki's causes additional work, amplified by the fact that different markup notation is required: HTML vs. Wiki markup vs. BBCode.

There were discussion about setting up a central plugin repository where the developers will be able to enter information about their plugins in a structured way. However, that may not solve the issue that the developer has to create and maintain two sets of description (for the repo and his own website), and it's not clear where this repository should be hosted.

Recently, Hartmut had the idea that the plugin descriptions could be offered in a common format by the respective developers. This way, several independent repositories could exist, which could simply crawl the developers sites for (changes) in the description files. Futhermore it would be possible to generate (parts of) the plugin description on the developers' website from these description files.

There is already such a format that might be used: Portable Application Description. This is XML based and several editors exist to create such files (if one wants to avoid writing the XML manually). If this format would suit our needs, has to be investigated.

Anyway, I quite like the idea to write a single description of a plugin, which can be used by several channels to present it.

I'm looking forward to hear your opinions.

Christoph

PS: A related discussion in the German forum: http://cmsimpleforum.com/viewtopic.php?f=16&t=7857.

[svasti]

a single description of a plugin, which can be used by several channels to present it

I think this is a very good idea

Portable Application Description. This is XML based and several editors exist to create such files (if one wants to avoid writing the XML manually). If this format would suit our needs, has to be investigated.

Something between this and Holgers update info file looks promising.

A format would be nice which could also be used on the website of the plugin developper to present his plugins.

As some developpers present theirs plugins in German and in English, it would be nice, if the plugin presentation file would have the possibility to enter descriptions in English plus an additional language.

I'm looking forward to see some code examples.

svasti

[bca]

Good idea

[johnjdoe]

Nice idea! +1

[svasti]

I think we may want to enlarge the Portable Application Description

There is already such a format that might be used: Portable Application Description.

What are the point we need to know about a plugin?

• Name of plugin
• What does it do? (short version + long version)
• Some examples of possible tasks the plugin would solve
• Prerequisites:
  • php-version
  • jquery
  • cmsimple(_xh)-version
  • server type (apache etc.)
• licence (public domain / GPL / no-cost but fobidden to distribute / free for no-commercial use)
• Size
• Download address
• Present author
• Previous authors

More ideas?

svasti

[cmb]

I think we may want to enlarge the Portable Application Description

I'm not sure whether we should stick with the PAD, if we want resp. have to modify it. This is likely to reduce the advantages of the PAD format (editor and validator support, for instance), still leaving the authors with an overly large specification.

Rolling our own description format seems to be not unreasonable. This might be based on XML or JSON, so automatic processing would be easy to accomplish.

More ideas?

• It should be possible to write the description(s) in different languages (as you've mentioned already).
• For automated searching/filtering some of the information (requirements, license etc.) should be very structured and clearly defined
• It should be possible to add tags or categorize the plugin (the allowed set of tags/categories might be predetermined)
• The description should allow for some simple markup, which should be easily parseable (to be able to automate a transscription to other markup formats); maybe a subset of XHTML is suitable
• The example task might be given in the description
• It should be possible to add URLs of resp. links to screenshots (it might suffice, if that can be done in the description)
• Version number and release date should be specified

[svasti]

Rolling our own description format seems to be not unreasonable.

+1
There are fixed formats, like Holgers version info or the data file of calendar_XH. Fixed data structure is good for small amound of data (version info) but becomes unflexible with complex data (calendar_XH data file).
So I'd propose a flexible and easily enlargable format, may be a JSON named array.

Then we'd need a repository plugin to display all those informations.
How would the plugin get the informations? Does one have to enter a URL for every plugin? Seems to be tiresome, if there are finally 150 plugins. And how does the plugin know, that a new author has developed a new plugin?

There could be a central place where all active plugin authers are listed with an URL. The repository plugin could get the authors URL from there. These URLs should give URLs of all plugins a particular author is offering. So there would be three steps:
1 - going to central place URL and getting the list of authors
2 - going to autors URLs and getting the list of plugins
3 - going to actual plugin URLs and getting the information

just an idea, may be there are better ideas
svasti

[cmb]

So I'd propose a flexible and easily enlargable format, may be a JSON named array.

Gets my vote.

There could be a central place where all active plugin authers are listed with an URL. The repository plugin could get the authors URL from there. These URLs should give URLs of all plugins a particular author is offering. So there would be three steps:
[...]

Sounds good. The file with the URLs of all plugin "descriptions" could be a simple text file with one URL per line.

Then we'd need a repository plugin to display all those informations.

It may be useful to have one or more examples of plugins that could be used by the developers themselves to present the plugin on their website. I definitely would try to use a plugin to use the information in the plugin description file to avoid maintaining the plugins's web pages manually. To do so, I anticipate some individual extensions to the format; it might be prudent to allow for this in a way, so that further extensions resp. changes to the format will not cause any incompatibilities.

[svasti]

What about a Plugin Pluginpromoter_XH:

• in the backend you enter all the text to promote your plugin (in a structured way)
• the plugin generates a corresponding JSON-array in e.g.: userfiles/downloads/pluginpromoter/quoteoftheday.plp
• the plugin generates the text on a XH-page, e.g.: {{{PLUGIN:pluginpromoter('quoteoftheday','calendar','morepagedata','...');}}} or simply {{{PLUGIN:pluginpromoter();}}}. The plugin first would look for the JSON on its own site, and if not there, look at cmsimple-xh.org/userfiles/downloads/pluginpromoter/pluginauthors.dat where to find the JSON. Calling pluginpromoter without pluginname would mean listing all available plugins, internal and external.
  The plugin could store the downloaded JSONs for faster retrieval and display.

Usually the plugin author likes to display his/her own plugins fully and other plugins only with 1 line, which could be enlargend by user action. May be plugins could have 3 displays: single line, short description, full description.

It would be nice, if one could download the plugin right away through the generated listing. This way one wouldn't have to visit dozens of pages to find the newest versions of all the plugins for a new site.

[svasti]

I'd propose that pluginauthors should be encoraged to put a desciptive file of their plugins in the same folder as the .nfo file.
We would have to decide if json or xml is better.
xml-advantage: Easy to read and easy to create. Easy to make changes in it. Disadvantage: has to be transformed into a multi-array later (not a big deal).
json-advantage: Information is already in array-form. Disadvantage: Cannot be written by hand.

Considering the advantages and disadvantages I'd go for xml.
We could have for every plugin a myplugin.xml. Alternatively a plugin author could write a combined plugins.xml file (exactly this name) containing the information for all his plugins.

So, the seaching plugin on cmsimple-xh.org will filnd in the .nfo files where to look for plugins.xml (i.e. in the same folder)

In course of time the plugins.xml file could become more complex, but we could start out with:
Names of the plugins each with subcat: demo-url, download-url, compatibility, licence-type, cost, maintainer, author, former authors, language with subcat: keywords, description.
No version info necessary as that could be read from the .nfo file.