πŸ‡«πŸ‡·France @Nixou

Toulon
Account created on 21 September 2012, over 12 years ago
#

Recent comments

πŸ‡«πŸ‡·France Nixou Toulon

Thank you ! It worked for me.

Just uploading the patch from the merge request to have a stable patch to include through composer.

πŸ‡«πŸ‡·France Nixou Toulon

Thanks for this !

In my case I have a paragraph field which is translatable in some content types and not translatable in others.

This patch works well when the field is translatable but breaks the translation when it is not.

I think it's just because the asymetric check is currently done on the field storage instead of the field instance.

I fixed this in the attach patch, both translation cases are now working with it.

πŸ‡«πŸ‡·France Nixou Toulon

Thanks for this.

I needed this feature to exclude a webform reference field which needs to stay translatable so it can be changed from a translation to another.
Without excluding it I had an error while TMGMT was translating the target_id and other elements in the reference field.

Attach is the patch from the MR so it can ben added through composer whitout including further change from the MR.

πŸ‡«πŸ‡·France Nixou Toulon

Thanks for this !

Attach is the patch from #48 (2875033-46.patch) rerolled for Drupal 10.3.x and 10.4.x

πŸ‡«πŸ‡·France Nixou Toulon

Test fails with errors like No space left on device which seems related to a CIT infrastructure problem.

Not sure what we can do to solve this.

πŸ‡«πŸ‡·France Nixou Toulon

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

πŸ‡«πŸ‡·France Nixou Toulon

Thanks for your feedback.

I tried again today on the Umami Demo and on my project and below are my observations (I ran all my tests on the /admin/content page) :

On the Umami Demo, without XDEBUG and XHPROF, the second JS file loads in ~0.6 second.

On my project, I was not able to reproduce the 8 seconds loading time today, the maximum I got was 4 seconds.

Below are the loading time of the second JS file :

  1. With XDEBUG (trigger mode) and XHPROF : 4 seconds
  2. With XDEBUG (trigger mode) only : 4 seconds
  3. Without XDEBUG and XHPROF : 1 second (which seems ok with all contributed theme and modules I have)

So it is about XDEBUG (even in trigger mode, which intends to avoid to slow the environment when xdebug is not used).

I had not this problem before on the previous version of Drupal, before the on-the-fly minification implementation.

I tried with XDEBUG enabled and the core JS aggregation disabled, all javascript files are loaded in 146ms and the whole page loads in 1.15 seconds.
As soon as the core JS aggregation is enabled again, the complete page loading time is back to 4 seconds.

So finally I think the only problem is that the new on-the-fly minification has an important impact for developers using xdebug making the back-office mostly unusable while developing.
It will be complicated now to work locally without disabling the JS aggregation or removing totally xDebug when not used.

Do you think something can be improved there ?

Let me know if you need more information.

Thanks again.

πŸ‡«πŸ‡·France Nixou Toulon

I can confirm the bug is still present (for example when uploading an image in the node edition form) and the last patch yoast_seo-3010164-12.patch needs to be applied to solve it.

Production build 0.71.5 2024