While there is a lot of negativity flowing around I would like to try something positive. At this point since there is no current plans to start a 2.6 Branch this may be just a pipe dream.

However lets assume that we start up development on a 2.6 Branch. What do we want to include and to what level do we want to go?

I like the idea of us going ahead and starting development on a 2.6 Branch regardless of what the XE team is doing. This branch should be considered "unofficial" and not supported by the Normal Core group. This should be considered at this stage as more of a community developed product at this point.

We SHOULD however try to only include items that will use current modules and not break anything in preparation to move to XE. But this should also prepare use of the X2 branch for years to come. This branch could also make the support of Legacy modules a moot point for XE.

Lets have only PRODUCTIVE conversation with this thread please!

Items I would like to see in a new version.

Multisite included in the core and installed as default to allow someone to add more sites on later. I believe multisite should allow a user to choose , by site, if they want to share a common user base and modules or use specific ones for each site. Thus you could have multiple sites that have no common thread in one engine instead of multiple copies of xoops. This would require any shared modules between sites were the same version obviously.


Multiple Database support.

These first two items have been developed at least in part already by wishcraft so they should be easy to implement.

I would also like to see the blocks anywhere hack be included into the core.

We should also consider removing any hard coded CSS code from the core and put it in the xoops.css file to help theme designers be able to build a true whole site theme.

I would like to see some improvements to the modules section as well as some better features to the install script.

If we add things such as the admin menu object they should be done with the solution in XE in mind so they can be more easily migrated.

Other ideas? Anyone willing to tackle some changes to the core?

I have some ideas for the install script and the modules section so I may work on something for those myself.

Also I think we should add hooks to the system for ALL sub systems so they can be replaced with modules. (Unless this is a huge performance hit.) Things such as comment system, authentication, user rating system, image manager, pretty much everything. This may also allow us to develop XE compatible "plugins" to help smooth the transition.

Hi,

The question is: is it that this is not already (or being implemented) in the x3? if so, why not implement it in the fork of XOOPS 2.5

Unfortunately it appears that we will need to move forward with planning for a 2.6 trunk. While we are working on a bug free 2.5 release lets figure out what we need today to bring xoops up to date...


Personally I will reiterate that I believe we need a new database engine, multisite as default support, better centralization of CSS code , and more flexibility for blocks.

It is with no disagreement that we need to get 2.5 finalized and finished up. But now with the results of what happened with XE we need to start working towards the future.

Do you think it would be a good idea that modules should actually be classes that extend a main core.module.class? Wouldnt that give us more control, extensibility and freedom on writing a module?

Even more we could have specifically named methods (in our modules class) to call for search, rss, latest submissions, comments etc and get the unified results from within the core.

the core.module class will just have to see if the specific method (showRSS() for example) exists, collect the results from each module that has it, and show them...does this make sense to you?

The Xoops image manager plugin for TinyEditor in Xoops 2.5.1 is very good (IMHO) but please can we have an image manager that uses relative URLs?. Absolute HTTP URLs are a real pain if you develop sites on localhost then upload to a live server.

Ideally, I would like to see the Xoops image manager become a file manager, enabling users to place links to downloads (e.g. PDFs) directly via the DHTML or WYSIWYG editor. Admins would naturally have some mime-type controls.

Also, in addition to category-based folders that everyone can access, it would be great if each user had their own virtual private folder in the image manager for which admins could allocate a fixed amount of file space.

Quote:

I am actually working on something like this...

It is not really core stuff but will operate closely with the core and hopefully provide module developers a common way to build modules.

If you follow this thread...

https://xoops.org/modules/newbb/viewtopic.php?topic_id=73281&forum=75&post_id=339822#forumpost339822

I am beginning work on a universal module system. It will be designed to work first with Xoops but because of its design it will allow modules to work with ANY CMS setup like xoops. So if modules are written for this they should also work with X3 whenever there is one made. This will evolve as I learn how things work but please check out that thread and make suggestions if you see something you would like.

I will be setting up a wiki page this weekend with my design and how I will plan to progress with it.

Rodney

Set date format in admin, or at the least as an install pref.

login using email instead of username and avatar image crop.

1. Date format will be defenitely a PLUS.
2. It should support latest version of PHP5.3 and MYSQL
3. Create PDF from any of the module/page (if its on the core, then no need to re-write the code on each module.
4. Some decent/light weight themes (as default)
5. One click functianlity to delete all post/comments by a specific user( now its a pain to delete a spammer's post by going to each and every module)

6. It will be great if Xoops.org can maintain a list the spam generator IP ban Lists and each of our xoops install should sync the server and update the IP ban list (the functionality should be optional to turn on/off)

Deepak