Athena

Athena is a PHP 5 Web CMS or framework design to create an efficient hosting platform for a multi-user environment. A few of it's out of the box features include:

• Sophisticated content editing tools
• AJAX powered forums
• Shopping cart and e-commerce systems
• Integrated analytics
• Vector image classes

However for a full-list of features, please visit the official Athena website. For more about how Athena approaches the web with a lateral approach, keep reading.

Synopsis

The goal of Athena is to create a framework and CMS (Content Management System) to be used as a wide foundation for both simple and advanced web systems. The framework is designed to meet the following critical requirements:

1. Offer an easy-to-use content editing platform
   
   1. Finding, adding and updating content should be user-friendly to end-users
   2. Code generation should be clean and efficient
   3. Content, generated code and content hierarchy should be search-engine friendly
   4. Content editing should offer any and all functions required by an SEO expert
   5. Images and media should be easily updatable by end-users
2. Offer safe-guards for mistakes or connection problems
   
   1. Real-time previews should be available in the content editor
   2. Content can be saved as a draft, without altering the live state of the site
   3. Drafts should be able to be previewed in a live-like state
3. A user and permission based hierarchy available
   
   1. Permissions can be distributed over users and access levels
   2. Content can be made available on read and write access levels, allowing sections or functions to be locked on a clearance basis
4. Flexibility
   
   1. URLs are assigned on a per-content basis
   2. Components (major systems) may exist on any page in any section, with any URL and not be limited by typical "section" methodology
   3. Additional and third-party components can be developed using an abstract base class, which entitles them to create unrestricted functionality
5. Efficiency
   
   1. The core should a framework for other component development to use for quick development and continuity
   2. The core should operate with maximum efficiency and minimal dependence on external data systems such as database queries
   3. All calculations specific to a transactions should be cached by the first caller, so that additional components or modules do not require a recalculation
   4. All common requests from the database should be cached in an IPC shared memory segment to reduce the overhead of database transactions
6. Redeployment
   
   1. Virtual host file-sets should be shared among many different virtual hosts
   2. The system should be able to add new hosts with minimal effort
   3. Additional hosts should be able to be created by a script

Abstract Base Topology

Problem and Solution

A key foundation to the effectiveness of Athena's management system is a lateral approach to the forward development of a typical website or system component. A typical approach is to provide a foundation platform, often a CMS or small framework, and then add 'sections' onto that which work independently (with the assistance of the framework) to complete that sections goal.

Once such example of this, for example, would be a conventional CMS that handles static page generation via content in a database and then uses a forums component to create a site forum. Often the forums component is an add-on which adds new tables to the database and integrates its own URL handler and using that, generates its own output parsed through the CMS's template system.

The problem with this approach is that normal content functions, such as adding body text or meta-data are now missing, as the forums component is in complete control of the output and URL resolution.

The solution to this problem has long existed in software development as "object orientated" programming. If we take the concept of object orientated programming and apply it to content management, then we can create a normal content page and apply a "derived class" which would be our forums component, on top of the normal content page then we can still use all normal content options, such as adding body text, manually controlling the URL and editing the meta-data associated with the page.

In this scenario, the core is still responsible for resolving the URL and passing page meta-data, body text, etc to the template while the derived forums component only adds to the existing page body.

Polymorphic Content Editing

In order to support the inheritance model for content, your content editor needs to be able to support generic content editing as well as derived functionality. Here-in lies the required need for a polymorphic content editor.



With Athena's content and component model, a generic content page receives it's "attributes" (such as meta-keywords, page title, etc) from an XML resource as a specification for stand-alone content. When the user selects a component in the content editor, the content editor receives new field information via JSON from the component class. This information can, remove and override the generic schema. This allows for Athena to create real-time polymorphic content editing and allow the user to provide the component with additional information it will require to generate that page.

Naturally, you can't provide all the information for a page to be generated in the content editor. Take a shopping cart for example - a category page can be loaded into the content editor and you provide no further information for the content editor. A backend component will then be set which will enable the user to dynamically apply products to products in one or many of the created content pages.

The creation of a page and setting it up as a category allows for the shopping cart system to create a category (which is all you are doing by creating a page with a "category" component), but still maintain control over exactly where in the site that category exists, and control all the inherited generic content options.

This model often appears unusual, as in conventional systems you would create a category in a special category editor. However, despite its unusual appearance this method offers amazing flexibility and control.

Complex Content Hierarchy

Athena's abstract content model boasts a new ability to control URLs very precisely at a much deeper level than conventional systems. This doesn't mean that all scenarios will give you the ability to enter a URL for every page - there will be dynamically generated content you can't account for in the content editor.

There are many ways Athena can account for this data. The ideal solution to control URL information for advanced dynamic systems is to use an integrated regular expression matching system. This system allows you to inform Athena of the URL syntax you require and then when Athena matches a URL to your RegEx, it will load a control page and pass the RegEx matches and a reference ID to the component. The component can then interact with the existing content hierarchy and then emulate extending the pathline, including automatically generation "Back" and "Up" navigation.

Athena's URL handler is very complex - it will also natively detect old URLs and provide 301 redirects to the correct page, detect draft and revision specifiers which allow you to view older versions of the page, or view a draft as if it were live.

Rapid Host Deployment

A large point of efficiency on the web is the redistribution of the same CMS over hundreds of hosts, increasing logistics for deploying and updating sites incredibly for anyone working with more than one domain. A CMS with single-host deployment options is only useful for small scenarios, so Athena has taken the best of both worlds.
Athena can work in two modes -

Multi-Host Mode

In multi-host mode, Athena's first point of business is to check the domain name the site was accessed from. When it receives a hostname it then checks it against a cached table of domains and associated sites. When successfully matched, the site engine has an opportunity to redirect the domain name, either as a domain redirect service or just correcting a www prefix to the domain name.

Once the process passes the redirection and site tests, it then is given database information for where it should connect to receive its content from. Each virtual host keeps its own database; virtual-host data is not shared or mixed in any way, keeping everything independent.

A potential problem here is then database structures need to be maintained across many sites. For this reason Athena keeps a version number of the current database structure and matches that against an integrated version number hard-coded into the Athena engine. If a mismatch is detected then Athena executes a database update procedure, which connects to a master database server and compares table structures.

If a table structure is mismatched then Athena will quickly recreate the table with the newer structure and move data from the old table to the new one, assuming defaults for new fields and losing data that is no longer required in the table. This process is normally executed in an unnoticeable timeframe, and executed before loading the requested page on that host so that the user that triggered the update will have the site update before them without even noticing.
When Athena has successfully acquired database information it can process the request in the same way it would a single-host connection. File data is separated into two sections - "common" data and "user" data. The user data is sectioned off on the file-system so that FTP access can be provided to the user files only, without revealing the core or other user files.

Single-Host Mode

Single-host mode is designed for single projects and redeployment on public or shared hosting. In single-host mode the site engine is skipped and direct database details for the host are used. Database updating is not checked automatically; however the database structure can be updated by manually asking the engine to check the database information.

Caching may optionally be put into fall-back mode. Fall-back caching assumes that PHP does not have access to shared memory and inter-process controls and the cache stores to a per-transaction memory only. This gives only marginally better than usual performance boosting, providing internal efficiency boosts only.

Caching

A conventional CMS will poll the database on every hit, and on every hit the database must be accessed numerous times to generate the content required for that hit. More complex systems, such as pathline information or automatically generated menus will require an even larger of database queries per hit.

Database queries are the slowest part of page generation and more often than not, the same queries are executing the same code. Although the database server should provide a caching mechanism to quickly respond to consistent SELECT queries, enormous time is spent establishing a new TCP link to the database server.

When Athena requests content of any kind, such as page data or component-specific information, it doesn't ask the database for the information. Instead, it asks the Athena's cache mechanism for the content. When the caching mechanism is asked for data it first checks its own cache and if present, will return that. If no information is available in the cache, the cache class will then establish a database transaction to retrieve the information, store it in cache and return it to the calling class.



The allows for one module of a session to remember what another did, while working in complete independence of each other, as well as allowing for one session to remember what a previous session did without needing to reload the same data which the server just compiled.

The positive effects of this system not only reduces CPU load on the server but also reduces the response time on each transaction. The negative effects are an increase in memory usage on a per-host level. The memory requirements for each host can be controlled, on a per-host level by limiting the number of items allowed in the cache at one time.
When a cache becomes full, it sorts the data inside it by usage frequency, allowing it to optimise itself on memory and performance efficiency.

PHP and Apache will also restrict the amount of memory each process can allocate, so the Athena caching class also allows for PHP/Apache to control the memory itself, happily allowing PHP/Apache to truncate IPC memory allocations and have Athena refresh them as needed.