A Call for "Extend" Improvements

[ccagle8]

With the upcoming 3.1 release, I want to spend a little time and update Extend with a few community-submitted requests.

What is missing in Extend that you would love to see?
Is there a part of Extend that makes submitting/editing plugins a pain?
What would you improve?

If someone else already submitted an improvement you'd like to see: +1 it in the comments.

Thanks in advance!

[ccagle8]

I am going to start things off (some of these came from discussions with Connie):

1. Create "rules" for plugins/themes/languages to adhere by. If they don't meet all the requirements, our moderators should have the ability to remove the file.
2. Break apart "plugin" and "core" language files. That category is starting to get confusing...

[mikeh]

I am going to start things off (some of these came from discussions with Connie):

1. Create "rules" for plugins/themes/languages to adhere by. If they don't meet all the requirements, our moderators should have the ability to remove the file.
2. Break apart "plugin" and "core" language files. That category is starting to get confusing...

What would be great is an addition to the api that I requested in august:

"I would like to request a simple api for extend which could retrieve an array including the title, download link, description, author, and version of each plugin."

It would make a plugin downloader plugin much easier to maintain.

[ccagle8]

"I would like to request a simple api for extend which could retrieve an array including the title, download link, description, author, and version of each plugin."

So one call that would give you that information for every plugin , or every theme? I believe our API already does this on a per-plugin basis.

[mikeh]

"I would like to request a simple api for extend which could retrieve an array including the title, download link, description, author, and version of each plugin."

So one call that would give you that information for every plugin , or every theme? I believe our API already does this on a per-plugin basis.

Yes that is what I am referring to. I know that it already does this on a per plugin basis.
I have a plugin-downloader I use for my own use that would be very ease to add to the extend if I could have an array with all the information at once, in addition to the per-plugin method.
If its too much work or you don't agree with it, don't worry about it. Just a suggestion

Screenshot of plugin downloader:

[ccagle8]

An article manager so we can have news/blogs would be good. Most websites I know benefit with a 'latest news' page of some sort!

This is a specific plugin request. I am looking for UI/UX/Feature improvements to the Extend section itself.

[mvlcek]

It would be nice, if language files

• would have a defined packaging, e.g. only the language file, no directories, zipped
  
• would be linked to a plugin
  
• would get an attribute language, e.g. "en" or "en_US" automatically extracted from the language file in the zip
  
• would be queryable by plugin with the Extend API
  

The idea is to have a plugin (or GetSimple Core function) to offer the user to download available translations for all installed plugins, when the GetSimple language is switched and offer a GUI to select additional languages.

But at least it should be possible to tell the user which languages are available with links to Extend.

[chrisbloom7]

Better support options per plugin. Instead of a single thread, how about our own forum area? That way we can keep track of separate requests, questions, etc.

Also, maybe some statistics reporting on downloads over time.

Finally, the ability to set a range of GS versions that a plugin supports, that way we could say that it works with GS 2 - 3.1, or 3.0 - 3.1, etc.

[shawn_a]

From a user standpoint and I imagine handy for devs too.

I would like to see documentation capability. Allow plugin or themes to register documentation files or links and plugin manager can show a link to it. I find i always have to chase down the docs for things like component plugins. What was that option syntax again, luckily some plugins register an action and stick some details in there , but that's overkill for docs only.

And plugin manager has no link to the actual plugin in extend, only an authors site, it makes finding info on it or docs or even version hard to manage. ( I imagine some of this is already taken care of with the new plugin features already )

[JWH_Matthew]

How about a Donate link? This would not benefit GS but it could encourage further development of that plugin if one was to donate.

[mogilka]

I'd like to receive extend's updates by rss, mail, twitter etc. Very much!

[Joshas]

How about a Donate link? This would not benefit GS but it could encourage further development of that plugin if one was to donate.

Flattr button would be nice too for plugin developers.

[ccagle8]

MikeH: here is your api call that lists ALL files within Extend: http://get-simple.info/api/extend/all.php
shawn_a: I submitted an SVN patch for your suggestion. Great idea! http://code.google.com/p/get-simple-cms/...ail?id=266

Everyone else - Keep them coming. I will continue to work on some of the other suggestions listed above...

[JWH_Matthew]

How about a publish date? Or a Don't display option.

The Publish date would be nice so you could integrate the API completely before publishing.

[mikeh]

MikeH: here is your api call that lists ALL files within Extend: http://get-simple.info/api/extend/all.php
shawn_a: I submitted an SVN patch for your suggestion. Great idea! http://code.google.com/p/get-simple-cms/...ail?id=266

Everyone else - Keep them coming. I will continue to work on some of the other suggestions listed above...

Awesome, in the plugin I will only make the api call if the user clicks on a refresh button.

Below are some more suggestions:
1. Could you return the description of the plugin?
2. A screenshot(s) field on the extend form.
This would be beneficial for plugins as well as themes.

For a plugin downloader plugin, there would be much less room for error if there was an 'installation level' field of some sort on the extend form. That way the script could adapt if a plugin installation required more then just placing files/folders in the plugins directory.

[RobA]

Not just in extend, but in the plugin API I'd like a way to specify requisites.

For example, extend now returns the entry "tested_with":"3.0" but it would be nice for this to be an array of versions that the plugin will work with.

Also things such as: php version required, gd or any other libraries, or even other plugins that a plugin depends on....

-Rob A>

[mikeh]

Not just in extend, but in the plugin API I'd like a way to specify requisites.

For example, extend now returns the entry "tested_with":"3.0" but it would be nice for this to be an array of versions that the plugin will work with.

Also things such as: php version required, gd or any other libraries, or even other plugins that a plugin depends on....

-Rob A>

I second all of Rob's request.

[ccagle8]

@rob & Mikeh - I agree with this request completely. The way I see this being changed (please confirm this is the way you guys would do it): The current "Tested With" becomes both the top and bottom of the "works with" range.

[ccagle8]

OK, a couple things that I got accomplished today:

- "All" extend api now shows description
- plugins now need to set their earliest/latest compatible GS versions.
- plugin languages are separated from core language files
- both extend apis now show earliest/latest compatible GS versions.

[mikeh]

OK, a couple things that I got accomplished today:

- "All" extend api now shows description
- plugins now need to set their earliest/latest compatible GS versions.
- plugin languages are separated from core language files
- both extend apis now show earliest/latest compatible GS versions.

great, thanks for the updates.

What are your thoughts on the below:
"For a plugin downloader plugin, there would be much less room for error if there was an 'installation level' field of some sort on the extend form. That way the script could adapt if a plugin installation required more then just placing files/folders in the plugins directory."

[ccagle8]

i'm not sure i follow what the installation field is for...

[mikeh]

I found a typo for in this api call: http://get-simple.info/api/extend/all.php

description node is spelled as desicription

[n00dles101]

Was toying with the idea of introducing a GS3.1 Approved or Certified flag for plugins and themes that have been approved and reviewed by the team.

what do you guys think?

[Connie]

that's a good idea, but who will do it?

Do you think we find the time to check? I will do my best to participate in that

[ccagle8]

I found a typo for in this api call: http://get-simple.info/api/extend/all.php

description node is spelled as desicription

I don't know what you're talking about Mike... I don't see this ridiculous error. Must have fixed itself