Using block_class module with language module throws $string ("") must be a string

Thanks a lot for reporting @Zigazou. Let's take a look

P.S. Any patch or Merge requests from anyone is welcome 😊

Hi, Zigazou patch seems working fine. Thank you and weolcome on drupal.org.

Same issue here in the same context (update from 2.0.0 to 2.0.2 on Drupal 9.4.5 multilang). However block_class module was already enabled. I get the error in several places: when trying to install a theme (like Seven, Claro, Olivero) or when placing a block on admin/structure/block/list/xx.

Here is the full log

InvalidArgumentException: $string ("") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).
Drupal\locale\LocaleConfigManager->getTranslatableData() (Line: 167)
Drupal\locale\LocaleConfigManager->getTranslatableData() (Line: 145)
Drupal\locale\LocaleConfigManager->getTranslatableDefaultConfig() (Line: 128)
Drupal\locale\LocaleConfigSubscriber->updateLocaleStorage() (Line: 92)
Drupal\locale\LocaleConfigSubscriber->onConfigSave()
call_user_func() (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (Line: 229)
Drupal\Core\Config\Config->save() (Line: 212)
	Drupal\block_class\Service\BlockClassHelperService->blockClassPreSave() (Line: 107)
block_class_block_presave()
call_user_func_array() (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 337)
Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook() (Line: 563)
Drupal\Core\Entity\EntityStorageBase->doPreSave() (Line: 517)
Drupal\Core\Entity\EntityStorageBase->save() (Line: 253)
Drupal\Core\Config\Entity\ConfigEntityStorage->save() (Line: 339)
Drupal\Core\Entity\EntityBase->save() (Line: 607)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 392)
Drupal\Core\Config\ConfigInstaller->createConfiguration() (Line: 263)
Drupal\Core\Config\ConfigInstaller->installOptionalConfig() (Line: 167)
Drupal\Core\Config\ConfigInstaller->installDefaultConfig() (Line: 75)
Drupal\Core\ProxyClass\Config\ConfigInstaller->installDefaultConfig() (Line: 235)
Drupal\Core\Extension\ThemeInstaller->install() (Line: 141)
Drupal\system\Controller\ThemeController->install()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

I can confirm this issue. It appears when saving ANY block!

The patch in #4 sadly won't be able to fix this for existing installations! As confing/install/* files are only used at installation, not for existing installations!

So this also needs an update hook to correct values or a different solution.

Raising priority to critical as this affects any multilingual page and makes it impossible to save blocks!

Any maintainer plans how to fix this for existing installations? Can we safely downgrade to a prior version? Or did the DB schema change already?

As written in #8 I guess that patch won't be able to solve this for existing installations.

But indeed the block_class.settings.yml data doesn't match well with types defined in block_class.schema.yml!
So a separate issue should be opened for that or this should be solved combined with this issue. But as written above, changing the install/block_class.settings.yml will not change anything for existing installation! There it needs an additional update hook to correct values!

The main issue here seems to be within BlockClassHelperService.php around $config->save(); in line 212.
To be honest, it looks very complicated to me what's done there and for example $block_classes_stored is never used after line 193. I think the code in that area needs a closer look from a maintainer, despite this issue ;)
Also I don't really understand why the config is saved several times, which is bad for performance, but I didn't look into this closer...

If commenting out the $config->save(); in line 213, the block saves fine, so I think the issue is in the $config there, which would relate to the patch from #4 fixing this for fresh installations.

debugging returns the following result:

maxlength_block_class_field => integer 255
field_type => string (19) "multiple_textfields"
default_case => string (8) "standard"
allow_only_letters_and_numbers => boolean false
enable_attributes => boolean true
enable_auto_complete => boolean true
qty_classes_per_block => integer 10
items_per_page => integer 50
enable_special_chars => boolean true
qty_attributes_per_block => integer 10
enable_id_replacement => boolean true
weight_attributes => null
weight_class => null
weight_id => null
langcode => string (2) "de"
block_classes_stored => string (7) "{"":""}"

I couldn't find a clear issue in this array, but we must be close to the root cause here.
So until someone fixes this cleanly, commenting out the $config->save(); in line 212 allows you to save the block.

That's enough for me here, over and out ;)

So updating the issue status to needs works

Based on #12 attaching a patch with the workaround

This isn't the final fix, but can help someone until the final fix

The original error seems to be provocate by filter_html_clean_css_identifier = FALSE on config/install/block_class.settings.yml, i've been upgrading from 2.0.0 to 2.0.2 and change manually that line to test and the problem apararently disapeare.

So i think the patch #4 could fix the problem.

If that's the case, can anyone tell me, why a config file from config/install/ affects existing installations?
I'd still expect this needs an update hook or is there any "magic" in the module?

So to resolve this, the maintainer and community should please

• test if #4 fixes the issue and why it was introduced to prevent a further regression
• compare the default values from the settings.yml to match the schema
• find out why config/install change affects existing sites, while https://www.drupal.org/docs/creating-custom-modules/step-by-step-tutoria... says
  

  This value will be used when the module is installed. So to verify, uninstall and install your module. And when you add your block again to a region, you should see the default value.

• read through the other comments to create follow-ups

I think config/install/ is used as base by system while the yml file does not exists as a file in the file system only in the database. That theory applies in my case.

I don´t know if config/install/ is always use by system when individual block settings are manage or when translations are updated.

So that is the cause of the error that has having me running around in circles. It was driving me crazy that i could not find the error.

I'm not sure if it means anything, but running 2.0.2 on a backup database does NOT give the issue. The backup is about a day before i upgraded to 2.0.2.

patch #14 is ok

#14 is not okay and just a workaround that should not be used in production! Please don't RTBC such!

2.x crashes for me on 9.4.5

so I downgraded to 1.x , everything is good on 1.x

New version 2.0.3 released with the fix

$ composer require 'drupal/block_class:^2.0'

Thank you so much everyone for your contribution

2.0.3 works for me. All blocks can be saved now. Thank you!
Drupal 9.4.5
PHP 8.1.8

@zsuffad I'm happy to know that 😊

Thank you so much, zsuffad. Have a great day