While this question sounds easy to answer at first 'something you plug into your website' it is still a good question.

I did a quick search and came up empty so far.



Now at which point does a script become a XOOPS module?

Just pluging a [size=xx-small]xoops_version.php[/size] file into a script would be the cheap way but then again not what i and some others would call a XOOPS module.

Now there are other criterias. For a start:

- uses XOOPS functions besides a [size=xx-small]xoops_version.php[/size]
- uses language file support
- does have an admin area integrated into XOOPS backend
- does have theming support

Now some are mandatory others might not be. E.g. some modules would not actually need a real admin area.


I really would appreciate some input here to come up with a defination of what is considered a real XOOPS module and what is more of a hack or what you actually would call it if its just an external script with an added [size=xx-small]xoops_version.php[/size]?

- Should be integrated with Search feature
- If Users in the module then also be integrated with the XOOPS users.

Perhaps a script can be seen as a XOOPS module if it can meet some/all the following:(from the original starting point for module quality asurance ages ago)


Is this module using XOOPS permission system
Is this module using XOOPS comment system. Test posting
Is this module using XOOPS notification system
this module uses cache functionalies
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 functionnality will be able to search data in this this module
Block are configurable through XOOPS admin (optionaly in module's admin)
all usual XOOPS directories are in use : /admin, /blocks, /class, /images, /langage,/sql, /templates, /templates/blocks)
Rem: cache /include /class /images are optionnal
A /doc directory that sets :
a) 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
b) Install file which indicates how to install this module
background information (why, motivation, etc...)
c) help file, addressing common problems, dislayed in forums
d) GNU License Text
e) Changelog, informing of applied changes /bugracker Nr links
f) credits file, listing those that have participated in the module development
process
g) upgrade file (if applicable)
h) lang diff file (if applicable)


Theres more if you want it with respect to the way code is written - but its a bit over my head...can send you the files Bender. let me know.

The arguments from the quality team actually apply in parts. Since a module might not get the certified sticker for not fullfilling some of them but might technically still be a module.


*Bump*

An interesting question as we have had some scripts submitted in news as "modules" although they are in reality self-contained scripts...

Marco and his team has done some excelent work with his quality assesment excel table for modules. I think the way forward for this is a rather old project which consisted of redesigning the module repository to reflect how the module is quality wise, based on the Xoops_module_QA Self Assessment V1.6.xls
I don't remember where that thread is but it might be worth reviving.

A XOOPS module! just a wild thought here.

should be built in the.

same architectural structures (and functionalities )
be the same as the previous modules
templates.
language
admin
xoops_version
includes
--compatible to XOOPS only.

then I would have define other SW that function within xoops, - as the xoops_plugin or xoops_hacks.
as a xoops_plugin or xoops_hacks it wont necessarily be built in the same architectural way, but simply be functional within xoops,

finally they all become module once you plug in

I think this is this link kaotik was looking for:

2.0 final of Quality Assurance tool for Modules released !

P.S. I just found another one too here:

How to build your own module ?

After what just happened of a person work being dismissed by anyone is wrong and so the approach to said problem must be!

As in what way does anyone have the right to say, oh its only an iframe of gabbly and so its not a module or it is someone elses Bible module to begin made into Xoops!
So this doesn't count either, so we stop all free sources all ideas unless it is systematical Xoops???

Xoops if you understand the core code is made of flipping hacks in the first place and loads of them, if it wasnt for new and innovative ideas XOOPS wouldnt be here.

So if someone manages to cross refrence ideas across the net to make something new, that works in XOOPS yet is a html copy so yes any other system, can also take it Good!!
It is open source!!!!! GPL GNU and the only reason I am here and others...

This is not and will not be a commercial project though it does apper like that at the moment...

So why if someone fixes the free games for instance isn't that a module, I used it, many still do...

Because the Iframe isn't in the templates as we speak its no longer a module so no one needs it?

Nope it is still working in Xoops, now a module isnt a module when it doesn't work and has security issues.
Yet that makes it beta or alpha not non exsistant that means you paint a picture of the mona lisa ooops its not the original lets forget about it...yet on the other hand it is actually better then the original and some tramp finds it in the bin and sells it to a collector and makes a million!


Xoops is not a commerical system that allows people to sell things, it is an OPEN SOURCE DEVELOPMENT!!!!!

Quote:

I'm worry Wiz but I have to disagree with you on that comment as I think you lack knowledge on the subject matter. The XOOPS core (2.0.x branch) contains some of the most coherent, well structured and best thought out php code I have seen in years. Even more so when compared to Drupal, Joomla, Mambo, Nuke cores.

I am sure if you study the kernel core classes more closely you will agree.