7.3.0

This release introduces a new feature: a "delete" reaction. This is useful when the import reaction is used to handle an item at a time and not a full dataset. In such a case, the deletion cannot be handled automatically, since External Import does not have the entire dataset for comparison. This way, it is possible to handle such a scenario from within External Import, without having to develop a custom reaction. Read the documentation for more details: https://docs.typo3.org/p/cobweb/external_import/main/en-us/User/Reaction/Index.html

The release also includes a minor bugfix improving the handling of null substructures.

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