Confirmed, something is very much up with this install of Drupal.
I manually copied the "search_api.settings.yml" file from search_api/config in to my site config, drush cim, and things work...
Thank you for that gudience.
This is a fresh 10.3.6 install, so I'm going to go look for issues around config not importing on module install...
Marking closed.
Thank you.
Drunken Monkey, thanks.
You keyed in on something else wacky going on with this site. We've been having issues with things not being installed via config.
lando drush php \Drupal::config('search_api.settings')->get('default_tracker');
zsh: no matches found: Drupal::config(search_api.settings)-
In multiple scenarios we've had to manually copy conifg out of modules in to the site config, to get it recognized.
I'm going to try and manually import the config, and see what happens, will report back.
This needs to be re-rolled for Drupal 10.3.6
This patch worked perfectly! (on 10.3.5)
Thank you.
How do we get this in to core?
alphex → created an issue.
I was receiving a similar error with MariaDB 10.4
This patch fixes the error.
If this helps anyone.
This patch doesn't work any more on 1.13.0
Well, I just had a client report that GA via GTM wasn't reporting anything since Late May of 2024. I verified that GTM' scripts were not showing up at all on the site.
I just updated to 2.0.x, and the scripts started loading.
So, this is something thats happening.
Confirming that #8 solves the issue.
The patch in #11 worked for me.
I had removed a menu, and apparently having the permission to manage that menu was not removed from the system.
Adding additional features and defining the permissions for them, caused this error, preventing the save of additional permissions.
The patch fixed it, allowing the permission change to be made, and config export cleared up the orphaned permission.
Just confirming that the steps in #28 worked for me.
Confirmed, this is happening, and it removes the save button... so you can't fix the error, and then save.
alphex → created an issue.
I can verify that this problem exists ALSO on webforms that are loaded by 'webform reference' fields.
On a number of my sites, I have content management activities where admins will create a page, and place a paragraph type that allows them to select from a series of webforms, that get displayed ont he page ...
When built on a page that way, the conditional logic does not work.
It does work when we got to the "webform" "view" directly.
Drupal 10.2.2 site reporting this is still a problem, despite 2807629 being marked fixed.
I have a bunch of pages that were built, and saved as unpublished, and now we can't view them as unpublished and we can't change the menu structure of them.
This is a site using workflow.
I can confirm this is still happening with Drupal 10.2.5 - WITH - the patch from #102 applied.
<!-- FILE NAME SUGGESTIONS:
x page--node--general-page.html.twig
* page--node--2.html.twig
* page--node--%.html.twig
* page--node.html.twig
* page.html.twig
-->
I would expect that "page--node--2.html.twig" would be at the top of the list.
----
When I add some code I've used in past sites, to my .theme file
function themename_theme_suggestions_page_alter(array &$suggestions, array $variables) {
// Add content type suggestions.
if ($node = \Drupal::request()->attributes->get('node')) {
array_splice($suggestions, 1, 0, 'page__node__' . $node->getType());
}
}
It puts the template suggestion, in the right spot, but the TOP one is still there, which is wrong.
<!-- FILE NAME SUGGESTIONS:
x page--node--general-page.html.twig
* page--node--2.html.twig
* page--node--%.html.twig
x page--node--general-page.html.twig
* page--node.html.twig
* page.html.twig
-->
I understand the goal of this idea - but I think it could lead to more confused frustration with the general public.
There is unfortunately a LOT of people who I encounter who say "oh man, Drupal SUCKS"
Not understanding that they're experience in Drupal 6 is ... well, dated...
I think theres value in some how making sure people know this is the NEW Drupal, and that even in the last year there have been significant improvements in "out of the box" user experience then there was in Drupal 9... and Drupal 8.
I don't know why this is a thing... but under ImageMagick, do the following to solve this.
Go to "admin/config/media/image-toolkit"
Under Image Formats
Scroll through the list, and find WEBP
Erase the line that reads "enabled: false"
Hit save...
And then the image styles "CONVERT" tool lets you select "WEBP".
Updated.
I can confirm theres something off.
When I switch between CLARO and GIN on an mapping I created, Its not showing all of the mappings.
I did this by simply switching the admin theme from GIN to CLARO...
vs
Ok, updating -- I'm going to mark this NEEDS MORE INFO because after switching the admin themes from GIN to CLARO, and back to GIN, its not working... I think.
I'll do another mapping to test.
alphex → created an issue.
#13 works as expected.
Thank you!
Added a merge request.
The module still has .once() code in it.
in web/modules/contrib/hide_autocomplete_id/misc/hide_autocomplete_id.js
on line 37 and line 60
Edited post, the site is running php 8.2
alphex → created an issue.
Crutch check out this module : https://www.drupal.org/project/asset_injector → to do CSS better then a custom block, the way you're doing it.
Status on getting a working D10 patch for this?
@joaopauloscho
@VladimirAus
Decisions like this make upgrading a D9 site to D10 more difficult for people who are less comfortable with composer.
For those of us who have D9 sites, we have to make a decision to keep or upgrade CKEditor4... And in my case, for most of my sites, I'm keeping CKEDITOR 5 cause many features my clients use on CK4 aren't ready yet.
I suggest removing the ckeditor requirement
and keeping 9 in the core requirements,
That way people who are doing the upgrade can make their own mind up about CK4, but don't have to do any composer song and dance to do the Drupal 10 upgrade.
Me as well, Drupal 10.1.5: Patch #8 solved it.
I can confirm, the patch at #11 works for 6.2.x-dev
Thank you!
I'm unable to apply the patch from #5 on ALPHA 5 now.
Same result for the DEV branch
@selwynpolit - solved it for me.
Thanks
Updating this ticket.
The patch in #19 hasn't done anything to make this better.
Just last night I got an alert in my page diff monitoring tool that something changed.
The larger red box on this image is a paragraph type that sits on a node.
And has 4 paragraphs inside of it.
The alert I got showed that the 4 sub paragraphs had vanished.
The only way to restore things when this happens is to edit the node, and simply change the weight of the elements that are impacted, and hit save.
This clears what ever problem is happening, and makes them show up again. (drush cr does nothing...)
No errors show up in watch dog related to this.
I think thats a big improvement from my perspective, Hestenet. Thank you very much!
Clarifying thoughts
In another medium, someone mentioned "the $1000 D7 sites built 10 years ago..."
First, that should be a testimational to the value of the software that its lasted that long hack free, right? And it was built to do that job with an even weaker "module" or "plugin" ecosystem then what exists today in both WP and Drupal.
Regardless -
This isn't the client scope we're talking about.
The client who paid $1000 ten years ago for a D7 site isn't reading drupal.org. But the business leaders who are in the $10k, $20k, $50k range might be, and if some WP developer shows them guttenberg and says it costs $5k, you know they're going to jump on that, and low and behold, There's a page on Drupal.org suggesting that you should use WP instead of Drupal.
I have often had conversations with potential clients who have a limited budget - and I have ABSOLUTELY told them to go make a squarespace or a wix site, because the $500 or even $2000 they have to spend isn't going to get them much. And I'm sure many people here would say that won't even get you much of a WP site either, even if it is "CHEAPER" to build on (I disagree with that value statement anyway).
MANY of those conversations have lead to real business for me 12 to 24 months later, when that client, feeling educated about their choices, comes back to me asking for the website they need, not what they hoped to pay for it...
I'm not robbing my clients for a $100,000 "blog", I provide competitive pricing in my market segment, and my reputation for quality of service and support is often why I get a phone call out of the blue... and MANY of those conversations will have the potential client saying something like...
"Well, we're also looking at wordpress ..."
And I get to use my reputation and my portfolio of work to demonstrate why their $25,000 or $35,000 project is worth being built on Drupal...
---
If anything, this section of the document needs to be heavily edited to communicate the value statement of why you may or may not want to use Drupal - and not blindly just shove off a valuable segment of the market that a LOT of us small shops make their lively hood on.
I don't know if this is the right channel to talk about this - because, I can't find another one.
But why are we suggesting Wordpress and other platforms that have an even smaller footprint than Drupal?
As a small Drupal shop, I've found fantastic success using Drupal for small clients, building sustainable and also easy to use products for my cients. And I also get a LOT of business from people moving on from Wordpress because of all of the problems it has in its ecosystem and fundamental architecture challenges.
This suggestion that people move to Wordpress, Joomla, Typo... WIX?!? feels like a slap in the face from the association.
I now have to compete even harder, against the recommendations of the Drupal association as a whole?
(To be clear I know there are good WP sites out there, but i'm not competing against the good ones.)
What was the rationale about pushing the audience AWAY from Drupal?
alphex → created an issue.
How many of you are on Pantheon?
I've built a few sites in the last year or two who rely on paragraphs HEAVILY for page building, and this symptom crops up every so often.
I'm testing this patch now on a production site, I'll follow up in a few days with any results.
Workaround in #5 fixed the immediate problem
Seeing this on Drupal 9.5.9
Are there any work arounds known? This of course is showing up on launch day...
alphex → created an issue.
Bump this.
alphex → created an issue.
alphex → created an issue.
I can confirm patch 91 doesn't work.
This is on Drupal 9.5.5, but... hoping the patch carries backwards.
I have a media entity which takes vimeo URLs.
But the project needs to upload their own custom placeholder image, but we want to use media for that.
So media library opens a modal for the VIDEO entity type, then clicking the add media button for the place holder image, opens the 2nd modal.
Selecting the image sends you back to the node edit screen ... and, you lose the other work you did to build the video entity.