Historically, PHP appeared after HTML to provide dynamic features to web pages.

Al you had to do was to rename your HTML page page.htm into a page.php without changing the content and the magic was here! You have now a dynamic page!

So PHP programs started to keep HTML data and inserted scripts inside where dynamic data were needed. And most of the current standard CMS are still doing the same.

When trying to provide inline editing into a HTML page, I realized that it was very difficult to get the wanted HTML code copied without problem to the server.

As a workaround, the most simple solution seems to be:

• handle the DOM on the client side and with AJAX transfer the DOM attributes to the server
• the server then keeps the DOM attributes and rebuilds the HTML on request

With this approach, HTML is completly generated by PHP. So we will have a PHP DOM equivalent to the HTML DOM.

To avoid heavy PHP process, we will also integrate a cache module.

One aspect, we have to focus on is the evolution and the flexibility of the Data Model. With a database, you can add more column to expand your data model or you can create joined tables. Thi allows to keep the current data and make it evolve to a new data model.

With PHP, the serialization of data linked to a Class can show problems if the data model eveolves and then cannot read the older version of the data. We need to ensure if there are problematic situations with the serialization/unserialization procedure when the classes involved are different.

One great advantage of serialization is to allow distributed communication between servers with PHP. No need to build a specific layer to communicate between servers!

Front End and Back End should be separated to allow caching and better performance.

With Apache Bench, it should be abel to stand at least a 500-concurrent, 5000 requests load test with no failure.

It's getting quite complicated to handle several versions of text and several versions of layout automatically.

For words replacement, we can provide some kind of dictionnary and then perform some search/replace process to provide international websites. But also in this case, there would be problems with layout as words are never the same length…

So for each language version, we should stay at the html code level ? Then we would provide text boxes, one ofr each language ?

The url is also a concern… Should we have a different url for each language version ? Or simply add some language ISO code as prefix or suffix to the default url ?

To provide sepatators in one content file to delimit the language could be an easy way to manage the content ?!

A solution ?

BALI manages content by folders (called albums)

Each folder/album can have several URLs: so there can be several url (one for each language) to refer the same content

e.g: home, home/fr, home/de, home/es

Each album has a configuration file. This configuration file should set for each URL what is the language (and needs a default one). Then from this language, the configuration file will gather the content elements needed.

Each album separates content parts in different files. So there can be one for each language. And media like images can remain unique and in the same album.