I am getting interested in how hole punching might work in magento inside a full page cache situation. This is not directly related to the enterprise edition and how its full page cache and hole punching mechanism might work, just in general.
Due to the way that the messages block is generated by magento i am really very curious as to how to deal with the messages block in a hole punching situation?
Have any magento devs out there tackled this before and can maybe explain to me how this particular block can be hole punched?
You will need to link a cache container to the core/messages block to be able to prevent the block from caching. To reach your goal you will need a basic module, or add this to one of your existing module, whichever is the best (read: more logical) place for you.
Within your_module/etc/ you will need to create cache.xml file:
<config>
<placeholders>
<your_module_messages>
<block>core/messages</block>
<placeholder>SYSTEM_MESSAGES</placeholder>
<container>Your_Module_Model_PageCache_NoCache</container>
</your_module_messages>
</placeholders>
</config>
The Your_Module_Model_PageCache_NoCache needs to be an extend of Enterprise_PageCache_Model_Container_Abstract and in that extend you need to overwrite the saveCache() method and directly return $this instead triggering the underlying $this->_saveCache(). Perhaps with more logic you can make this punch hole a bit smarter, but for now assume that you never know when there is a new messages, thus leaving the hole open at all times.
public function saveCache($blockContent)
{
return $this;
}
The only thing left is to trigger Magento to load the core/messages block from within the whole. This you can accomplish by adding the following method to your class.
protected function _renderBlock()
{
$block = $this->_placeholder->getAttribute('block');
//$template = $this->_placeholder->getAttribute('template');
$block = new $block;
//$block->setTemplate($template);
$block->setLayout(Mage::app()->getLayout());
return $block->toHtml();
}
It will fetch the block information from the cache.xml file and return the output of the block. Since core/messages actually generated it's own HTML you don't need to provide a template. So might as well remove those commented lines from the code.
Hopefully this helps you with your task at hand!
Related
I am using code Igniter for my PHP project. I want to give provision in my site such that users can create new pages of their own, and access them directly from domain.com/their_page_name.
But, my developers have raised a concern that, 1000's of dynamic links that are presented in the format of domain.com/ is "not good for site's performance". For some 10-15 pages, it is fine. But, beyond that, it would effect the site's performance.
So, they proposed that the URL format should be like www.domain.com/something/page_name (here, 'something' is the controller name, as they mentioned it)
But, I really can't sacrifice my framework nor my requirement.
Is there any way that I can achieve the format of "www.domain.com/page_name" without effecting the site's performance?
Thanks in advance.
No issues on
Www.domain.com\userpagename.
It's not a framework issues. Codeigniter support this type of URL.you can create n no of URL.
Performance will matter how you are handling that particular controller or that particular function.
If may be 10 may be 100 ,work around same way.
You just have to put route accordingly.
$route[default_controller]=userurl;
$route[userurl/(:any)]=userurl yourfunction/$1`;
What it seems you need is dynamic controller, which can be done using Codeigniter's build in function _remap().
A code example is:
public function _remap($method){
if($method != null){
$this->yourFunction($method);
} else {
// handle the error as you like
}
}
public function yourFunction($key){
// your code logic here
}
All this code block goes inside your controller.
Edit: the performance is exactlu the same as going with domain.com/controller/method. What it matters, as stated above, is how you handle the data.
Problem
When I try to add a block into my transactional email template in the following manner:
{{block type='core/template' area='frontend' template='invent/baskettimer/email_items.phtml' record=$record}}
I get the following error, and nothing is rendered.
CRIT (2): Not valid template file:frontend/base/default/template/invent/baskettimer/email_items.phtml
Troubleshooting
Normally this warning points to a typo which is breaking the inheritance but I have quadruple checked and this should work.
I then copied the file into the base and did a test, it rendered correctly.
Create a custom block and set the template, same error is displayed.
Theory
To me it seems template inheritance is broken / not implemented for emails, so it is always looking in base, I cannot put my templates there so I am not sure how to call them.
Possible workarounds
Render the block to html then send it to as a variable to render, problem with this is I am sending the emails from Model level and am having a hard time pre rendering the block, even with a helper.
Render the data using a method, don't really want to do this as it is message / against MVC.
Any help is much appreciated.
Bounty update
So I have traced down the problem, it is probably an easy solution now.
The problem is that I am calling it from a cronjob does not have the correct store view, it is fairly easy to replicate similar situation by using a shell script, then changing the _appCode to null.
<?php
require_once 'abstract.php';
class Mage_Shell_Shell extends Mage_Shell_Abstract
{
protected $_appCode = ''; // works - remove to not work
/**
* Run script
*
*/
public function run()
{
Mage::getModel('invent_baskettimer/email')->sendJob();
}
}
$shell = new Mage_Shell_Shell();
$shell->run();
So basically the question has become:
How do I call a block->toHtml() regardless of store view?
There is not way of setting a cronjob to be like that. Lucky magento lets you emulate your store views, see the following to emulate the default store.
public function cronjob()
{
$iDefaultStoreId = Mage::app()
->getWebsite()
->getDefaultGroup()
->getDefaultStoreId();
$appEmulation = Mage::getSingleton('core/app_emulation');
$initialEnvironmentInfo = $appEmulation->startEnvironmentEmulation($iDefaultStoreId);
.. do your stuff here ..
$appEmulation->stopEnvironmentEmulation($initialEnvironmentInfo);
}
For more info see: http://inchoo.net/ecommerce/magento/emulate-store-in-magento/
I'm fairly new to Joomla (I've been more of a Wordpress guy) and I have a question about module positions.
Can a module know what position it's in. For instance can I do something like this:
if(modulePosition =='left'){
Do this...
}else{
Do that...
}
It seems easy enough, but I've searched for hours and can't find anything that will help me with that. I know there is a countModules function but from what I can tell, that just checks to see if the module is active or not.
Thanks for your help!
I found the answer! Mostly thanks to #Hanny. His idea of using the modules id got me googling for that and I came across the answer. For anyone else that happens to be looking to do something similar here it is.
You use a global variable $module (who'd a thought, right?)
So my code now looks like this:
$class = '';
if($module->position == 'position1'){
$class = 'class1';
}
and so on...
Pretty simple, huh?
To find out what else you can do with the global variable $module just put this in your code and see what info you can use:
echo(print_r($module));
Thanks for all your help!
The short answer is 'yes', you'll assign a module a position based on your template. When it shows up you can have conditionals like that regarding that position (different templates have different naming conventions for positions, so make sure you know what they are before coding).
For example, some use "Position12", others may use "leftcol", etc. You just have to check in the template files to see (you can check the .xml file in the template directory to see the positions listed in the template, or look in the index.php file for the jdoc includes).
In some of my experience, the only time you'll really ever need code like that is in the core layout files of the template (for example, if you have different widths of columns depending on modules being present or not), otherwise there won't really be a time where you 'may or may not' have a module showing up - because you'll explicitly be telling them where to be and when on the back end.
I tried to comment under john's solution but I don't have a enough rep points-- I wanted to add it doesn't matter what you name the module position in your template case-wise the position name you get back from $module->position is always all lowercase regardless of how you named the position in the template... ie. in your template xml somewhere you might have topBar position will be named 'topbar' not 'topBar' when you try to check it with
if($module->position == 'topBar') //always false... use instead
if($module->position == 'topbar') //what you need to use
I'm going to disagree with Hanny. I think the answer is no, not as you describe.
The template knows when it has reached a module position, and it gets a list of modules assigned to that position, then calls for them to be rendered. But it doesn't pass that information on. It's not stored in JApplication or JDocument etc either (like, nothing stores where in the template the rendering is up to or anything).
There are some hacky ways to almost get what you want though. If you know the template positions you need to search (sadly there's no easy method for getting this from the template - otherwise you could parse your template's .XML file for <position> elements...), then you could do something like:
<?php
$positions = array('left', 'right', 'top', 'bottom')
$found_in = false;
foreach ($positions as $cur_position)
{
$module_positions = JModuleHelper::getModules($cur_position);
foreach ($module_positions as $cur_module_in_pos)
{
if ($cur_module_in_pos->module == 'mod_MYMODULE')
{
$found_in = $cur_position;
}
}
}
if ($found_in)
...
Of course, this doesn't work well if your module is included multiple times on the page, but maybe that's an assumption you can make?
Otherwise it'd be up to hacking the core - you could use a JDispatcher::trigger() call before the template calls a module, set some var etc. Unfortunately there's no such event in core to start (a pre_module_render or something).
A module instance is assigned to a single position and this is stored in the database and normally you would style the position in the template. A module instance can only be assigned to one position. So while it's an interesting question, it's not really a practical one.
The exceptions to this are the following:
loadposition ... you might want to know if a module is being loaded using the plugin because this would put it potentially somewhere besides the styled area for the position. THough i would recommend always making a new instance for this precisely so you have more control.
loadmodule ... module loaded by name using the plugin. In this case again you are probably better off making a new instance of the module and styling it. Also I'd put it in a span or div anyway, depending what it is.
jdocinclude:module ... loading a module directly in a template. Again if you are doing this I would wrap it in a span or div. In this case you are also allowed to include a string of inline styles if you like that kind of thing.
Rendering the module to a string and echoing it, again that is basically a very customized solution and you would want to set the styles and options.
I wish to remove the following setting:
<cms>enterprise_pagecache/processor_default</cms>
... from the config.xml of the core / Enterprise / PageCache / config.xml file so that the home page will not be cached, (because we have a complicated custom store switch in place).
Since this value is not stored in core_config_data I am unsure of the best way to override the out of the box value. The comments above the line in the core file do hint that it is not actually bad practice to edit this file, however, can I open this to the community to see what they think?
PS = This is a multi website setup with a custom store switcher.
Hole punching is what it sounds like you may need.
Add a etc/cache.xml file with a <config> root to your module. (see Enterprise/PageCache/etc/cache.xml). Choose a unique [placeholder] name.
The placeholders/[placeholder]/block node value must match the class-id of your custom dynamic block, e.g. mymodule/custom
The placeholders/[placeholder]/container node value is the class to generate the content dynamically and handle block level caching
The placeholders/[placeholder]/placeholder node value is a unique string to mark the dynamic parts in the cached page
placeholders/[placeholder]/cache_lifetime is ignored, specify a block cache lifetime in the container’s _saveCache() method if needed
Implement the container class and extends Enterprise_PageCache_Model_Container_Abstract. Use _renderBlock() to return the dynamic content.
Implement the _getCacheId() method in the container to enable the block level caching. Use cookie values instead of model ids (lower cost).
One last note: You DON’T have the full Magento App at your disposal when _renderBlock() is called. Be as conservative as possible.
SOURCE: http://tweetorials.tumblr.com/post/10160075026/ee-full-page-cache-hole-punching
in a 'native' Zend Framework application I would enable the use of ezComponents by adding the autoloader of ezComponents to Zends autoloader:
$autoLoader = Zend_Loader_Autoloader::getInstance();
require_once('../library/EZComponents/Base/src/base.php');
$autoLoader->pushAutoloader(array('ezcBase', 'autoload'), 'ezc');
Now, I'm wondering how I could do the same with Magento.
Is there a way to extend Varien_Autoload (magentos autoloader) to enable easy integration of ezComponents?
OR:
Is there a way to use Zends autoloader beside the one from Magento without interfering each other?
edit:
Well, I implemented a workaround, by adding the following to function autoload() in Varien_Autoload:
if(substr($class, 0, 3) == 'ezc'){
require_once('EZComponents/Base/src/base.php');
return ezcBase::autoload($class);
}
I consider this as a very bad hack though, because it will be overwritten, when upgrading Magento. Does anyone has a better idea?
My basic approach here would be to create a custom module with an observer for the
controller_front_init_before
event. In the event observer, you'd be able to setup your autoloader however you want. There's a Magento Wiki article on Setting up Event Observers. The controller_front_init_before event is one of the first non-generic events to fire in Magento. That's why we're using it.
The big problem we need to solve is this: Magento's autoloader is on the stack first, and if it doesn't find a file (which will be the case with the EZComponent classes), its include will raise a error that will halt execution.
So, what we need to do in our event observer above is to
Remove the Varien_Autoloader from the spl_autoload stack
Register our own autoloader (we'll use Zend_Autoloader, since it ships with Magento and you seem familiar with it)
Re-add the Varien_Autoloader to the stack
There'll be a little extra jiggery-pokery we'll need to do since loading of the classes in the Zend namespace is normally handled by the autoloader we'll be removing. See comments for more details
//we need to manually include Zend_Loader, or else our zend autoloader
//will try to use it, won't find it, and then try to use Zend_Loader to
//load Zend_Loader
require_once('lib/Zend/Loader.php');
//instantiate a zend autoloader first, since we
//won't be able to do it in an unautoloader universe
$autoLoader = Zend_Loader_Autoloader::getInstance();
//get a list of call the registered autoloader callbacks
//and pull out the Varien_Autoload. It's unlikely there
//are others, but famous last words and all that
$autoloader_callbacks = spl_autoload_functions();
$original_autoload=null;
foreach($autoloader_callbacks as $callback)
{
if(is_array($callback) && $callback[0] instanceof Varien_Autoload)
{
$original_autoload = $callback;
}
}
//remove the Varien_Autoloader from the stack
spl_autoload_unregister($original_autoload);
//register our autoloader, which gets on the stack first
require_once('library/EZComponents/Base/src/base.php');
$autoLoader->pushAutoloader(array('ezcBase', 'autoload'), 'ezc');
//lets just make sure we can instantiate an EZ class
#$test = new ezcBaseFile();
#var_dump(get_class($test));
//IMPORANT: add the Varien_Autoloader back to the stack
spl_autoload_register($original_autoload);
Put the above code in an observer method and you should be good to go.
The other approach you could take, one that would fit in more with Magento patterns, would be to create a custom module that implemented an EZComponent loader.
$o = Mypackage_Mymodule_Loader::getModel('ezcBaseFile');
You'd then implement autoloader style require code in your static getModel method, and use it whenever you wanted an ezcBaseFile class. You'd probably want methods for loading a class without instantiating an object in case you wanted to call a static method on an ezcBaseFile base class.
$o = Mypackage_Mymodule_Loader::getLoadclass('ezcBaseFile');
I took a quick look at the code for Varien's autoloader and it appears to use a call to spl_autoload_register, which is a stack for performing autoloads. While I don't think you'll have much success adding to the default Magento autoloader, this means that you should be able to push another autoloader on top of Magento's.
Hope that helps!
Thanks,
Joe
I've just integrated the Sailthru_Client class into Magento, thought this might help.
I have sailthru.php, the Sailthru Client API, which contains Sailthru_Client class.
I created magentoroot/lib/Sailthru folder then copy sailthru.php into it, then renamed to Client.php making it magentoroot/lib/Sailthru/Client.php. This pattern is auto-loaded by Varien_Autoload class.