Account created on 19 June 2009, almost 15 years ago
  • Senior Drupal developer at DropsolidΒ  …
#

Merge Requests

More

Recent comments

πŸ‡ͺπŸ‡ΈSpain akalam

Uploaded a new version of the patch to use EntityContextDefinition instead of ContextDefinition, otherwise there's an error:

AssertionError: assert(!str_starts_with($data_type, 'entity:') || $this instanceof EntityContextDefinition) in core/lib/Drupal/Core/Plugin/Context/ContextDefinition.php

πŸ‡ͺπŸ‡ΈSpain akalam

I can't reproduce the bug anymore following the steps from #46 on drupal 10.2

πŸ‡ͺπŸ‡ΈSpain akalam

This looks like a duplicate of πŸ› Cache tags from Computed fields do not bubble up to Entity render array Fixed , which has been committed on 10.2

πŸ‡ͺπŸ‡ΈSpain akalam

Re-rolled against core 10.2

πŸ‡ͺπŸ‡ΈSpain akalam

Re-rolled against core 10.2

πŸ‡ͺπŸ‡ΈSpain akalam

I've created a MR rerolling the patch from #33 to the latest Drupal 11.x release. I'm attaching also a static patch to apply safely from composer

πŸ‡ͺπŸ‡ΈSpain akalam

akalam β†’ made their first commit to this issue’s fork.

πŸ‡ͺπŸ‡ΈSpain akalam

This module is intended to be used until the patch on πŸ“Œ Allow synced Layout override Translations: translating labels and inline blocks Needs work gets committed to core, so I wonder this issue can be closed, as the incompatibility seems natural.

πŸ‡ͺπŸ‡ΈSpain akalam

Here's a patch adding back the counter depending on the facet configuration.

πŸ‡ͺπŸ‡ΈSpain akalam

This is great! the patch is displaying the facets in a hierarchy manner. However the counter disappear when the patch is applied for both hierarchical and non hierarchical facets.
I will take a look on and try to provide a fix.

πŸ‡ͺπŸ‡ΈSpain akalam

I've found when you have a menu link derivative, and you are using an TranslatableEntityLabelMarkup as title, the title gets overridden by the static_menu_link_overrides, transformed into a string and not displaying the proper translated text.

I'm adding a patch with a fix so the title override skips in case it has been defined as a TranslatableEntityLabelMarkup.

Note: I've found the patch doens't apply anymore for the 11.x branch, so I'm uploading it as it is, just introducing the change mentioned above. The patch is applying on 10.1.x

πŸ‡ͺπŸ‡ΈSpain akalam

This issue exists on 1.x branch as well. The patch is applying and solving the issue on that version too

πŸ‡ͺπŸ‡ΈSpain akalam

Added a new commit to fix an error because the entity.entity_subqueue.add_form doesn't have the entity_subqueue as route parameter.

πŸ‡ͺπŸ‡ΈSpain akalam

Hi @artemboiko the problem with patches from MR is that they are dynamic, they are generated automatically from the MR and the MR can change at anytime. It can lead on your site being deployed introducing untested code, or even the patch not applying without prior notification. There's a big discussion on this topic on the following issues: πŸ› GitLab Merge Requests Unable to Generate Incremental Patch Files Active and #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces β†’

πŸ‡ͺπŸ‡ΈSpain akalam

Static patch updated with latest changes from MR

πŸ‡ͺπŸ‡ΈSpain akalam

I'm uploading a static patch to apply from composer

πŸ‡ͺπŸ‡ΈSpain akalam

Thanks for the MR @artemboiko! I'm still seeing the links for the operations which the user don't have access on the "Entity Queue" tab on entities, so I'm adding a new commit to fix it.
In the commit I'm checking the access to the url instead of checking the access to the entity operation. That's because the access could had been extended by other modules (like the group_entityqueue for example or custom access requirements) and by checking the access to the url will work properly on all scenarios.

πŸ‡ͺπŸ‡ΈSpain akalam

akalam β†’ made their first commit to this issue’s fork.

πŸ‡ͺπŸ‡ΈSpain akalam

Uploading a patch to apply easily from composer

πŸ‡ͺπŸ‡ΈSpain akalam

akalam β†’ made their first commit to this issue’s fork.

πŸ‡ͺπŸ‡ΈSpain akalam

I've created a MR with a fix. Not sure if it's the optimal solution but it works.

πŸ‡ͺπŸ‡ΈSpain akalam

Created a MR with the initial implementation of the new "Combine Ldap attributes" view filter

πŸ‡ͺπŸ‡ΈSpain akalam

I'm uploading a patch based on the MR to apply safety from composer

πŸ‡ͺπŸ‡ΈSpain akalam

Patch on #5 is also fixing the integration with other modules (I'm working with layout_builder_lock for example), because it's adding third_party_settings to the Section as well, already supported in core since 8.7: #2942661: Sections should have third-party settings β†’

πŸ‡ͺπŸ‡ΈSpain akalam

The MR !5263 worked for me in Drupal 10.1. Uploaded a static patch to apply safety from composer.

πŸ‡ͺπŸ‡ΈSpain akalam

Created a MR and uploaded a static patch to apply easily from composer.

πŸ‡ͺπŸ‡ΈSpain akalam

The MR 165 wasn't solving the issue. I created a new MR with a different approach. The problem seems to be during the creation of the view, not during the creation of the facet. Seems like the depends on the view (this is correct) but view is having the facets as exposed filters so the facet source is being initialized at that time. The new approach is to skip the initialization during the config import.

πŸ‡ͺπŸ‡ΈSpain akalam

Created a MR against 3.0.x branch, and uploading a plain patch version to apply safely via composer.

πŸ‡ͺπŸ‡ΈSpain akalam

I'm uploading a patch based on the latest version of the MR to ensure it can be applied safety via composer. Tested and working fine in Drupal 10.1.7. Thanks!

πŸ‡ͺπŸ‡ΈSpain akalam

Uploading a patch based on the MR 19

πŸ‡ͺπŸ‡ΈSpain akalam

The MR looks good to me. Thanks! I'm uploading a static patch based on the MR 14 to use it easily with composer.

πŸ‡ͺπŸ‡ΈSpain akalam

The patch on #3 is working fine in case there's a single exposed form block. In case there are many instances it will replace only one of them. I'm adding here a modified version using data-drupal-selector instead of the id as selector for the replacement.

πŸ‡ͺπŸ‡ΈSpain akalam

I have tested some of the patches attached in this issue (#84, #86 and #93) and all of them work with ajax disabled. Having 2 exposed forms with ajax enabled avoid the exposed form block from being replaced (both don't get replaced). Without the patch at least one of the blocks get replaced but with the patch none of them.

πŸ‡ͺπŸ‡ΈSpain akalam

Finally, our issue was coming from the following patch: https://www.drupal.org/project/drupal/issues/2605218#comment-15002530 πŸ› Views Block Display skips preBlockBuild() call on ajax rebuild Needs work

After applying the latest version of the MR on πŸ› Views Block Display skips preBlockBuild() call on ajax rebuild Needs work the issue went away!

πŸ‡ͺπŸ‡ΈSpain akalam

We have personally found this issue when trying to update a view to use facets v3 as exposed filters and ajax enabled. The view have 7 exposed filters (6 of them are facets) and 1 exposed sorting criteria. The error happens after changing the filters a few times (not too many), for example, applying the filters one by one.

πŸ‡ͺπŸ‡ΈSpain akalam

I can confirm the commit on the issue πŸ“Œ Compress ajax_page_state Fixed helps by reducing the size of the request uri, but doesn't solve the duplication when consecutive ajax calls get triggered on a Drupal 10.1 instance.

πŸ‡ͺπŸ‡ΈSpain akalam

The MR doesn't solve the issue and is changing the indentation wrongly. There's a working patch with a proper solution: πŸ› Library detection warnings when using contrib version of CKEditor 4 Needs review

πŸ‡ͺπŸ‡ΈSpain akalam

The MR is correct because the $hex variable is a string so should use "." to concat. I fixed a wrong format with the if closing bracket.

πŸ‡ͺπŸ‡ΈSpain akalam

Under some circumstances the facet_link value is an absolute URL so the ajax request fails with a 500 error. Here is a patch fixing it.

πŸ‡ͺπŸ‡ΈSpain akalam

Patch on #185 is working fine unless the site is installed in a subdirectory. I'm adding a new patch covering that use case.

πŸ‡ͺπŸ‡ΈSpain akalam

Patch on #34 doesn't work on bootstrap_styles 1.x because the code depends on ResponsiveTrait which is only available on the 2.0.x branch

πŸ‡ͺπŸ‡ΈSpain akalam

I created a MR with the changes to ensure "search" fields work in the same way as text fields

πŸ‡ͺπŸ‡ΈSpain akalam

I found after applying patches #11 and #12 the config export is fixed but the config import started to fail. Here is a single patch combining both patches and adding a fix for the config import

πŸ‡ͺπŸ‡ΈSpain akalam

I'm adding support for the dropdown widget based on the #67 patch. Sorry for not providing an interdiff but it's giving me a whitespace related error.

During testing I found something that might be an issue. The apply button on the facet summary is only visible if there's at least one facet activated on the facets summary configuration. As consequence, it's not possible to create a facet summary block to display only the apply button, without the information of the selected facet values.

πŸ‡ͺπŸ‡ΈSpain akalam

MR rerolled against latest 1.x version

πŸ‡ͺπŸ‡ΈSpain akalam

MR updated with the latest changes from 8.x-1.x branch

πŸ‡ͺπŸ‡ΈSpain akalam

Rerolled #3 against latest 1.0.x release

πŸ‡ͺπŸ‡ΈSpain akalam

Rerolled #29 against latest 1.0.x version

πŸ‡ͺπŸ‡ΈSpain akalam

Rerolled #29 against latest 1.x release

πŸ‡ͺπŸ‡ΈSpain akalam

Hello @tunic.

I'm setting you as maintainer so you can contribute on the D10 migration. The quick process is because you where already contributing on the D8 migration when I was working at Metadrop.

Could you start reviewing the already opened tickets that exist with that purpose?
https://www.drupal.org/project/node_authlink/issues/3365570 ✨ Drupal 10 release Fixed
https://www.drupal.org/project/node_authlink/issues/3369567 πŸ“Œ Automated Drupal 10 compatibility fixes Active

πŸ‡ͺπŸ‡ΈSpain akalam

I will try to provide a fix this evening by refactoring the javascript so we get rid of jquery completely and we replace jquery.once by core/once

πŸ‡ͺπŸ‡ΈSpain akalam

I can confirm the issue, the referenced entities are displayed in the original content of the parent entity, instead of using the current language selected for the page. The MR is fixing the issue.

πŸ‡ͺπŸ‡ΈSpain akalam

The issue comes from the field_formatter module. I'm referencing an issue where there's a patch solving it.

πŸ‡ͺπŸ‡ΈSpain akalam

Add a MR with the requirement changed

πŸ‡ͺπŸ‡ΈSpain akalam

Thanks a lot Brent for your testing and feedback.

πŸ‡ͺπŸ‡ΈSpain akalam

Still need to implement an upgrade path, but would like to have a first review and impressions first.

πŸ‡ͺπŸ‡ΈSpain akalam

Added a MR with the first approach: Add dependency on pathauto.

πŸ‡ͺπŸ‡ΈSpain akalam

Sorry I forgot to answer @smustgrave regarding the change in the constructors. The only changes are replacing the type hint to use the interface instead of the class, so IMO doesn't have an impact on the future deprecation in favor of constructor property promotion.
However, if it can help I can refactor the touched classes to use constructor property promotion.

πŸ‡ͺπŸ‡ΈSpain akalam

I do agree that the plugin system would be a much nicer solution, but it will require some analysis and can take much longer to commit it in core. Having an interface in a service dont have a downside and wont impact in a new plugin system.

πŸ‡ͺπŸ‡ΈSpain akalam

I created a MR adding a new sub-module called bynder_media_library. The module depends on patch at πŸ“Œ Add an interface to media_library.ui_builder so the service can be decorated properly Needs work so the media_library.ui_builder service on the media library can be decorated properly.

πŸ‡ͺπŸ‡ΈSpain akalam

@andrew.farquharson regarding the media library extend module, adding the interface doesn't make the module obsolete, but can allow the maintainers of the module to refactor it to use the interface instead of extending the core class, making it compatible with other modules which also decorates the media_library.ui_builder. If you extend a class instead of using the interface to call the inner service, you introduce your functionality but block others to introduce other functionality as well.

Regarding the test, I agree that there's no new functionality so nothing to test at that level, but still can be phpunit tests, like testing that the service can be decorated for example.

Production build https://api.contrib.social 0.62.1