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

Merge Requests

More

Recent comments

🇪🇸Spain plopesc Valladolid

Added new iteration to latest MR including code from #12

🇪🇸Spain plopesc Valladolid

@jonathan1055 Thank you for taking a look into this.

It is not necessary to custom build the callable string concatenating the $module and the $hookName variables when we already have the $hook variable that does it for you.

Example for procedural hooks:

  • $module = 'my_module'
  • $hookName = 'hook'
  • $hook = '\my_module_hook'
  • $module . "_" . $hookName = 'my_module_hook'

There is no difference and hook is invoked because the custom variable represents the same function as $hook.

Example for OOP hooks:

  • $module = 'my_module'
  • $hookName = 'hook'
  • $hook = [
    '\Drupal\my_module\Hook\MyModuleHooks',
  • 'hook',

    ]

  • $module . "_" . $hookName = 'my_module_hook'

The custom variable points to an undefined function instead of the actual method that implements the hook.

🇪🇸Spain plopesc Valladolid

Great job!

It seems that the MR has conflicts now, though.

🇪🇸Spain plopesc Valladolid

Thank you for the heads up!

Tests are green again.

Those changes were necessary to make 3.0.x fully compatible with D11. We had some hook conflicts between recurring_events and recurring_events_views modules when views hooks were declared in the recurring_events.views.inc file.

🇪🇸Spain plopesc Valladolid

@pfrenssen Are those items flagged against last 3.0.x version?

We're already using the module in D11 and it seems the mentioned lines do not contain the problematic code.

🇪🇸Spain plopesc Valladolid

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

🇪🇸Spain plopesc Valladolid

Looks good! This is a nice improvement that will be very helpful.

🇪🇸Spain plopesc Valladolid

Looks good to me!

Thank you for keeping the module up to date.

🇪🇸Spain plopesc Valladolid

Created MR that allows to execute both OOP and traditional procedural hooks.

🇪🇸Spain plopesc Valladolid

plopesc created an issue.

🇪🇸Spain plopesc Valladolid

Can confirm that it works like a charm for us as well! :)

Woul be great to have it merged and included in a future release of this useful module.

🇪🇸Spain plopesc Valladolid

MR looks good added suggestion about hook class naming conventions.

🇪🇸Spain plopesc Valladolid

Sounds good to me.

Initially I reverted it back to 8.1 to give support to D10.3. Since 10.3 supports 8.3, sites taht want to move to 3.x will have to move to PHP 8.3 first.

Thank you for the heads up!

🇪🇸Spain plopesc Valladolid

MR created.

Small compatibility tweaks on top of the changes made in Make Commerce Fraud Drupal 10 compatible Active .

🇪🇸Spain plopesc Valladolid

Created MR with suggested changes. Could you please confirm that works as expected?

🇪🇸Spain plopesc Valladolid

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

🇪🇸Spain plopesc Valladolid

Do not worry about branches. I'll take care of them. Thank you!

🇪🇸Spain plopesc Valladolid

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.

🇪🇸Spain plopesc Valladolid

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

🇪🇸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.

Production build 0.71.5 2024