Wishlist for XOOPS 23

From XOOPS Web Application System

Back to: Wishlist for Next XOOPS | Wishlist for XOOPS 3.0

XOOPS 2.3 will be

• The merge of XOOPS 2.0* and 2.2*, which has been expected by all XOOPS community.
  • Profiles Module
• experimental implementation of features that not design ready for XOOPS 3.0
• PHP 4 compatible and supporting MySQL 3.23+

Add your wishlist as a XOOPS user

Please use "Horizontal line" to separate each one's post. Or you can refer to XOOPS 2.3 specs on sourceforge.

My feature suggestion:

• Feature one
• Feature two

User's wishlist for xoops 2.3 -
SEE: forum post added by Maxxy

SEE: forum post added by jimmyx

SEE: forum post by Slyss

SEE: forum post by Irmtfan

irmtfan:

• put each and every feature from XOOPS 2.2 in 2.3
• 2.3 should be released and get a stable label ASAP.
• do not spend more time to implement or add any new feature. first release the promised 2.3 and after that all new features can be added.

kiang:

• Change the i18n format from constants based to getText or XLIFF based.

SEE: forum post

Marco
- 1st : merge all the branches into one. For now, having different branches prevents devs from collaborating, because they feel it's not worth to collaborate on a dead branch. It generates frustration as well : no innovation. It generates private frameworks.
- 2nd : merge all branches into one ;-))))
- 3rd : write and imagine a strong and robust architecture for next branches of xoops, that facilitate evolution --> strong database model, rep structure, naming conventions

Garrath
(sorry for my bad english)
- first refactoring of actual xoops to php5 and to use the correct way to create object then after, we can have modularization of all you want in xoops. I think it's the only way to have Compatible Code modules, and there is lot of work in this way.
- after that you can add any feature...
- a choice for RIA... flex or an AJAX framework.

wingrider101

• One WYSIWYG Editor that is embedded and can be used by all modules. Easier development, and standards for going forward for the future. Allow other editors to be used as well, if desired, but embed at least one in the code that can be counted on to be there and hook into. For that matter, build all of the add-on "class" structures into the core, or at least support and distribute them with the core. Running around looking for all of this stuff drives you crazy when you need it in a hurry in a business environment.
• Captcha, or a Captcha-like spam prevention algorithm embedded in the core, and usable by simple calls from any module. Again, standardization, and ease of development.
• In general improve the security in use for e-mail addresses, user information, and access.
• Integrate "Protector" features into the core. As a seperate module, many new users do not implement it (because they don't know about it like I didn't!), and are at risk until they find out about it. Either ship the core with "Protector" in a supported fashion, or BETTER - supersede protector with core features that work better (like telling someone WHY they are blocked, and who to contact if it's a mistake, for example!).
• Eliminate the need for a "XoopsInfo" module. Build this information display into the admin interface, where it can be used as a standardized troubleshooting tool. This is "MUST HAVE" info for that purpose.
• Use "hover help" baloons, and have a link to real live working documentation or help off of the admin menu with easy return to where you were (Ajax?).
• More flexibility in the user "profile" table. Have a set group of fields (data to be collected), which are implemented in the login and new user registration, but allow the webmaster to define ADDITIONAL fields (maybe even just call an additional module/block as part of the registration or user infor processes) for custom use. This is a "must have" in order to be taken seriously in the business environment, where demographic data is the life's blood. BTW, business could care less about "Social Networking". This is NOT a path I would like to see Xoops go down.
• Ensure that avatars can be uploaded safely without opening security holes.
• Allow signatures that can be built using HTML and graphics (see Wysiwyg above).
• Come up with a way to display the user's e-mail address (if the box is checked) as a graphic that can't be read by bots, but can be read by humans (captcha for e-mail addresses???).
• Implement the "universal log on" according to the standards proposed.
• A seriously improved administrative interface is desperately needed. Use some of the great ideas that have been created for blocks admin, group admin, and module admin in the addon modules that have been created. PLEASE PLEASE either alphabetize the module list (you can eliminate the graphic icons too for my money), or better still go to a textual pull down system like Joomla has to work on the modules. Something along the lines of pull down number one, select the module admin interface from an automatically generated alphabetized list, pull down number two, select blocks admin, group admin, module setting admin (for all of the stuff that used to be on the modules main admin page), template admin, Image admin (see below), Pull down number three, Preferences list, etc.
• An improved Image Manager, implemented for easy use in the wysiwyg editor above, and with and admin interface that is able to sort the graphics, use key words and keyword searches, and allow moving graphics around, editing the data associated with the graphic, and deleting graphics on the fly while viewing the graphics in an ordered display.
• A spelling checker (see wysiwyg editor above) in the core usable by any editor (Aspell Implementation?).
• Put the installation manual and basic documentation in the distribution, better still, make them links right off of the main page during install, and available on each page thereafter during install. Make them available in the Admin interface as well (see below).
• Break the Administration menu selection out of the User Menu. Intranets have no need of the User Menu in some cases. Make it a group definable block or call that can be put wherever you want it, or which can be called quietly as part of a special icon or text in your theme (for security purposes).
• Update Mimetypes to include newer file types that are missing (nrg, dmg, daa, png, swf, torrent, etc) and which are "benign". Eliminate Mimetypes that we now know are problematic (PHP, HTML, etc.).
• Build the "Tags" module into the core. This would again allow new users who don't know about it to use it from the beginning, and would standardize how it works for development.
• If you aren't going to include a group of core modules (which I really think you should), then you should at least provide an HTML or PDF file with some "Recommendations" with links as to where to get the modules. Better still, how about giving them a copy of XSAS in the distribution, and put all of the documentation and things they need in there! Base it on popularity of the downloads, or whatever, but new users MUST be able to get at least a News or Article module day 1!
• Establish standards for included module and theme documentation. The Gnu public license is nice, but it's not enough. Support sites are nice, but they too are not enough. Every theme and module should come with at least 1. a description of what it does. 2. Version and release notes. 3. Installation and upgrade instructions.
• The internationally standardized language of the Internet is English. Xoops should adhere to this standard as the baseline for XO and for documentation purposes. We need to have a "Translations Team", made up of bi-lingual or multi-lingual volunteers who are dedicated to helping those for whom English is not their first language, and who are willing to assist in translating module and theme documentation prior to release, and on request by developers.
• I hate to say it, but set standards on the XO site for uploads... no documentation, upload deleted. If you make it easy enough to create documentation (a manual or howto, templates and forms), and provide assistance for our non-English speaking friends, then this should be an acceptable rule, and will go a long way towards standardization and user friendliness. BTW, the Translation Team can also provide English to other language translations! This will also go a long way towards providing English to other language translations as well. It just needs to be organized, and formalized. Documentation Team??
• Ensure that all PSD and other master graphic files are included with themes that are shipped with the core, so that they can be modified easily. This includes special fonts.
• Update the very old and very tired "system" blocks. Most notably "System Info", and "Who's Online". UGLY and tired. Put some JavaScript and dynamism to work in them. There are lots of examples.
• Xoops needs a reporting capability. Admin interface should include a "user info dump" at minimum. Statistics should be gathered automatically without having to install a third party counter or a module. Core statistics need to be available as a series of reports that can be run by admins to determine information about their system. In general, reporting is a really weak spot in Xoops, and keeps it out of a lot of business environments.
• A lot of great ideas and the code to implement them can be had at "PHP Classes Repository" [1]. It should be trauled for useful ideas that are easy to implement.
• The CMS Matrix [2]site offers a "spreadsheet" with which CMS has what features. We should look at our listing for Xoops, and update it where it's wrong, and take items we don't have and either add them to the 2.3, or 3.0 updates as appropriate.
• Trauling OpenSource CMS [3] for new innovations is not a bad idea either.
  
• How about some integration with CakePHP to allow easier module development for the more programming challenged among us? CakePHP has been selected as the new core framework for Mambo 5.x, which may mean Joomla will use it too. It does seem to be hot right now!

PPCM
- User management :

 * Have same fonctionnalities as in XOOPS 2.2
 * Make user management as a real module (not like in XOOPS 2.2)

- XOOPS Persistance Objects:

 * Make a real object inheritance, especially with the database

Pick up a task as a developer

Task: developer(s)

• New block engine:
• Admin area theme engine and GUI:
• Extensible user profile module: phppp,
• Modularization of private message:
• Modularization of banner management:
• Moularization of comment system: phppp,
• Moularization of notification system:
• Enhancement of XOOPS form and editors: phppp,
• Initialization of i18n: phppp,
• CAPTCHA implementation: phppp,

Refer to XOOPS 2.30 kick-off and task distribution

Back to: Wishlist for Next XOOPS | Wishlist for XOOPS 3.0