Fork me on GitHub

Search

Donat-O-Meter

Make donations with PayPal!
Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00

Learn XOOPS Core

Local Support

Advertisement

XOOPS Code hosted on SourceForge

Cumulus Tag Cloud

- 2 2.5 2.6 3.0 4 6 2013 adslight Android AntiHarvesting AntiMalUser AntiSpam API Apple Battlefield billige Bootstrap By Captcha cell cent chronolabs CHUNG Clicks content CĂN demo docek download Dresses evden eve facebook Fat Food for free Gateway Google Guide herre Honeypot Human HỘ IP iPhone jQuery Law Legal List log Loss mobile module modules Monster new newbb news NHÀ online PARK Payment phone PHP Prevention profile project Protector publisher RESIDENCE responsive review Rights rmcommon security Sentry Signatures Signed site Smartphone Smoking Solution Spam Studio tags tdmcreate template The Theme themes web weight Wishcraft xoops Xortify XPayment

New Users

Registering user

# 137911

mydarkglobe

Welcome to XOOPS!

Archives

News Archives

Roadmap for XOOPS 2.6

Posted by Mage on 2012/7/7 13:30:00 (11837 reads) | Posted on Developer News
This is a proposed Roadmap for XOOPS 2.6.0. Please read it, and provide us with feedback and suggestions.

Resized Image

The development of XOOPS 2.6 will take place in three stages. These three stages are characterized every time by the release of an alpha version. So we will have three alpha versions. These versions allow module developers have enough time to change their modules and make them compatible and fully functional with XOOPS 2.6.

Alpha 1

· Update the XOOPS Core and all classes to PHP5 (public, protected, static) and E_STRICT.

- This is the main goal of this version. Of course, some modules may have some difficulty in the beginning, but E_STRICT will help developers to minimize errors and significantly improve the quality of XOOPS.

· Create a central class "xoops", this class will help developers and will give a direct access to XOOPS API

- This class will help to simplify the development of XOOPS.

· Delete unused files in XOOPS.(cache and template_c).

· Remove the extra themes and have a single theme for the administration and user interface.

- Provide a "theme model" as a reference for all themes.

· Remove / clean up old source code.

- remove legacy code of older versions (eg. XOOPS 1.0 with the use of PHP in the themes).
- remove all HTML code found in the PHP files.

· Automatic loading of all XOOPS classes

· Do not use global variables, these variables can be used from XOOPS class (e.g. $xoopsModule -> $xoops->module).

· Create a folder for all multimedia public frameworks (jQuery, CSS, JS, images, ...).

· Create Module Class Admin to give the same admin interface for all modules, this class already exists in such frameworks, but now it is included in the core and uses HTML templates.

· moving of some libraries, such as Smarty, to the xoops_lib folder.

· Refactoring the system module.

· Extract some parts of the system module in order to recreate them as a separate module create as a module (eg. Banners).

· Adding a new feature: System Extensions.

- Now some modules in the admin will be called Extensions (eg. Protector). Some features of the current System module are removed and recreated as Extensions. Added to XOOPS (eg. Avatars, Smiles, User ranks, ...).
- All these Extensions are runing as modules, but they cannot be renamed, and they will be shown in a separate menu module

· Integration of CSS Frameworks Bootstrap from Twitter.

· Removal of all queries for the block templates and modules.

- Now, XOOPS reads directly the templates for each part.

· Reduction of queries in all pages.

· New theme in the Admin interface.

Resized Image

· New theme in the User interface.

Resized Image

· New contact form.

- Use of templates.
- Forms Validation with HTML5 attributes.
- CSS3 and HTML5 compatibility.

Alpha 2

· Adding a theme manager in the system module.

- This section allows you to manage themes like modules so you can install, uninstall, or disable a theme.
- We can of course add a few settings in the theme (eg. Logo, size, etc. ..) and all these settings will be visible in the theme.

· Add of new plugins.

- Comments.
- Notifications.
- Image manager.
- Search.

· Integration of PDF library.

· Content module.

- In order to easily add content "out of the box" .

· Menu Module.

- This system allow to create all kind of menus.

Alpha 3

· Integration of rewrite mode in XOOPS.

· New connectors to access the data bases.

· Modification of blocks positions.

Beta

· Adding other features..
· Bugs fixed

RC

· Correction of the latest bugs.

Estimated Dates (Subject to change!)

Version Alpha 1: July 2012

Version Alpha 2: September 2012

Version Alpha 3: October 2012

Versions Beta ( 1, …): From November to December 2012

Versions RC ( 1, …): From January to February 2013

Final Version: March 2013


This timeline seems to be long, but it is based on current available resources. If more people will get engaged in Core development, testing, and bug fixing, we'll be able to release it earlier. So it is really up to the community to speed up the process by getting involved and providing help.

XOOPS 2.6 brings many new features and several important changes in the XOOPS Core. These changes were required to keep XOOPS as a world-class CMS. The Blue Move modules might need some small modifications, but they should be pretty straight forward, and appropriate tutorials will be provided. Older modules will need to be updated to Blue Move first.

The period from July 2012 to December 2012 is necessary to make modules developer more familiar with the kernel changes, and to update their modules.

If you are interested to join the team, don't hesitate to let us know, every help is most welcome. The more help we get, the faster we'll arrive at the XOOPS 2.6.0 Final release!

Your Core Development Team

Grégory Mage (Mage) and Nicolas Andricq (MusS)


Printer Friendly Page Send this Story to a Friend Create a PDF from the article
Bookmark Me
Bookmark to Google Plus
The comments are owned by the author. We aren't responsible for their content.

Woauuu,

i love read this :

- Remove the extra themes and have a single theme for the administration and user interface.
- Create Module Class Admin to give the same admin interface for all modules, this class already exists in such frameworks, but now it is included in the core and uses HTML templates.
- Refactoring the system module.
- New theme in the Admin interface.
Published: 2012/7/7 16:47 • Updated: 2012/7/7 16:47
This is surely BIG. One of the things I can add is, guys, porvide us with a nice AVATAR manager. Making people resize images manually is no good.
Published: 2012/7/7 16:52 • Updated: 2012/7/7 16:52
Looks nice! Only concern I have... What about backward compatibility, upgrade earlier xoops verions is one but also, will the upgraded 2.5.5 modules still function? Xoops can't afford a new debacle with a nice core but without working modules. And will current themes still work?
Published: 2012/7/7 19:01 • Updated: 2012/7/7 19:01
You can test already the current version as a new installation (upgrade for older versions of XOOPS is not available yet).

Download: from XOOPS SVN

Quote:

Flipse:
Only concern I have... What about backward compatibility, upgrade earlier xoops verions is one but also, will the upgraded 2.5.5 modules still function?

As stated, all the "Blue Move" modules that we are working on right now, and which will be part of the "Basic Module Pack", will be made compatible with XOOPS 2.6.0. I've been told that it should take 15-30 minutes per module to make it compatible, so there should be no problem with it.

And as soon as the Basic Module Pack is released, I'll start work on making them compatible with XOOPS 2.6.0, so we can test them and make sure that the modules, as well as the Core, are working well together.

I believe that the Basic Module Pack should cover 80% of the needs of our users, so if they all are made compatible, then we should be in good shape. I totally realize that having a XOOPS 2.6.0 Core without working modules is not acceptable, so you can be sure that we'll be doing whatever we can to make sure that the modules are totally compatible.

Of course, some esoteric and old modules will need more work, but it will be up to their developers to make those changes. We as XOOPS will take care of the "Basic Module Pack"

But I would like to encourage everybody to start testing the current pre-Alpha code, and most importantly, get engaged and start contributing!!!
Published: 2012/7/7 20:24 • Updated: 2012/7/7 20:24
Great news!

I will help with whatever I can in my limited spare time.

Still working on the PDO stuff based on 2.5.5. Depending on spare time available I hope to have this complete in the next few days. I will look at the 2.6 code when I am done with this and see if anything is different in the database class stuff. I believe the whole Database class should be modified to work with PDO as the intended class which should allow further refactoring of the core code to take advantage of the PDO improvements in performance and security.

This should only "break" modules that use xoops API for some things but for some things access the database directly. Because of the move to a multi database supporting API such as PDO, modules should always use the Xoops API instead of accessing the database directly. This will insure compatibility with xoops databases no mater what happens.

(If I do further development on the database stuff towards 2.6 Beta 3 I will try to document what I can along the way. Basically with PDO you should always try to use what is supported by all of the databases. PDO allows specialization dependent on the databases used but I think this is a bad road to go down since we can do without the specializations keeping it simple while maintaining future compatibility with other databases.)

Deka:
I am not sure if the extensions system was due to my pushing for this but I originally pushed for this because this allows us to easily replace core features with upgraded modules without requiring rewriting of core code. And similar as what has happened with Profile, PM and Protector we can have independent development which is great for us all! So now someone could create a new Avatar extension that is compatible with the old one and if it works well it could be included in future releases!

Flipse:
From what I understand from watching the discussions in the past the new core is much changed. This will likely be the biggest change to core since moving from 2.0.18 to 2.3.3. MOST of the changes were really required years ago but due to the (failed) attempts to moving to a xoops 3.0, further development of the 2.x branch was frozen. With this change to the structure in 2.6 a lot of the old, obsolete (for years) code has been replaced with newer much better code. From what I have seen mentioned from Xoops core developers and developers from forks the code really consisted of bandages applied over years by different programmers and made the code hard to manage. With 2.6 a lot of the old code has been updated and replaced with better structured code. Moving forward this should be the last major change to the core structure for a while. Yes this will require some changes in the module code but the changes should be very simple. Moving old modules to be compatible with 2.5.5 is MUCH more time consuming than the upgrade from 2.5.5 to 2.6.

As I work on the "move to blue" for xroster I will try to move it first to 2.5.5 and document all I do. But then I will also do the same to move it from 2.5.5 to 2.6. The conversion should be simple. A new database connector will be required due to the PHP extension that the current one uses is depreciated and is being slated to be removed from PHP in the future. Although moving to a new connector will support many of the new features of MySQL 5, the modules will only require simple conversions to work with whatever connector is chosen. Someone could however upgrade the module to make use of these new features of MySQL 5 but it won't be required. Alpha 3 looks to be where the new Database connector will be added unless I misread the above. The other changes required are due to the difference in how the new xoops object is designed and essentially should be as simple as a search and replace in most instances with some minor tweaks to code beyond that. Documentation will be the key here...
Published: 2012/7/8 0:09 • Updated: 2012/7/8 0:09
I like this roadmap specially reduction of queries and server resources is very progressive. please focus on it. Mamba even set a prize for it.

I just want to mentioned some important missings:

- Please move all possible configurations to the database. eg: captcha configs, image configs,... I can understand some important configurations like debug should be in file because maybe the end user lost its connection to the database. but all other configurations should be in the database. it is just confusing for new users to struggle in the whole xoops files. Also please unify all important configurations to the xoopsconfig.php

- The localization deserve more attention. please read features in sourceforge.
I like to see just one file for languages (one for admin and one for main module).
I like to see a Jquery calendar (fully localized)
I like to see developers using xoopslocal functions like number_format. they even do not use xoops API sometimes. it is too bad.
I like to see a local function for getting the inputted date/time.
see: http://xoops.org/modules/newbb/viewto ... id=347361#forumpost347361

It is enough for now.
Published: 2012/7/8 1:31 • Updated: 2013/9/9 0:31
I wish someone consoluted ForMuss before writting this you are missing the section I have been working on for him.. You will find all the code ready for merger and spot checking here:

Download: http://xoops.svn.sourceforge.net/view ... es/tasks/2.6.0-wishcraft/

Includes:
  • MySQL PDO Support
  • Postgres PDO Support
  • Postgres support
  • Firebird Support
  • Sitemap support with modules - see sitemap.org
  • DB Query File cache for long and repeated queries like config
  • Xortify AntiSlavery/Human Rights Abuses prevention
  • Comment RSS Feed
  • Actual Statistic in the Model Objects


This was for Alpha 3 but I finished soon than the core did in distro, so it can probably be rolled back to Alpha 1.

If you see the blue move whitepaper i sent Michael Beck on my additions for XOOPS 2.6 it will be the last of the open callable SQL engines of the late 1996 (Which the current one has a bottleneck in it, it performs better with the one i put together) as it is planned to move over to an ORM like doctrine in 2.7 which will require the use of the XoopsPersistenceObjectHandler object which is part of the model to call to the database correctly.
Published: 2012/7/8 4:40 • Updated: 2012/7/8 4:56
Quote:

This is surely BIG. One of the things I can add is, guys, porvide us with a nice AVATAR manager. Making people resize images manually is no good.


Support for gravata would be the best method of doing this, like wordpress and the other CRMS, ERPs and CMS as well as portals..
Published: 2012/7/8 5:11 • Updated: 2012/7/8 5:11
Quote:

And will current themes still work?


Speaking of themes, they need preloaders, there is an article in here somewhere i have linked to on the Cores Google group with the code for this. this is stuff like suckerfish menus and so on. Remember preloaders are for automations, when I came up with them for trabis to code in, I based it on the Hooking stratum found in Windows and how windows works with hooks like our preloaders, they may need a fail safe disabling so if one fails or E_ERROR then it is aborted for a period of time.. But apart from that i am sick of putting theme related preloaders for tabs, menus and other things on sites when they are part of the theme in the system preloader area.
Published: 2012/7/8 5:16 • Updated: 2012/7/8 5:16
If your wondering why a lot of my modules when you enable .htaccess mode seo so well, for example i had one site recently which sits 6th in the organic listings on www.google.com.au when you type in 'psychatric medico-legal' into it that has had no SEO promotions done on it, and normally these sites are attacked with demotion farms of pharmecutical companies and so on.. I will refer this comment:

Quote:

Alpha 3

* Integration of rewrite mode in XOOPS.


URL Sanitisation Article which should be part of it: http://simonaroberts.com/2012/06/19/s ... ion-farms-url-sanitation/
Published: 2012/7/8 5:21 • Updated: 2012/7/8 5:21
Quote:

Still working on the PDO stuff based on 2.5.5. Depending on spare time available I hope to have this complete in the next few days. I will look at the 2.6 code when I am done with this and see if anything is different in the database class stuff.


Redheadrod: Who asked you to do the PDO that was a task given to me by ForMuss.. Anyway maybe your is better there is a database benchmarking tool on the SVN I wrote, make sure you run some bench tests. I am about to for it on PDO with mine. We will see who performs better then swap code and do it again on each others system?
Published: 2012/7/8 5:26 • Updated: 2012/7/8 5:26
Quote:

Support for gravata would be the best method of doing this, like wordpress and the other CRMS, ERPs and CMS as well as portals..

wishcraft, you are a fan of globalization. first by Xortify and now gravata

Just please pay attention that xoops should work as an stand alone platform because after sometimes it should follow other websites changes too.
Anyway gravata website is filtered here like too many similar image related websites

please consider an stand alone avatar plugin for poor internet countries

Also please please do not work in parallel. we already have not many active developers around.
Published: 2012/7/8 6:00 • Updated: 2012/7/8 6:03
...and no word about language files ?
not using en-GB, en-US, en-AU locales, no changes in the way of maintaining them, again tons of duplicated files, and again PHP Define...
Published: 2012/7/8 6:53 • Updated: 2012/7/8 6:53
Quote:

...and no word about language files ?
not using en-GB, en-US, en-AU locales, no changes in the way of maintaining them, again tons of duplicated files, and again PHP Define...

I already mentioned this.
Please include localization in that roadmap.
Also there was a comment from somebody here complains about the timeline and it seems has been deleted.

IMO despite the Mage wrote in the news that timeline is rather short. It just 8 months left for developers and community to release the final version and they include too many undo tasks that accumulate from the old xoops system.

I wait for 8 years to see those mentioned improvements so 8 months is nothing.
Published: 2012/7/9 0:44 • Updated: 2012/7/9 0:44
Quote:
I am not sure if the extensions system was due to my pushing for this but I originally pushed for this because this allows us to easily replace core features with upgraded modules without requiring rewriting of core code. And similar as what has happened with Profile, PM and Protector we can have independent development which is great for us all! So now someone could create a new Avatar extension that is compatible with the old one and if it works well it could be included in future releases!


A stand-alone stable avatar module/extension with all the automatic resize and crop features inclluded in the xoops installation pack is an extremely good idea.

Quote:
Support for gravata would be the best method of doing this, like wordpress and the other CRMS, ERPs and CMS as well as portals..


Gravatar is a very good idea too, but as an alternative extra feature for the module IMO.
Published: 2012/7/9 1:39 • Updated: 2012/7/9 1:43
localization is too important. I stop useing xoops in some of our projects because it,s don't support some localization methods and don't have some important functions.

Some important methodes are :

1- local main calaender ( It supported by xoops at this moment )
2- local java calaender ( jqueryui calander support all local calenders ) But local languages must able to use local funxtions Instead of main function : http://hasheminezhad.com/datepicker
3- local captcha support ( irmtfan add this in persian version )
4- local support in pdf class , tcpdf support to many languages but we need function for localization it if you want use it in xoops
5- local number : numbering system is different system in many language for example in persian we use: ۱ ۲ ۳ ۴ ۵ ۶ ۷ ۸ ۹ ۰
6- rtl - ltr change : in xoops 2.3 if I use multi language systems when I change my language , local style lode and english style stoped, but in xoops 2.4 and 2.5 this function don't work , and if I change my site language old style still loaded and new stile not loaded

some of local functions is esay for add , I hope core developers support local functions

------------------------------------------------------------------
Published: 2012/7/9 4:29 • Updated: 2012/7/9 4:29
Quote:

1- local main calaender ( It supported by xoops at this moment )

not supported yet. local output date format is supported through local function "formatTimestamp" function. local input date and local calendar is not supported.

Quote:

2- local java calaender ( jqueryui calander support all local calenders ) But local languages must able to use local funxtions Instead of main function : http://hasheminezhad.com/datepicker

calendar is a user side feature so one java calendar is enough.
JQuery is added by timgno and maybe included in the next version:
http://xoops.org/modules/news/article.php?storyid=6333

Quote:

4- local support in pdf class , tcpdf support to many languages but we need function for localization it if you want use it in xoops

you mean if xoops use tcpdf we can have persian pdf? please show us an example.

Quote:

5- local number : numbering system is different system in many language for example in persian we use: ۱ ۲ ۳ ۴ ۵ ۶ ۷ ۸ ۹ ۰

currently number_format function is localized. but developers should use this function everywhere they work with numbers and want to show an output through templates.
for example newbb developer (alfred): in newbb/viewpost.php line 314
should change this
'post_no'             => $start+$pn,

with this:
'post_no'             => XoopsLocal::number_format($start+$pn),


Quote:

6- rtl - ltr change : in xoops 2.3 if I use multi language systems when I change my language , local style lode and english style stoped, but in xoops 2.4 and 2.5 this function don't work , and if I change my site language old style still loaded and new stile not loaded

it is ok in 2.5.5 now.
theme.html should contain the customize constant:
<!-- customized header contents -->
<{$xoops_module_header}>

Quote:

Gravatar is a very good idea too, but as an alternative extra feature for the module IMO.


+1
Published: 2012/7/9 5:50 • Updated: 2012/7/9 6:06
Hello everybody,

First, we are sorry to publish the roadmap at this time, we can't do it before and be sure that we do all the work that we can.
We can add some feature and analyse all demands in this release, but the main idea is to prepare Xoops futur.
We start from an old version (old code, etc...) and must give a first step for you for the futur.

Some points:
- modules: actually a lot of xoops modules don't use PHP 5.3 STRICT and can have some errors. We now that but we want to give a real help for change module and give more security and more power.
- themes: old themes work completly, but we need to have theme area like wordpress and just give a simple way for admin to change some settings.

Be sure, that we know that all changes is important for you, but if we don't change, we can't give to YOU all you need in the futur.
But a good community work, can resolve all problems, and give for all user all module for this release.

I hope that we can find some help for development, tests and docs for have just one way: XOOPS

Nicolas
Published: 2012/7/9 14:11 • Updated: 2012/7/9 14:11
We've opened a separate threads for discussions:

Please discuss the general Roadmap in this Thread

Also, we have another thread for Internationalization/Local Support issues
Published: 2012/7/10 1:31 • Updated: 2012/7/10 1:31
My modest support is available here
Published: 2012/7/11 14:18 • Updated: 2012/7/11 14:18
Quote:
If you are interested to join the team, don't hesitate to let us know, every help is most welcome. The more help we get, the faster we'll arrive at the XOOPS 2.6.0 Final release!


Based on this quote, and since the alpha version 2 of September is blown, what should be the program and the duties of those who would help the project?

A simple statement of work would help better!

Some staff should draw up a profile of the tasks to be performed, to arrive on time or before the final release.

Thank you!
Published: 2012/10/1 8:06 • Updated: 2012/10/1 8:06