Releases: cobwebch/external_import
8.0.0
This major release comes with support for TYPO3 13, while dropping support for TYPO3 11. It also adds PHP 8.4 support and drops compatibility with PHP 7.4 and 8.0.
On top of this, it contains several new features:
- compatibility with "svconnector" 6+ (in particular, using the call context API of svconnector)
- configurations can belong to several groups
- the import reaction can target a group (and not just a single configuration)
- configurations can be disabled (becoming invisible for all purposes)
- relation-type fields (select, group, inline, file) with no "minitems" property or "minitems = 0" are considered nullable (could have unexpected effects, please read the documentation)
Under the hood, much happened in the JavaScript for the backend modules, most notably dropping usage of RequireJS (as the TYPO3 core has done) and updating DataTables to version 2+, which made it possible - in particular - to improve some initializations. Also all tests were updated to use the "typo3/testing-framework" (previously using "nimut/testing-framework").
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
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.