Personally I think you should look at a tier grading system, ermm gimme a sec to explain but I think this could work.

Lets look at a simple grading system first, listed below are possible grades and what is required to achieve these grades (an XOOPS graded image could be used to show it's status).

First of all there should be a status applied to modules again maybe with an XOOPS image, and similar to way Joomla list their components showing which systems a module is compatible with.

(please note the txt below per status is taken from others ideas of how to grade a module)

Entry:

As Mith stated:

1) Installs through XOOPS module admin - i.e. database tables are created during installation
2) Navigational through main menu (if it has front-end pages)
3) Access governed by XOOPS module permissions and XOOPS user login

readme file with basic information, module support site / support email, and bugtrack tool
Description of the purpose of the modules, as well as a little

Install file which indicates how to install this module
background information (why, motivation, etc...)

help file, addressing common problems, dislayed in forums

GNU License Text

Changelog, informing of applied changes /bugracker Nr links

credits file, listing those that have participated in the module development process

upgrade file (if applicable)

lang diff file (if applicable)

Although a database is not always required imho

I've not tried Wiz modules so I'm only assuming that this would make his self-acclaimed module, an entry module ie it's basic it's not all XOOPS but it's basic enough to qualify.

Intermediate:

From bender, including the basic entry first:

- uses XOOPS functions besides a xoops_version.php
- uses language file support
- does have an admin area integrated into XOOPS backend - Not always required though.
- does have theming support
- Should be integrated with Search feature - if required
- If Users in the module then also be integrated with the XOOPS users.

Advanced/true module:

From Jen:

Is this module using XOOPS comment system. Test posting
Is this module using XOOPS notification system
this module uses cache functionalities
this module is smarty compliant, uses template, and applies it to theme design and theme css
Preference settings are available. No settings in file.
Xoops search functionality will be able to search data in this this module
Block are configurable through XOOPS admin (optionally in module's admin)
all usual XOOPS directories are in use : /admin, /blocks, /class, /images, /language,/sql, /templates, /templates/blocks)
Rem: cache /include /class /images are optional

I'm sure there can be a lot more added here too, I'm no expert so this should be down to some one whom is.

Quote:

And why can't people make money from it, people like McNaz and Marcan are doing some outstanding work whilst also offering a commercial service. Commercial services can help benefit us all, they certainly benefited me and I know many others.

There are many others which offer some excellent commercial services via themes and modules, they all bring extra value.

When a developer submits a module or theme, they should also be given the option of claiming status, it is then down to the module cert/quality team to confirm and post the article under the correct status.

This way everyone wins.

I also feel all these modules and themes should be submitted to the XOOPS download sections, and feed from source forge. One of the most annoying things is finding something you really need or want from the news then finding the developers site is no longer on-line, and neither is the module, availability is always an issue for me and I'm sure others.

Quote:

Over your posts in this and other threads I keep seeing this dictatorship thing keep popping up, I certainly don't feel this way, I have my own mind, I've challenged people on here before, admittedly not always in the correct way, and if after debate I feel I made the wrong assumption or decision I stand corrected.

I think Benders initiative here is exciting and well over due, I've worked with bender before, and I would like to assume we are friends, we spoken many times I respect him amongst many others. He's aware he's human and simply lives to better any potential mistakes.

This thread is not about discussing dictatorship, as he's stated if this is what you wish to discuss open another thread for it or deal with it via private message.

keep up the good work guys and gals

Just to clarify to avoid misunderstandings:
I only want database tables to be created, when there actually ARE tables to create.

Basically, my thought is that when I install a module through the modules administration, it is installed. I don't have to run installation scripts to setup the database tables (since it is very trivial to do this the XOOPS way, I find this a very reasonable requirement), when it's installed, I'm done with installing and can immediately go to configuring it (using my XOOPS admin account - not by creating a new one in the "module").

Basically, if it walks like a horse and jumps like a horse, I might as well use it as a horse and call it a horse (don't take too literally, please).

If language files HAVE to be XOOPS-structured and use XOOPS functions etc. we'll have to disqualify a great number of modules such as Wordpress and the ZenCart module.

Maybe there should be a better distinction (category for ported scripts) or a text saying "This module is a port of scriptname version x.y.z"

Another note is that I am not commenting on Wizanda's statements, modules or anything - only Bender's question.

Quote:

That sounds a reasonable idea to me.

i also want to be clear on what i meant when i quoted

Quote:

I Meant That The 'Module' Will Install In XooPS. That It Becomes A Part Of XooPS. Yea I Know Its A Bit Of CommonSense That A XooPS Module Will Install Into XooPS, But That Should Be Stated.

When Any Module Gets Installed Through The Module Admin Section. Entries Are Created In The DataBase.

All Modules (Installed Through ModuleAdmin). Create Entries In prefix_modules For The Module's Name, Version, Directory Name, Etc.. Some Are Required, Some Are Not.

If Has Blocks.
Rows Added In prefix_newblocks ..

Edit:
So Basically ... Yea.. What Mith Said..

Defining axoops module IMHO is straight forward. If a script works and is integrated within XOOPS framework, then it's a XOOPS module. The real question is whether it is a standards complient module, or not. When we define exactly what those standards are and how they should be applied, then we can say whether it's comp;lient module or not. I nearly applied another definition by saying 'it must be within the XOOPS module folder' but even that has is not reliable. (vis. GIJOE's Wraps module which uses scripts in the XOOPS root)

Ported scripts wrapped in 'xoops include mainfile.... etc' are adopted modules rather than native and probably contain some security violations. They are still 'modules', even though non-complient.

Is ther a XOOPS module API? conventions?

Quote:

That's kinda how the grading system I've spoke of could work.

The entry level status couple encompass ported modules too, maybe even a tag-line as you mention just to make it clear.

I also feel it might be important to have a separate rating system for ported scripts which may require separate setup or configuration settings done in php rather than admin. There have been modules like this released I think one of the old invision ports worked similar (don't quote me though), although not compliant as a true module it should still be released as many people may want it even though it's not 100% a true module.

In my opinion I suppose I feel all XOOPS type things should be released even Wiz's latest attempts which are now on hold but given a rating as I mention, this way Wiz and others similar would be happy, and so would people whom want something more compliant, as it would be stated by an official XOOPS rating.

Thoughts on this?

Agreed and in my case; modules will have XOOPS langauges; as I learn more, so if it is a rating system, this may help us as they do.
As then we can then help depending where the module is to begin with in the rating system...
That way we can all contribute on a low rated module, if they are a needed fuction; untill it is higher rated module and so overall all XOOPS modules shines.

maybe we should propose a new category for users & developers and discuss some criterias for each.

Modules: These should be modules that have specifically been designed and written for the XOOPS system, and integrate fully with XOOPS both on frontend & backend coding.

3rd Party Modules: These are modules that have been created by porting scripts designed to be standalone scripts or ported from another System to work with XOOPS but do not fully utilise XOOPS coding or structure.


i'm not saying my interpretation above is the correct 1 or complete in description, it is merely an opinion.

ported modules always have these problems:

- the author is/can not responsible for the bugs in the main module/script.
- the author dont update module regularly or immediately when the main module upgrade( eg: xcgal)

so i think its good to have 2 categories in the news and also in repository.
1- ported modules
2- XOOPS based modules

so after that it can be possible to divid any module between these 2.
Personally i try to found a XOOPS based module even if it has not all features.

Quote:

But then based on what a module should comply with this still wouldn't encompass everything, as a ported module could be fully xoopsified.

You then have work like by Wiz which are not shown the light of day because they don't really comply with either.

maybe I'm wrong but I do feel some kind of grading system will help people when their deciding what modules to use to make an informed choice and also to see how well intergrated a module is.