print 

Mara flatfile CMS

Development and Versions

Version 6.0 production release, September 2016

Focus in this release is on responsiveness; the themes have been extensively restyled to provide a dynamically-resizing page that works well on all sizes of device from 400px width upwards. Responsive layouts do seem to be the way forward in Web design, so we aim to cater for that. Though, if you prefer statically sized pages don't worry, just change the theme.css to suit and you have a fixed-width page. That's one of the really nice things about Mara, the code is kept easy to understand, easy to customize. Understandable technology, is our aim.

Some of the older and more basic themes have removed from the main package. The intention from now on is to provide just three or four themes which demonstate how to create most popular page layouts. Additional themes may be made available for separate download. There is no longer a minimalist package; instead there is the single download with enough material to get you started on building a website. We feel this is a potentially better approach.

Included is the latest CKEditor, 4.5.11, with a number of important updates. Whilst editing pages on a phone is probably not a good way to work, we've even allowed for a reduced toolbar with only the essential buttons on narrow screens.

Upgrading from v5 should not present any major issues, but you should note that the naming of certain objects has changed. Therefore, plugins from old versions should not be mixed with themes from the latest.

One addition to siteini.php allows for a site language declaration.

Themes can now be called by their name regardless of whether hidden or visible. That is, theme=blog will load the blog theme if present, but will load any .blog theme present if not. This should avoid the need to change page headsections if you decide to make a theme hidden.

In the interests of providing the best experience on modern equipment we have to accept that 'the moving finger writes, and having writ, moves on' so support for older browsers, especially Internet Explorer versions before 11, is more limited in this release. We really don't want to go down the road of using browser-dependent code, since that makes everthing thing so much more complicated. Let's stick to CSS3 and keep things simple. Well, relatively. If you're using old equipment, then the simple solution is to install Firefox, anyway. 

 


Version 5.0 production release, November 2015

Name change to Mara cms, as it is felt this invokes more modern and attractive imagery, plus of course having Scottish associations. 

Some refinements in blog feature.

Component naming overhaul.

Restyled default theme.

Help pages updated

 

Version 4.2

Blogging interface

In this version we've introduced a system for indexing your webpages in a date-by-date format, which is the essential basis of a blog. See the example blog section for more information.

An updated portable version.

Also, a few minor bug-fixes.

Version 4.1

This is largely a maintenance release in which a few minor issues with the new 4.0 code are addressed, including a fix to multilevel site handling where .php extensions are used. CKEditor has been upgraded to 4.5.1

Image captions can now include single or double quotes.

As a security enhancement, the setting of a site-specific master salt has been made automatic on first change of the admin password, whereas previously this was a manual option. Note, this change means that the userini.php file is specific to one site only, and any backup/restore of the userlist must include all configuration files.

The demo user account has been removed, as it was felt that its presence by default is not desirable on production versions. To reinstate it, just create a user with name guest, password guest and Demo mode privelege level.  

A blogging module is also under development, and although it is working in a basic form it was felt that it was too early to release this for general use yet.

Version 4.0

It was originally intended to name this release as Version 3.1, however we feel that the changes made are of a sufficiently fundamental nature that a new major version is called for.

This time there are some fundamental changes to the theme structure which will require adjustments to any v3 or earlier sites which you wish to upgrade to v4. Therefore we suggest you read the upgrade instructions carefully before proceeding. In principle we'd rather not make these 'compatibility-breaking' changes, but the advantages are such that any small amount of reconfiguring of existing sites will be worthwhile.

New in 4.0:

In this version we've expanded on the theme concept by allowing the site visitor to select one of a number of available themes, which determine the layout and styling of the site. Since the choice is saved in the session, provided cookies are allowed it will apply to all visited pages on the site, for as long as the browser is kept open. This can be helpful for visitors who need a high-contrast display, for example - so long as you provide a suitable theme, of course. Or, just for plain showmanship. ;) 

themes are now stored as subdirectories of the theme directory, which is itself empty. This may cause slight issues for upgrades from previous versions, but is felt to be a preferable arrangement since it allows you to have as many themes as you like without cluttering the site's root directory.  Note that as before you give the theme's name to select it, not the full path. It maybe should have been like this from the beginning, but hey, hindsight is a marvellous thing.

We're also working on a set  of example themes to give you a feel for what is possible with Mara. By examining their php  and css code, you can also see how the various page layouts are constructed, which should help get you started with your own. As has been said before it's not intended that you should directly use any of these examples as the theme for a live website, though you could of course use one as a starting-point to build your own theme. That way you have the necessary elements in place.

The menu system is now a plugin instead of core functions. This gives the option to replace the menus entirely without having to rewrite the system code. The new plugin-based menu system provides both top and side menus from a common set of functions. Menu files themselves are unchanged, but some of the theme css styling options have had to be rewritten. Thus, you may need to do some restyling on your menus when upgrading. However, the new system is simpler and clearer -especially for the top menu- and allows more styling options. The sidebar menu is largely unchanged since this has always worked well. The dropdown menu is now click-based rather than mouse-hover based, and we think this will win friends fast from tablet users due to its better touchscreen compatibility. It should also make it easier to operate for people with limited dexterity.

In the page editor, you are now warned if you forget to save your changes.

Optionally, javascript and other code can be cached in the browser to improve performance. This is mainly of advantage in online editing mode where the large amount of code to be loaded causes a delay of a few seconds for each page. The downside of caching is that changes to code may not take effect until the browser is completely closed and re-opened. This can make error checking difficult. Hence when developing a site it is best to turn caching off. It is controlled by the browser_cache=0/1 option in siteini.php.

The Ajax data handler has been upgraded to correctly handle Chinese, Japanese and other Asian language character sets. Note that this will only work on computers with the required fonts installed. The Mara interface itself remains single language, but page text, theme text and menus -basically everything the site visitor sees- can now be in a much wider range of languages. Multilanguage sites might be an idea for the development pipeline.

New in 3.0:

Of the new features, we feel that the Quick Image tool should win the most friends. It offers what must be one of the most intuitive and straightforward ways of getting a photo or graphic up onto your webspace AND (importantly) displayed on the page with good, and controllable, styling. We said that Mara would be aimed at experienced webmasters, but we've bent that rule a little, realising that if you are to offer editing facilities to your clients, then very user-friendly tools are needed in some areas.  Feedback suggests that Image uploading is the one single area that beginner editors have the most problems with on any CMS, and this new tool should greatly reduce their difficulties.  Besides, it's handy for the experienced user too.

Fixes for minor bugs:

Image selector gives incorrect path if in subdirectory - Fixed in 3.0
Dir.php Preview uses wrong file types. Presently basing on action, should base on extension. Fixed 3.0
Page preview not terminating path with / -Fixed 3.0
Inline scripts limited to 3 in number. Raised to 255 in v3.0
Srcedit.php - Not checking permissions correctly. Fixed in 2.5.0.1
theme change not working from commandline parameter - Fixed 3.0

There are no significant code changes between the 3.0 preview and this production release, although the help pages have been updated.

History


Mara has existed as an internal project for around four years, used for our own Web presence and a few client sites. The early versions did not feature an online editor as this was not seen as a requirement where pages were being created locally and uploaded. With Mara's release to the public, user management and online editing were thought to be necessary additions. An innovative and simpler method of loading the common page elements was also developed. Hence the releases posted to Sourceforge are considered Version 2.x or 3.x

New in 2.5:

Preview mechanism now renders most file types as their native appearance. Since some people found the dual tree listing confusing, the file selector now shows only the standard locations for everyone, but Site Editor or higher users can click for an unrestricted view.

Easier online access to version history, with sourcecode inspector, for rollback of changes.

Editing sessions should not be subject to any time limits so long as the client remains connected to the server, but should disconnect relatively quickly in the event of the client computer or browser going offline or into standby. This is felt to offer better security against 'session resurrection' exploits -especially those created by browser tab-restore features- whilst reducing the incidence of timeouts during work. Two config settings, keepalive and timeout, control this feature.

Although Mara manages the page <head> section output to the browser largely automatically, it is sometimes useful to be able to edit that of individual pages. This can be accomplished by way of FTP or a file manager, but the new source editor feature adds convenience.

Pages may now contain tags which limit editing priveleges to specific users. See the Page Head section for info.

A page may now contain several discrete sets of gallery images, all of which are included in the slideshow.

 

New in 2.4:

Live source code editing is now possible, using a button in the editor toolbar. This performs direct code swapping between the page being edited and the code editor, without affecting the saved version of the page. Javascript or PHP scripts can be directly created in the source editor, provided that the user has sufficient permissions. (If the user has insufficjent permissions the scripts will be removed on copyback to the HTML editor)

When first logging in to the admin interface on a page with scripting, any data reloads necessary to permit script editing are now handled automatically by ajax, making for a much smoother process. If the user does not have sufficient rights to edit a page containing scripts, then on attempting to do so the page content is replaced with a warning message.

CKEditor enhancements are detailed in the /codebase/ck/CHANGES.md file. Some changes to ckeditor.cfg and ckinline.js have been necessary to accommodate the new version, which we think you'll find offers an even better editing experience. Firefox 22 or Seamonkey 2.8 are now the minimum browser versions for online work.

Harvesting protection is a very valuable feature in protection against casual leaking of email addresses to spammers, however it does impose some extra server workload if it is invoked every time a page is served. Since it should hopefully be the case that knowledgeable users don't make such blunders, it was felt acceptable to do the harvesting check whenever a page is saved from the online editor. This covers the main risk without impacting on the site visitor's experience. Harvesting protection is now ON by default in siteini.php, and will block the saving of pages containing nude email addresses.

The Tools menu now displays Help and File Manager links if and only if the relevant directories are present.

The Disqus plugin contained a minor oversight which led to its working with the example comment thread, but no other. Apologies if this caused some head-scratching!

New in 2.3:

No changes that should affect compatibility with existing Mara sites, other than the need to add a few options to sitecfg.ini

New in 2.2:

 

Plugins:

Improved display in older browsers, and a test for (hopelessly) outdated browsers before allowing online editing.

Several minor bugfixes

Site-breaking changes:

If you are upgrading an earlier site to 2.2 or later and wish to retain your existing menu styling, you need to adjust your theme.php to create a <div class="menutree"> container for the lefthand menu. As in:

<div class="menutree">
<?php sitemenu('side')?>
</div>

Previously this div was mandatory, being supplied by the sidemenu function in core.php. It is now optional. The change is to allow greater flexibility in menu layout and styling.

Version 1:

Version 1.0 operated more along the lines of mainstream CMS, in that pages were loaded via parameters to an index.php file. Although this arrangement was found very reliable, it raised the issue of calling for URL rewriting to achieve 'tidy' URLs in the client browser. The rewriting element was a real pain, since it interfered with access to files in subdirectories unless each had its own .htaccess directives cancelling the rewriting. Around v1.5 we set about eliminating the rewriting requirement, by way of loading pages reflexively.  This works by  prepending a php routine to all pages, such that the prepended script takes over from the webserver's processing of the page, and instead 'plays' the page contents in to memory buffer. From there, the theme items are added, and the result is sent to the browser.

The key advantage of reflex loading is that the URL you see in the browser topbar is the page you get onscreen, just as if it were a static HTML file, with no untidy gibberish and no confusing redirects. Naturally, this is also searchengine friendly by default, thus eliminating the complex URL rewrites often needed in mainstream CMS to achieve proper site spidering. Reflex page loading is also potentially more secure than parametric loading, since it is hard to see how a foreign URL could be injected into a direct page request. Meanwhile the reflex loader takes its referring-page info from php constants which, unlike URL parameters, the site visitor cannot change. Thus if the browser's request is not the name of a local file, then a 404 is generated and that is the end of the matter.

Version 2 sees the addition of user accounts and 'live' page and menu editing, plus several other enhancements.  This version has been a long time under development, perhaps not surprising as it's a fairly large project (Yeah, a LOT bigger than we thought it would be, but aren't they always!) and we're a small team doing this work as and when time is available in between pay-dirt jobs.

This release is now considered a production version, and is in use on several live sites. It serves our own main website which delivers ~1GB of downloads per month. We are still in the process of evaluating compatibility with various webhosts, and feedback on that aspect would be helpful. It has so far been tested on various paid and free services, and experiences are that hosting company settings for php do vary quite a lot, so some tinkering with .htaccess and php.ini is often necessary to get things working smoothly. That is unfortunately the nature of Web hosting, and we have to accept that adjustments to suit the working environment are often necessary. Greater standardisation of hosts would be a really positive step toward making it easier to deploy websites, regardless of platform, but then that is unlikely anytime soon.

 

Powered by Mara cms