<?php
namespace Cylancer\CyWatermark\Hook;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Extbase\Event\Persistence\EntityUpdatedInPersistenceEvent;
#[AsEventListener(
identifier: 'cylancer/cy_watermark',
)]
final class CategoryRecordListener {
public function __invoke(EntityUpdatedInPersistenceEvent $event): void {
debug( $event->getObject() ) ;
debug( $x = 25 / (100- 100) );
}
}
If I understand correctly, the event should always be triggered when a record is updated. So I change a category, click save and … nothing happens. Actually it should blow up in my face!?
What am I doing wrong?
Under Configuration > Event Listener (PSR-14) > TYPO3\CMS\Extbase\Event\Persistence\EntityUpdatedInPersistenceEvent
it says:
TYPO3\CMS\Extbase\Event\Persistence\EntityUpdatedInPersistenceEvent
cylancer/cy_watermark
service = Cylancer\CyWatermark\Hook\CategoryRecordListener
method = __invoke
Looks fine, right? Can someone reproduce this? Or does it work for someone else and they do it slightly differently?
Where do you “click save”? If it’s in the backend, the event is not fired (only Databandler+FormEngine do the work there, no extbase is involved). There you would need to do the DataHandler Hooks.
The event above would only be fired in Extbase domain model operations, usually from extbase controllers and their repositories.
That’s not great, is it? Why is there a distinction between updating an object via the frontend (FE) or the backend (BE)?
Under Hook + DataHandling I found something about caching.
I’m confused…
The frontend and backend have different scopes and different approaches to data permissions. As a difference to many other CMSs, TYPO3 differentiates clearly between frontend and backend users, and thus also their data access. It has security benefits, but also means a data modification event in the frontend is contextually different to one in the backend.
In the frontend, you as a developer are responsible for implementing the security and custom permissions that match the data access you need for your application. Frontend users do not include data access permission settings, and Extbase is very good for this use case.
Backend users, on the other hand, can be given explicit access to tables and fields. The TYPO3 Backend makes heavy use of the DataHandler for data manipulations, rather than Extbase. It is slower than Extbase and not suited for frontend use, partially because it automatically checks that the logged-in user has access to modifying the data and a lot of other conditions.
I don’t know exactly where you found the information about caching that you refer to, but caching exists and makes sense both in the frontend and backend.
I hope this explanation was helpful. Please feel free to ask further questions!
The detailed explanation that FE and BE are different is nice, but it doesn’t help me in any way.
It’s good that the data handler is used extensively in BE, but either I’m blind or there’s no hook where I can hook into the (post)save process to perform my cleanup if necessary.
<?php
defined('TYPO3') || die();
use Cylancer\\CyWatermark\\Hook\\DataHandlerHook;
$GLOBALS\['TYPO3_CONF_VARS'\]\['SC_OPTIONS'\]\['t3lib/class.t3lib_tcemain.php'\]\['processDatamapClass'\]\['cy_watermark'\] = DataHandlerHook::class ;
Cylancer\CyWatermark\Hook\DataHandlerHook;
<?php
namespace Cylancer\CyWatermark\Hook;
use Cylancer\CyWatermark\Service\WatermarkService;
use TYPO3\CMS\Core\DataHandling\DataHandler;
use TYPO3\CMS\Core\SingletonInterface;
class DataHandlerHook implements SingletonInterface
{
/**
* Generate a different preview link *
*
* @param string $status status
* @param string $table table name
* @param int $recordUid id of the record
* @param array $fields fieldArray
* @param DataHandler $parentObject parent Object
*/
public function processDatamap_afterDatabaseOperations(
$status,
$table,
$recordUid,
array $fields,
DataHandler $parentObject
): void {
if ($status === 'update' && $table === 'sys_category' && $this->watermarksFieldChanged($fields)) {
....
}
}
