XOOPS: The light at the end...
Posted by: skalpaOn 2005/9/27 16:40:00 35778 reads3) About XOOPS 2.3/2.4 The release of this new version of XOOPS intending to show that what was announced are not vain promises is also expected very quickly. Those which have been able to follow my presentation during the FOSDEM or read the roadmap for XOOPS 4 will recognize some ideas: I explained there how I saw the future of this system, and it is thus logically that the next releases will gradually bring us closer to this vision. To simplify, whereas X4 corresponds so what XOOPS should become, 2.4 will be an intermediate stage, corresponding more to what XOOPS should be today: best Web portal management system available... the modifications carried out during the development of this version will bring many possibilities, but some big additions like real multi-sites support and the Content Management layer will have to await a forthcoming stage (nevertheless XOOPS 2.4 will allow us to prepare the core to receive these additions). A detailed description of what this version will be made of should be the object of another article, but here are anyway some of the mainthings you will start to see shortly... Development methodology: - As of the first version (2.3.0), this branch will get instantaneously the level of stability and compatibility of XOOPS 2.0.13. The explanation is extremely simple: we will "go back in time" and will use the 2.0.13 codebase to work (which will be more practical and quick than to modify or repair some parts of 2.2). - This small magic trick will allow me to publish very quickly some improvements I have kept for almost a year, although they were never made public. - The functionalities of 2.2 will be added at this codebase, individually: some will be copied from the 2.2 branch, others corrected or improved, and the last ones concerning parts entirely remade from scratch in XOOPS 2.4 (like the blocks management) will be left of , but we will ensure in this case the equivalent 2.4 layer is compatible with both the 2.0.x and the 2.2.x one. - The unstables releases (2.3.x) will be really usable, although limited (for example: the 2 or 3 first 2.3.x may require Apache to work). These limitations will be documented so that most developers, designers or webmasters can possibly use 2.3.x without makor problems. - The creation of this branch will be followed by the creation of a new site dedicated to the development team: you will have the possibility to follow the evolution of our work and our reflexion, and to comment or participate (I talk again about this point later, as it is of extreme importance: the purpose of all the 2.3.x will be to show people what tomorrow will be, so they can give us feedback as soon as possible, before all is finished). A few objectives: - Low-level refactoring A lot of work will be done to refactor the kernel and its boot sequence. Here we'll have several objectives. The first will be to clean up this part of the core, and obtain something highly structured to allow further, distributed development of the classes it will contain. It will allow us to add a few functionalities before 2.4.0 is reached (enhanced session and auth, the possibility to use several boot files, real https awareness...). Last, this necessary step will allow us to bring some highly requested features to the core in a next (2.5./2.6) version, like the possibility to manage several XOOPS sites from a single install, or real multi-language functionnalities. - The output layer The new output layer will be one of the first additions to be released. Inspired from some of the concepts of OO programming (like inheritance), it will allow themes to have parents so a webmaster can make a common theme for his site, then add children themes changing only a few templates or files. This new layer will remove the confusing separation between themes and templates sets, allow any resource to be customized (templates, css, but also images), and is expected to be quite faster than the actual buggy one. - Web standards This part will also be extremely important: the respect of web standards is what will allow XOOPS to morph from a server platform (like most other CMS), to a real Web platform. All the XOOPS pages will strictly respect the HTTP standards (use response codes, redirections, but also send appropriate headers). On another side, several default themes will be provided: at least one to ensure XOOPS can work with old browsers, but more importantly one strictly standards-based XHTML theme for real browsers like Safari, Mozilla or Opera: and stricly means strictly here... if it was bad to misuse html tables some years ago, it's not better to misuse CSS or put