$extensionName is empty in site configuration

[grischpel]

An error occurred trying to process items for field "Available page layouts/templates (empty selection means allow-all)" (Parameter $extensionName cannot be empty if a fully-qualified key is not specified.).

[markoschmidt]

I fixed this by translating the labels in page templates, instead of having a hard coded label. So something like this label="LLL:EXT:my_ext/Resource/Private/Language/locallang.xlf:flux.pages.homePage". The error is thrown by TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate when it doesn't receive an extensionName parameter and translation key doesn't start with LLL:

[NamelessCoder]

Can you provide a bit more information about how/when this happens? The function in question will use foreach ($pageService->getAvailablePageTemplateFiles() as $extensionName => $templateGroup) { when iterating over the available page templates - an empty value for $extensionName simply shouldn't be possible. It should either be a full extension identifier like FluidTYPO3.Flux (when everything is registered correctly) or a non-empty value that somehow was used in Core::registerProviderExtensionKey as first argument (if something was not registered correctly). In either case, the resulting call to LocalizationUtility::translate should never pass an empty extension name - although it may pass an invalid extension name on misconfigured sites.

I am also not able to reproduce this by crating a page template with any combination of valid ways to specify a label (hardcoded label, short XLF identifier, full XLF path or even intentionally wrong XLF identifier, short or long).

So I'm wondering how it can be that this error is raised on your setups.

[grischpel]

Can you provide a bit more information about how/when this happens? The function in question will use foreach ($pageService->getAvailablePageTemplateFiles() as $extensionName => $templateGroup) { when iterating over the available page templates - an empty value for $extensionName simply shouldn't be possible. It should either be a full extension identifier like FluidTYPO3.Flux (when everything is registered correctly) or a non-empty value that somehow was used in Core::registerProviderExtensionKey as first argument (if something was not registered correctly). In either case, the resulting call to LocalizationUtility::translate should never pass an empty extension name - although it may pass an invalid extension name on misconfigured sites.

I am also not able to reproduce this by crating a page template with any combination of valid ways to specify a label (hardcoded label, short XLF identifier, full XLF path or even intentionally wrong XLF identifier, short or long).

So I'm wondering how it can be that this error is raised on your setups.

[grischpel]

I fixed this by translating the labels in page templates, instead of having a hard coded label. So something like this label="LLL:EXT:my_ext/Resource/Private/Language/locallang.xlf:flux.pages.homePage". The error is thrown by TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate when it doesn't receive an extensionName parameter and translation key doesn't start with LLL:

That does not work for me

[NamelessCoder]

@grischpel I'm afraid that error message doesn't help me. The error could come from anywhere; TYPO3 is catching an exception and turning it into a flash mesasge.

You can help by editing \TYPO3\CMS\Backend\Form\FormDataProvider\AbstractItemProvider::resolveItemProcessorFunction and in the catch section, add throw $exception;. This should result in TYPO3 no longer converting the exception to a flash message and should show the proper stack trace. Then I'll be able to tell where this failing translation call is being executed.

[grischpel]

@NamelessCoder If you can tell me how to get the file? I can not find it in the directory tree in the files in Typo3. Maybe I am too stupid to find them, but I have this problem now in some projects. Actually in all since Typo3 11. Has this possibly to do with the registration in the template?

ext_localconf.php ->

\FluidTYPO3\Flux\Core::registerProviderExtensionKey('Vendorname.Templatename', 'Page');
\FluidTYPO3\Flux\Core::registerProviderExtensionKey('Vendorname.Templatename', 'Content');

[NamelessCoder]

Depending on TYPO3 version, this class is either in vendor/typo3/cms-backend/Classes/Form/AbstractItemProvider.php or typo3/sysext/backend/Classes/Form/AbstractItemProvider.php (within your public folder, if your project uses one).

Assuming that the Vendorname.Templatename is constructed with your vendor name and the extension key in UpperCamelCase format, then those registrations appear to be correct. If you actually registered with the template name and not the extension name then your templates wouldn't be resolved correctly; Flux would look in the wrong place.

[grischpel]

Maybe I should mention that I have the following versions: "fluidtypo3/flux": "9.7.2", "fluidtypo3/vhs": "6.1.3".

Unfortunately, newer versions of Flux and vhs do not work in any way with Typo3 11. With newer versions, Flux does not work higher than version 9 in any of my projects that I have moved from Typo3 9 or 10 to Typo3 11.

Depending on TYPO3 version, this class is either in vendor/typo3/cms-backend/Classes/Form/AbstractItemProvider.php or typo3/sysext/backend/Classes/Form/AbstractItemProvider.php (within your public folder, if your project uses one).

Assuming that the Vendorname.Templatename is constructed with your vendor name and the extension key in UpperCamelCase format, then those registrations appear to be correct. If you actually registered with the template name and not the extension name then your templates wouldn't be resolved correctly; Flux would look in the wrong place.

Path found here: /var/www/websitename/public/typo3/sysext/backend/Classes/Form/FormDataProvider

Depending on TYPO3 version, this class is either in vendor/typo3/cms-backend/Classes/Form/AbstractItemProvider.php or typo3/sysext/backend/Classes/Form/AbstractItemProvider.php (within your public folder, if your project uses one).

Assuming that the Vendorname.Templatename is constructed with your vendor name and the extension key in UpperCamelCase format, then those registrations appear to be correct. If you actually registered with the template name and not the extension name then your templates wouldn't be resolved correctly; Flux would look in the wrong place.

Yes, I made sure that the vendor names and template names matched. So I paid attention to upper and lower case.

[NamelessCoder]

Flux 10.0 and VHS 7.0 should both work with TYPO3v11. It's possible that other packages are constraining the allowed versions.

Yes, I made sure that the vendor names and template names matched. So I paid attention to upper and lower case.

The extension identity must be created from your vendor name and the extension name, not the template name. I'm pretty sure you've got it correct, just wanted to mention that again to be totally clear. If your vendor name is Acme and the extension key is awesome_templates then the registration should use Acme.AwesomeTemplates as extension identity.

[grischpel]

The extension identity must be created from your vendor name and the extension name, not the template name. I'm pretty sure you've got it correct, just wanted to mention that again to be totally clear. If your vendor name is Acme and the extension key is awesome_templates then the registration should use Acme.AwesomeTemplates as extension identity.

Yes, Sir, thats correct.

Flux 10.0 and VHS 7.0 should both work with TYPO3v11. It's possible that other packages are constraining the allowed versions.

Unfortunately, it just doesn't work for me. No matter with which website / project.

[grischpel]

@grischpel I'm afraid that error message doesn't help me. The error could come from anywhere; TYPO3 is catching an exception and turning it into a flash mesasge.

You can help by editing \TYPO3\CMS\Backend\Form\FormDataProvider\AbstractItemProvider::resolveItemProcessorFunction and in the catch section, add throw $exception;. This should result in TYPO3 no longer converting the exception to a flash message and should show the proper stack trace. Then I'll be able to tell where this failing translation call is being executed.

(1/1) #1498144052 InvalidArgumentException
Parameter $extensionName cannot be empty if a fully-qualified key is not specified.

in /var/www//public/typo3/sysext/extbase/Classes/Utility/LocalizationUtility.php line 86
$key = array_pop($keyParts);
$languageFilePath = implode(':', $keyParts);
} else {
if (empty($extensionName)) {
throw new \InvalidArgumentException(
'Parameter $extensionName cannot be empty if a fully-qualified key is not specified.',
1498144052
);
}
at TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate()
in /var/www//public/typo3conf/ext/flux/Classes/Integration/FormEngine/SiteConfigurationProviderItems.php line 55
* @codeCoverageIgnore
*/
protected function translate(string $label): ?string
{
return LocalizationUtility::translate($label);
}
}
at FluidTYPO3\Flux\Integration\FormEngine\SiteConfigurationProviderItems->translate()
in /var/www//public/typo3conf/ext/flux/Classes/Integration/FormEngine/SiteConfigurationProviderItems.php line 43
continue;
}
$label = (string) $form->getLabel();
$identity = $extensionName . '->' . lcfirst(pathinfo($templateFilename, PATHINFO_FILENAME));
$label = $this->translate((string) $label) ?? $identity;
$tca['items'][] = [$label, $identity];
}
}
return $tca;
at FluidTYPO3\Flux\Integration\FormEngine\SiteConfigurationProviderItems->processPageTemplateItems()
at call_user_func_array()
in /var/www//public/typo3/sysext/core/Classes/Utility/GeneralUtility.php line 3127
$methodName = (string)$parts[1];
$callable = [$classObj, $methodName];
if (is_callable($callable)) {
// Call method:
$content = call_user_func_array($callable, [&$params, &$ref]);
} else {
throw new \InvalidArgumentException('No method name '' . $parts[1] . '' in class ' . $parts[0], 1294585865);
}
} else {
at TYPO3\CMS\Core\Utility\GeneralUtility::callUserFunction()
in /var/www//public/typo3/sysext/backend/Classes/Form/FormDataProvider/AbstractItemProvider.php line 97
$processorParameters['flexParentDatabaseRow'] = $result['flexParentDatabaseRow'];
}

    try {
        GeneralUtility::callUserFunction($config['itemsProcFunc'], $processorParameters, $this);
    } catch (\Exception $exception) {

throw $exception;
// The itemsProcFunc method may throw an exception, create a flash message if so
$languageService = $this->getLanguageService();

[grischpel]

I fixed this by translating the labels in page templates, instead of having a hard coded label. So something like this label="LLL:EXT:my_ext/Resource/Private/Language/locallang.xlf:flux.pages.homePage". The error is thrown by TYPO3\CMS\Extbase\Utility\LocalizationUtility::translate when it doesn't receive an extensionName parameter and translation key doesn't start with LLL:

@markoschmidt
this is my locallang.xlf

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xliff version="1.0">
  <file source-language="en" target-language="de" datatype="plaintext" date="2023-04-27T18:36:30Z" product-name="XXX">
	<header/>
	<body>
	  <trans-unit id="flexform.main.title">
		<source>Main Settings</source>
	  </trans-unit>
	  <trans-unit id="article">
		<source>article</source>
	  </trans-unit>
	  <trans-unit id="eroberung">
		<source>eroberung</source>
	  </trans-unit>
	  <trans-unit id="lightbox">
		<source>lightbox</source>
	  </trans-unit>
	  <trans-unit id="standard">
		<source>standard</source>
	  </trans-unit>
	  <trans-unit id="flux.pages.article">
		<source>article</source>
	  </trans-unit>
	  <trans-unit id="flux.pages.eroberung">
		<source>eroberung</source>
	  </trans-unit>
	  <trans-unit id="flux.pages.lightbox">
		<source>lightbox</source>
	  </trans-unit>
	  <trans-unit id="flux.pages.standard">
		<source>standard</source>
	  </trans-unit>
	</body>
  </file>
</xliff>

[grischpel]

Ok, I got it working now.... BUT:
I had to edit the extension FLUX in version 9 for this, because this does not work in version 9 yet.
I edited -> Path Classes/Integration/FormEngine/SiteConfigurationProviderItems.php.

public function processPageTemplateItems(array $tca, TcaSelectItems $bar): array {
	  /** @var ObjectManagerInterface $objectManager */
	  $objectManager = GeneralUtility::makeInstance(ObjectManager::class);
	  /** @var PageService $pageService */
	  $pageService = $objectManager->get(PageService::class);
	  foreach ($pageService->getAvailablePageTemplateFiles() as $extensionName => $templateGroup) {
		foreach ($templateGroup as $form) {
		  /** @var string|null $templateFilename */
		  $templateFilename = $form->getOption(Form::OPTION_TEMPLATEFILE);
		  if ($templateFilename === null) {
			continue;
		  }
		  $label = (string) $form->getLabel();
		  $identity = $extensionName . '->' . lcfirst(pathinfo($templateFilename, PATHINFO_FILENAME));
		  $label = $this->translate((string) $label, $extensionName) ?? $identity;
		  $tca['items'][] = [$label, $identity];
		}
	  }
	  return $tca;
	}

	/**
	 * @codeCoverageIgnore
	 */
	protected function translate(string $label, string $extensionName): ?string {
	  return LocalizationUtility::translate($label, ExtensionNamingUtility::getExtensionName($extensionName));
	}

[grischpel]

Flux 10.0 and VHS 7.0 should both work with TYPO3v11. It's possible that other packages are constraining the allowed versions.

Yes, I made sure that the vendor names and template names matched. So I paid attention to upper and lower case.

The extension identity must be created from your vendor name and the extension name, not the template name. I'm pretty sure you've got it correct, just wanted to mention that again to be totally clear. If your vendor name is Acme and the extension key is awesome_templates then the registration should use Acme.AwesomeTemplates as extension identity.

@NamelessCoder I have this error, if I upgrade Flux to Version 10: #2110

Warning: Undefined array key "native"

[NamelessCoder]

Warning: Undefined array key "native"

You will need to flush the caches via the install tool "Maintenance" module, or delete the var/cache/* folders. TYPO3 caches the available ViewHelper arguments and will not pick up and assign default values of the new arguments until the DI cache is flushed. This is why you get this particular error.