I have an old typo3 installation using TYPO3 v6.1.7 and I now want to export the side tree and import it on a new installation using v12.4.10. I just moved all the contents of the filadmin folder to the new installation and then went to export the side tree (I tried pretty much all combinations of settings) which all worked perfectly but when trying to import the file in the new installation I get
TypeError
TYPO3\CMS\Core\Utility\PathUtility::stripPathSitePrefix(): Argument #1 ($path) must be of type string, null given, called in /var/www/typo/vendor/typo3/cms-impexp/Classes/ImportExport.php on line 819
and then about 50 code snippets. The first is in /var/www/typo/vendor/typo3/cms-core/Classes/Utility/PathUtility.php line 428:
/**
* Strip first part of a path, equal to the length of public web path including trailing slash
*
* @internal
*/
public static function stripPathSitePrefix(string $path): string
{
return substr(
$path,
strlen(Environment::getPublicPath() . '/')
);
}
(I am not going to paste every single one now. If anyone thinks the entire trace is important I can provide the html file)
I didn't try many things yet but I also don't know what to try. I didnt find any reference to similar errors with TYPO3 when researching this problem and the only references I did find all seemed to be related to incompatible php versions (not related to typo3 though), but on the bottom of this page it says that everything should be backwards compatible and the I can hardly run TYPO3 v12 on php v5.5...
Phew, this is really some very old dump. Basically, TYPO3 Import/Export is meant to be used within the same version, it's not aimed at providing an migratable import, especially for these old versions.
Luckily the format itself has not changed so much, but the underlying data structures have. Especially inside the file management and file references.
What currently "bites you" is that there are file relations that cannot be read properly, and throw that error.
While it would be possible to fix that specific error by bypassing the type-check, you will probably face many more issues along the way.
It would be easiest if you can disregard and not export any old images, and better re-assign the images after import. Yes, this is work. But it will probably not work automatically. You would need to write your own FAL importer for that, or actually instead of jumping from v6 to v12 you would have to migrate the existing instance from v6 to 7, 8, 9, 10, 11 and then 12. That is the only guaranteed way to keep all data.
Having said that; the error at hand could be patched if you replace all occurrences of:
PathUtility::stripPathsitePrefix($somevariable)
with
PathUtility::stripPathsitePrefix((string)$somevariable ?? '')
to ensure that at least an empty string is passed to the method.
I made a simple patch against this for 12.4.10:
https://gist.github.com/garvinhicking/f95e94784a78db16100331e613ae72b0
This is done against a legacy installation, if you use composer you'll need to adjust the patch to use "./vendor/cms-impexp/..." as the patch base instead of "./typo3/sysext/impexp". But it may give you a clue.
Hope that helps a bit, but I want to manage/curb your expectations - this kind of site migration will cause a lot of pain. It's like trying to import a Windows98 application into Windows 11 just by copying the .exe files.