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.
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.
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 frame 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 frame concept by allowing the site visitor to select one of a number of available frames, 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 frame, of course. Or, just for plain showmanship. ;)
Frames are now stored as subdirectories of the frame 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 frames as you like without cluttering the site's root directory. Note that as before you give the frame'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 frames to give you a feel for what is possible with Hyperframe. 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 frame for a live website, though you could of course use one as a starting-point to build your own frame. 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 frame 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.
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 Hyperframe interface itself remains single language, but page text, frame 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 Hyperframe 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 18.104.22.168
Frame 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.
Hyperframe 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 Hyperframe'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
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 Hyperframe 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.
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!
No changes that should affect compatibility with existing Hyperframe sites, other than the need to add a few options to sitecfg.ini
Improved display in older browsers, and a test for (hopelessly) outdated browsers before allowing online editing.
Several minor bugfixes
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 frame.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.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 frame 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.