AbstractService::getResultMessage takes two arguments, $status and $message, which are both null by default. When trying to print an error message with just $status set (as e.g. MigrateRelationsService does) only $status is printed because $message has already been overridden by LocalizationUtility::translate('moveAlong', 'dam_falmigration').

Furthermore, to actually print an error message, amountOfMigratedRecords has to be set to a negative value, else default messages (migrationSuccessful & migratedFiles or migrationNotNecessary & allFilesMigrated) will be used instead of the requested headline & message.

This looks unintended as e.g. MigrateRelationsService has not been written that way. How were error messages supposed to be working?

Plus, if $message was not overridden early on, the translation key would still be wrong as the dot after migrationStatusMessage prefix is missing:

$message = LocalizationUtility::translate('migrationStatusMessage' . $status, 'dam_falmigration');

I test the migration EXT, but I get an error during invest an task.

PHP Fatal error: Class 'TYPO3\CMS\DamFalmgiration\Task\tx_scheduler_task' not found in /srv/www/project/typo3conf/ext/dam_falmigration/Classes/Task/MigrateTask.php on line 41, referer: http://localhost/typo3/mod.php?M=tools_txschedulerM1&SET[function]=list&CMD=add&tx_scheduler[class]=tx_damfalmigration_task_migratetask

Any idea how I can fix it?
TYPO3 6.0.4
dam 1.3.1

If a dam record contains a file which was uploaded by an user directly in a field, the migration isn't done properly due to the limitation to storages. The extension should take care about moving files to the _migrated folder of the first storage before any migration process starts.

I get these error when I try to install the EXT:

Extension Upload failed
PHP Catchable Fatal Error: Argument 1 passed to TYPO3\CMS\Extensionmanager\Utility\InstallUtility::processDatabaseUpdates() must be of the type array, null given, called in /var/www/clients/client1/web1/web/typo3_src-6.1.5/typo3/sysext/extensionmanager/Classes/Utility/InstallUtility.php on line 133 and defined in /var/www/clients/client1/web1/web/typo3_src-6.1.5/typo3/sysext/extensionmanager/Classes/Utility/InstallUtility.php line 244

Typo3: 6.1.5 on a Linux Host

It migrates only name format.

If media tag doesn't contain other parameters than uid (name) - such media tags won't be migrated.

I think there is a problem here:
'uid_local' => $categoryRelation['sys_file_uid'],
'uid_foreign' => $categoryRelation['sys_category_uid'],

This means the file ID will go into sys_category_record_mm as uid_local.

But that is wrong: sys_category_record_mm has "sys_category" as the local record.
This is logical because sys_category_record_mm can categorize any table!

With tx_dam_mm_cat it was the other way around: It had tx_dam as the local record - and it was only used for categorizing DAM.

So foreign and local need to be switched in the import.

<media xxx>xxx<media>

Function execSelectDamReferencesWhereSysFileExists orders records by field tx_dam_mm_ref.sorting.
In my case, I had 7 records with sorting=0, but sorting_foreign was filled with 1 to 7.
The migration resulted in mixing up images and their captions.

tx_dam_mm_ref.sorting_foreign sould be at least the 2nd order by-Parameter

return $this->database->exec_SELECTquery(
'tx_dam_mm_ref.*,
sys_file_metadata.title,
sys_file_metadata.description,
sys_file_metadata.alternative,
sys_file.uid as sys_file_uid',
'tx_dam_mm_ref
JOIN sys_file ON
sys_file._migrateddamuid = tx_dam_mm_ref.uid_local
JOIN sys_file_metadata ON
sys_file.uid = sys_file_metadata.file
',
$where,
'',
'tx_dam_mm_ref.sorting ASC,tx_dam_mm_ref.sorting_foreign ASC',
(int)$this->getRecordLimit()
);

Cheers
Roland

I startet the mirgation command for dam metadata and occured this error
"Unknown column 'caption' in 'field list'"

SQL:
UPDATE sys_file SET tstamp='1413387271',caption=NULL,color_space='RGB',creator='',content_creation_date='1400161927',content_modification_date='1400161927',fe_groups='0',download_name='20140515..._01.jpg',unit='',visible='0',note=NULL,keywords=NULL,language='',location_city='',location_country='',pages='0',publisher='' WHERE uid = 5889

Backtrace:

include(4/typo3/sysext/extbase/Scripts/CommandLineLauncher.php),4/typo3/cli_dispatch.phpsh#53 // TYPO3\CMS\Extbase\Core\Bootstrap->run#21 // TYPO3\CMS\Extbase\Core\Bootstrap->handleRequest#184 // TYPO3\CMS\Extbase\Mvc\Cli\RequestHandler->handleRequest#195 // TYPO3\CMS\Extbase\Mvc\Dispatcher->dispatch#61 // TYPO3\CMS\Extbase\Mvc\Controller\CommandController->processRequest#69 // TYPO3\CMS\Extbase\Mvc\Controller\CommandController->callCommandMethod#112 // call_user_func_array#211 // B13\DamFalmigration\Controller\DamMigrationCommandController->migrateDamMetadataCommand# // TYPO3\CMS\DamFalmigration\Service\MigrateMetadataService->execute#63 // TYPO3\CMS\Core\Database\DatabaseConnection->exec_UPDATEquery#150 // TYPO3\CMS\Core\Database\DatabaseConnection->debug#245

Fix:
I removed the foreach on $this->fileMetadataColumnMapping in File MigrateMetadataService->createArrayForUpdateSysFileRecord and it works.

The service first reads in all dam records which are not migrated yet which presumably exhausts the memory_limit on larger tables. Solution would be to fetch each record just short before it is going to be migrated.

Documentation uses :ref: markup and .. _My Reference Name: commands on top of files. However, GitHub does not appear to interpret these (at least not across files) which makes it impossible to switch between files using the linked references in .rst files. How should references across files be entered so they work on GitHub?

Before introduction of FAL image captions, links etc. in TYPO3 used index-based multi-line fields which were split up over line-breaks on frontend rendering. Migration with dam_falmigration works by splitting over line-feed (LF) characters (ASCII code 10). If multi-line fields were saved with CR LF line-break sequences, the leading CR character (ASCII code 13, hex 0D) will be left over. This happens to sys_file_reference fields title, link, alternative and description. The only multi-line field where this will be visible on the backend (trailing line-break) is description but it's present in all other fields as well. For example, this happens to links if multi-line input was present before migration; to check see: select link, hex(binary(link)) from sys_file_reference where link is not null and link != '';

In combination with bug 73156 in TYPO3 Core this may result in indexes being off by one if processed by legacy FE rendering code.

A possible fix could be to right-trim all white-space (e.g. by using \TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode instead of explode) upon splitting. Another (possibly better) fix would be to normalize CRLF to LF and then CR to LF before splitting on LF (not sure if it is/was ever possible to enter "old-world" Macintosh-style CR-only line-breaks in TYPO3).

We can't currently provide a tested patch for this issue, as we have no other TYPO3 migrations in queue at the time. If TYPO3 Core includes our patch to the core bug, previously migrated content will start to appear again on the correct indexes but unnecessary CR characters will remain in DB (which shouldn't cause any harm, though; the only side-effect being BR tags appearing at the end of image captions).

Hi ;

I try to use your extension with TYPO3 6.2. During the installation of the extension I get an error

PHP Fatal error: Uncaught exception 'UnexpectedValueException' with message '$hookObject must implement interface TYPO3\CMS\Core\Database\TableConfigurationPostProcessingHookInterface' in /var/www/project/TYPO3.CMS/typo3/sysext/core/Classes/Core/Bootstrap.php:966\nStack trace:\n#0 /var/www/project/TYPO3.CMS/typo3/sysext/core/Classes/Core/Bootstrap.php(919): TYPO3\CMS\Core\Core\Bootstrap->runExtTablesPostProcessingHooks()\n#1 /var/www/project/TYPO3.CMS/typo3/sysext/extensionmanager/Classes/Utility/InstallUtility.php(293): TYPO3\CMS\Core\Core\Bootstrap->loadExtensionTables(false)\n#2 /var/www/project/TYPO3.CMS/typo3/sysext/extensionmanager/Classes/Utility/InstallUtility.php(119): TYPO3\CMS\Extensionmanager\Utility\InstallUtility->reloadCaches()\n#3 /var/www/project/TYPO3.CMS/typo3/sysext/extensionmanager/Classes/Service/ExtensionManagementService.php(219): TYPO3\CMS\Extensionmanager\Utility\InstallUtility->install('t3ext-dam_falmi...')\n#4 /var/www/project/TYPO3.CMS/typo3/sysext/extensionmanager/Classes/ in /var/www/project/TYPO3.CMS/typo3/sysext/core/Classes/Core/Bootstrap.php on line 966, referer: http://project.local/typo3/mod.php?M=tools_ExtensionmanagerExtensionmanager&moduleToken=a5f70df44824cad53cc755d2bd6cf95f4986c6fe&tx_extensionmanager_tools_extensionmanagerextensionmanager%5BrefreshModuleMenu%5D=1&tx_extensionmanager_tools_extensionmanagerextensionmanager%5Baction%5D=index&tx_extensionmanager_tools_extensionmanagerextensionmanager%5Bcontroller%5D=List

After executing the commands dammigration:migratedamrecords and dammigration:migratedammetadata the command dammigration:migratemediatagsinrte ends up with several "No FAL record found for dam uid: ..." error messages.

After investigating the problem I can say that there are two possibilities.

• The extracted dam uid is referencing a deleted dam record. Then the deleted field of the record in table tx_dam is set to 1.
• The extracted dam uid doesn't match the field sys_file._migrateddamuid of any sys_file record but it is still possible to identify the sys_file record by comparing e.g. the dam record's file_name with sys_file.name.

I think the migration of media tags should therefore compare the sys_file.identifier with the values of the according dam record fields file_path and file_name if the comparison of the _migrateddamuid field fails. Is this a bug?

Cheers,
Thomas

https://github.com/b13/t3ext-dam_falmigration/blob/master/Classes/Controller/DamMigrationCommandController.php

on line 43 there is a hard reference to uid 1

public function migrateDamRecordsToStorageCommand($storageUid = 1, $recordLimit = 999999)

When the uid in your TYPO3 installation have a other id you get no usefull information in the backend module.

dammigration:migratedamrecords crashes with fatal error:

Fatal error: Call to undefined method TYPO3\CMS\DamFalmigration\Service\MigrateService::getRecordLimit() in /.../typo3conf/ext/dam_falmigration/Classes/Service/MigrateService.php on line 183

While rewriting caption/title/alt handling for images I noticed that migraterelations may query for tt_content.uid using a page ID (tx_dam_mm_ref.uid_foreign when tx_dam_mm_ref.tablenames is pages or pages_language_overlay), then uses the result as captions. This does seem wrong unless I'm missing something. According to history, this was introduced for migration of dam_pages extension providing file ("media") references on page properties and should only be effective for $insertData['fieldname'] === 'media' (mapped field name according to getColForFieldName). As it appears to query the wrong table for metadata, however, it may never have worked.

Merging pull request #74 will limit image metadata processing to tt_content, media metadata is still queried the same way as before but now has a comment with a reference to this issue.

Edit: Column mapping for dam_pages is of course media, not image. Changed fieldname above.

On migrating DAM categories, the mountpoints in be_users and be_groups (field tx_dam_mountpoints, prefixed with the type of mountpoint where txdamCat makes sense in this case) should be migrated to category_perms field.

I could provide a pull request for that.

To have $migratedFileFields set (step 2a in backend module, cf Template Overview), I had to change the relevant line in FileController, where the array key

'Tx_Install_Updates_File_TceformsUpdateWizard'

$migratedFileFields = \TYPO3\CMS\Core\Utility\GeneralUtility::trimExplode(',', $GLOBALS['TYPO3_CONF_VARS']['INSTALL']['wizardDone']['TYPO3\CMS\Install\Updates\TceformsUpdateWizard'], TRUE);

Maybe this has changed from 6.0 to 6.1? It is at any rate the key I find is set in LocalConfiguration.php.

Hi,

got the forked fixed module an tried to run the MigrateTask but my typo only gives me an error:

Die Ausführung von Task "DAM-FAL Migration: Migrate DAM Records to FAL Records (dam_falmigration)" ist fehlgeschlagen mit folgender Meldung:

But there is no error message from the script.

run typo 6.1.1 and dam 1.3.

Hi there,

i encountered a problem with my UTF-8 typo3 installation (all tables and fields are in utf8_general_ci, setDbInit has set names utf-8 and so on) with special characters like german umlauts (ä ö ü) or 'ß'.

Those made the dammigration:migratedamrecords throw a "FIile does [...] not exist" Error in MigrateService.php on Line 121.

The damrecord fields contains already broken characters in $damRecord['file_name'] after reading from DB and cant be revealed by any of the mb_convert_encodings.

I also tried resetting the database connectionCharset and reinitializing it right before the query that fetchs the damrecords but with no effect.

The cli_dispatch.phpsh was ran on a windows xampp with php 5.3.9 (i know that's very outdated but was the only 5.3 xampp i found to install the typo3 4.5 i had to update).

I now manually fixed the broken entries but i'm sure i'll get back to this extension on the next LTS->LTS update and it would be great if there is a solution then.

Best regards,
Simon

On checking for existing relations in sys_file_reference a wrong dataset is used. Instead of using the sys_file.uid as uid_local, the old tx_dam.uid is taken as reference. This results in wrong or not existing references and leads to multiple references when the command is called multiple times.

When I try to execute this script, I get the following error:
SQL-Error in getCategoryRelationsWhereSysCategoryExists()

Classes/Service/MigrateMetadataService.php produces SQL errors when migration with EXT Media in version 3. The fields mapped in $mediaColumnMapping are not longer available.

There should be a version check in place to prevent errors.

I just realized that this extension consists of 6 scheduler tasks and 1 command controller with 8 public methods.

The readme file tells to use the scheduler tasks. Is the command controller obsolete? Should we delete it to avoid confusion?

This is the current list of cli_dispatch commands:

• dammigration:migratedamrecords
• dammigration:migratedammetadata
• dammigration:migratemediatagsinrte
• dammigration:migratedamcategories
• dammigration:migratedamcategoriestofalcollections
• dammigration:migratecategoryrelations
• dammigration:migratedamfrontendplugins
• dammigration:cleanupduplicatefalcollectionreferences
• dammigration:updatereferenceindex
• dammigration:migraterelations
• dammigration:migrateselections
• dammigration:migratedamttnews

But in the User Manual doesn't reflect this and contains mismatches like dammigration:connectdamrecordswithsysfile

In the SQL of \TYPO3\CMS\DamFalmigration\Service\MigrateRelationsService::execSelectDamReferencesWhereSysFileExists the field sys_file_metadata.caption is added as select field. This field only exists in the database table if the extension filemetadata is active. There should be a check if the extension is loaded before inserting it into the SQL statement.

Repository returns empty results in TPO3 4.7 when fetching methods

How about the migration DAM references from extensions like news or tt_news?

I got these error when I try to start the Extension:
PHP Fatal error: Class '\TYPO3\CMS\DamFalmigration\Task\MigrateTask' not found in

typo3 6.1.5