plopesc → created an issue.
MR created.
Small compatibility tweaks on top of the changes made in ✨ Make Commerce Fraud Drupal 10 compatible Active .
MR merged and released v2.1.1
https://www.drupal.org/project/path_redirect_import/releases/2.1.1 →
Thank you!
Created MR with suggested changes. Could you please confirm that works as expected?
plopesc → created an issue.
Do not worry about branches. I'll take care of them. Thank you!
As mentioned in #8 🐛 Compatibility with Migrate Tools 6.0.x-dev Active , the patch should include changes in composer and info files to ensure that new module version including this change will work with migrate_tools ^6.1.0.
It's hard to define a tighter dependency because we don't have the exact information about when the parent module will introduce new changes in the parent class constructor.
MR created
plopesc → created an issue.
Hello, we are experiencing the reported bug and the patch above solved it for us. Steps to reproduce:
Create a Taxonomy Exposed filter. Vocabulary should have multiple terms and ensure that it is not sorted alphabetically.
Configure BEF as checkboxes and sort the options
Check the view and confirm that items are not sorted properly
Core Version: 10.4.7
BEF Version: 7.0.5
MR merged.
Since many of the issues related to 🌱 Roadmap to modernize code for D11 + PHP 8.3 Active modified this file last days, this issue ended up in a single line MR :)
MR merged
MR is green
MR merged
MR replacing \Drupal calls reported by PHPStan (Remaining ones in PHP classes should still be there).
While I was there, fixed the outstanding PHPStan issues, so PHPStan pipeline is green now as well!
Update roadmap
MR merged!
It seems the issue is not related to json_api, but related to the computed field carinality.
That's solved in 🐛 Field cardinality is not preserved on inheritance Needs review
This one seems outdated. Module relies on the new Gitlab CI.
Marking as duplicated of 🐛 Destination entity does not reflect a new inherited field until its entity form is submitted Active
Created new MR to address the constructor architecture.
Note that from constructors are not making use of readonly since that's problematic due to form object serialization process.
MR merged.
All the D11 required changes are made in the current MR. We could iterate on the remaining items, most of them related to \Drupal invocations that should be replaced with proper DI.
Submodule moved to its own namespace in https://www.drupal.org/project/group_recurring_events_series →
MR created.
I would declare the service as an optional parameter in the formatter constructor.
Then in create() method, use the NULL_ON_INVALID_REFERENCE class constant to use NULL instead of throwing an exception if the service is missing.
Finally, the isApplicable() method will define the formatter as available if the module is installed.
Another option, probably simpler would be to define the daterange_compact module as formatter provider. Hence will be discoverable if only the provider is installed.
Already addressed as part of 📌 Make 3.x branch compatible with Field Inheritance 3.0.0 Active . Thank you!
MR merged. Thank you!
MR merged. Thank you!
Thank you for bringing this one.
This change was already implemented as part of 📌 Make 3.x branch compatible with Field Inheritance 3.0.0 Active . It should be possible to use FI 3.0.x in the latest -dev version of this module.
Patch looks good, but I would prefer not to add a new dependency for all the module installations.
It might be declared as a soft dependency where the formatter is only available if the service is available as well?
Patch in #6 applied against 2.0.x and 3.0.x branches.
MR merged and cherry-picked into 3.0.x. Thank you!
MR merged. Thank you for your review!
Nice suggestion. It works great.
Merged into 2.0.x and cherry-picked into 3.0.x
This feature has been provided through the new module Recurring Events Scheduler ( https://www.drupal.org/project/recurring_events_scheduler → )
Marking as Fixed to give proper credit to all the involved folks.
Postponing on 📌 Make 3.x branch compatible with Field Inheritance 3.0.0 Active since some of the bits there are required to make the tests green.
MR is green. Ready for review!
Merged MR that checks the field existence before a¡making any DB update.
plopesc → created an issue.
We can mark it as fixed since 3.0.0 was released yesterday.
Thank you all!
MR merged.
As you mention in the issue, the way how relationships are stored in 2.x branch require to explicitly define all the Field Mappings.
However, in 3.x branch, a new way to define the relationships has been defined in 📌 Allow to define entity based relationships to allow implicit assignments Active .
Migrating to 3.x and defining Entity Mappings instead of Field Mappings would solve the described scenario.
Thank you!
MR created
MR merged!
IS Updated
After
📌
Store relation with the parent entity in the database instead of the State API
Active
, the Field Inheritance form is a field widget. And we can use the widget visibility rules for this.
Also, other contrib modules like Field Permissions can help to add more granularity.
After 📌 Store relation with the parent entity in the database instead of the State API Active this is not necessary anymore. The Field Inheritance information is stored at entity level and the upstream Drupal subsystems take care of it.
We can work on this one since 📌 Store relation with the parent entity in the database instead of the State API Active has been already merged.
MR merged.
Thank you all for your help here!
Create an issues-fixed list for stable release using the drupalorg-cli tool.
https://drupal-mrn.dev/ is a simple alternative that will make your life easier :)
Tested locally and works as expected.
Made some minor updates in the MR to reduce boilerplate code that can be removed once the module only supports PHP 8.1+
Hope to get a D11 release soon!
Code looks very good, tests are green and tested locally with no issues.
Marking as RTBC.
Thank you!
Feedback has been addressed and the new 3rd level item functionality works according to previous comments.
I would say this can be marked as RTBC now.
Checked and tested locally code in MR 12148 and it looks good to me.
The manipulator approach adds useful flexibility for the future without significantly impacting the current codebase — I think it's a solid direction.
I’ve added a couple of comments to the MR, but this is very close to being ready!
MR merged
Documentation fixed. Thank you!
Thank you for bringing this up!
MR created.
Description field added to v3! 🎉
As part of this MR, the schema architecture has been updated.
Functional MR created