more then 8 blocks areas

now we have 8 areas:
left, right,
top left, top center, top right,
bottom left, botom center, bottom right

it'll will be useful if administrator could create all the blocks area he needs... in others cms is possible

Hey Mamba, if there is a poll module on here I think we should try having a list of features listed for 2.6 and let the users choose their top 5 features that they desire.

Would be interesting to see what features we have listed would be most desired.

Rodney

For poll, it was interesting to have a new topic that listed all features.

+ a new default modern theme
+ core content module
+ block with it owns url and searchable if thats possible
+ easy mobile version of our xoops website
+ tags
+ improvement of the core pm module
+ more blocks position
+ social network share button in xoops fb/twitter etc
+ profile module upgrade - i like the vbulletin profile features..
ability to add friend, recent visitors list etc
+ cron job in admin panel
+ avatar auto resize
+ redesigned all the core system blocks to be modern,
+ site logo manager
https://xoops.org/modules/newbb/viewtopic.php?start=0&topic_id=71580&viewmode=flat&order=ASC&type=&mode=0

thats all for now

I shared this in the developer thread and will do so here as well...

With the core we really should build 2.6 to have support for three different ways to add functionality.

By including them in 2.6 I think we will be building a way to migrate alot of current core functions to this. By migrating things out of core we can simplify the core and make it easier to upgrade in the future and outright replace with a totally new system.

The three ways to add functionality and the details on each one...

Modules: Modules include both an admin interface, user interface, also includes permissions and full access to other things as well. Basically would be what we now use as modules. I do believe we need to add 3 things to the Module system. We need a dependency system, a way to monitor when updates to a certain module are available, and bring a way to do multiple install, update etc to modules. (Like the initial install). The dependency system should prevent modules from installing without the required dependencies being the case first. And modules etc that have dependencies on them should not be allowed to be removed unless the other modules are removed first. Or will automatically disable the modules.

Plugins: Plugins should be things that are very light. They should be basically add-ons to the system that allow better functionality but don't have a user side to them. Admin plug-ins would be something that adds to the admin control panel. Such as xoopscare. You can also include anything that would be an add on that could be used by modules. Those things that have an Admin side to them to adjust them but are not stand alone and are used by modules. Things such as the Tags module would go here. You use Tags from other modules but the tags module really isn't much useful on its own. No reason why you couldn't package plugins together as well so you are not installing 30-50 plugins. This should be added to the dependency system as well ..

Libraries: Libraries would be a set of code in the form of objects that can be accessed by any module, core or plugin. These would essentially replace the framework system as we know it. There should be a core library and then support for other libraries to be added to this. There would be no limitations on these accessing the database so there should be an admin side to these as well. Even if it is a generic system that just allows installation, update and deinstallation. Essentially any function or associated data would be included in the libraries. With this in mind the add on libraries would be intended for stand alone libraries that are not already included in the core but will be maybe migrated to the core library at some point and module libraries. The Module libraries should be any and all code that does the main work for the Module. Because these would be bare objects there would be no user side or permissions etc. These would be similar to how frameworks are used now. We should also use an Autoloader system for ALL libraries except core code that wouldn't make sense as they are used constantly (Such as criteria, xoopsobject etc) . This would promote code reuse and help develop future modules more rapidly.

These are the things I am looking to program into my "uModules" project but I think they would also work very well built into the core. (I had further discussions of ideas for these and reasons for them in this thread). I think that the current code base for the core is too bulky and tries to do too much. By putting a system like this in place for 2.6 we can then start pulling alot of the code out of the core and update it on the way. Things like the image manager, rating system, comment system etc should all be plugins. The main core API could be built into a library with this system as well. By pulling the code out and putting it into plugins and libraries we can simplify what the core is doing.

It does sound like the work being done on the XMF framework is headed in this direction and even the RM Commons stuff is going in this direction so I think it is a solid idea. I think I have expanded it out further and trying to relate it to changes we should make to the core code to support for the future.

Hello,
i know it's a small thing but it will help a lot and it will decrease the number of tables in database is to include one 'vote_table' and a vote system like the comments because right now each module add his own vote table.

Tarik

Hello

I am a French amateur user, absolute fan of xoops

I dream of:
-automatic and simple URL REWRITTING in the core of xoops
-automatic SITEMAP GENARATOR in the core (for google and Co but also, most beautifull for visitors)
-TAGS in the core
-PRIVATE MESSAGE MANAGER with more advanced specs (notification mail sending particularly)

Thank you very much, Great Idea !

+ a new default modern theme(I can help?)
+ core contact, slider, tags, social network share and content natives
+ easy mobile version of our xoops website
+ theme manager and theme editor (see the system of wordpress)

SEO:
+ URL REWRITTING native
+ XML Sitemap generator native (see: http://bit.ly/pc3Lwl)

this is my suggestion.
thanks!

We have had a lot of great suggestions in this thread and they are being compiled for seriously looking at. I do hope that people realize that there is a lot of work to get accomplished and I think in order to bring out a useable version there will be some limitations on what can be brought out. We should start thinking about the branches and how we want to progress on these. Do we want a "super version" that does A LOT of things or do we want to move forward with new branches every few months. Each branch (2.6, 2.7, 2.8) should have a different "theme" and from there we should look at what to add for that "theme". IMHO..

At this point in time I think that the "theme" for 2.6 should be to bring the 2.x branch more up to date. And make preparations for any structural changes for the future. If we followed the suggestions that have been put forth then the theme here would be things like better SEO support, Changing the Database engine, updating anything that has a newer version. (smarty, phpmailer, etc... ). We should also look at adding things like plugins, library support or other items we can use to extend future versions. We should also look at doing things like the blocks anywhere (Which also by design would make blocks unlimited.) If we do the blocks anywhere then this would be when to do the publication of the blocks as well. Multisite would also be a good addition here.

Once we have the 2.6 thread done my thought is then 2.7 would be the major "extentions" or "module" and GUI version. This is when we would get more serious about adding more support for rapid module development, pulling specialized code out of the core and making them into modules or plugins (Things such as image manager, comment section, authentication plugins etc...) Prior to 2.7 being worked on we would settle on a CSS/XHTML framework system that would be used throughout the system which would make it much easier to centralize everything into the theme. This could be where we change the template system as well. This would also be where we incorporate XMF into the core to help with module reuse. Plus if we decide on a Library system or something this is when we would want to make it exist..

Assuming we have a library system and an autoload system in place I would think then that 2.8 would have its sole purpose to be to pull a lot of the core code pulled out and put into the library system. The core included frameworks would be converted into libraries as well. Since this would be a large under taking it would likely take some time.

Just some thoughts.

My reasoning for the 2.6 branch is that the 2.x thread has been left to die on the vine for the past 2 years while the prototype for 3.0 was being developed and a lot of things have changed since then. We need to modernize xoops and prepare it for future versions. There is work on a new module framework (XMF) and discussion on some other changes to make to CSS. I think these ideas won't be ready for 2.6 and there are FAR many other things that are already over due that we can add so that we can build a better mouse trap for 2.7. The 2.8 branch would take into account all the prep work done in 2.6 and 2.7 and make better use of it. Along the way the modules should still work that were made with the "blue move" but newer modules could be made with less code and be more standardized in feel. (Heck newer versions of modules may be able to be gutted and be better versions.)

In System/Blocks the title does not have the name of the module of membership, may have different modules of the same name or same functionality and it is hard to tell at a glance which module belong to certain blocks. Another solution might be what you are doing now but with the addition of a small image of the module, before the block title