Thank you SO much for this! I was getting complaints from a client that some form submissions weren't getting through and I was going nuts trying to reproduce the issue. It's been several days now and it looks like the merge and patch did the trick... thank you SO much!
I suggest this should be committed soonest – thanks again!
Thank you for the response – much appreciated.
This is a live site that's working fine. I've been working on a dev version of the site, to which I've applied all module and core updates.
On the source (live) site, I go to Results > Download. I export CSV download, clicking Use UUID for all entity references.
Click Download (all submissions). I open the file in Mac Numbers and remove the rows submissions that exist on the dev (target) site.
Export to .csv in Numbers.
On dev site, go to upload. Mapping is correct.
Execute upload and it seems to process, but I get the following status result, followed by the errors as listed above. (Row #101: 25 values expected and only 1 found., etc.)
Submission import completed. (total: 200; created: 0; updated: 0; skipped: 192)
Row #1: Math question field is required is particularly puzzling. Any ideas? Again, thanks for your input!
I did an upgrade to 10.3.1 and now I get the following error (and page crash) upon viewing a node:
ArgumentCountError: Too few arguments to function Drupal\image\Plugin\Field\FieldFormatter\ImageFormatter::__construct(), 9 passed in [site]/web/modules/contrib/field_slideshow/src/Plugin/Field/FieldFormatter/FieldSlideshow.php on line 98 and exactly 10 expected in Drupal\image\Plugin\Field\FieldFormatter\ImageFormatter->__construct() (line 76 of [site]/web/core/modules/image/src/Plugin/Field/FieldFormatter/ImageFormatter.php).
Does anybody have any ideas here? Thanks in advance!
First, thank you very much for the quick and detailed response!
I assume that running composer require 'drupal/blazy:^2.23' won't harm any existing configuration data, correct?
If so, I'll then afterwards be able to run composer update drupal/blazy -W -n from here on out, yes? LMK...
Thanks again!
Yup. Did all the above and admin/reports/updates/update still reports 8.22.
I suppose I could do composer require 'drupal/blazy:^2.23' which would take care of it, but I'd like to figure out what the issue is. I have my host looking into it and will report back... thanks for the quick response!
Thanks - I applied the patch, but the problem is that Advanced RSS doesn't output the custom fields I need. Unsurprisingly, the RSS feed remains unchanged.
I've worked around my problem for now by adding a "last-updated" field - the client will need to update this field manually whenever they make a change to the node. Not ideal, but at least it allows me to work around the issue for now. (The nodes are political officeholders and candidates, so changes will be infrequent.)
Thanks again for looking into it - much appreciated!
Subscribing to this thread - I had been muddling through for a while by disabling CK 5 entirely and just writing HTML, but as I'm about to launch this site and release/train the client, this will not be acceptable.
Is there a way - any way at all - to use CK 5 without it stripping out valid HTML? (e.g., style attributes) +1 for a "let my stuff alone" option.
Please? Thanks...
This looks to have been a permissions issue and my host (Imegeleet.com) was good enough to find a workaround. Note that I was having this issue with Drupal 9 and I haven't yet seen the same thing in Drupal 10.
Below is what they told me:
Default "Public Files Directory" option is not working which i suppose will download sites/default/files folder if working, its not pointing to any specific error in PHP logs. I tried resetting permission of all files and folder in installation.
I added new source for public files specifying public files directory as /[site]/web/sites/default/files naming source as "Public Files Folder", if you use backup source as "Public Backup Folder" and Destination as Download it will work now. You can also use destination as public_files which will store backup on server at /[site]/backups/public which can be downloaded using File Manager. Similarly you can backup any folder even entire site by specifying folder as source.
To fully restore site or clone it you will need all files from [site] folder, its better to simply backup entire [site] folder by making zip and database backup can be downloaded using this module.
Hope this helps - good luck!
Thank you both for your attention to this. (And @cilefen, thanks so much for the Slack guidance!)
There are plenty of working fields in my custom feed that aren't in the RSS spec, so I don't see why it's only the last-updated field that doesn't work, especially insofar as it's working in the page/block views. (Yes, and I know those views aren't RSS.) I'd suggest that if the RSS spec is the reason the data won't display, the field shouldn't be made available as an option in the first place. But that's neither here nor there.
The publication date field won't work; it doesn't change upon node edit. So I suppose what I need is either:
1. A way to output the last-edited field in the feed, or...
2. A way to have the name-created field use the last-edited data instead.
Custom module? Patch? I have no idea, but I'm willing to talk about what it might take.
Thanks again for your guidance here!
Thanks, @cilefen - the most recent post in Slack DrupalNYC is two months old and I have no idea how to use Slack anyway. I assume there's an overall Drupal Slack channel, but I have no way to get to it nor how to use Slack, as I mentioned.
I'll leave this open for now and hope someone comes along who might have an idea what I can do next... thanks...
The actual feed is accessible here:
https://d1024.suffolkcountydems.com/feed/officeholder/shelter
The "last-updated" field is one that I added manually this morning as a workaround to the problem. (It's the last field in the feed.)
The site admins will now need to manually update the new field whenever they make a change so that the target site will know what nodes need updating. It's an extra step I'll need to ask them to do and something that could easily be missed; if the "content: change" field was being output, all they would need to do is make the desired node change(s) and that would be that.
Thanks, @cilefen, for continuing to circle back on this. Much appreciated.
Thanks so much for the response. I'm using the feed to populate another site and there's specific data I need to output that doesn't correspond to what I assume to be the typical RSS feed. The row style options in fields (e.g. Content: Title, Link, Creator, etc.) are irrelevant for my use case and there's no provision for the data I need to include.
The configuration that outputs what I need is:
Format:
RSS Feed | RSS Feed
Settings: Force using fields
Show:
Content | Content
RSS | RSS
In this configuration, everything outputs perfectly except for the Content: Changed feed item, which doesn't appear at all. I only mentioned converting the display from page to feed to save a step; I suppose I should have clarified that the problem happens not in all configurations, but in the specific configuration I need to use.
Does this help? Thank you so much for taking the time - I am really stuck here, so any ideas are greatly appreciated!
(Happy to send you a like to the feed privately...)
UPDATE: Custom display for RSS does the trick. That's why it's there - Duh. Maybe this will help someone else... Again, Duh.
This thread should b closed - sorry for the false alarm...
OK - apparently, if the field isn't displayed in the node, it won't appear in the feed. Block and page views don't apparently have this limitation.
I need the taxonomy to categorize on affiliate sites and I guess I'l just hide it with CSS. As far as the location data is concerned, I'm using Leaflet maps, which the feed apparently has no idea what to do with, so I might just need to enter those manually. (Boundary data is involved.)
Off the dime, at least - any suggestions greatly appreciated and perhaps this might help someone else... thanks!
My host (imageleet.com) figured this out:
Storage issue is due to field_location_value column defined as blob in table field_location which limit the data to 64 Kb, If its defined the mediumblob during module installation then large location data can be uploaded if required.
By updating the field storage, up to 64MB can be stored, thus solving the problem:
Storage type update should work for all region as now data up to 64 MB can be uploaded.
Figured it out. I created a "fill color" field that uses a taxonomy. In referencing the field from the View (as a label), the field defaults to "link label to the referenced entity". If that's not turned off, when the {{ field_fill_color }} token is invoked in the Leaflet Path Geometries in Leaflet settings, it borks the boundaries views. Turning it off solves the problem.
Perhaps this will help someone else... thanks for following up!
Thank you so much for looking into this - much appreciated.
When I mention the Congressional boundaries - and only the Congressional boundaries - in View 1 (the working example) it’s to explain why they look odd; it’s an entirely different issue than what I’m reporting here. I know what it is, how to fix it and will open a separate thread.
In View 2, the view fails on any and all boundary views; the Democratic Clubs are points, not polygons.
The data for both views is identical, so there’s something else going on that’s causing the polygons in View 2 to fail.
Would you mind verifying what I’m saying here and reopening? Thanks in advance…
Holy cow - I spent the day trying to figure out why my images weren't displaying; I'm rebuilding from a dev site and in creating the identical view, one view displayed images while the other didn't. I was going nuts. Then I found this post. Patch fixed it and, sure enough, I see that the dev site was running 8.34.
I think this should be more heavily flagged, though, if possible - those doing upgrades on live sites could easily have all their images disappear without having a clue as to what did it. Just sayin'.
Thanks for the module... and for the fix... Whew!
I'll also mention here that once saved, the Location field just contains a string of numbers and nothing else, although it works fine.
Duh. If the input is set to Leaflet Map, the data formats fine, so ignore that. But otherwise...
Looking further into this, I don't believe it's a storage issue, per se. Here's the error message:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_location_value' at row 1: INSERT INTO "node__field_location" ("entity_id", "revision_id", "bundle", "delta", "langcode", "field_location_value", "field_location_geo_type", "field_location_lat", "field_location_lon", "field_location_left", "field_location_top", "field_location_right", "field_location_bottom", "field_location_geohash") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array ( [:db_insert_placeholder_0] => 5 [:db_insert_placeholder_1] => 71 [:db_insert_placeholder_2] => region [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => 010600000020000000010300000001000000a80300005136e2da961e52c051202a39cd6b4440ea408f649d1e52c0868c12c6e86b4440133e6b56a11e52c03a8ab114f76b44406f847235a31e52c054de79b9f86b4440fb1ef67ba41e52c03e94b43ff96b4440ce8e5e31a61e52c086f4e89ef86b4440e9f78bdcaa1e52c009ff7071...
(This string goes on for pages and pages - no wonder the system refuses to store it.)
[continued]
[:db_insert_placeholder_6] => MultiPolygon [:db_insert_placeholder_7] => 41.023295607948 [:db_insert_placeholder_8] => -72.676583405565 [:db_insert_placeholder_9] => -73.497092807085 [:db_insert_placeholder_10] => 41.295312500864 [:db_insert_placeholder_11] => -71.856074004036 [:db_insert_placeholder_12] => 40.751278715027 [:db_insert_placeholder_13] => dr ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->saveToDedicatedTables() (line 1400 of /home/suffolk/d1024/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Severity ErrorAl the other .json on the site works fine, so I suspected a problem with the data, but the data checks out everywhere. The problem is with [:db_insert_placeholder_5] (location value) as the error message indicates and it's only on this particular region, out of dozens that are working fine.
Any ideas? Suggestions greatly appreciated...
I'm on PHP 8.1.24 and you probably don't need to see my composer.json file - the output of the command says it all:
drupal/recaptcha_v3 2.0.2 requires drupal/captcha (^2.0)
(I was running captcha 1.14.)
composer require 'drupal/captcha:^2.0' does the trick, followed by composer update drupal/recaptcha_v3
Thanks!
Same problem. Following.
Got it - I neglected inserting some of the lines from the 575d85d2 commit.
Thanks for the work done here - a few other fixes and I'm ready to launch!
I'll offer a bounty to get this fixed if it'll help - it's the one issue that's holding up a D10 site launch.
Standing by hopefully...
OK - I've managed to install and patch the module, as well as applying the changes from:
https://git.drupalcode.org/project/field_slideshow/-/merge_requests/3/di...
I still get the spinning wheel.
Here's the log error:
Message Warning: Undefined variable $file_url_generator in Drupal\field_slideshow\Plugin\Field\FieldFormatter\FieldSlideshow->__construct() (line 98 of /[site]/web/modules/contrib/field_slideshow/src/Plugin/Field/FieldFormatter/FieldSlideshow.php)
Any ideas? Any help greatly appreciated!
Thank you very much for the module, the work you've done here and for the quick response! In my case, there are only 60 users to import, so it's a manageable task for me to update each as needed.
Thanks again for your help - greatly appreciated and I'm hoping this will help others as well!
I'm attaching a renamed .csv file - if you change the suffix, I think it should work. (Upload of .csv files is disallowed.)
It's just one record - you'll note that name and email are the only two fields that import successfully. Hope this helps!
OK - thanks for taking care of all this! The dev version with the patch works, but with a proviso:
The Drupal 7 system view puts Name and email in a single column; when exported, email is in its own column, but without a column heading. Email isn't imported unless table header is added and it has to be "mail" (lower case.)
I haven't had success importing Active status, Roles, Member for and Last access, even with all headers lower case. It's only 60 users, so I suppose I could plow through, but it would be nice.
Will check back... thanks much!
Thanks for the quick response!
The patch in https://www.drupal.org/project/user_csv_import/issues/3384659 🐛 RoleAssign with User CSV Import form alter doesn't work Fixed does, indeed, work.
I have a different issue now - emails fail to be imported. I see this has been reported here and is fixed on the dev version:
https://www.drupal.org/project/user_csv_import/issues/3308074 →
Question: should I remove the patch and install the dev version? Or should I install the dev version, keeping the patch?
Thanks for the help!
I have the same issue - this is a new install, running 10.1.5 on a pretty bare bones installation. Clearing caches has no effect.
I thought perhaps that roles needed to first be enabled at admin/people/roleassign - no such luck.
@virginia - were you able to solve this? This is the one issue holding up site launch for me... thanks!
I have a 9.5.10 site that depends on this module that I'm trying to upgrade to Drupal 10 - I'm assuming that I need to access the forked version at https://git.drupalcode.org/issue/field_slideshow-3341466/-/tree/3341466-... and select the 3341466-drupal-10-compatibility branch.
(I also assume that I would need to manually change the entry in the "require" section of my composer.json from "drupal/field_slideshow": "^3.0@beta", to "drupal/field_slideshow:^3.x'",)
But when I try to download, I get "Unsupported GitLab operation." I don't even know if downloading would work; I'm not familiar with Git and have been handling everything via composer install.
I am totally lost here. Can anyone provide some guidance on what I need to do to get this working in 9.5.10 so that I can successfully upgrade to Drupal 10? Composer install, uploading a file - whatever would work. Any guidance greatly appreciated... thanks in advance!
Update: Commenting out hidden: true in stable9.info.yml eliminates the DB error - let's see if I can make the transition to Drupal 10 and get rid of the deprecated themes there.
Thanks for the quick response!
I installed Bootstrap5 3.0.9 and it seemed to work initially - cleared caches and crashed.
Reading watchdog via Drush I got the following:
Drupal\Core\Theme\MissingThemeDependencyException:
Base theme stable9 has not been installed.
in Drupal\Core\Theme\ThemeInitialization->getActiveThemeByName() (line 115 of /[site]Saw this post:
https://designkojo.com/base-theme-stable9-has-not-been-installed
Enabled stable9 using Drush:
drush theme-enable stable9
Site came back up and seems to be working, but I get a DB upgrade warning.
Trying to update DB results in the following:
[site]# drush updb
------------ ------------------------- ------------- -----------------------
Module Update ID Type Description
------------ ------------------------- ------------- -----------------------
bootstrap5 install_stable9 post-update Enable new theme:
stable9.
bootstrap5 uninstall_stable_classy post-update Uninstall old themes:
stable and classy.
------------ ------------------------- ------------- -----------------------
Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes
> [warning] Post update function bootstrap5_post_update_install_stable9 not found in file bootstrap5.post_update.php
> [error] Update failed: bootstrap5_post_update_install_stable9
[error] Update aborted by: bootstrap5_post_update_install_stable9
[error] Finished performing updates.
At least the site seems to be working - any ideas here? Jeez...
Thanks for your help!
I'm on 9.5.10 and prepping to upgrade to Drupal 10 - I see no uninstall option as shown in #12. I could drush pm-uninstall, I suppose, but I'm using a subtheme of Bootstrap5 2.0.9. So if the following from #18 holds true for 2.0.9...
You need to uninstall Bootstrap5 version 2.0.5 if you want to be able to uninstall Classy and Stable. The reason for this is that Bootstrap5 2.0.5 is set up with Classy as a base theme, and it in turn depends on Stable.
I could end up completely borking the site. Any ideas? Suggestions greatly appreciated!
FYI - happens pretty much every time, perhaps with an occasional exception. Totally reproducible.
bcobin → created an issue.
Got it. Thanks for the suggestion (it was jCarousel.)
Thanks again!
How do I generate a backtrace? Thanks.
OK - here's what happens:
1. Change a block setting and save. (In this case, it was display or override title.)
2. Note that setting doesn't save.
3. Remove any title setting from block and save.
Result: Website reported an unexpected error. (Errors 1 and 2 from above.)
4. Delete block
Result: Website reported an unexpected error. (Error 3 from above.)
5. Re-assign block with desired settings and save.
Result: Success!
So there is a workaround, if you can deal with the error messages.
Any ideas? Thanks!
Thanks, Ravi! See below - there are three errors in the log for each failure.
Something occurs to me: I'm using a Bootstrap 5 subtheme for all affiliates; theme structure is:
themes > custom > subtheme > config > optional > block.block.[subtheme_name]_[various].yml
For each affiliate theme, I'm copying an existing theme and changing the name and content of the .yml file accordingly.
Here's what I'm wondering:
Each .yml file declares a specific ID:
langcode: en
status: true
dependencies:
config:
- system.menu.account
module:
- system
theme:
- [affiliate_theme]
id: [affiliate_theme]_account_menu
theme: [affiliate_theme]
region: nav_additional
weight: -7
provider: null
plugin: 'system_menu_block:account'
settings:
id: 'system_menu_block:account'
label: 'User account menu'
provider: system
label_display: '0'
level: 1
depth: 0
expand_all_items: false
visibility: { }Note the ID under settings. (In this case, id: 'system_menu_block:account')
I haven't changed these IDs. So although the names are different for each affiliate, could the errors be on account of the same id (in this case, 'system_menu_block:account') being used across several sites?
I don't see how this could/should affect custom blocks, though. In any event, below are the error messages. Thanks for reaching out - greatly appreciated!
Error #1:
Warning: Undefined array key "core.extension:global_overrides:[affiliate]_comen" in Drupal\domain_config_ui\Config\ConfigFactory->doLoadMultiple() (line 92 of /home/[site]/web/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php)
#0 /home/[site]/web/core/includes/bootstrap.inc(164): _drupal_error_handler_real(2, 'Undefined array...', '/home/[site]/...', 92)
#1 /home/[site]/web/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php(92): _drupal_error_handler(2, 'Undefined array...', '/home/icrmedia/...', 92)
#2 /home/[site]/web/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php(112): Drupal\domain_config_ui\Config\ConfigFactory->doLoadMultiple(Array, true)
#3 /home/[site]/web/core/lib/Drupal/Core/Config/ConfigFactory.php(89): Drupal\domain_config_ui\Config\ConfigFactory->doGet('core.extension')
#4 /home/[site]/web/core/lib/Drupal/Core/Extension/ThemeHandler.php(70): Drupal\Core\Config\ConfigFactory->get('core.extension')
#5 /home/[site]/web/core/modules/block/block.module(169): Drupal\Core\Extension\ThemeHandler->listInfo()
#6 [internal function]: block_rebuild()
#7 /home/[site]/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(409): call_user_func_array(Object(Closure), Array)
#8 /home/[site]/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(388): Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object(Closure), 'block')
#9 /home/[site]/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(416): Drupal\Core\Extension\ModuleHandler->invokeAllWith('rebuild', Object(Closure))
#10 /home/[site]/web/core/includes/common.inc(510): Drupal\Core\Extension\ModuleHandler->invokeAll('rebuild')
#11 /home/[site]/web/modules/contrib/admin_toolbar/admin_toolbar_tools/src/Controller/ToolbarController.php(205): drupal_flush_all_caches()
#12 [internal function]: Drupal\admin_toolbar_tools\Controller\ToolbarController->flushAll()
#13 /home/[site]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#14 /home/[site]/web/core/lib/Drupal/Core/Render/Renderer.php(583): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#15 /home/[site]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#16 /home/[site]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#17 /home/[site]/vendor/symfony/http-kernel/HttpKernel.php(166): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /home/[site]/vendor/symfony/http-kernel/HttpKernel.php(74): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#19 /home/[site]/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /home/[site]/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /home/[site]/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /home/[site]/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /home/[site]/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /home/[site]/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /home/[site]/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /home/[site]/web/core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /home/[site]/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#28 {main}Error #2:
Error: Call to a member function setModuleOverride() on null in Drupal\domain_config_ui\Config\ConfigFactory->doLoadMultiple() (line 92 of /home/[site]/web/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php).
Error #3:
Drupal\Core\Config\ConfigDuplicateUUIDException: Attempt to save a configuration entity 'babylon_subtheme_countdownblock' with UUID 'e911d7c4-df1d-4394-a00b-58209be2997f' when this entity already exists with UUID '43cf125a-1ed8-45ce-9cfc-297d6e0f5b72' in Drupal\Core\Config\Entity\ConfigEntityBase->preSave() (line 314 of /home/[site]/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php).
UPDATE: Crash only happens on Flush all caches - individual cache clears work OK. So there is a workaround.
Don't mean to reopen this (or perhaps I do) - my composer looks exactly like #7, but I still get:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/animate_css ^2.1 -> satisfiable by drupal/animate_css[2.1.0].
- drupal/animate_css 2.1.0 requires daneden/animate.css 4.1.1 -> found daneden/animate.css[3.7.2] but it does not match the constraint.
Any ideas? Thanks...
bcobin → created an issue. See original summary → .
bcobin → created an issue.
UPDATE: Title was not available as a searchable field at first - after futzing around (and disabling core search), it did.
Perhaps this will help someone else...
I'm running into the same issue - no matter what I do, Drupal search is not picking up node titles (making Search pretty much useless) and I was hoping that this module might help me to create a usable search. After reading comment #4 (this is also an online magazine with about 1,000 articles), I'm not even going to try.
In the meantime, if anybody can suggest how I can get plain old core Search to see note titles and forget about Search API, that would be great.
Thanks in advance...
Wow - it must have been me not being careful enough with the upgrade. (For one thing, I didn't go into maintenence mode - this is a dev site.)
When I enabled verbose error messages and reloaded the site, that may have cleared things out enough so that the site started working - who knows? In any event, perhaps this will help out someone who runs into the same issue.
Thanks for the prompt response! Much appreciated...
I had my host check out the "save" issue and they were able to make changes; when I checked again, things seemed to be behaving normally, although block changes seemed not always to "stick."
I then had a real problem with CKEditor5 - all sorts of weird behavior like HTML in blocks disappearing upon save, which was truly odd. I disabled CKEditor and was able to save; I re-enabled it and now things now seem to be behaving.
I'll be digging in more after the holiday and adding more domains - getting there, let us hope.
Thanks for everybody's help here - a Happy 4th to all!