[TYPO3-dev] RealStatic HTML Files idea

[Bernhard Kraft]

Benjamin Mack wrote:

> 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.

And what are you serving when now a logged in FE-Users comes along ? The
same content as for normal users ? This is against the deafult behaviour
of T3 :(

> 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).

And what if someone has set start/stop times for other pages ? You will still
serve the old file when already some different should be available at a special
time set via the start/stop fields of pages/tt_content :(

> 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".

You can use the "crawler" extension for this ...


> 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.

When you clear the page the whole cache directory is cleared.

> 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?

kb_quickfe is doing almost exactly this for realURL pages ... you just would have
to add an option line in the .htaccess and the files would get serverd "statically"
(except passed through mod_rewrite).
The only thing you would have to change in kb_quickfe is that it doesn't write the
hash-values into the filename - but then you must be sure that you have no single
page which has a "?extraParam=123" which could not have been encoded by realURL ...

i tought that many people haven't taken care of all their GET parameters (like no_cache
or such) and so I encoded the hash value into the filename - think of one page
/products/detail/product/123?cHash=1sdfsdfsd
when you forgot to encode the cHash value into the URL or let it get removed and stored
into the DB by realURL (there is an option for that) then you will have more than one
page in a directory ...

It would be easy to change that behaviour so the quickfe extension uses the full requested
path as storage filename - only with a /static/ prefix in the path.


I already started working on a modified version of mod_rewrite which should be able to handle
cookies (FE/BE-Users) and Expire-Timestamps of pages - It will take much work to implement that
TS conditions work. (Think of a case where you switched the css with an [browser = msie] condition.)
Different browser will generate different versions for the same path:
/company/about_us/

:(


To sum the problems :( in generating static pages:

* Page expire times
* FE-Users
* Conditions

When those three criterias are properly handled and different versions are created depending
on them then a module is fully compatible with TYPO3 (what kb_quickfe currently is)

COBJ's are in such a way special that they require $GLOBALS['TSFE'] (tslib/class.tslib_fe) and
some ->cObj (tslib/class.tslib_content) to be loaded ... and those two are main libraries and
they require_once() a lot of other libraries - which means it takes long to load those.



greets,
Bernhard
-- 
----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
----------------------------------------------------------------------
[[ http://think-open.at | Open source company ]]