Filesystem Layout

The framework assumes a self contained directory structure for a site shown below, where areas in green are safe for site creators to alter things.

DOCUMENT_ROOT   The web server root directory (often ..../htdocs)
     /sitename This can be omitted if the site is the only one present and at the root
  /admin Used by the framework for messages files for offline etc.
               /css CSS files
  /favicons Favicon files
  /i18n Any internationalisation files you may need
  /img Image files
/js JavaScript
  /public If enabled, this is where uploaded files without access control are stored
  /scss Sass files
  /… Any other stuff that can be accessed without intermediation through PHP
  /class PHP class definition files named "classname.php"
  /ajax Put classes implementing your AJAX functions here, see the instructions for AJAX developers
  /config Classes in the Config namespace
  /framework Classes in the Framework namespace
            /ajax Classes implementing Framework AJAX support
            /exception Classes implementing Framework Exceptions
            /formdata Classes implementing Framework support for handling forms
            /pages Classes implementing Framework specific pages
            /support Classes implementing various functions that support the Framework
  /utility Some classes that provide specialist support
  /web Web related classes
/models RedBean Model files - add your models in here. Extend existing models using traits in the next directory
/modelextend Traits that allow you to extend some of the Framework's own models
/pages Where user defined pages go
  /support Where user defined support functions go - add methods to Ajax, Context and SiteInfo here
  /debug A place where debugging output goes when you use the Debug class
  /devel PHP files for development purposes only
  /licences Software licences
  /private If enabled, this is where uploaded files that have access control are held
  /scripts Shell scripts used when installing the framework
  /testing Various scripts and configuration files used when testing the framework
  /twigcache If Twig caching is on this is where it puts its files
  /twigs Twig templates go in here
  /content Twig templates for user pages : @content Twig namespace
  /framework Twig templates for the framework pages
  /adminTwig templates for the admin sub-pages : @admin Twig namespace
  /devel Twig templates for the devel pages : @devel Twig namespace
  /edit Twig templates for admin/edit operations : @edit Twig namespace
  /error Twig templates for error pages : @error Twig namespace
  /pages Twig templates for the pages
  /users Twig templates for login etc. : @users Twig namespace
  /util Twig templates and macros that are used throughout the framework : @util Twig namespace
  /view Twig templates for admin/view operations : @view Twig namespace
  /info Twig templates for robots.txt, sitemap.xml etc.
  /multi Twig templates for static pages with multi-part URLs – see the instructions for developers
  /surround Twig templates for header, navbar and footer content : @surround Twig namespace
  /vagrant Vagrant files
  /vendor Composer puts files in here.

Web Access

The .htaccess file is setup to serve :

  • anything in /assets to be served by Apache i.e. the Framework code is not invoked when these are accessed. N.B. this means that there is no access control applied to these files so anyone could get at them. If you have files (images etc.) that need to have access control applied to them then you must mediate accesss to them through the mechanisms provided. You usually need to do this if you are allowing users to upload files. Note that if you need total cacheability for your files you probably need to remove this line and enable the /assets page in the admin panel as this will deliver the files with all the headers needed to ensure cacheability.
  • anything beginning "/ajax" is passed to ajax.php. AJAX calls are assumed to be RESTful
  • everything else gets passed into index.php where it treats the URL thus:
    / => /home
    /action/r/e/st/ => Broken down by the Context object into a call on the class associated with action with the other values stored in an array.

Query strings and/or post fields are in the PHP superglobal arrays as normal ($_GET, $_POST). The Framework provides a utility class to access these fields that carries out a variety of common error checks so that your code is easier to read and it is recommended that you use this class where possible.