The most frequently visited pages on my site are not truly dynamic: I add a new story to the front page of my site one every two weeks or so. The stories themselves then are fixed for a long time. The code in the left navbar and at the top changes once every month or so. Now, some sections are truly dynamic. The comments. The polls. The search bar and so on.

What I would like to do somehow is dump snapshots of the unchanging pages out to static files and have them served directly by apache, but update them on the rare occasions when I do make a change. Meanwhile I'd like to have the truly dynamic pages like comments and such still served by the dynamic geeklog engine.

For example, if you clicked the "comment" or "edit" link on a story maybe that would bounce you to the dynamic .php version of the file, and editing that would update the fixed .html version on disk as well as in the DB.

Any thoughts on how to accomplish something like this?

why would you even want to do that? seems like a lot of work for little return.

if it's just speed you're worried about, try php caching.

Any suggestions on how to do that?

http://www.ilovejackdaniels.com/php/caching-output-in-php/
http://eaccelerator.net/HomeUk
http://www.phpaccelerator.co.uk/

Gee that's lovely. Maybe I meant in geeklog? Looking at the way geeklog generates pages it is not obvious to me how to cache it so that only the truly static pages get cached.

Maybe you guys are missing my point. For example, if the user logs in, the page cannot be cached. If the page is a search result page, the page cannot be cached.

However, if the index page could be cached for users who are not logged in, and ditto for the articles, then MOST hits on my site would hit cached pages. This is why originally I thought of dumping those pages to static files and updating those static files only when something actually changes. But you guys are really so smart, you think I can solve this problem by throwing two lines of PHP at the top of my header.thtml file, great.

Even the index page for anonymous is not static. It displays the current date and time, last comments, newly added links, etc.

Ignoring the date and time: If your site is busy, then the other information can change at any time, which means that you would have to regenerate the cached pages often. Which means that you hardly gain anything from it. And if your site is not that busy, then it's not worth the effort either ...

bye, Dirk

So an excellent strategy would be to somehow regenerate that cached page every time someone adds a comment or a story or a link.

I don't agree that the cached pages would be regenerated "often", think about it, right now they are regenerated on every page *view*. There are far fewer page updates than there are page views.

OK. So I have done it with a hack. To avoid hitting the database I had to put the caching code in the .php before lib-common.php is loaded. As a result, I don't have the config loaded and so the hack is I had to hardcode the name of the cookie that stores the username. If that cookie is set I do not cache the page. I stuck this code into index.php and article.php so that now most anonymous users load up the pages without a single database hit.

I'd like to know if there is a nice proper way to do this, or if this feature could somehow be built into geeklog. I don't like that my files are gradually becoming more and more diverged from the geeklog sources. This would be a pretty clean solution if I coudl somehow read the configs (to learn cookie_name) before loading in all the libraries and doing all the session stuff that lib-common does.

Note to all the smarties who thought I could just stick it in the .thtmls: That dont' work. First, for whatever reason footer can't have

The other thing my hack does not do is it does not delete the caches when there is an update. So, the way it stands, comments aren't necessarily visible right away unless you are logged in; neither are new stories visible right away.

Maybe I will add some code to the comment/story submission to delete the relevant entry from the cache... my hack grows... anyway, it seems like something that should be core geeklog, not an add on.