Fixed Installer difference in _output vs _data installer; Extend custom field types causes error

Xon

Well-known member
Affected version
2.1.4
When installing via the CLI with a _output folder, this error occurs if a custom field type is added to a thread custom fields;
Code:
In AbstractField.php line 125:

  [ErrorException]
  [E_NOTICE] Undefined index: message


Exception trace:
 () at /var/www/html/src/XF/Repository/AbstractField.php:125
 XF::handlePhpError() at /var/www/html/src/XF/Repository/AbstractField.php:125
 XF\Repository\AbstractField->getFieldCacheData() at /var/www/html/src/XF/Repository/AbstractField.php:142
 XF\Repository\AbstractField->rebuildFieldCache() at /var/www/html/src/XF/Job/CoreCacheRebuild.php:34
 XF\Job\CoreCacheRebuild->run() at /var/www/html/src/XF/Job/Manager.php:253
 XF\Job\Manager->runJobInternal() at /var/www/html/src/XF/Job/Manager.php:195
 XF\Job\Manager->runJobEntry() at /var/www/html/src/XF/Job/Manager.php:146
 XF\Job\Manager->runUnique() at /var/www/html/src/XF/Cli/Command/JobRunnerTrait.php:30
 XF\Cli\Command\Development\RebuildCaches->runJob() at /var/www/html/src/XF/Cli/Command/JobRunnerTrait.php:13
 XF\Cli\Command\Development\RebuildCaches->setupAndRunJob() at /var/www/html/src/XF/Cli/Command/Development/RebuildCaches.php:23
 XF\Cli\Command\Development\RebuildCaches->execute() at /var/www/html/src/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /var/www/html/src/XF/Cli/Command/Development/RequiresDevModeTrait.php:20
 XF\Cli\Command\Development\RebuildCaches->run() at /var/www/html/src/XF/Cli/Command/Development/Import.php:84
 XF\Cli\Command\Development\Import->execute() at /var/www/html/src/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /var/www/html/src/XF/Cli/Command/Development/RequiresDevModeTrait.php:20
 XF\Cli\Command\Development\Import->run() at /var/www/html/src/XF/Cli/Command/AddOnActionTrait.php:156
 XF\Cli\Command\AddOnSubAction->importAddOnData() at /var/www/html/src/XF/Cli/Command/AddOnSubAction.php:69
 XF\Cli\Command\AddOnSubAction->execute() at /var/www/html/src/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /var/www/html/src/vendor/symfony/console/Application.php:960
 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/src/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /var/www/html/src/vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at /var/www/html/src/XF/Cli/Runner.php:63
 XF\Cli\Runner->run() at /var/www/html/cmd.php:16

xf:addon-sub-action [--k K] [--] <id> <action>


Running clean up tasks...

In AbstractField.php line 125:

  [ErrorException]
  [E_NOTICE] Undefined index: message


Exception trace:
 () at /var/www/html/src/XF/Repository/AbstractField.php:125
 XF::handlePhpError() at /var/www/html/src/XF/Repository/AbstractField.php:125
 XF\Repository\AbstractField->getFieldCacheData() at /var/www/html/src/XF/Repository/AbstractField.php:142
 XF\Repository\AbstractField->rebuildFieldCache() at /var/www/html/src/XF/Job/CoreCacheRebuild.php:34
 XF\Job\CoreCacheRebuild->run() at /var/www/html/src/XF/Job/Manager.php:253
 XF\Job\Manager->runJobInternal() at /var/www/html/src/XF/Job/Manager.php:195
 XF\Job\Manager->runJobEntry() at /var/www/html/src/XF/Job/Manager.php:164
 XF\Job\Manager->runById() at /var/www/html/src/XF/Cli/Runner.php:134
 XF\Cli\Runner->postExecutionCleanUp() at /var/www/html/src/XF/Cli/Runner.php:64
 XF\Cli\Runner->run() at /var/www/html/cmd.php:16

The error is caused by this;
PHP:
foreach ($fields AS $fieldId => $field)
{
   $fieldTypes = $this->getFieldTypes();
   
   $cache[$fieldId] = $field->toArray() + [
      'title' =>     $field->getPhraseName(true),
      'description' => $field->getPhraseName(false),
      'type_group' => $fieldTypes[$field->field_type]['type']
   ] + $this->getAdditionalCacheData($field);
...

Problems in this code;
  • getFieldCacheData is called during the import process when the add-on is disabled via the is_processing flag.
  • getFieldTypes is called in a loop
  • The line $fieldTypes[$field->field_type] assumes the type always exist, which may not be the case if the field type is added by an add-on and the code is called during a rebuild. Simply skipping that field type in the cache building is probably the only sane solution.

The only occurs via the CLI with an _output, it doesn't happen if the installer installs from _data (CLI/Web)
 
Thank you for reporting this issue. It has now been resolved and we are aiming to include it in a future XF release (2.1.5).

Change log:
Prevent an undefined index error in some situations when rebuilding field cache data.
Any changes made as a result of this issue being resolved may not be rolled out here until later.
 
Top Bottom