System-Check

[Tata]

So what about:

• Category(array),
• Name,
• Version,
• Date of last release,
• Compatibility,
• Licence or Cost,
• Developer,
• Download site,
• History of Plugin/previous developers,
• screenshot(array),
• description,
• user comments

For me this list seems to be to long and offers more than I - simple user - need.
I would feel totally satisfied with:

• Category(array),
• Name,
• Version,
• Date of last release,
• description

Everything other may be kept in the package itself. These infos are enough for me to deside if I download and test the plugin. If I decide to use it further, I will read details and evtl. decide (if this will be the case) to buy, advertise, link etc. the plugin.

[svasti]

May be it sould be something like this:
When the online visitor goes to http://cmsimple-xh.com/?Plugins (sorry not yet there) all the information is sent to the browser and further selection is done via java script (so it's fast).
(May be the template for this page could have a little wider editable area.)
I imagine there could be something like a table with 2 rows (or divs):
The left row could contain a clickable selection of categories (like a menu), the right row the resulting list of plugins, at first in random order and only a few listed.
Clicking on a category would list under the category in an "accordeon style" all the plugins of that category, like subheadings under as heading. Clicking on any subheading (= plugin name), would show the full description of the plugin on the right side.

The backend would have 2 levels: 1st level entering new plugins, 2nd level entering and deleting categories and different fields for the plugins.

svasti

[cmb]

hmm, several good ideas, but I'm missing a very important feature to rectify developing a plugin for this purpose: a powerful filter functionality. If this is not needed, we might as well stick with the WIKI approach. What I mean: the user should be able to filter by category, license, compatibility (i.e. required CMSimple(_XH) version), up-to-dateness and/or keywords contained in the description, etc.

I wouldn't put rating into it ..., but comments are quite useful.

+ 1, because the comment functionality could probably use a CMSimple comments/guestbook plugin. The rating would have to be programmed explicitely.

all the information is sent to the browser and further selection is done via java script (so it's fast).

I don't expect performance issues, if the plugin is mostly done in PHP. And the processing is probably easier to do with PHP than JS.

(May be the template for this page could have a little wider editable area.)

I can imagine that some information (list of categories, filter form) might be placed separately (e.g. in a newsbox that's placed in one of the sidebars only for this page).

PS: BTW: the discussion went somewhat OT

[svasti]

Yes has gone OT. Should we start a new thread? May be we just have to agree on who does the plugin. After seeing a first version we could continue the discussion.
svasti

[Holger]

Hi,

back to topic ...

I would like to see a "System-Check" too.
But how are the plans to code that?
IMO it should be possible to use the new (core-)function(s) in plugins too.

Holger

[cmb]

Hi Holger,

But how are the plans to code that?
IMO it should be possible to use the new (core-)function(s) in plugins too.

That's probably very reasonable. Depending on the flexibility the system check should provide, it might suffice to have a single function (at least as public interface) to do it. This function could be fed with a multidimensional array stating the required PHP version, the required PHP extensions, the folders that should be writable etc., and return the (X)HTML output.

If more flexibility is desired, we could code a class offering different methods that could be called as needed (similar to pluginmenu()). But probably the single function solution is simpler to use.

Christoph

[Holger]

Hi Christoph,

it might suffice to have a single function (at least as public interface) to do it. This function could be fed with a multidimensional array stating the required PHP version, the required PHP extensions, the folders that should be writable etc., and return the (X)HTML output.

Yes, for me that should be enough.
And probably it could be made with a few changes of the code from the system-check of your plugins?

Holger

[cmb]

And probably it could be made with a few changes of the code from the system-check of your plugins?

I've made a draft of the system check for possible integration to the core quite a while ago. It is based on the code that I'm using in my plugins, but uses an <ul> instead of <br>s (cleaner semantic). This might serve as a base for a parameterizable version. I'll have a look at it.

[cmb]

I've implemented and committed (r207) a first draft of the system check. Some usage notes for plugin authors: just call XH_systemCheck($data). $data is a multidimensional array that has to be filled before. It accepts the following keys (all are optional; list, pair and triple mean numerically indexed arrays):

• 'phpversion': the version string of the required PHP_VERSION
• 'extensions': a list of strings (the name of the extension) or pairs (the name of the extension; a boolean indicating the type of failure: TRUE=failure, FALSE=warning, default is TRUE)
• 'writable': a list of strings (the filepath, either relative to CMSimple's index.php or absolute) or pairs (the filepath; a boolean indicating the type of failure as for the extensions). This works for folders as well as files.
• 'other': a list of triples (a boolean specifying, if the check was positive; a boolean indicating the type of failure as for the extensions; the message as string)

For an example see the code that prepares the $data array in cmsimple/adm.php line 117ff.

Do you think it's useful this way? Can it be improved?