.. include:: ../Includes.txt
.. _usage:
Usage
=====
fluid_page_cache works out of the box, when it is installed.
Backend Module
--------------
fluid_page_cache ships a Backend Module which allows you to see the records used in view, for each page variation in
page cache.
.. image:: ../Welcome/Images/backend_module.png
:width: 100%
:alt: Page cache tags in TYPO3
.. caution::
The Backend Module does not work for all Cache backends, yet.
**Supported cache backends are:**
- Typo3Database
- Redis
- SimpleFile
When you use e.g. APCU, the info module will not work. But, the main functionality of fluid_page_cache is not affected.
It supports all cache backends, the Caching Framework is compatible with.
.. hint::
The Backend Module has restricted access, only admin users can see it.
You can also disable or enable the Backend Module in extension settings.
Handling new records
--------------------
fluid_page_cache works with zero configuration, but also adds a new option to pages cache options:
.. image:: Images/page_cache_settings.png
:width: 100%
:alt: Extended page cache settings
When this option is enable, Fluid Page Cache will create **an additional cache tag** for the records' PID
(e.g. sys_folder).
This is especially useful, when the page cache of all page variants of this page should get cleared,
for example when you **create a new record in a sys_folder**.
Therefore this option makes sense to enable for pages, which primarily contains
**lists of records** (with/without paginations).
If you not activate this option on such pages, a new record in a related sys_folder will have
**no effect to page cache** at all.
So, you **should not** enable this option for dedicated detail pages. Otherwise their cache would also get cleared,
when new records have been created.
Register cache tags manually
----------------------------
fluid_page_cache is just able to create cache tags for used entities in view,
when they get passed **into** the template using variables.
View helpers like ``f:cObject`` provide own data, which the variable container in Fluid does not know about.
View helper
~~~~~~~~~~~
To be still able to provide cache tags here, fluid_page_cache ships a view helper, you can use in your templates.
**Example Fluid template:**
.. code-block:: html
{namespace fpc=T3\FluidPageCache\ViewHelpers}
{element.uid}
PageCacheManager class
~~~~~~~~~~~~~~~~~~~~~~
The central class ``\T3\FluidPageCache\PageCacheManager`` is entry point for all parts of this extension.
You can call the static method **registerCacheTag** from everywhere you want.
.. code-block:: php
PageCacheManager::registerCacheTag($table, $uid, $pid);
Keep in mind, that fluid_page_cache only apply:
- when ``TYPO3_MODE`` constant is ``FE``
- ``$GLOBALS['TSFE']`` is set
The pid is used to create an additional cache tag for the related e.g. sys_folder. It only applies when
the setting ``tx_fluidpagecache_pid_cache_tag`` in page settings, is enabled.
If you want to register an Extbase entity manually, you can use the static **registerEntity** method:
.. code-block:: php
$entity = $this->myRepository->findByUid(1);
PageCacheManager::registerEntity($entity);
``$entity`` must be:
- an instance of ``\TYPO3\CMS\Extbase\DomainObject\AbstractDomainObject``
- persisted (and have an uid available)
All cache tags made with fluid_page_cache got this syntax:
``fpc_{table_name}_{uid}``
``{table_name}`` may also store the keyword ``pid``, which is related to ``tx_fluidpagecache_pid_cache_tag`` option
in page settings.
DataHandler Hook
----------------
Creating cache tags does only make sense when you use them to clear specific cache entries.
fluid_page_cache provides an after-save-hook, which is triggered each time you modify a record using the DataHandler
(e.g. editors in backend).
When a new record is created, e.g. in a sys_folder, the cache tag ``fpc_pid_{uid of current page}`` is cleared.
This cache tag only applies to pages, which have the setting **FPC: Enable PID cache tag** enabled.
It applies automatically, when fluid_page_cache is installed.