Magento Full Page Cache (FPC) is a very useful technique or mechanism that allows us to copy web content by storing the output of a given URL to a temporary container (caching) to help reduce bandwidth usage, cpu load, memory comsuption, database stress, perceived lag among other benefits.

We need to understand what the run function in Mage_Core_Model_App does and how it is architected:

/**
* Run application. Run process responsible for request processing and sending response.
* List of supported parameters: * scope_code - code of default scope (website/store_group/store code)
* scope_type - type of default scope (website/group/store)
* options - configuration options
*
* @param array $params application run parameters
* @return Mage_Core_Model_App
*/
public function run($params)
{
$options = isset($params['options']) ? $params['options'] : array();
$this->baseInit($options);
Mage::register('application_params', $params);

if ($this->_cache->processRequest()) {
$this->getResponse()->sendResponse();
} else { $this->_initModules();
$this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);
if ($this->_config->isLocalConfigLoaded()) {
$scopeCode = isset($params['scope_code']) ? $params['scope_code'] : '';
$scopeType = isset($params['scope_type']) ? $params['scope_type'] : 'store';
$this->_initCurrentStore($scopeCode, $scopeType);
$this->_initRequest();
Mage_Core_Model_Resource_Setup::applyAllDataUpdates();
}

$this->getFrontController()->dispatch();
}
return $this;
}

The most important part in that function is:

$this->_cache->processRequest()

What that line does is that checks if you have defined a caching node like this under app/etc/cache.xml:

cache.xml is just an arbitrary name I chose for this blog post (It’s not really arbitrary as you will see later).

The request processor node gets checked whenever the cache model gets instantiated:

/**
* Class constructor. Initialize cache instance based on options
*
* @param array $options
*/
public function __construct(array $options = array())
{

$this->_defaultBackendOptions['cache_dir'] = Mage::getBaseDir('cache');
/**
* Initialize id prefix
*/
$this->_idPrefix = isset($options['id_prefix']) ? $options['id_prefix'] : '';
if (!$this->_idPrefix && isset($options['prefix'])) { $this->_idPrefix = $options['prefix'];
}
if (empty($this->_idPrefix)) {
$this->_idPrefix = substr(md5(Mage::getConfig()->getOptions()->getEtcDir()), 0, 3).'_';
}

$backend = $this->_getBackendOptions($options);
$frontend = $this->_getFrontendOptions($options);

$this->_frontend = Zend_Cache::factory('Varien_Cache_Core', $backend['type'], $frontend, $backend['options'],
true, true, true );
if (isset($options['request_processors'])) {
$this->_requestProcessors = $options['request_processors']; } if (isset($options['disallow_save']))
{ $this->_disallowSave = $options['disallow_save'];
}
}

This piece of code:

if (isset($options['request_processors'])) {
$this->_requestProcessors = $options['request_processors'];
}

Is what matters most.

The next thing that magento does is to find / initialize the class you have defined and it expects that you have an extractContent function defined in your model. How you do that is totally up to you but look at Magento’s implementation and get a hint or two.

Magento Full Page Cache has its own config model that loads your module’s (see no arbitrary) cache.xml file which gets initialized whenever you dispatch this event core_block_abstract_to_html_after and do you know where that event gets dispatched? If you thought in the toHtml method in Mage_Core_Block_Abstract then you should be writing this article not me.

Anyhow, the Enterprise_PageCache_Model_Observer::renderBlockPlaceholder observes that event and initializes the Enterprise config model. It has a method called _initPlaceholders which iterates through all of the cache.xml nodes and finds the definition of the holes and fillers. This model is the one that basically takes control of filling the holes you defined in the cache.xml which has a syntax similar to this:



So now we know how Magento finds the cache, config, events and adds the container name in the page. However we don’t know what the containers are? Essentially they are the ones responsible for filling the holes you have defined. Each container has two important methods applyWithoutApp and applyInApp that Vinai has explained exceptionally well here. But it will be awesome if you go take a look and be amazed because trust me YOU will need to, to fully understand it.

The function that will probably will matter most for you is:

/**
* Render block content from placeholder
*
* @return string|false
*/
protected function _renderBlock()
{
}

As that is the one that will get your dynamic content (read holes).

Magento is a very powerful and fast growing ecommerce script, created by Varien. It is an open-source platform using Zend PHP and MySQL databases. Magento offers great flexibility through its modular architecture, is completely scalable and has a wide range of control options that its users appreciate.

In this section, we are going to build a MySQL script that you can use for adding a new admin account within seconds.

It is recommended to have a salted password hash ready.

Paste into the MySQL script:

Don’t forget to set your own values on lines 4-8, 26, 27.

Note: If you use Magento CE 1.3.2.4-1.4.*, remove lines 16 and 17.

Now you are ready to run script:

That is it! Now you can execute script any time you need to add admin account.

Alternatively

If you are not comfortable using script than another way can meet your needs:

1. Click Insert button to make new admin_user record. Fill out necessary fields using existing record values and this manual as template.

2. Next we need to add record to admin_role table.

Here user_id – is ID of user that we have created. parent_id is role_id of Administrators record:

Test your new admin account.