Not signed in ( Sign In)

Categories

Welcome, Guest

Want to take part in these discussions? Sign in if you have an account, or apply for one below

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

  1.  permalink
    Hi,

    I'm currently looking into developing a plugin that will add itself to the 'wp_head' event.

    As part of its operation the plugin will require access to the contents displayed by that page.

    I can see for statics that the contents of the page is available in the {static_page} array.

    For posts the id appears to be available from {$flatpress}[PARAMS][entry]. Is there a variable that contains the posts contents like {static_page} for statics or will I have to resort to calling FPDB_Query with the entry id?

    For pages holding multiple posts (e.g. page 1, page 2, etc.) I can see that the page number is available from {$flatpress}[PARAMS][paged]. Is there a way to determine what entries appear on that page - or even better a variable containing the contents like {static_page} for statics?

    Many thanks...
    •  
      CommentAuthorNoWhereMan
    • CommentTimeAug 27th 2010 edited
     permalink
    One of my aim for FlatPress was making it *fast*; now, we can all probably agree that a flat file system is not probably the best way to guarantee speed.

    In fact, with the word 'fast' I don't mean *absolutely* fast, but *perceived* as fast; this in fact implies answering to a user request as soon as possible, which is generally accomplished by doing the least necessary to show some user interface, and then showing the progress in some way.

    e.g. When you download a file, a progress dialog with a bar will show up.

    In FlatPress, being 'fast' means starting spitting out the part of the page which needs the least effort, and advance progressively.

    While this is best practive in common interaction design, it's not so provably 'the best' approach when we speak about web apps and web sites, since spitting out pieces might imply the webserver and the user client will have to negotiate the size of the chunks multiple times, which in turn would make the download bigger... it's a matter of tradeoffs... which I did consider... and then ignored.

    Simply put, if FP loaded all the data into memory before rendering the page, your browser would sit and wait much longer than now.[1]

    Now, you might want to ask, why all this long introduction? Because I'm going to tell you there is *no* way to know what you want to know in the header.

    heh. I'm kidding. The answer lies in index_permatitle() (index.php , lines 17+)
    which hooks wp_head


    Posted By: ramblingrossIs there a variable that contains the posts contents like {static_page} for statics or will I have to resort to calling FPDB_Query with the entry id?


    function index_permatitle($val, $sep) {
    global $fpdb;
    $q =& $fpdb->getQuery(); // get the FPDB_Query main object
    // reads the current entry on the list, and does not advance the internal pointer
    // (which, since this is wp_head is reliably the first -- and only, since it's a permalink)
    // this forces FP to load into memory the contents of the post
    list($id, $e) = @$q->peekEntry();
    if ($e)
    return "{$e['subject']} {$sep} $val ";
    else return $val;
    }




    Posted By: ramblingrossIs there a way to determine what entries appear on that page - or even better a variable containing the contents like {static_page} for statics?


    Well, ideally you would call getQuery() the same way you called it in the first example, but in this case, you can't because if you call getNext() on the FPDB_Query object you will advance its internal pointer, and then when smarty encounters {entry}, which does nothing but calling repeatedly list($id, $entry) = $main_query->getNext(), $main_query will have reached its end; there is no $query->rewind() method. There is a $query->prepare() which you might want to call after you're done; be aware that I never tried that path: it might lead to unexpected results.

    the only other thing I can think of that you might want to try is passing the $fp_params contents to a new FPDB_Query (sanitizing, first) (ugly, I know)... I should think about it.


    HTH

    [1] you can try it yourself: open index.php change the line with $smarty->display($module) with $out = $smarty->fetch('module'); echo $out; you should feel some difference. Depending on your webserver config, it might bufferize the output or not, which influences the load time.
  2.  permalink
    Great!

    Thanks for the info NoWhereMan.

    Now lets see if I can get some time to put it into practice.