[TYPO3-dev] RealStatic HTML Files idea

Mon Jul 31 11:50:39 CEST 2006

Hey everybody,

I just thought about a nice idea.

There is a similar approach as Bernhards extension 
(T3X_kb_quickindex-0_0_0.t3x) last month to speed up the performance.

For simple static sites with little changes I would love to have a good 
and simple solution (not with external programs like scp / wget) to have 
*real* static files, on the same server as Typo3 is installed. It's also 
a nice idea for huge pages we a lot of traffic where you can get a bit 
more performance.

The advantage should be clear: For instance - Apache serves plain 
html-files about 10 times faster than a PHP-file with the same content 
(e.g. with echo "<html>...") because it does not need the mod_php module.

Prerequisites:
* SimulateStatic / RealURL has to be enabled
* Write access to the main directory

This is the idea: For all pages with static content (no USER_INT), we 
can create real HTML files. Every time a page gets rendered for the 
first time, Typo3 should write the file to the filesystem and also add 
an entry to a DB table ("pages_static" or so), with the path (realurl => 
pathcache), pageID, the creationTS and maybe a hash over the file.
For those files .htaccess won't be needed anymore, for all other files 
(forum etc.) we still are redirected to index.php as we know it right now.

So, if a page gets changed (e.g. new page content), the static file gets 
deleted and the DB entry too. The next time this page should be 
rendered, the file gets created again (same deal).

If a page gets moved, renamed etc. all static files should be deleted 
("Clear cache").

Also, a button with "(Re-)create all static files now" could be helpful.

In addition, if you really want to dump all static files to a different 
server (of course, this is not possible with dynamic pages like calendar 
etc.) there could be option "dump all files to folder XYZ".

I also still see problems with multiple domains, also if a guy deleted 
the DB entries by hand, there should be an option to find orphans in the 
file system.

So... what do you think of this idea, does this have potential to get in 
the CORE for e.g. 4.5 or should it be an extension, or an addition for 
RealURL?

-- 
greetings,
benni.
-SDG-