🇪🇸Spain @jjcarrion

The MR81 worked fine for me but I had a warning like:

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\ContentEntityStorageBase->loadMultipleRevisions() (line 667 of /app/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php)
#0 ...
...
#4 /app/web/modules/contrib/scheduler/src/SchedulerManager.php(354): Drupal\Core\Entity\ContentEntityStorageBase->loadRevision(NULL)
...

Added a commit to fix the issue where the Scheduler was encountering NULL revisions for some translations. This may occur when certain translations have no scheduled actions. I'm skipping translations, allowing the process to continue for other affected translations.

Thanks!

jjcarrion → made their first commit to this issue’s fork.

Thanks for the patch!

Thank you for the MR and sorry for the delay applying it, now it's merged.

Patch #6 fixes the issue.

Thanks!

Hi,

I'm still experiencing those cache issues with latest patches.

1. Clear caches
2. First load -> Footnotes are there
3. Second load -> Footnotes are gone forever (until next cache clear or invalidation)

After some debugging I have seen that the plugin is not collecting the footnotes after the cache is clear. I have seen in the annotation of the FootnotesFilter.php that there is a "* cache = FALSE," but it seems that the plugin is cached anyway.

I have added a $result->setCacheMaxAge(0); into the process() of the FootnotesFilter.php so it's processed always and not just when we clear caches.

Attached the patch from the MR7 + the cache max-age=0

I think this could be related to this other issue: 🐛 Unable to modify certain paragraph - You are not allowed to edit or remove this Paragraph. Active

I am experiencing a problem that's related with the content_lock module and content translation:

• The content_lock module initiates an AJAX request to verify permissions. When the current user lacks the necessary rights to edit the original language, a 403 error arises.
• Similarly, I faced challenges on the content translation overview page. Even though users could access a specific language, they were unable to edit a node if they didn't have permissions for the original language.

To provide some context, in my setup, I always maintain the UI in English across all languages. This causes patch #3 not to function correctly for me because it relies on:

\Drupal::languageManager()->getCurrentLanguage()

and in my case, I'm getting always English because the UI is set to English always.

I tried out patch #3 (kudos to @peterwcm!) and it almost fixed the issues for me. After diving deeper with some debugging, I removed the access check with the \Drupal::service('allowed_languages.allowed_languages_manager')->hasPermissionForLanguage($current_language, $user) from the .module (in my case the $current_language was always English). This check is already managed within \Drupal\allowed_languages\Access\ContentTranslationAccessCheck. As of now, I haven't come across any permission-related issues, leading me to believe that the extra verification might be redundant.

However, I'm still contemplating whether this is the optimal spot for the correction. Any guidance or suggestions about a better location for this fix would be greatly appreciated.

Thank you!

Hi,

I'm facing the same problem after updating core to 10.1.2.

It seems that the root cause will take some time to be fixed https://www.drupal.org/project/drupal/issues/2883450#comment-15218088 🐛 Missing url prefix on language neutral content Fixed so I have applied a hack for now, I'm agree with @masilipa that this is not the way to go, but until we find a better solution I'm uploading the hacky patch just in case anyone find it useful, I'm not even using dependency injection but as I said, this is not the right solution.

Thanks!

I can confirm that #3 and #4 fixed the issue

jjcarrion → created an issue.

jjcarrion → made their first commit to this issue’s fork.

Patch #2 worked for me for the Drupal 10 upgrade,

Thanks!