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,...
agree..this will confuse newbie as experienced by me when i first use xoops..i then since look for new release from the news section
currently this is the situation in the rep to many multiple module with different version a quick example is the forum category (cbb 1.16,cbb 2.32 <--this are dead modules right ? so there is no reason to let this modules stayed in the repository cause a stable version 3.08 is there)
everybody want to see old versions, history, can click on the mirror link that redirect to sourceforge.net
First, I am very happy with the way things are going, sorry I haven't been around I have had some things I needed to fix, non-computer related. There has been good response to this thread and I think this will work to the benefit of everyone. I like the fact there was a place to report Dead Modules created the same day as this original post. I will start another thread explaining what versions of modules to not use of mine and why, and which versions to use. Maybe other developers could do the same.
Some other ideas.
change the structure of the repository so the first page you get when you click on module repository is something like
Current Modules - Modules known to work with the current version of Xoops. Orphaned Modules - Modules no longer being actively developed, but still work. Dead Modules - Modules that DO NOT work with the newest version of Xoops. Maybe even a Non- Secure section for modules that have reported security risks.
Maybe the forum could be changed so that the modules section is broken down the same way. So when a user replies to a post they will know whether it is a Current Module or not.
For this to happen we need to evaluate all these modules and see which ones should fit into which categories. Maybe we should have something like an evaluation party or evaluation weekends, where we could as a community just see what modules still work with XOOPS
In my opinion we don't really want to get rid of modules, just make it so people won't download them and try to use them on a live site. We just need a special category for these modules. Because you never know when someone might want to use a module that is no longer a 'GOOD' module and they may try to fix it.
My original thought about this was for the community to do most of the work here, and leave the Core Developers to work on the Core, knowing that this other stuff will be taken care of. Although it is nice to see they are interested in this too.
I have a question. What is the newest version of this xfmod? I can only seem to find xoopsforge 2.0.7 and it is a part of that. I would like to take a look at it.
jlm69: your hard works are appreciated. i like to see you more involve in the XOOPS Project. according to the DPT Proposal: http://www.xoops.org/modules/mediawik ... x.php/Draft_Proposal_Team we should establish a "Module Dev Team" ASAP. could you help? just show your interest and write a draft proposal about the team creation ( rules,membership,...) and send an announcement here or in the new topic.
This seems to be a very good idea to me. I would like to suggest something that does not only count for the "old" modules, but to all.
As a newby to Xoops, I have spent a lot of time looking for modules and have still not found what I am looking for. The module(s) I need exist, but where to find them?
In the module repository are plenty modules, but only few have documentation, and less have good manuals.
Xoops was so easy to install. It took only a couple of minutes. Even for somebody new to it (like me , thank to the good doumentation for Xoops. But as you all know, XOOPS without the right modules is as good as nothing.
Then there is the problem that in the repository are a lot of modules that are outdated. Where to find a newer version (for a beginner)?
It would be nice to have a kind of spreadsheet, or table, in which you could find what (kind of) module would be best for you. "If you want to do this or that" try "that module". A simple cross-list would do.
The idea for a sample site is great, but please not only for dead modules. It would be nice to have a site with live examples of good working modules as well. All together with explaination how to set up those modules. Users of those modules could contribute with their experiences.
I have setup a site ietBugs.com which may be treated as a live example of a college students portal with all required services. None of the modules are dead. I created my own theme and integrated all the modules to make it a complete students portal. Hope you like it.
... a quick example is the forum category (cbb 1.16,cbb 2.32 <--this are dead modules right ? so there is no reason to let this modules stayed in the repository cause a stable version 3.08 is there)
Actually, this is an example where not everyone will agree that progress is an improvement.
IMHO, CBB 1.16a is still better than the latest version of CBB. In fact, there are many modules for which I have that opinion. It's not always a personal preference either, in my experience some new releases just don't work. The CBB 3.* series had a number of problems when it was first released.
The nice thing about the dev forge was that developers could easily present their latest version, but users could still choose a legacy version if needed (i.e. until the bugs were ironed out in the new one). Devs could also remove anything that was unsafe.
Conversely, the module repository is a simple download module where developers cannot change anything once it's uploaded. Which is why we get posts like this.
As long as it was classified properly (e.g. 'forums', 'image galleries' instead of developer-jargon like 'troves' and 'snippets') then a dev forge replacement would be the place to go for XOOPS modules IMHO.
First off John, let me say a hearty "Well Done" for stepping forward with what will surely be a "daunting" task. The module repository is frustrating at best in it's present incarnation. The categories make little sense. Most modules have little or no documentation. The ones that do work are lost in the rubble of the ones that don't. You are dead on in all counts.
jlm69 wrote: I am not a XOOPS Core Developer, nor am I part of any team in Xoops. I am just a XOOPS User just like you, and I like XOOPS alot.
That's the best kind of motivated user. Some of the "Core Team" could learn from you! I like XOOPS a lot too. I'll pitch in where I can. I have a hard drive that is essentially a collection of all things Xoops. It's not sorted to any great extent, and it's certainly not ready for prime time, but I can build a torrent, and you or anyone else can get it (it's a BIG file). I spent 5 years collecting all of it. I'll leave it up to the new Module Dev Team to sort them all out. I can help some, but I haven't even scratched the surface on the vast majority of them.
Over the years I have read some posts saying that this module or that module doesn't work anymore. I think we should get this sorted out.
I couldn't agree more!
BlueStocking has posted a zip file with all of the XOOPS Modules in it.
And a hearty big thanks to Darcy for doing that too! I downloaded it the day it went up to compare against my list, and I have a LOT more than the zip file, but there were some new ones in there that I didn't have.
I think We as Users of these modules should help these good people I mentioned earlier because they can't do what I am thinking by themselves, so here is my idea.
When you download a module to use on your site and it doesn't work, don't just be disappointed and walk away from it, you can notify me or we could have a special forum to report 'Dead Modules', some way of knowing they don't work. Then we can have them removed from the Module Repository and maybe have a special place for these 'Dead Modules', once they are listed maybe someone who wants to use one of them and has the ability can update it so it can be put in the Module Repository again. To make this work we would need people willing to do the testing of these modules, no one person or small group would be able to do this themselves, but as a community we could make this happen.
How about another field in the WF-Downloads or whatever it is that XO uses that contains the "status" of the module. Like "Certified" for modules which have been tested and found to be working by the Module Dev Team, "Pending" for a module that is working with the current version by popular report, but which has not been tested by the Module Dev Team, "Broken" for modules which do not work, and "Obsolete" or "Superseded" for modules that might work, but newer versions exist? I have long maintained that the modules for file upload and download are inferior to the very oldest BBS software's capabilities back in the 80's and 90's.
Module documentation standards MUST be imposed. Additon of a fileid.diz file to describe what the module does... a Readme with special instructions... install_en.txt for a file in english that describes installation... manual_en.txt for the operations and admin manual... user_manual_en.txt for the user operating manual (yes, the users need to know all those fancy features built into the module, or what point is there to the module?)... and so on... I have lots of ideas... maybe we should open a section on the Wiki for a module "Submission Standards" compliance rule set??
I'm not asking you to test all the modules on the list, but pick the one or more that you would want to use. If you would like to contribute something to Xoops, but don't feel you can, here's you chance.
We could even have polls or some way of knowing which modules are most important to the XOOPS User (You) and then maybe some developers would see the need and fix a module for the community.
I have to disagree with you here. How many times have you seen "I can't get module ___Fill_in_the_Blank___ to work ... blah blah blah..." and in the next 4 posts they go something like "works fine here", "no problem", "how do you (unrelated to the module problem to begin with) do something". All of these are mis-leading to the newbie, and the pro. The fact is that some of us can't read, and we miss the detail that makes the module work, causing us incorrectly to believe that it doesn't. Do we want the status of a module to be determined by the "mob" as someone once put it?
I believe, and have always believed that a module when submitted must be tested by the "Module Dev Team" (for lack of a better term for who does the testing), and goes into one of those states I mentioned above until it's tested. Yes, that's a lot of work NOW, because there are some 2500 modules, and 3000 themes to be tested over the life of Xoops. But over time, as things get tested and certified, the actual number of modules to be tested per month is manageable for a team of three or four people dedicating an hour a week to Xoops. I believe it could be done, and it's the RIGHT way to do it. Otherwise, it's chaos, and a year after you finish, we'll be right back where we started... if we finish!
That's kind of how I got started doing my modules, I wanted a Jobs module for a site, so I made one out of the myads module, then I saw that other Xoopers wanted a Jobs Module so I released it, and as they say the rest is history.
I don't have all the details figured out it's just an idea right now , but lets figure a way to make this or something like this happen. I know that the XOOPS Core Developers and the XOOPS teams out there read these posts, and I'm sure they wouldn't mind a community effort like this, in fact I don't know, but I think they would really appreciate it. I have not asked for permission from anyone to do this and no one has asked me, it is just me asking the Community I have been a part of for a long time to come together and help those good people make XOOPS the best it can be.
Let me add, that there is a bigger XOOPS Community... Cube, Tube, ImpressCMS, you name it, there are forks. If we really want to take the "higher ground", another field in the module repository might be whether the module is compatible with any of the other forks. We don't have to test them, we just have to have the submitter/author tell us that it works with XOOPS Cube, and XOOPS Classic... just a thought, and I know that it would go a long way towards getting some great modules that the forks are developing into our repository, and getting the entire community including the forks working together. Just a thought.
If it takes having a special site for these Dead Modules, I could make it. I am willing and able to work on this. How about You.
This is not for Modules that have a few errors, it is for Modules that no longer work at all.
If they don't work with current versions, or don't have support any more, why keep them? Make a list certainly, but I wouldn't try to maintin the dead modules in the repository other than as mentioned somewhere else, having a "catchall" area on Sourceforge or somewhere. BTW, Sourceforge is in trouble. The advertising is going up because their funding is going down. The thingy asking you to register on every download is NOT going away. And it's getting VERY slow. There are about 20 fewer mirrors than there were this time last year. I'd rather see a XoopsForge set up somewhere for module development, and a simple FTP site for old and dead modules.
Thanks for listening and if you have any ideas please don't be shy.
I'm not! It's a great idea. Let me know how I can help, and if you want all the stuff I have, drop me a private mail... and before anyone else goes running for the PM button,... I'm offering this to the Module Team, NOT the general population. Maybe I'll put the torrent on a public tracker somewhere (any offers for who would like to host it?), and if someone offers about 4.3GB of space (unzipped) to hold it, then we can make it publically available. I can't spend the time tidiying it up, but at least you'll have a LARGE collection to get into... Volunteer sites that run BT?
Just in case I failed to mention it, and I did.... I would not had thought about downloading those files and making them available if D. J. had not mentioned to me how important he thought it was to have the modules archive backed up. I thought so too and volunteered to do my best to make it happen.
It is good knowing there are copies out there that can be re-coded and updated.
This is where my module-ability ends. We truly need those who have expertise with module building to pick up on what they can do and submit.
We need someone to set up a workable file structure, that shows what modules go with what XOOPS versions, etc.
We have the wiki so it would make sense to start making pages and relating them through categories.
As a side note, the Wiki is very forgiving on misplacing a file at first... they move from category to category with just the addition of a couple of braces and a category name. They can be put in multiple categories.
I can help YOU work with the wiki, whoever YOU are.
i start to purge module repository from old versions module that have newer versions. BlueStocking: could you help me? just go to admin and begin from the last page(39) because i start from first page and now im in the page 3... just set them offline
If you want more people to use your system you need to change one or two things. First the most popular and use type of sites on the ne contain a FORUM you in your idiots way do not include a forum with the basic set up AND thoses you have for down load dont work even whne instructions are followed thay #OOPS# up the admin page. this wasts users time and dos no credit to yourselves you need to sort this out or you will face legal action some time in the future (false advertising extra)