7.2.9

This release improves the bugfix provided in version 7.2.8, which was really crappy and I must apologize for that. The DatamapPostprocessEvent now provides the data as it did before (buggy but unchanged) using the getData() method. It provides the new, not-buggy data using a new method called getStructuredData().

Again assuming that External Import has handled two records in two different tables, what you get from getData() is:

[
    23 => [
        'title' => 'foo'
    ],
    47 => [
        'title' => 'bar'
    ],
]

and what you get from getStructuredData() is:

[
    'abc' => [
        23 => [
            'title' => 'foo'
        ],
    ],
    'def' => [
        47 => [
            'title' => 'bar'
        ],
    ],
]

7.2.8

This release contains a single bugfix, but it may break usage of DatamapPostprocessEvent so please read carefully before upgrading.

The DatamapPostprocessEvent class exposes the data saved by External Import, in a structure similar to what is used by the Core's DataHandler class. However, since External Import handled only a single table for a long time, the table was not referenced inside that structure. Ever since the children property was introduced, an import run may handle two or more tables. The DatamapPostprocessEvent class had not been adapted and records from different tables would then overwrite each other, if they shared the same primary key.

This has been fixed by adding the table name as additional dimension to the data, which will break existing processing performed when listening to the DatamapPostprocessEvent. However, to keep backwards-compatibility as much as possible (before the next major version), the single-dimensional structure is kept when the import handles a single table.

With a single table

Before:

[
    23 => [
        'title' => 'foo'
    ],
    47 => [
        'title' => 'bar'
    ],
]

After: unchanged

With multiple tables:

(assuming record 23 belongs to table "abc" and record 47 belongs to table "def")

Before:

[
    23 => [
        'title' => 'foo'
    ],
    47 => [
        'title' => 'bar'
    ],
]

After:

[
    'abc' => [
        23 => [
            'title' => 'foo'
        ],
    ],
    'def' => [
        47 => [
            'title' => 'bar'
        ],
    ],
]

7.2.7

Minor bugfix release with a (hopefully final) fix for handling messages coming from the Core's DataHandler and a better reporting of warnings when using reactions (thanks to Mathias Brodala).

7.2.6

This release contains a few bug fixes and minor improvements:

• when using reactions, if you create a reaction with a predefined configuration, it is not necessary anymore to include the table and the configuration index in the payload. The configuration is taken from the reaction (thanks to Mathias Brodala).
• once an override storage pid was set in a Scheduler taks, it was not possible to remove it. This has been fixed.
• some old DBAL API was still used in some parts. This was cleaned up by Tim Obert.

And a huge, invisible work was made under the hood by Lina Wolf, who introduced a script and configuration (adapted from the TYPO3 Core) for running unit tests, linting the code and generating the documentation. This is a wonderful improvement for the stability and quality of the extension.

7.2.5

This release finally offers a good interoperability between TYPO3 11 and 12, solving the bad interaction there was due to trying to use system extension "reactions", which does not exist for TYPO3 11. This process is now invisible for users of TYPO3 11, and also for TYPO3 12 when "reactions" is not installed. "reactions" is mentioned as suggestion in the Composer manifest.

Furthermore compatibility with PHP 8.3 was verified.

7.2.4

This release contains a minor bug fix when evaluating if a property is nullable or not (strict casting to boolean) and a switch to PHP-based rendering for the documentation (thanks to Lina Wolf).

7.2.3

Minor bug fix release, correcting a regression in backend module access for TYPO3 11.

7.2.2

Release with one bug fix: the disabledOperations property was not handled correctly when it contained blanks in between keywords.

7.2.1

Minor release with two bug fixes:

• the first one is very important and is related to the handling of hidden records in child tables (i.e. when using a children configuration). These were not considered as existing records and thus recreated anew upon each import.
• the second one is just improved logging of DataHandler errors

7.2.0

This release introduces two minor features, although the first one may have an important impact depending on your configuration, so please read carefully:

• the HandleDataStep used to drop fields with a "null" value in the imported data. This is no longer the case and is complementary to allowing "null" values to be stored, fixed in a previous release. The impact may be that fields that were left as is until now, will now be nulled if they are "null" in the data to import. Also, user functions used during the TransformDataStep may not expect values to be "null" where there were none before.
• the \Cobweb\ExternalImport\Event\InsertRecordPreprocessEvent and \Cobweb\ExternalImport\Event\UpdateRecordPreprocessEvent events may not throw the special exception \Cobweb\ExternalImport\Exception\InvalidRecordException in order to exclude records from the insert or update operations.

On top of these features, two bugs were fixed:

• the main backend module does not have access rights anymore (which means it does not have to be explicitly selected in BE groups)
• the backend modules have a slightly improved look with TYPO3 12, thanks to a better integration with the stylesheet for that version.