As someone considering starting a XOOPS site after a few Xoops-free years, I'd very much appreciate having a ONE-STOP source for modules where I can SEE-AT-A-GLANCE what likelihood there is that the module could be worthwhile trying out.

I think it is important that:
- it EASY for users to give feedback about the functionality of a module
- just because one user gets a module to generate a white screen of death should not mean that it lands in a module graveyard
- opinions from more qualified / experienced people are given more importance.

How about a simple five point rating scheme as a way of gathering initial feedback from users? I think this should reflect what the module should do, how well it actually does it and the security.
For example:
5 - works perfectly, great functionality.
4 - works with minor errors (php warnings?), good functionality.
3 - works but some functions give php errors and fail. Has possible security leaks.
2 - Only some functions functions work without generating errors Provides a confirmed security risk.
1 - does not work at all without generating php errors / causes XOOPS system to crash. Provides a major security risk.

A single parameter such as the average rating of a module multiplied by the number of users providing feedback or similar could then be used to determine how urgently a module was needing attention.
This could be done using a modified version of XOOPS Polls.

Alan

Quote:
Those are EXACTLY the kind of questions I hope the module 'orphanage' initiative should help to answer.

For example, I believe that a lot of hacker and spam exploits come through unsanitised forms and unsafe methods of requesting data through URL strings.

I more or less understand the issue of pre-defining POST/GET vars etc., but I could never find a comprehensive guide that explained what to LOOK FOR in a script that could make it vulnerable to other kinds of attack.

If the QA team has a security expert and they could publish some guidelines it would be a great help to people trying to upgrade a module IMHO.

For example, I assume one of the modules in the xfmod suite has a vulnerability that was used to hack the dev forge. It would be good for trabis to know what that was and how to fix it!.

Yesterday I found a module in XoopsAddons called cforge. It is based in xoopsforge but has been improved. It is 95% compatible with XOOPS 2.0 series, already using smarty, etc. The hard job is already done so I put 2001 xoopsforge apart.
This cforge also works with register globals on wich is a vulnerability. Some times it picks GETS and POSTS and trow them directly to queries. Cforge is a great step, saved me a lot of work but, but it is not finished yet, many bugs.

I've already made it work with register globals off and fixed some forms here and there, later I will install it in xuups.com so we can debug it better.

I did look at Cforge but my untrained eye couldn't see any difference from the later (2.1) version of xfmod.

If it has been improved that's great, but... unless the hacker exploited a vulnerability in Xoops, there is a serious loophole somewhere in one of those modules that needs to be closed, otherwise you could wind up with the same problem as the dev forge.

Can somebody with admin access please, please, please update the copy of Formulize that is in the repository? The version in the repository is 2-and-a-half years old. The latest version can be got here:

http://www.freeformsolutions.ca/formulize

Also, I apologize for not paying close attention on this, but can anyone fill me in on when/if the info that was in dev.xoops.org will be part of another site? There was three years for support postings and examples and stuff in those forums that was very useful to Formulize users and I would like to see them back on the web sometime.

--Julian

Quote:
updating the repository is in my todo list. but it takes times and i make mistakes.and you see i dont reach to DJ's modules too.
i will add these tomorrow.

Hello,

1. About "dead modules", why not creating a dedicated category in the module repository (with same sub-categories in it), to put those, instead of creating a separate area in the wiki, that adds dispersion. I recommend to promote unicity and homogeneity.
--> As a new incomer place, it's easier to look at one area and to know that module is declared as depreciated, instead of looking at another area.
---> As dev, i need a module and want to check wether there is already one that could match my needs and/or prevent me from creating one from scratch : it's better to look at one area, to pick up that module, and finaly to update/improve it or rewritte it with getting inspired with all good ideas/features already included in it

2. RC stages
Is the module rep the area to put modules that are still at RC stage ? Here too, take the end user point of view.
Xoops.org is the area to promote xoops, we have to promote quality, and modules should work before adding it in the rep. If the module is already free of bugs, it's up to its creator to tag it as final release --> we have to ask him to do so.

BS, irmtfan, i know you devote a lot of time on maintaining those 2 areas (thanks a lot), but what is your expert thoughs about each of those 2 points?

Marco
QA

@ Marco,
https://xoops.org/modules/repository/viewcat.php?cid=115
https://xoops.org/modules/repository/viewcat.php

DONE!!!

It may not be a 'useful' block but the block will be useful to us as a place to put our dead modules. /and release candidates.

Thanks for the suggestion, and if you wish to supply me with more appropriate text I will add it to the summary's and description.

Now you tell us what to list there when you find them, and we will do it ASAP ... Second though, you may be able to list them there yourselves. That would be a big help, don't you think?

We appreciate you, now keep those suggestions coming.

BS

my suggestion

...if possible replace the old modules with the latest stable release (recommended release)...and in the description put a download link to previous module release/ or a beta release

after establishing the "Module Dev Team" one of their first task should be defining "Dead modules"
as i wrote before IMO a dead module is a module that doesnt support anymore by anyone like Xhelp or Xstreamer.
maybe it still works fine even with the recent XOOPS versions, recent php/mysql versions,... but End Users dont have any support when it stop working.

so i insist on Moving these kind of modules in the category BlueStocking created:
https://xoops.org/modules/repository/viewcat.php?cid=115

Quote:
very true...
and it would be the second task for "Module Dev Team"
this is the reason i decided to dont add some modules to the repository.
in my idea we should have 2 repository:
# sourceforge: ALL modules, ALL status, really UP-TO_DATE
# xoops.org: Only Stables Modules, From well known developers, ...

and IMO we should just have "ONE LATEST STABLE" version from "ONE" module here in xoops.org.
for example dont need to have news 1.44, news 1.54, news 1.56,...
so we should just update old module not add them.

i said i made some mistakes because i add some modules but i should update them.
belia,

everybody want to see old versions, history, can click on the mirror link that redirect to sourceforge.net