Textpattern Support Forum

maniqui wrote:

Guillaume,
you could try this (not tested).
Replace lines 312-317 with:

         if($Status >= 4) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          } else { 
            //New status is less than 4 (that is, it's not "live" nor "sticky")
              // Check if status for "old" article was "live" or "sticky"
              if ($oldArticle['Status'] >= 4) {  
                 // If so, update lastmod
                 update_lastmod(); 
              }
         }

simplify patch:

         if($Status >= 4 or $oldArticle['Status'] >= 4) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          }

or add expires condition

         if( ($Status >= 4 or $oldArticle['Status'] >= 4)and (!$expires or $expires>=time()) ) {
              if ($oldArticle['Status'] < 4) {
                  do_pings();
              }
              update_lastmod();
          }

makss wrote:

IMHO, it’s a core bug.

Yes, didn’t say otherwise. Particularly whole update and caching model is lacking of features. Serves very little purpose of any site that get stream of new content. Things you get from having an open model.

Using this plugin here… phtww.com and it really helps with page load times.

The main nav, pretty much cycles through every article on the site, so caching that part is really powerful.

I’ve been using the following approach for article forms.

<txp:aks_cache id='this-form-<txp:section/>-<txp:article_id/>'>Form Contents</txp:aks_cache>

This produces about 30 cached items.

Q: Is this too much? Ie are the benefits of caching going to decrease as I have more items cached?

@makss

I wonder if it would be possible to integrate disk caching or more concrete: mem caching, to reduce the mysql load, because if you have several small pieces of a page in cache, for every piece you have to make a mysql query and that could possible slow down the site rendering, if your site has several parallel requests.
For example:
On a typical artical page, I have eight different aks_cache blocks and about 7000 entries in aks_cache. That means eight mysql queries per page.
The debug shows, that for page rendering 79 queries (maybe too much stuff) are made, so with disk/mem caching I could save these eight requests.
<!-- Runtime: 0,1350 --><!-- Query time: 0,020996 --><!-- Queries: 79 --><!-- Memory: 6585Kb
Ok, maybe it sounds not worth it, but anyway if you have not two request a second, but five or more it could be a relevant speed factor. I mean for huge sites on textpattern not small blogs or something :-).

So as an alternative you could consider to offer as an option disk caching in memory, for example in /dev/shm/textpattern_cache or so …

In principle the good old zem_cache could fulfil this function, but I’m not sure if it is still working and it seems to me, that aks_cache is more flexible in use.
A problem is, that AFAIK only root users have rights to use /dev/shm on hosting plattforms, so standard directory for caching could be /textpattern/tmp, but then you depend not on memory speed, but on disk speed. Anyway I think disk/memory caching could speed up some sites.