Wednesday, December 29, 2021

How to manually create the default crop variant string for an imported image in TYPO3 CMS

When data in TYPO3 is created automatically (e.g. through a custom API or by an import script), it is very common, that also new files (especially images) are imported. TYPO3 has the well documented FAL (File Abstraction Layer), which provides an API for common tasks. 

One typical task is to import an image to FAL and next creating a file reference for the imported image to a record (e.g. event record of ext:sf_event_mgt). Such a task is easy to implement in a custom extension when you follow the example documentation from the TYPO3 FAL API. This all works fine as described, as long as the referenced image does not use Crop Variants. For image fields, where crop variants are configured, no crop variants will be created for imported images and as a result, TYPO3 will always use the aspect ratio of the imported image no matter which crop variant is configured for output.

TYPO3 internals

Available crop variants for image fields are defined in TCA. When an editor adds an image to a record in the TYPO3 backend, TYPO3 will automatically calculate the default crop variants. The result is saved to the table sys_file_reference in the field crop as a JSON encoded string like the shown example crop variant string below:

{"heroimage":{"cropArea":{"x":0,"y":0.23,"width":1,"height":0.54},"selectedRatio":"16:9","focusArea":null},"teaserimage":{"cropArea":{"x":0,"y":0.14,"width":1,"height":0.72},"selectedRatio":"4:3","focusArea":null}}

This process if performed in ImageManipulationElement. When an editor for example edits a record with an imported image and opens an image inline element, then the ImageManipulationElement is rendered and the default crop variant string is calculated for the imported image and saved, as soon as the editor saves the record.

Manually calculating the default crop variant string

In order to manually calculate the default crop variant string in an image import process, it is required to extract 2 code snippets from the ImageManipulationElement, since both are not public available:

  1. The default crop configuration - see code
  2. The function populateConfiguration - see code
Both is extracted to a class named CropVariantUtility and an additional public function is added which returns the crop variant string for a given file as shown below:

/**
 * Returns a crop variant string to be used in sys_file_reference field "crop" for the given file and table/fieldname
 *
 * @param File $file
 * @param string $tableName
 * @param string $fieldname
 * @return string
 * @throws InvalidConfigurationException
 */
public static function getCropVariantString(File $file, string $tableName, string $fieldname): string
{
    $config = $GLOBALS['TCA'][$tableName]['columns'][$fieldname]['config']['overrideChildTca']['columns']['crop']['config'];
    $cropVariants = self::populateConfiguration($config);
    $cropVariantCollection = CropVariantCollection::create('', $cropVariants['cropVariants']);
    if (!empty($file->getProperty('width'))) {
        $cropVariantCollection = $cropVariantCollection->applyRatioRestrictionToSelectedCropArea($file);
    }

    return (string)$cropVariantCollection;
}

The whole class is available in this gist.

Finally the new CropVariantUtility can be used in a file import routine as shown in the example below:


protected function addFileToEvent(File $file, int $eventUid): void
{
    $eventRecord = BackendUtility::getRecord(self::EVENT_TABLE, $eventUid);

    $fileReferenceUid = StringUtility::getUniqueId('NEW');

    $dataMap = [];
    $dataMap['sys_file_reference'][$fileReferenceUid] = [
        'table_local' => 'sys_file',
        'tablenames' => self::EVENT_TABLE,
        'uid_foreign' => $eventUid,
        'uid_local' => $file->getUid(),
        'fieldname' => 'image',
        'pid' => $eventRecord['pid'],
        'show_in_views' => 0,
        'crop' => CropVariantUtility::getCropVariantString($file, self::EVENT_TABLE, 'image'),
    ];

    $dataMap[self::EVENT_TABLE][$eventUid] = [
        'image' => $fileReferenceUid
    ];

    $this->dataHandler->start($dataMap, []);
    $this->dataHandler->process_datamap();
}

The example code will create a new file reference for the given file object for the table  self::EVENT_TABLE (tx_sfeventmgt_domain_model_event in this case) and the given event UID. The usage of the new CropVariantUtility ensures, that the new file relation has a default crop variant string and configured crop variants can directly be used for imported images.

Sunday, October 17, 2021

TYPO3 extension "Event management and registration" version 6.0 for TYPO3 11.5 LTS released

I am really proud and happy to announce, that the new version 6.0. of my TYPO3 extension "Event management and registration" (GitHub / TYPO3 Extension Repository) is now fully compatible with TYPO3 11.5 LTS including support for PHP 7.4 and 8.0.

Originally I wanted to release this version of the extension on the same day as TYPO3 11.5 LTS got released, but I decided to consider all possible deprecations from TYPO3 core and also to reactor the extension to support strict types and strict properties where ever possible. All in all, my planned 6 days for a TYPO3 11.5 LTS compatible version resulted in more than 10 days of work. Well, not all changes were required for the release (e.g. removal of switchableControllerActions), but the code base is now better than before and I'm happy with all improvements that made its way into the extension.

Changes in more than 145 commits

The most important changes are of course those who break existing functionality. Although the new version contains 7 breaking changes and much of the codebase has been changed too, existing users can migrate to the new version with the least possible manual work. 

The list below contains some of the important changes:

  • The extension uses strict types and typed properties wherever possible
  • switchableControllerActions have been removed. The extension now has 7 individual plugins instead. An update wizard will migrate existing plugins and settings.
  • Data Transfer Objects do not extend AbstractEntity any more
  • Native TYPO3 pagination API support for event list view
  • Captcha integration has been refactored to support both reCaptcha or hCaptcha
  • All possible TYPO3 core deprecations have been handled
All breaking changes have been documented in detail in the release notes, so existing users know which parts of the extension need further attention when updating.



Sunday, August 15, 2021

"Unterminated nested statement!" using TYPO3 rector

TYPO3 rector is a really helpful application when it comes to TYPO3 major updates. It helps you to identify and refactor TYPO3 deprecations in custom extensions and can save hours of manual refactoring. I use TYPO3 rector quite a lot and stumbled across the following error recently.

"Unterminated nested statement!"







This message is not really helpful, so I digged deeper into the problem. The "Parser.php" throwing the exception is located in "helmich/typo3-typoscript-parser" package, so I first thought that there was a problem with the TypoScript in the desired extension, but after checking ever line manually, I could not find any error. 

It came out, that the extension I wanted to process by TYPO3 rector had a "node_modules" folder, which contained a lot of Typescript (not TypoScript) files. Those files where obviously parsed by the TypoScript parser resulting in the shown error message. After removing (excluding should also work) the "node_modules" folder, everything worked as expected.

If you like rector and/or TYPO3 rector, please consider to support the authors.
 

Friday, June 4, 2021

How to use constructor dependency injection in a XCLASSed TYPO3 class

Some time ago in needed to extend an Extbase controller in TYPO3 10.4 which used dependency injection through constructor injection. So I used XCLASS to extend the original controller and added an own constructor which added an additional dependency, but this obviously did not work out properly, since the constructor was always called with the amount of arguments from the original class.

Later I created this issue on TYPO3 forge in order to find out if this is a bug/missing feature or if I missed something in my code. In order to demonstrate the problem, I created this small demo extension which basically just extended a TYPO3 core class using XCLASS and just days later, a solution for the issue was provided.

The solution is pretty simple and you just have to ensure to add a reference to the extended class in the Services.yaml file of the extending extension.

Example:


  TYPO3\CMS\Belog\Controller\BackendLogController: '@Derhansen\XclassDi\Controller\ExtendedBackendLogController'

The complete Services.yaml file can be found here.

Thanks a lot to Lukas Niestroj, who pointed out the solution to the problem.


Monday, March 22, 2021

How to migrate switchableControllerActions in a TYPO3 Extbase extension to single plugins

TL;DR - I created this TYPO3 update wizard which migrates plugins and Extbase plugin settings for each former switchable controller actions configuration entry.

Since switchableControllerActions in Extbase plugins have been deprecated in TYPO3 10.4 and will be removed in either TYPO3 11 but most likely 12, I decided to remove switchableControllerActions in my TYPO3 Extbase extensions already with the upcoming versions that will be compatible with TYPO3 11.

In this blogpost I will show, how extension authors can add a smooth migration path to their existing extensions by adding an update wizard which migrates all existing plugin settings, so users do not have to change plugin settings manually. 

As a starting point lets have a look at my TYPO3 extension Plain FAQ, which is a very simple Extbase extension with one plugin, that has 3 switchableControllerActions.

  • Faq->list;Faq->detail
  • Faq->list
  • Faq->detail
For all 3 switchableControllerActions, I created 3 individual plugins (Pilistdetail, Pilist, Pidetail) which handle the action(s) of each switchable controller action from the list above. 

For each new plugin, I added an individual FlexForm file which holds the available settings for the plugin. This can be done by duplicating the old FlexForm (Pi1 in this case) and removing those settings, which are not available in the new plugin. Also display conditions based switchableControllerActions must be removed.

Finally I created a new item group for the Plugins of the extension, so all plugins are grouped as shown on the screenshot below.


This is basically all work that needs to be done on code side in order split the old plugin to the new plugins.

Migration of existing plugins


To be able to migrate all existing plugins and settings to the new plugins, I created a custom upgrade wizard that takes care of all required tasks. Those tasks are as following:
  • Determine, which tt_content record need to be updated
  • Analyse existing Plugin (field: list_type) and switchableControllerActions in FlexForm (field: pi_flexform)
  • Remove non-existing settings and switchableControllerAction from FlexForm by comparing settings with new FlexForm structure of target plugin
  • Update tt_content record with new Plugin and FlexForm
As a result, a SwitchableControllerActionsPluginUpdater has been added to the extension. It takes care of all mentioned tasks and has a configuration array which contains required settings (source plugin, target plugin and switchableControllerActions) for the migration.

private const MIGRATION_SETTINGS = [
    [
        'sourceListType' => 'plainfaq_pi1',
        'switchableControllerActions' => 'Faq->list;Faq->detail',
        'targetListType' => 'plainfaq_pilistdetail'
    ],
    [
        'sourceListType' => 'plainfaq_pi1',
        'switchableControllerActions' => 'Faq->list',
        'targetListType' => 'plainfaq_pilist'
    ],
    [
        'sourceListType' => 'plainfaq_pi1',
        'switchableControllerActions' => 'Faq->detail',
        'targetListType' => 'plainfaq_pidetail'
    ],
];
So basically, one configuration entry has to be added for each switchable controller action setting of the old plugin. The wizard determines the new FlexForm settings using configured TCA, removes all non-existing settings (which is important, since TYPO3 will pass every setting available in pi_flexform to Extbase controllers and Fluid templates) and changes the "old" Plugin to the new one.

The update wizard can possibly also be used in other Extbase extensions, since the MIGRATION_SETTINGS are the only configuration options that need to be changed.

The required changes for the complete removal of switchableControllerActions is available in this commit.