Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>i'd like this post to be a community answer detailing approaches to particular handles and suggested caching and invalidation logic needed if it's not already included in the phoenix or aoe_static module. basically caching will be done by module/controller/action pattern laid out in the aoe_static module and most of the existing invalidation exists in the Phoenix module. </p> <p>so we need to decide which blocks should be rendered via ajax and where addition cache invalidation is required. like gondo says you'll need to add a lot more invalidation logic to cache searches. i plan to start smaller with the catalog, cms and aw blog pages, much has been done here but a little more is required. if we could add search too, with the help from gondo :), that would be great.</p> <p>for instance - widget instances could be a problem, as could static block saves. this can (as far as my very quick investigation has shown) be easily solved only by running a total cache invalidation using the event dispatched by the core_model_abstract method _beforeSave()</p> <pre><code> Mage::dispatchEvent('model_save_before', array('object'=&gt;$this)); </code></pre> <p>we'd need to match the type of model before invalidating the entire cache. this pattern will also be a real time saver in other difficult areas of cache invalidation. using the instanceof method is fine but we'll need to know model names to check for. i guess community involvement is great here because the code's so easy but so is missing a model.</p> <p>widgets are essentially the same from frontend point of view. the one with products should be loaded with aoe_static, as they are changing quite often. but the static ones can be treated as static (html) blocks. </p> <p>we don't want to invalidate the entire cache when a product is saved and can't check if the product has been included in a widget. but the aoe_static module works with layout rendering. widgets will need to be included via layout xml and not in the admin wysiwyg as the often are. these widgets could be added to the call controller handle and place holders to what ever handle is needed.</p> <p>full varnish invalidation, time to time, is not a bed thing. the whole cache invalidation is an issue if it happens too often, or if it does not happen when needed. the main goal should be to capture every invalidation scenario and trigger notice in admin panel, same type of message as you get when you save product: "One or more of the Cache Types are invalidated..." this way admin can make the decision if he/she wants to invalidate cache manually or wait. and ofc there can be some automatic invalidation logic build in based on this scenarios.</p> <p>also the model must be created to store the url's created by layered nav and these should be invalidated along with the category view url's. </p> <p>and with layered nav and invalidation in general in mind we must invalidate the entire cache when an attribute is saved (i think). </p> <p>we should be able to put the product reviews on the product page without ajax for seo purposes. </p> <p>this means when a review model is saved it must be checked using the model_save_before event and we should invalidate the product page url. this save changes the rating but i suggest this block is grabbed in the ajax call. it's not important for seo. this goes for the product view and list pages. </p> <p>we could also cache and invalidate review module pages but this isn't important to the majority of users and should wait. </p> <p>who wants tags blocks. these can't be loaded by ajax it defeats their purpose. at the same time they're not worth our efforts now imo. </p> <p>if you cache url's with the session id appended it will cause users to get each others sessions i'm told. i think this is easily solved by piping in vcl_fetch based on a regex.</p> <p>this answer is getting messy and should be redrafted sometime soon. feel free to add your 2 cents!!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload