Seems like it's a core issue.
It only occurs when installing using a profile.
If I export the config of the website and reinstall using the minimal profile and an existing config, the issue doesn't occurs.
Still looking around in the install.core.inc code and if it's confirmed, I'll open a core issue.
This may be related to this core issue :
#2852557
📌
Config export key order is not predictable, use config schema to order keys for maps
Fixed
Fixed the issue in MR !17
Issue occurred on Drupal 9.5.11 after an update of the module from 3.3.0 to 3.6.0.
Patch in comment #3 fixed the issue.
The .info.yml notation of "project:module". The project part at runtime is completely ignored. "drupal:action" and "action:action" for Drupal is really just "action". You could write "foobar:action" and Drupal is still happy. Modules don't actually have a project group/namespace. The prefix is just for drupal.org to translate it into composer dependencies.
Didn't know that, thanks for the heads up !
So what is your suggestion here to move on ?
Fixed in MR !60 for branch 4.0.x
Needs to be done on the 4.0.x branch
oldeb → created an issue. See original summary → .
Fixed in #3494549
Fixed. And the D10 compatibility is now restored.
Still poking around to check if everything is working proberly.
Does it? Earlier versions of core have a replace statement for this.
Yes because the module now require the contrib Action module which is not compatible with Drupal 10.2 and below.
I recommend not using an open ended version compatibility. This can't be undone, this version will forever claim to be compatible with any core version.
Your are right, I changed the version requirements.
Made the quick change, looks like everything is working as intended after a cache clear.
Warning : this change break the compatibility with Drupal versions 10.2 and below !
I confirm that when displaying a formatter inside a component slot, neither of field_formatter_range or nomarkup is working.
Fixed in 4.0.1
Duplicate of 🐛 The module no longer works with Drupal 10 Active
I have similar issues when upgrading from 4.0.0 to 4.0.1 on Drupal 10.3.
Fatal error: Declaration of Drupal\Core\Entity\Plugin\Validation\Constraint\EntityHasFieldConstraint::getDefaultOption() must be compatible with Symfony\Component\Validator\Constraint::getDefaultOption(): ?string in /app/app/web/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/EntityHasFieldConstraint.php on line 50
PHP Fatal error: Declaration of Drupal\ckeditor5\Plugin\Validation\Constraint\ToolbarItemDependencyConstraint::getRequiredOptions() must be compatible with Symfony\Component\Validator\Constraint::getRequiredOptions(): array in /app/app/web/core/modules/ckeditor5/src/Plugin/Validation/Constraint/ToolbarItemDependencyConstraint.php on line 39
Downgrading to 4.0.0 fixes the problem.
Both mentionned modules seems to work as intended.
The only thing I noted is that when using a field formatter to render the field inside component the slot, the "Remove field markup" option is not there but that don't seems like a bug to me.
This patch works also for me.
Changing to RTBC.
Do you have any update ?
The issue in fact is that the container is called from a static method which is not aware of the container.
What I think we should do :
- move the fixutres data (current static functions) to yaml files
- avoid calling the Url class in the fixtures data (if possible)
- call the Url class dynamically in the test method (if required)
- mock the pathValidator service
If possible, fix an issue in LinksPropTypeNormalizationTest where 2 tests where disabled (commented) because they need the service container:
If you need the service container then you need a KernelTest instead of a UnitTest.
Should I change the whole test class into a KernelTest or should I split the it into 2 tests (1 unit test and one kernel test) ?
Big +1 !
Created a new branch and rebased everything with the help of @Grimreaper.
Fixed an issue with the slots being arrays instead of objects.
oldeb → changed the visibility of the branch 3439414-2.0.0-alpha2-add-unit to hidden.
oldeb → changed the visibility of the branch 3439414-2.0.0-alpha2-add-unit-source-plugin to hidden.
Finished, MR is blocked because ComponentPluginManager.php changed on both sides ...
Rebase is not helping :/
Progress status :
- Canonicalizer ✔
- CompatibilityChecker ✔
- ReferencesResolver => WIP
- StreamWrapper ✔
When an incorrect scheme is passed : an error is thrown. This should never happen since it's checked by the ComponentPluginManager before calling file_get_contents and, like you said, the streamwrapper is always called with the correct scheme because of the tags in the service definition.
When an incorrect plugin is passed, the file_get_contents return a string with an empty array : "[]"
So there is no error, the schema is just empty.
Check for correct scheme is already done in the ComponentPluginManager::annotateProps/a> method.
PropType availiblity is done by the PluginManagerBase::createInstance method.
Patch is applying correctly but I'm not able to test that everyting is working properly.
Added the following tests :
- PropTypeAdapterPluginManager::guessFromSchema()
- PropTypePluginManager::guessFromSchema()
Done as asked in #7
Test are passing correctly now
- Fixed issue by overriding SDC's alterDefinition method in our own ComponentPluginManager.
- Fixed error in getCategories when no group is defined
- Adding sort on getGroupedDefinitions to have the group/categories in the same order as getCategories
Added basic kernel tests for the ComponentPluginManager but following error is making them fail :
PHPUnit\Framework\Exception: PHP Deprecated: basename(): Passing null to parameter #1 ($path) of type string is deprecated in /var/www/html/web/core/lib/Drupal/Core/Theme/ComponentPluginManager.php on line 316
Deprecated: basename(): Passing null to parameter #1 ($path) of type string is deprecated in /var/www/html/web/core/lib/Drupal/Core/Theme/ComponentPluginManager.php on line 316
PHP Deprecated: basename(): Passing null to parameter #1 ($path) of type string is deprecated in /var/www/html/web/core/lib/Drupal/Core/Theme/ComponentPluginManager.php on line 316
Deprecated: basename(): Passing null to parameter #1 ($path) of type string is deprecated in /var/www/html/web/core/lib/Drupal/Core/Theme/ComponentPluginManager.php on line 316
Also wondering if this may be a side effect of https://www.drupal.org/node/3298550 →
Nope, I tried and nothing changed.
Also seeing a commit in Drupal 10.2.5: https://git.drupalcode.org/project/drupal/-/commit/321dc38ac602fc2de74de...
I can't figure out how to use that ...
I also tried access the data using xpath but it's not working either ...
Tests are failing due to another unrelated issue : #3437169
@Grimreaper what's your take on this ?
Added requirement to composer.json
This change broke my D10 upgrade.
There is a compatibility issue with the address contrib module → , in the AddressItem field type they are decraring a "Country" constraint and giving a "availableCountries" option which they collide with this change and provoking the following error :
Symfony\Component\Validator\Exception\InvalidOptionsException: The options "availableCountries" do not exist in constraint "Drupal\field_validation\Plugin\Validation\Constraint\CountryConstraint". in Symfony\Component\Validator\Constraint->normalizeOptions() (line 180 of /app/vendor/symfony/validator/Constraint.php).
I think we should find another id for the CountryConstraint.