Valladolid
Account created on 24 April 2008, about 17 years ago
  • Senior PHP / Drupal Developer at Lullabot 
#

Merge Requests

More

Recent comments

🇪🇸Spain plopesc Valladolid

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 :)

🇪🇸Spain plopesc Valladolid

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!

🇪🇸Spain plopesc Valladolid

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

🇪🇸Spain plopesc Valladolid

This one seems outdated. Module relies on the new Gitlab CI.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

plopesc made their first commit to this issue’s fork.

🇪🇸Spain plopesc Valladolid

plopesc made their first commit to this issue’s fork.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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?

🇪🇸Spain plopesc Valladolid

MR merged and cherry-picked into 3.0.x. Thank you!

🇪🇸Spain plopesc Valladolid

plopesc made their first commit to this issue’s fork.

🇪🇸Spain plopesc Valladolid

MR merged. Thank you for your review!

🇪🇸Spain plopesc Valladolid

Nice suggestion. It works great.

Merged into 2.0.x and cherry-picked into 3.0.x

🇪🇸Spain plopesc Valladolid

plopesc made their first commit to this issue’s fork.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

Merged MR that checks the field existence before a¡making any DB update.

🇪🇸Spain plopesc Valladolid

We can mark it as fixed since 3.0.0 was released yesterday.

Thank you all!

🇪🇸Spain plopesc Valladolid

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!

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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 :)

🇪🇸Spain plopesc Valladolid

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!

🇪🇸Spain plopesc Valladolid

Code looks very good, tests are green and tested locally with no issues.

Marking as RTBC.

Thank you!

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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!

🇪🇸Spain plopesc Valladolid

Documentation fixed. Thank you!

🇪🇸Spain plopesc Valladolid

Thank you for bringing this up!

🇪🇸Spain plopesc Valladolid

plopesc made their first commit to this issue’s fork.

🇪🇸Spain plopesc Valladolid

plopesc created an issue.

🇪🇸Spain plopesc Valladolid

Description field added to v3! 🎉

As part of this MR, the schema architecture has been updated.

🇪🇸Spain plopesc Valladolid

Functional MR created

🇪🇸Spain plopesc Valladolid

Nice feature for 3.x branch

🇪🇸Spain plopesc Valladolid

Hello @avpaderno,

I have not heard from the original maintainer along these last 15 days.

I'm still interested in moving forward this module.

Moving the issue to Needs Review to confirm if any other action item is necessary from my side.

Have a great week.

🇪🇸Spain plopesc Valladolid

Postponing on 📌 Store relation with the parent entity in the database instead of the State API Active . Module architecture changes there will affect how tests might need to be addressed.

🇪🇸Spain plopesc Valladolid

Hello @pfrenssen!

I really like the idea brought in this issue. Last week I started to work on a similar upgrade path for Field Inheritance module. You can see how it looks in 🌱 [META] 3.0.0 Plan Active .

Key part of the upgrade would be to integrate the Field Inheritance architecture changes introduced in 📌 Store relation with the parent entity in the database instead of the State API Active , which you actually suggested a while ago.

I'm wondering if we could define a similar approach for Recurring events, where a new 3.x branch is used to define Drupal 10.3+ releases based on Field Inhetance 3.x.

The reason why I preferred to use 10.3 instead of directly a new 11.x branch was to give sites the opportunity to have an stable environment with the new Field Inheritance architecture before moving to 11.x. This approach was taken by Drupal Commerce and the 3.x version. That was very convenient for us in other Commerce based projects, where the migration was taken in 2 steps to reduce friction points.

I'm open to help and collaborate with the migration of this module, given that it's a key requirement in some of our projects. At the same time a review and test of the new FI architecture would be very helpful to ensure that both modules are aligned.

Production build 0.71.5 2024