I was facing the same problem here with a component with no props has made a similar approach to solve the issue, but I didn't even create the $context if there is no $schema->properties, since the $context is only used to set the props.
What do you think?
Best!
Hi there!
I was trying to "convert" a component that I was using with the module Component do Single Directory Component and was facing the same problem, but there are two thing to consider:
1) The problem here is not with the sdc_block module;
2) To bypass this problem, add some prop to your component. SDC Components with no props are causing this issue;
I was debugging and the problem I found is in the cl_editorial module, docroot/modules/contrib/cl_editorial/src/Form/ComponentInputToForm.php file, line 62.
When there are no props, the $context variable returns null and it breaks the code when calling:
$element['props'] = $this->formGenerator->transform($schema, $context);
I'll add the details I found in the proper place, in an issue related to cl_editorial module.
Best!
Hi guys!
I know the issue is old, but recently we upgraded one of our clients from D8.5 to D10.1 and we discovered this problem yesterday.
One thing I noticed, this is not a Pathauto module issue. This is a path_alias (core) problem.
I tried to assign a custom path manually, with Pathauto disabled, but the error remains. The only way we can "bypass" this error is not assigning a custom path.
The solution is really to alter the tables (path_alias and path_alias_revision), directly or with hook update, but I guess that new Drupal installations already have the tables created correctly.
So, for those that are upgrading their Drupal installations from <8.7, this is a useful issue/thread, even being unrelated to pathauto.
Thank you all!
I was still getting this error with 1.0.0-rc4 (Drupal 9.5.9 / PHP 8.1.24):
Error: Class "Drupal\component\Plugin\Derivative\DeriverBase" not found em include() (line 13 of /docroot/modules/contrib/component/src/Plugin/Derivative/ComponentBlockDeriver.php)
#0 /vendor/composer/ClassLoader.php(576): include()
#1 /vendor/composer/ClassLoader.php(427): Composer\Autoload\{closure}('/mnt/www/html/s...')
#2 [internal function]: Composer\Autoload\ClassLoader->loadClass('Drupal\\componen...')
#3 /docroot/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(217): class_exists('Drupal\\componen...')
#4 /docroot/core/lib/Drupal/Core/Plugin/Discovery/ContainerDerivativeDiscoveryDecorator.php(20): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDeriverClass(Array)
#5 /docroot/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(99): Drupal\Core\Plugin\Discovery\ContainerDerivativeDiscoveryDecorator->getDeriver('component', Array)
#6 /docroot/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)
So I created this patch. Maybe it's not right, but due the ambiguity with the project name and the core Component class, it seems to solve the problem.
Best! (sorry if should be done through a new issue or in other way)
I still guess there is a false positive, since my path was s3://public/filename.ext and not public://filename.ext.
If anyone in the S3FS configuration form uses "public" as the name of their public folder or "private" as the name of their private folder, the check is going to throw the exception.
If this is not allowed, the form validation should check and avoid this.
Best regards!
Hi there!
What's the real reason to have this condition in this trait?
I recently upgraded from 8-beta3 to 3.3, as part of my Drupal core upgrade (D10) and I'm facing this issue.
What happens is that when you configure the fields public folder with the value "public" or the private field with the value "private", it enters the condition and throws the exception.
I had to rename the folder from public to whatever, like: public2 ou pub, to solve without any code change.
The site was working fine using the module beta version without this trait. So I'm thinking here if I move on without any patch (if it's working as it should) or we must consider patching this.
Do you need any more information on this regard?
Can't apply the patch, even requiring the alpha3 version of the module.
Is there anyone working on this module yet?
Best regards!
Hi there!
Are you going to add this the rc-branches too?
Running here with 1.0.0-rc4 and the use statement is still missing.
Best!