Mambo Open Source 4.5 Roadmap

Mambo Open Source 4.5 Roadmap

16 May 2003

Work has begun on creating Mambo Open Source (MOS) 4.5. (Mambo Open Source is Free Software and is released under the GNU/GPL License).

MOS 4.5 is a major overhaul of the code base and we are introducing many changes and fixes. We are also introducing into the code a new open source editor called htmlarea. We expect to have an early beta release available before the end of July.

For detailed overview of what is going into MOS 4.5 read on.

1.0 TERMINOLOGY
1.1 The use of the term "themes" has been dropped in favour of "templates"
1.2 The term Modules refers to code that is used to display content that is displayed on either the left or right of the main body of the page
1.3 The term Components refers to code that is used to display content in the main body of the page
1.4 For existing users the pdf directory has been renamed to media to accommodate various file types.

2.0 CORE
2.1 General code structure changes include formatting for easier code changes and maintenance.
2.2 Update the "auth.php" file to so the same functionality but with less code, therefore, increasing performance.

3.0 ADMINISTRATOR
3.1 Update all the administration code to remove the need for two levels of files i.e. "administrator/articles.php" then "administrator/classes/articles.php". This code will now all be found in the one file administrator/articles.php". This change is being made to both tidy up the code and make it easier to modify and update but also to marginally improve run time performance as there is the need to find and open one less file each time.
3.2 Addition of display # per page navigation concept to the "articles" list page. This will improve usability of this area for the administrator. Also general improvements in the coding structures of this section to include storing article variables into an array and passing the array through to the html code for display rather than passing long lists of variables for display. Also adapting the "add new" and "edit existing" forms to be only one set of code. This improves usability and removes duplicated code.
3.3 Addition of display # per page functionality to faqs. This will improve usability of this area for the administrator. Also general improvements in the coding structures of this section to include storing faq variables into an array and passing the array through to the html code for display rather than passing long lists of variables for display. Also adapting the "add new" and "edit existing" forms to be only one set of code. This improves usability and removes duplicated code.
3.4 Addition of display # per page functionality to top-level menus. This will improve usability of this area for the administrator.
3.5 Addition of display # per page functionality to sub level menus. This will improve usability of this area for the administrator. Also added the pass thru of the selected category name used to sort list on to the form when adding a new menu item. This is then the pre-selected default section to add the new sub-section too.
3.6 Update the display code for the sub-menu items so it will list the sub items one after the other, as they would appear in a hierarchical menu. This will use a recursive function in the code. This code is more robust and stable than the previous coding methods.
3.7 Update the whole image gallery to use new improved code and better methods of presentation of images, plus the ability to search on images etc.
3.8 Remove database functions, as these were security risks if someone were to hack into your Mambo administration area.
3.9 Build ability for page modules to be assigned to administrator defined pages.
3.10 Improve user management, add ability to edit a users details. Add a search form at the top of the user list to find a particular user's details more easily. Add additional fields to user table (TBC).
3.11 Online help in administrator section.
3.12 Add in some ability to upload new components and page modules. This will be an improvement on the existing functionality in that it will allow the user to simply select the file they wish to add to the "components" directory (for example) from their local machine. They can then give this component a name etc and click on an "upload" button. This would then copy the file into the "components" directory and rename it to the required naming conventions i.e.: comm_userlist.php. This script would then also open the file, and place the name in the required location within the file code id the name of the module has to be in the first line surrounded by "//"and "//" such as //Mambo userlist//. This interface will need to be added in the "Components->Main Menu->Install Custom" menu area, which may then need a re-design or an icon etc to allow you to upload your new module. Also a similar feature is required for the "Components->Page Modules->Install Custom" area as well. This code will be added to the "administrator/component_installer.php" and administrator/module_installer.php" files which are currently undergoing changes as well to try and separate as much php code from the html display code as possible and be more in keeping with the current Mambo coding structure.
3.13 Look at creating an easier method for adding templates. A new templates (changes from templates) directory, then an admin would upload a template_name.tar.gz file that contains the template file, a css file and a directory containing all images. The php script would then unzip the tarball, and create the directory as appropriate wherever it needs to go. This would involve an administrator uploading a tar.gz file containing the template php file, the css and a directory called "templatename_images" containing all the required images to make that template work. When the administrator uploads this tar.gz file, a php script needs to run that unzips the file and installs the unzipped files into the templates directory. This script would also then update a new database table that is used to store information about the templates available such as "template name, link to template index file, link to template preview image, date added etc". Then the code within the template manager would also need to change to read the data from the database rather than from the directories.

4.0 FRONT-END
4.1 Search Engine friendly URL's.
4.2 Update language support in the front-end to mostly read from the one file only. Also update the links to this language file to only occur once in the "index.php" page or any other page, which is not called directly through the index.php page. It was not necessary to have these function calls on every file. The benefit of having only one file is that people translating only need to make changes to one file, and also anyone looking for something to change only needs to look through one file.
4.3 Update the templates to remove as much php code as possible. This makes it easier for a designer to build a template without the worry of removing or interfering with unknown php code.
4.4 Provide optional Print and Email links to Top and Sub-menu content pages.
4.5 Provide ability for any content item to be linked to the front page.
4.6 Provide ability for Top and Sub-menu items to be just headings (that is, not associated with any content, they are just there to expand what's under them)
4.7 Provide ability for Top and Sub-menu Items to link directly to another component item (e.g., link directly to a category of News, FAQ, etc)
4.8 Provide support to associate Menu Items or Content Items to support a "Quick Links" module (i.e., dropdown or expanded list of 'bookmark' type links to otherwise buried areas of a site). {This could be used for the 'Front Page' items as well, so if the module was called bookmarks, then you could have Categories of Front Page, Quick Links, My Bookmarks, etc}

5.0 DATABASE SCHEMA
5.1 Numerous database changes in order to simplify standardise and increase performance.
5.2 Add new field "date" to the faqs table to allow the legend in the front-end of Mambo to display correctly.
5.3 Consolidate 'like' content tables (such as Articles, FAQ's, News and possibly Links, Top and Sub-menu sections) to use a single table thereby effectively reducing the amount of very similar code and schema for handling these individual components.

6.0 COMPONENTS
6.1 General code tidy of banners & banner clients code and the removal of anything to do with "finished_banners" code, which was old unused legacy code.

Mambo so (very) far

23 Apr 2003

" A lot of people ask us every day; where did Mambo come from, what's the difference between open source and commercial, and where does Miro sit with everything? The following is an extract of an email explaining a few of these things."

In the Beginning

When we started developing Mambo it was more by accident than anything. After a few years of building CMS-style websites we had realised that there was a commonality to the components we'd been creating. It makes sense that many of us want the same thing from a content-driven website, and the most logical thing we could do about it was to create a framework that would kick-start the development of any website, from the most basic to the most advanced. Sixteen weeks later, Mambo had been hatched. It was April 2001.

At the time the other content management systems on offer were community-oriented portal style bulletin boards; but what about the little guy on the corner who's struggling to keep his hardware store afloat and needs a professional online presence like pizza needs cheese. We wanted a CMS that would be accessible to everyone.

With Mambo Site Server's first release, nine months of debugging, testing and code alteration commenced. Mambo was just out of diapers and it had already made many quick fans.

Miro, Mambo and open source

We put Mambo on Source Forge in order for people to help get the code 'straightened out' so that it could be re-released commercially. Anyone who helped out by contributing code could also do the same, providing they acknowledged where it came from. Meanwhile, we continued to work on the 3.0.5 release, providing bug fixes and patches.

Mambo 2002 was released commercially early in 2002 after 5 months of re-development. It featured several functional differences, a vast number of optimisations & bug fixes, a nice html-based installer, and a manual. Many people still ask what the differences are - why should they pay for something that's probably not that different from the open source one? In lieu of contributing something back to the code, you can pay us for the thousands of programmer-hours that have gone into Mambo. After all, we had to pay their salaries :)

It's a curious thing, open source. Commercial software companies don't understand it. They think open source developers are mad, putting in 12 to 16 hours a day creating a brilliant piece of code and then giving it away for free. They are very happy, though, to contribute not a thing - while taking the code, adding a few touches to it and releasing it as their own commercial product. It happens all the time. Disappointingly, many individuals also think the same way.

So why does Miro do it? We offer the open source code at no charge, the community adds to it, we ALL take it away and use it for our own purposes. It's an evolutionary thing that grows to benefit all. That's the theory anyhow.

Miro developed Mambo and, as such, will continue to release customised, enhanced commercial versions of the code. Everyone else has the right, provided they adhere to the required acknowledgements, to charge for any value-adding they might do on top of Mambo; however, no one other than Miro has the right to sell the Mambo code.

Miro will NOT inhibit the development of the open source product in order to make our commercial version seem superior. In contrast, we build improvements and ADDITIONAL functionality to the commercial version of the code, suitably justifying whatever price we decide to charge. We will donate code from the commercial versions from time to time; and we will allocate developer hours to assist the open source community in building a better, more robust product. We will also continue to donate hardware, network, systems administration and technical support to the MOS project.

Growing the community

The simple goal is to see ordinary people able to publish their content to the web without having to be experts; to create a tool so powerful and versatile that the three main groups of users are 100% fulfilled. Mambo's 3 user groups are: the untrained end-user who is the content publisher; the web designer who doesn't want to wrestle with the code; and, last but definitely not least, the programmer who adds functionality to a robust, modular framework. If we just keep this in focus, then Mambo Open Source will stay on track.

Growing the community requires creating a stable developer base and continuing to develop a great product. Instability in the developer group will result in slow, buggy releases that drift away from the original goal. To avoid this we need plenty of interaction and agreement in an environment where we all get something out of being here.

Mambo at large

It would be foolish to ignore the fact that CMS's are here to stay, and Mambo is a sound competitor on this brilliant landscape. At Miro we believe that the future is ours, all of ours to write, and we'd really like you to be a part of it.