🇸🇮Slovenia @joco_sp

Thank you @andrew.wang, but in the meantime I found this module Keep referenced entities → .

Before re-applying for Prevent term delete I would like to try out Keep referenced entities, because if it will work as expected, it will be even better for our case. I like it more that it covers all entities. If it won't work then I'll come back to this module.

joco_sp → created an issue.

Thank you. It's added to 2.x. It will be available in the next release.

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

As @Anas_maw mentioned, this was solved in the parent issue.

Thank you all for the support.
I merged it with the 2.x branch and it will be available in the next release.

Instead of

$time = (int) $time;

I added

$time = (float) $time;

otherwise you are getting the read time of 0 min. Additionally we could show also seconds, but this would be a new feature.

Thank you @HeikkiY. I commited it to 2.x branch. It will be available in the next release.

It will be available in the next release.

@malcomio thank you for the support and wait. I used the solution from the related issue 🐛 I get an error when previewing a node. Fixed as it checks for the id sooner.

Quite an old issue :D Thank you for your support.
I committed it do 2.x. It will be available in the next release.

Thank you all for the support. I merged the patch #14. It will be available in the next release.

@cmconklin thank you for expressing the interest to co-maintain the module. I added you :)

@vishal.kadam thank you for the review.

I applied the fixes.

Thank you @gisle. I contacted both maintainers and applied for security advisory policy.

joco_sp → created an issue.

Thank you @andrew.wang. I opened a new one on the project's page Offering to maintain Prevent Term Delete 💬 Offering to maintain Prevent Term Delete Active .

joco_sp → created an issue.

Hi @cmconklin did you apply for speeding up the deployment of your issue ( https://www.drupal.org/project/ckeditor_readmore/issues/3388400 ✨ CKEditor 5 Support Fixed ) or did you want to make more contributions to the module?

Hello @apaderno.
Is there a chance that I can become the co-maintainer/maintainer of this module ( https://www.drupal.org/project/prevent_term_delete → )? We are using it on some websites and for almost half a year we are running it with patches.

For the start I would like to make a Drupal 10 release and fix some other issues that are also tested and ready to be committed:
- https://www.drupal.org/project/prevent_term_delete/issues/3354210 📌 Automated Drupal 10 compatibility fixes RTBC
- https://www.drupal.org/project/prevent_term_delete/issues/3157733 →

I also contacted karthikeyan-manivasagam, but as you didn't have any luck getting his response, I decided to write also here. In case this can speed up the process and make it possible.

Thank you. Then I am closing this as it is outdated.

@cossovich thank you. This functionality is now in 3.x

levmyshkin nice feature :)
As 2.x is deprecated, this has to be ported to 3.x

PROMES are you still facing this issue? Did you uninstall it first or just removed it with composer remove?
We should test this on 3.x version, because 2.x is not supported anymore.

It has to be ported to 3.x

I tried the solution, but it didn't work in the 3.x

Libraries are solved in 3.x. If there is a problem with translation, please open another task or check if there is already one open on this subject.

Thank you. I updated the description.

Thank you all for the support! :)
I merged the code from #3388400 ✨ CKEditor 5 Support Fixed and created the 3.0.0-alpha1 release.

Thank you all involved into making this possible!! :)
I merged it to the 3.x version and deployed it to the 3.0.0-alpha1. In that version, I also removed CKEditor4 files.

Patch #25 worked for me on 8.x-3.1.
I didn't try the previous solutions, but all once error messages are gone and the popup is working again.

I am changing the priority to Major, because the bug makes the popup unusable.

joco_sp → created an issue.

This is happening also on the 2.0.x-dev version.

Hopefully I put the changes in the correct branches.

The issue is still present. We have it on multiple websites. Core Drupal 10.2.2 and the module version 2.1.0. It's happening only for the anonymous users and on the production websites.

I managed to pintpoint the cause to the core aggregation of the JavaScript files.

Two solutions worked for me. Either attach the library to the head

default:
  version: VERSION
  header: true # Added
  js:
    js/obfuscate_email.js: {}
  dependencies:
    - core/drupal

or do not preprocess it

default:
  version: VERSION
  js:
    js/obfuscate_email.js: {preprocess: false} # Added
  dependencies:
    - core/drupal

I prefer the option to put it in the head.

@micropat Thank you.
I can confirm, that the error message is not visible anymore. For the future will have it in mind and report the false positive directly on the form you mentioned.

joco_sp → created an issue.

We applied the patch on multiple websites (also on version 10.2.2) and it seams that the patch solved that issue for us.

@Vivek_Lnwebworks all are public.
Also, if you try the one drupalassociation you'll get the same output.

https://api.woxo.tech/instagram?source=drupalassociation

What alternatives to api.woxo.tech would you suggest?

@Vivek_Lnwebworks I tried with both. Personal and business and I get the same result.

I'm not getting any data. I tried it with drupalassociation, but also multiple other usernames
{"data":[],"cache":"HIT","expiredPeriod":1440}

I have the same issue as RoloDMonkey. I did a change in the core/modules/content_translation/content_translation.admin.js -> #7. It worked for me. I didn't do an extensive test of it. So, I don't know if it's the right way or if this opens new problems, but it worked on my project.

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

Hm, actually I see that this was already mentioned did in another issue. Probably more relevant - > https://www.drupal.org/project/shs/issues/3357151 🐛 Use core/internal.backbone lib Needs work

If that solution solves the original problem, we should probably mark this issue as a duplicate.

It's not a problem of the permissions, but of the libraries. Instead of using core/backbone, I changed it to core/internal.backbone.

See the MR !24 in the comment #9. After you apply the patch, don't forget to run drush cr.

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

Running composer require gravitypdf/querypath did the trick. Thank you @jansete :)

#8 worked nicely for me too. Thanks sebasgd :)

+1 to implement this

#15 works

We are getting the same warnings as #29
PHP 8.1.13 and also on PHP 8.0.30
cleantalk 9.2.7

In our case it happened on core 9.5.10. The temporary folder was not configured correctly. After adding

$settings['file_temp_path'] = 'tmp';

the problem went away.
So, it's worth checking if your tmp folder is correctly configured and if it has the correct permissions before applying a patch.

Thank you for the patch.
The cookies are now blocked, but when clicking on Accept all, they are not added to the website.

I'm using:
core 10.1.2
cookies (cookies_gtag) 1.2.3
google_tag 2.0.2

I have the same problem.
The patch mentioned in the #4 for the core didn't work for me, so I tried the solution from this MR and it solved the issue.
Thank you @Stefdewa :)

The solution from #8 worked for me, but I couldn't apply the patch to 2.0.0 version. Maybe I had to use the DEV version.
Anyway I made a patch for my version 2.0.0 and I am uploading it if somebody else will have the same issue.

We have the same problem

@dkosbob tnx for the tip. It was also in our case. It was an old project and we missed that. Thank you

#6 worked. Thank you

This one solved my issue https://www.drupal.org/project/google_analytics/issues/3361353 🐛 Empty tracking ID numbers (on the form and on the website) Closed: works as designed

joco_sp → created an issue.

@dwisnousky no need for that. There is already one. If you add the .patch at the end to the commit, you have it :) -> https://git.drupalcode.org/issue/draggableviews-3346320/-/commit/4988d64...
Hope it's useful for the future.

I just updated the module to v9.2.3 in another project and I'm still getting the same error.

I see the change in the 9.1.x branch, but not in the 9.2.3 tag. Hopefully will be committed to the next release, because this error is breaking the module for who has the database table prefix + firewall enabled.

@znaeff tnx for the fix in the 9.1.x version. For now, until we don't get the version with that fixed, I applied the patch from the 9.1.x commit and it looks like this fixed the problem. We will test it on multiple projects and come back if we'll still have this issue.

We got this error on a custom form where we had the datetime field and we had to use it as an array. Which is then also array in the $elements['#value']. For us, the problem occurred after an update to Drupal core 9.5.5 and PHP8. Before that, we didn't get WSOD, but just a warning.

In my opinion it's good to add a check if the $elements['#value'] is really a string, because if it's not, you are getting a WSOD in PHP8.

I am attaching a patch that checks if $elements['#value'] is a string. It should work on core 9.5.x

@rclemings tnx for the tip :)

I found this issue on another one -> The "paragraph" entity type did not specify a translation handler. 🐛 The "paragraph" entity type did not specify a translation handler. Closed: won't fix .

The patches on both issues didn't help. Uninstalling Shield also triggered the error. And also after uninstalling it, the error was there.

What helped was the patch from the comment #27 on this issue ModuleHandler skips all hook implementations when invoked before the module files have been loaded 🐛 ModuleHandler skips all hook implementations when invoked before the module files have been loaded Needs work . I don't know how much the issues are related, but it solved the problem in my case. At least for now :) If it appears I'll report it.

#27 worked for me also on core 9.5.5.
Thank you all for making that patch, because it solved a big issue :D If I see the error reappearing, I'll report it here.

As multiple people reported above, this seams like a core issue. Applying the patch from https://www.drupal.org/project/drupal/issues/3207813 🐛 ModuleHandler skips all hook implementations when invoked before the module files have been loaded Needs work worked for me.

At first I thought that the error was related to paragraphs, later to Shield module, but nothing worked until I applied the patch #27 from that issue 🐛 ModuleHandler skips all hook implementations when invoked before the module files have been loaded Needs work .

@vegardjo I just added .patch at the end :) I didn't like using the Merge request, because I'm not sure if somebody else can change it. I preferred to use my specific commit. Just to avoid possible problems. And it worked :D

#9 works

This is quite a long period, because the problem creates a WSOD.

Reinstalling the module doesn't help, because there is a bug in the code. Where the db_prefix is not added to the table name. Therefore if you have a database with tables that have prefixes, when the query is used, you get the WSOD. I first thought it was just in \Cleantalk\Common\Firewall\Firewall, but then I got also other errors. So, I suspect this is a problem on multiple places.

The attached patch solves the issue in 328 line \Cleantalk\Common\Firewall\Firewall::sfw_send_logs(), but not in line 81 of /contrib/cleantalk/lib/Cleantalk/Custom/Db/Db.php).

I'm using core 9.5.4. PHP 8. Module version 9.2.3.

This is probably a problem, because the table prefix is missing when table_name is called.

Possible the same issue as here - https://www.drupal.org/project/cleantalk/issues/3211127 🐛 Firewall Class doesn't use db table prefix RTBC

The same issue:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'DB_NAME.cleantalk_sfw' doesn't exist ..... in Cleantalk\Custom\Db\Db->fetchAll() (line 81 of /contrib/cleantalk/lib/Cleantalk/Custom/Db/Db.php)

It looks like everywhere the table_name is used, the prefix is not added to it.

I see that this is implemented in the 9.1.x. When will it be committed? Because it's still a problem in the latest stable 9.2.3 version of the module.

My bad, I see this is in the 9.1.x

joco_sp → created an issue.

@Adrianm6254 it should work on 2.1.2. I tested it on multiple websites with that version.

You can add those lines to your composer.json

"patches": {
  "drupal/draggableviews": {
    "Undefined draggableviews_structure_parent => https://www.drupal.org/project/draggableviews/issues/3346320": "https://git.drupalcode.org/issue/draggableviews-3346320/-/commit/4988d648001430ef4496899e8d8205364c6bc595.patch"
  }
}

or use the direct link to the patch and apply it as you are used to:

https://git.drupalcode.org/issue/draggableviews-3346320/-/commit/4988d648001430ef4496899e8d8205364c6bc595.patch