Also remember to tell him to go into "edit" of the block - from the main System -> Blocks you can look at blocks available for Top Page/News/Newbb etc. - can't choose more than one in the drop-down menu...

Hi All:

I'd like to throw out my suggestions for core enhancements as well. Some of these have been mentioned, some have not.

I'm very happy with XOOPS and you guys have done a great job. Here are just a few things that I think would help a lot of people in the XOOPS community (i.e., not just my personal "wishlist".)...

NEWSLETTER FUNCTIONALITY

This maybe should be separate from the "receive email from webmaster" checkbox, and may be a module, not sure. Here are a couple of quick ideas.

Automatcially pull "new" content snippets from modules via a hook into each module (similar to the current "search" functionality). For example, when you create a new newsletter, it should automatically pull some type of information on new downloads, links, articles (wf-sections?), gallery items, etc., that have been added since the last newsletter, and provide links to the full content on the site for those items. This would require building an API into the core to call modules to provide this information.

Provide ability to allow users to receive the newsletter without being a registered member of the site (but some users may not want this, so it should probably be a flag).

CROSS-MODULE LINK CHECKER

For all modules that have the ability to link to an external website, including downloads, web links, news, provide the functionality on the admin section to parse and check for valid and invalid links, and allow some action based on whether the link is good or bad. Gossamer Threads' "Links" program has had this for years, and XOOPS is in bad need of it.

For example, if it finds bad links in the Weblinks section, the admin should have the ability to block-delete bad links from the web links directory. Same for downloads (or this super-module you all keep talking about).

It should also parse the News and Articles (Sections, WF-Sections, etc.) for included [url= links and parse them and validate those links and notify the admin if they are not valid or need to be manually checked.

AUTOMATED DATABASE PURGING

Not sure if this is a module discussion or not, but some some database tables need to have some sort of purging mechanism set up for them, either from the admin menu, or more preferably, something you could schedule in cron or something.

News, forum posts, inactive users, etc., are candidates for this automated purging. For example, say I only want to keep one year's worth of forum posts in my forum. Right now there is no easy way to do that. This is going to get more critical as more and more XOOPS sites are on the net longer and grow to have larger userbases.

CREATE TRUE USER COMMUNICATION SYSTEM

I know this work is in progress, and it may be a module, but the system used to communicate between users right now needs a lot of work. Here are some ideas.

Beef up the PM system to be more of an email like system. Provide the ability to send a PM to multiple users, incorporate the buddy list into the PM functionality, allow users to save their favorite addresses into an address book etc.

What would be even one step beyond that would be to provide the functionality to check external POP3 email addresses using the PM system, as well as send mail through those POP3 mailboxes.

Another feature that would be a nice addition to the PM functionality but is not necessarily related to the above it to allow a user to specify in their profile that they be notified by email when they receive a PM.

I think these would be great additions to Xoops.

I'd like to chime in. A LARGE majority of the CMS' out there fully support MySQL but not any other databases. If XOOPS would incorporate einsturz's work, XOOPS would take a HUGE leap forward and be the ONLY CMS (that I know of and I've been searching for over a year) to fully support MySQL and PostreSQL.

Refer to this thread for more info.

Please please please look over his work and incorporate it in the main source tree. I, as well as many others have been hesitant to go with any single CMS because of the lack of support for PGSQL. With XOOPS being MUCH more efficient and clean codewise over PHPNuke, this would be a huge win for Xoops.

Thanks,
-Ed

I think to that it would be very good if XOOPS support different Database. Mysql, Pgsql, Oracle, ..

It's a main functionnality to enter XOOPS in a professionnal
way.

I've already discussed the following modules before with core developers but thought it worth posting here too.

A build on jerryj's post.

I like the idea of getting pop in the pm's box and sending smtp but you would need to be able to limit this feature by member and group, after all you don't three thousand members downloading 20 E-mails a day to your server, imagine the space you would need.

Private Messages:

+ Limit PM inbox size by groups
+ Drafts and sent items - sharing inbox size, or poss have different limits per group.
+ Outbox
+ Search all PM's
+ option to turn of PM's for groups
+ Notification via E-mail for new pm's

Notifications:

+ Option to receive notifications when ever one is set (As it is now)
+ Option to receive a sumerised version of notifications either by the day, week, or month. (instead of individualy)
+ Option in admin to set either of the above as default.

Edit Users.

+ option to disable/suspend user account.

NewBB (Core Module)

+ Quick reply
+ Option to delete post without deleting replies
+ Option to move Post to another thread, with out affecting the thread it was originaly in.

There are more but this is a start.

I would love to know if there are any plans or time scales for the above so I can feed them back when asked, please reply per new feature request.

Good post tom. I agree with your suggestions.

This is a long thread, so I hope I'm not suggesting something that has already been said.

At the moment you can give a user/group admin rights over a module. For http://iamstalker.com I have hacked all modules so people could eg get admin rights over one category in a module, like one news or downloads category. This way I can give people something like a "hosted site". What I would like in Xoops' core is that every object has it's own read and write permissions. Maybe like on a unix system each object would have permissions for a user, a group and the rest of the world.
This would make it a lot easier to limit access to eg certain articles and will make my "hosted sites" easier to implement.
I think this would make the great framework XOOPS offers a lot stronger.

1) Multi-lingual friendly (or friendlier if you want) keeping in mind not only admin / programmer types but also average users who add content.
I did like what I had read over at Xaraya's site about the ability to turn off this feature to enhance performance in need be. But if the feature is needed, allow it at the cost of a bit of performance.
This should be something handled at the back-end exclusively. There is too much to get wrong by hacking the core for inexperienced people.
I think out of the box XOOPS should be multi-lingual because this will also force module development with this in mind.

2) Better detailed documentation.

3) I totally agree with sunsnapper's though concerning the theme management by better utalizing DIVs via CSS, etc. Seemingly a bit complex to start with, however EXTREMELY powerful. This really brings the page out of the box and gives much more freedom to designers.


4) both the ability to control access via groups but allow also for individual access (may actually be redundant or too slow?) I am open to be wrong :)

blessings,

Chris

Hey Chapi, thank you! It is indeed possible to extend the selection with Ctrl. Stupid of me not figuring out I could use the Ctrl too . In windows explorer I use it all the time

One thing I forgot to mention while the discussion was on:

It would be great if there were some way to coordinate events or sharing data across modules.

An example could be every module which has the ability to select a data and time for some event, should have a core-function to reley on, where all dates entered into the system, should be available in a database, along with a short description. This would limit the number of times the same information needs to be entered.