Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Last revision Both sides next revision
litespeed_wiki:cache:litemage:customization:configuration-file [2015/12/18 20:55]
Michael Alegre created
litespeed_wiki:cache:litemage:customization:configuration-file [2015/12/18 20:58]
Michael Alegre
Line 1: Line 1:
-====== LiteMage Cache Basic Customization ====== +====== LiteMage Configuration File Customization ​======
- +
-This page is dedicated to covering common methods of customizing LiteMage Cache for different use cases. +
- +
-===== LiteMage Configuration File Customization =====+
  
 LiteMage'​s "​config.xml"​ file, located under "​app/​code/​community/​Litespeed/​Litemage/​etc/​config.xml",​ is based on Magento'​s sample store data. If you have a customized Magento setup, you may need to add additional ESI blocks or events there. LiteMage'​s "​config.xml"​ file, located under "​app/​code/​community/​Litespeed/​Litemage/​etc/​config.xml",​ is based on Magento'​s sample store data. If you have a customized Magento setup, you may need to add additional ESI blocks or events there.
  
-**__Block ​Type Denoted By "​T:"​__** +===== Block Type Denoted By "​T:" ​=====
 In previous versions of LiteMage you needed to explicitly change or add blocks that have been re-named by installed extensions. As of version 1.0.4, most custom blocks will be detected automatically by type. In previous versions of LiteMage you needed to explicitly change or add blocks that have been re-named by installed extensions. As of version 1.0.4, most custom blocks will be detected automatically by type.
  
Line 23: Line 18:
 Where instead of listing out each individual "​cart"​ block by name in the <​blocks>​ section, we use the type indicator prefix "​T:"​ along with the inherited Magento class for "​cart"​ type blocks to get "​T:​Mage_Checkout_Block_Cart_Abstract"​. Now any blocks that inherit this type will be automatically detected and included. ​ Where instead of listing out each individual "​cart"​ block by name in the <​blocks>​ section, we use the type indicator prefix "​T:"​ along with the inherited Magento class for "​cart"​ type blocks to get "​T:​Mage_Checkout_Block_Cart_Abstract"​. Now any blocks that inherit this type will be automatically detected and included. ​
  
-**__Purge Tags__**+===== Purge Tags =====
  
 Also new in LiteMage 1.0.4 are the inclusion of purge tags. These changes the block into a composite block that uses the combined purge events of other existing blocks without having to redefine those purge events in the block itself. Also new in LiteMage 1.0.4 are the inclusion of purge tags. These changes the block into a composite block that uses the combined purge events of other existing blocks without having to redefine those purge events in the block itself.
Line 36: Line 31:
 Here the "​top.links"​ block is using the purge tags "​cart"​ and "​wishlist"​ instead of explicitly re-listing these purge events for these blocks in a <​purge_events>​ section. This will cause the "​top.links"​ block to be purged whenever an event would cause either the "​cart"​ or "​wishlist"​ blocks to be purged. Here the "​top.links"​ block is using the purge tags "​cart"​ and "​wishlist"​ instead of explicitly re-listing these purge events for these blocks in a <​purge_events>​ section. This will cause the "​top.links"​ block to be purged whenever an event would cause either the "​cart"​ or "​wishlist"​ blocks to be purged.
  
-**__Valueonly ​Blocks Denoted By "​$v"​__**+===== Valueonly ​Blocks Denoted By "​$v" ​=====
  
 Marking a block as valueonly will keep the HTML tags and comments surrounding a value in an HTML text field from being output when in debug mode. This is important in keeping behavior consistent between viewing a page normally or in debug mode. Valueonly blocks will also not appear when using the "​LITEMAGE_DEBUG=SHOWHOLES"​ parameter to highlight injected blocks on a page. Marking a block as valueonly will keep the HTML tags and comments surrounding a value in an HTML text field from being output when in debug mode. This is important in keeping behavior consistent between viewing a page normally or in debug mode. Valueonly blocks will also not appear when using the "​LITEMAGE_DEBUG=SHOWHOLES"​ parameter to highlight injected blocks on a page.
Line 48: Line 43:
 Where the "​nickname"​ block has been marked as valueonly. Where the "​nickname"​ block has been marked as valueonly.
  
-==== Hole-punching Dynamically Created Blocks From A Template ====+===== Hole-punching Dynamically Created Blocks From A Template ​=====
  
 As of LiteMage 1.0.6, you can now hole-punch dynamically created blocks from a template. LiteMage injects after the layout files are loaded and all blocks are generated. This works for most cases, but when a template block is rendering, it can dynamically create a block that is not defined in the layout file.  As of LiteMage 1.0.6, you can now hole-punch dynamically created blocks from a template. LiteMage injects after the layout files are loaded and all blocks are generated. This works for most cases, but when a template block is rendering, it can dynamically create a block that is not defined in the layout file. 
Line 84: Line 79:
 Note: When testing, be sure to use "​Enable LiteMage Cache Only for Listed IPs" (see full explanation in the Configuration Notes section below). This setting specifies certain IPs that will test caching while other IPs are served normally. Note: When testing, be sure to use "​Enable LiteMage Cache Only for Listed IPs" (see full explanation in the Configuration Notes section below). This setting specifies certain IPs that will test caching while other IPs are served normally.
  
-==== Custom ESI Block Structure And Purge Events ====+===== Custom ESI Block Structure And Purge Events ​=====
  
 **__Custom ESI Block Structure__** \\ **__Custom ESI Block Structure__** \\
Line 125: Line 120:
 This uses the predefined "​purgeEsiCache"​ method to purge any ESI block groupings that are using this purge event from the cache whenever this event is triggered. This uses the predefined "​purgeEsiCache"​ method to purge any ESI block groupings that are using this purge event from the cache whenever this event is triggered.
    
-==== Single Language Sites ====+===== Single Language Sites =====
  
 LiteMage'​s "​config.xml"​ file contains a rewrite for Magento'​s translate line to fix a bug. If you intend to only use a single language for your store, you may remove this rewrite for a possible performance improvement. The rewrite is located near the start of "​config.xml"​ in <​config>​ -> <​global>​ -> <​models>​ and will look like the following: LiteMage'​s "​config.xml"​ file contains a rewrite for Magento'​s translate line to fix a bug. If you intend to only use a single language for your store, you may remove this rewrite for a possible performance improvement. The rewrite is located near the start of "​config.xml"​ in <​config>​ -> <​global>​ -> <​models>​ and will look like the following:
Line 135: Line 130:
   </​core>​   </​core>​
   ​   ​
-==== List Customized Block Names For "​welcome"​ And "​toplinks"​ Tags ====+===== List Customized Block Names For "​welcome"​ And "​toplinks"​ Tags =====
  
 As of LiteMage 1.0.8, we have introduced two new fields to LiteMage'​s "​User-Defined Cache Rules" under System >> Configuration >> LITEMAGE CACHE >> LiteMage Configuration in the Magento Admin Panel. These fields are "​Customized Block Names for '​welcome'​ Tag As of LiteMage 1.0.8, we have introduced two new fields to LiteMage'​s "​User-Defined Cache Rules" under System >> Configuration >> LITEMAGE CACHE >> LiteMage Configuration in the Magento Admin Panel. These fields are "​Customized Block Names for '​welcome'​ Tag
Line 145: Line 140:
  
 (It is not necessary to have other predefined tags configurable from within the Magento Admin Panel as they are already intelligently detected by class type, which would cover most use cases.) (It is not necessary to have other predefined tags configurable from within the Magento Admin Panel as they are already intelligently detected by class type, which would cover most use cases.)
- 
-===== Setting Different Views For The Same URL Based On Customized Cookie Values ===== 
- 
-As of version 1.0.11, you can use a rewrite rule to store separate cached copies of a page based on a customized cookie name. The rewrite rule is as follows: 
- 
-  RewriteRule .* - [E=cache-vary:​cookie_name] 
  • Admin
  • Last modified: 2016/05/05 20:17
  • by Long Hu