I've made a number of "modules" myself by Iframing... java chat modules (by using JIRC), Shoutcast playlists (by framing the default server), a wiki (by framing an existing one) and more besides...

.. but I've not released these myself as I don't count them as full modules.

I'm not saying that any code that is not 100% XOOPS code shouldn't be released... but for my cases, I didn't think they where applicable.

I know what you mean, yet in other place ideas evolved like that; remember XOOPS didn't always have Smarty and E-Xoops span off…. which is where I started at...
So in reference to an iframe module, these can be full adapted within XOOPS smarty given time, yet if we deny people the right of freedom of speech on here in the first place.
Which is basically how I feel now having a number of news and ideas articles; I just didn’t post due to that some moderators (not community) didn’t see a lot of ideas as purposeful and so denied freedom of speech, so then we won’t see any new ideas appear in the first place?
Like Shi-painter reference being stopped on comments, so I could ask phppp personally and being told to shut up?
So I asked on msn the other night to find also that the Chinese have been asking as well.
Now given that I did a lot of research to add it to my own site this helps others, as a demo yet still in an iframe to mix cgi and php.
We have to find a balance between an open source community and dictatorships; where people are in fear of posting anything some moderators don’t see as suitable.

Can you please stay on topic and if required open another thread for this?

Since this even concerns one of the issues in the other one i don´t understand why you are pulling this one off-topic.

Thank you.

Also how will XOOPS go about helping people as it always has done>?
Gabbly was hidden before us and after a people seeing new concepts like that it helps the web evolve more, which helps us, do you stop this?


Maybe on that note it should be us and we all vote and people get off this ego trip of they need to tell others with over 500 posts, where they need to post...its offensive..

skipped

Hey this is on what defines a XOOPS module.. now with the first post it came as law...
Which both me and Giba have included, why that this can not always be the case in some senarios and each could be voted on...
As everything is community is it not...
so it depends on if the programmer is one of us, why they made the module like that ect as some times you can't follow such strict rules...

Personally, I regard this a XOOPS module:

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

If those three criteria are fulfilled, it is a XOOPS module by my standards.

Language and admin stuff using XOOPS' structure would make it even more a XOOPS module (you'll notice that I have gradients ) but if the three above are fulfilled, I can use it in any way as if it was any other XOOPS module.

Otherwise the XOOPS port of ZenCart, Wordpress and similar would not be XOOPS modules - which I think they are.

So in conclusion; if a module is completely XOOPS'ified with language, admin, blocks and templates it would be great - but to the webmaster installing it on his or her site, it doesn't matter that much how it was programmed. If it has hardcoded MySQL stuff in it and XOOPS changes to be usable on PostgreSQL and the module doesn't work anymore, it is the problem of the module developer - we'll have to accept that, I think. However nice it would be to have perfect XOOPS modules that will always be working on all future versions of XOOPS, we just cannot be sure unless the module is completely using XOOPS's structure - and can we really expect to see a ZenCart system as a XOOPS module? Let's not overestimate the influence of XOOPS on other scripts (at least until XOOPS 2.4)

yes Mith I agree there are various 'levels' of XooPS modules
--
For Me I Believe The Base Of What Is A XooPS Module Is.
Quote:

#1 requires that the module also has a image for it. to show up on the admin menu. (this is kinda getting into the quality of modules.. like a set maximum size for that module's image )

Quote:

Yes. Gotta Be Easy To Uninstall. Like It Was To install. (again this is more into the module quality section... making sure the module has the lines to specify the tables the module uses in the database)

language files.. i believe that that is a must. that the module has to have the ability to use different language files. since XooPs is international and stuff..

[size=x-small]Edit: [/size] Able To Run On Different Configurations Of XooPS. Meaning That .. Using Version X Of XooPS, People With Different Modules Installed And Different Languages Selected.. Will Be Able To Use The Module.. -Install-Configure-Use-Uninstall- (That Again Is Leaning Into Module Quality. Variable Naming Conventions. Modular. Usability)

[size=xx-small] Edit.. Again:[/size] We Gotta Have Standards.. This is the XooPS.org site. we gotta set an example for the rest of the community sites. by having modules that work for different languages, it promotes sharing between the different community sites. if not .. language will become a bigger barrier. a barrier between different XooPS users that want the same thing.

Our Goal, Making XooPS The Best CMS Ever. With The Community To Back It Up. People From Different Backgrounds, Professions, Beliefs, Hobbies, Etc.. Sharing Their Ideas And Knowledge...

Maybe Thats More Of A . My Goal.

Taken from my post in that "other" thread -

Quote:

Like it or not, if it looks like a module and acts like a module, it should be called a module until there's something else you can call it. Perhaps there should be different "levels" of module category, similar to what Mith said above.

Rather hard to define. I would say this:

- Installs through XOOPS module admin - i.e. it has xoops_version.php. Creating database tables is not compulsory.
Example: Gijoe's altsys or tplsadmin modules. Those rely on (and modify) the contents of the database created by the System module. I don't think that makes them less of a modules.

- Access governed by XOOPS module permissions and XOOPS user login.

- Language files.

- Uses some XOOPS functions. (But probably the use of xoops_version.php can qualify as that.)


Having a front-end is not compulsory. Example: again Gijoe's altsys, tplsadmin, protector modules. Partly the system admin module.

Having an admin backend is not compulsory either. For example the Xoopsmembers module (which was part of the 2.0 releases not so long ago) has no theming support, has no admin backend but installs through XOOPS module admin, the access is governed by XOOPS module permissions and XOOPS user login and it has some language files in place. It does not need a database as it uses the one provided by the core (or system admin module).
Another example would be the sitemap module which has some preferences to set on the backend but that's it. It does not create it's own database, does not really have an admin part but generates a sitemap ffrom your site.

Having a search feature is not compulsory either. You don't need one for an admin type of module only. And if it is a front-end one: it really depends on the purpose of the module. Adding one to Xoopsmembers or Sitemap is pointless.

I'll just give an example with another excellent module (even used on here): comments search module which makes use mostly of search.inc.php. It does not have an admin part it hardly has a front-end as well. It again uses the database tables created by the core and you'll see it in action only when searching.

Would you all agree that all those modules I have used as examples are excellent ones? Even though a bit odd they add great functionality to a site (be it on the admin or user side). Can those qualify as anything else than modules?


I'll add that I fully agree with Bassman's post above.