Not quite sure what fixed the issue since I'm not quite sure what the problem was but here is what we did:
- Created a clone of the entire LIVE server
- Changed local Host file to point us at the new clone site
- Went to a page that uses CKEditor to be sure it was still causing an error (success)
- Since using drush cr possibly made the site worse, I tried going through individual cache commands and checked the site after each one to be sure it was still working
- cd ../../var/www/drupal
- ./vendor/bin/drush cache-clear theme-registry
- ./vendor/bin/drush cache-clear css-js
- ./vendor/bin/drush twig-compile
- ./vendor/bin/drush cache-clear router
- ./vendor/bin/drush cr
- ./vendor/bin/drush eval "drupal_flush_all_caches();"
- ./vendor/bin/drush config:status
- ./vendor/bin/drush cex
- ./vendor/bin/drush cr
- lastly I clicked the Cache Rebuild button in the admin UI
The site was no longer giving me anymore of the "plugin not found" errors. So we did the same in the LIVE server with the same results.
Unfortunately, I did not test any pages using CKEditor during any of these steps so I can't say which step made the magic happen. Sorry, I forgot and I'm kicking myself.
But our site is back up and running so hope this helps someone else with their similar issues.
In my case I have a DEV server and a LIVE (production) server. We have yet to be able to reproduce the errors in DEV that we see in LIVE. We are looking into possible server differences but we have not found any yet. We've tested backups of LIVE in DEV and still can't recreate in DEV. The first "plugin" error I get in LIVE is for CKEditor5. Any page that needs to use the WYSIWYG in the admin is not accessible. CKEditor5 is not listed in the Text Formats page. Just "---" where it should say CKEditor5.
We are in the process of cloning the LIVE environment so we can recreate the issue and debug it in LIVE-CLONE without affecting the actual LIVE site.
I am looking for a solution to adding a cache rebuild link to my custom menu.
Everything I've found so far relies on the Admin Toolbar module. It may be popular but it does not fit all needs. It may be popular because no one has offered something in its place.
Drupal is meant to be customizable and the permissions are meant to be granular.
If I could code my own solution, I would. Maybe in time.
Hello, leymannx.
I'm trying to include your "tab" link in a custom, hard-coded backend menu I've designed in order to replace the admin_toolbar. Unfortunately, just copying your module's rendered HTML and pasting it into my template doesn't work and I think it's because of the "token" element in the URL.
Is there any easy way to produce a standalone link for this function that could be placed anywhere?
Appreciate any help.
#15 worked for me. Thank you. Spent all day reading and researching this.
I had just updated our TEST server to 10.2.5 and was having AJAX errors caused while trying to run manual updates, add media, add images, remove images, edit fields in Views... Didn't have these issues on our DEV server which was running the same version. However we did copy our LIVE server over to our TEST server, so at first I thought it was something else.
Thank you for the regexp so I didn't have to look that up myself.
The culprit was in the web/sites/default/settings.php file. A lonely blank line above the opening <?php tag. The version on our DEV and LIVE servers did not have this line so I'm still trying to figure out who/how this appeared.
#29 helped me with my issue. Thank you.
As of today, spam is still coming through but Honeypot is registering more blocking in the log reports due to "honeypot field" usage rather than just "time" blocking. Before these edits to the module, I was not seeing "field" logs.
I still don't know how to make or work with patches yet (some day). But I did alter the code in the module's HoneypotService.php file to this:
// Build the honeypot element.
if (in_array('honeypot', $options)) {
// Get the element name (default is generic 'url').
$honeypot_element = $this->config->get('element_name');
$alt_titles = [
'website_address',
'fav_number',
'apartment_number',
'maiden_name',
'favorite_cereal'
];
if($honeypot_element == 'url'){
$random_number = rand(0, 4);
$honeypot_element = $alt_titles[$random_number];
}
$replace_underlines = str_replace('_', ' ', $honeypot_element);
$label_title = ucwords(strtolower($replace_underlines));
// Build the honeypot element.
$honeypot_class = $honeypot_element . '-textfield';
$form[$honeypot_element] = [
'#theme_wrappers' => [
0 => 'form_element',
'container' => [
'#id' => NULL,
'#attributes' => [
'class' => [$honeypot_class],
'style' => ['display: none !important;'],
],
],
],
'#type' => 'textfield',
'#title' => $this->t($label_title),
'#size' => 20,
'#weight' => 0,
'#attributes' => ['autocomplete' => 'off'],
'#element_validate' => [
[$this, 'validateHoneypot'],
],
];
}
Based on some of the ideas in some of these related issues, I've added an array of element name options to be selected randomly if you leave the default 'url' option in the config page. It then replaces the underscore for a blank space to create the #title, redefining the element label and the element machine name at the same time. Lastly, I set the #weight option to 0.
Now the field appears first in the forms and randomly changes the field label and input ID and classes based on the 5 options I've provided.
The resulting HTML look slike this:
<div class="maiden_name-textfield" style="display: none !important;"><div class="js-form-item form-item js-form-type-textfield form-item-maiden-name js-form-item-maiden-name"><label for="edit-maiden-name">Maiden Name</label><input autocomplete="off" data-drupal-selector="edit-maiden-name" type="text" id="edit-maiden-name" name="maiden_name" value="" size="20" maxlength="128" class="form-text"></div></div>
I will continue to monitor the results. I just started using this module today and prior to making these changes, I was only seeing "time-base" results in the logs and still getting spam submissions. I will be trying additional methods but I will give this a few more days. Over the weekend we got hit with a non-stop attack that I was only able to stop by changing the access level of each of my webforms. Within minutes I had over 700 spam submissions come into my email. I just turned the forms back on this morning.
If anyone would like to turn this into a patch for me, I will love you forever.
:)
Drupal 9.5.11
Webform 6.2.2
Honeypot 2.1.3
I had the same issue in D9 and turned out it was the custom template fix #16 that helped.
Now I just have to remember why I had removed the wrapper DIV in my theme originally.