Thanks.
So maybe it's NOT a terrible idea to simply edit my composer.json file (so it looks similar to yours)? I was worried that doing so might cause unforeseen complications.
Sorry, everyone. I just realized that the original builders of the site have some custom code that is complicating the behavior of this view. I assume that this is responsible for the problem, and so am going to close this topic.
Apologies for the overquick post.
Yes, this is correct. As I see it, it's the worst of all worlds. We have to carry around a heavy field that nets us almost nothing.
I suppose the way I should have phrased my question is my like this: In general, to what extent do un-displayed fields slow down node view operations? My assumption is that since this field isn't rendered on a page view, that it may not be slowing the site down. But I could imagine that my intuition here is wrong, as well.
In hindsight, I should have been more cautious in framing my reply to the OP. But I also have done a fair amount of successful db surgery over the years. So long as I make sure that a) I understand what I'm doing, b) I do it on dev instance, and c) I test my solution adequately, I have never had a problem from it.
I'm not sure which table gotten written to, but you can find it by logging into your database and using this command:
SELECT
table_schema as `Database`,
table_name AS `Table`,
round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB`
FROM information_schema.TABLES ORDER BY (data_length + index_length) DESC;That will show you the size of each table. I suspect that the bloated table will be at the top of this listing. You could then either truncate the table or remove the entries associated with the bot.
have you tried typing: composer composer prohibits drupal/core 10?
that should get a listing of which packages are blocking your progress.
it appears from your unix prompt (and the composer error) that you are logged in as root when running the upgrade. I believe you need to be logged in as a non-super-user to complete the upgrade. You may need to change some permissions to be able to do so, but it should be doable.
I'm attaching a screenshot that shows an example of how the Article edit form looks in my D10 install, before applying any correction to the styling.
I think I figured this one out for myself, at least temporarily.
I checked my old, working 9.5.9 install and noticed that the relevant CSS files in Claro had changed between then and the new 10.1.0 install. Patching the CSS so it reverts to the 9.5.9 syntax fixed the issue. I think this may be bad practice (not really sure what the proper build pipeline is for core assets), but I figured out enough to start a bug report in the Core issue area. If you're interested about the details, you can refer to that issue 🐛 updated Claro theme renders badly for some content type edit forms Postponed: needs info .
Thanks, so much, Jaypan. That did indeed fix that part of the code. And better, I think it gives me (thanks to your comments) what I needed to track down the other issues. I'm going to hold off on marking this as solved until I'm confident I've resolved the issue. But I think this puts me on me way.
Thanks again!
well that was interesting...I turned off JS aggregation and, voila, it started working like a charm!
I'll go back now to figure out why this was the case. But this was exactly the nudge I needed to move forward. So, thanks a million for that! I'll post a follow-up here when I figure out what was going on. But now now, please consider this solved.
Cheers!
Thanks for the suggestion. For clarity, I'm going to post the entire theme.libraries.yml for the site. Also, the root problem is this: after upgrading from 9.5.9 to Drupal 10, all javascript on the site is broken. This is the case in both my custom theme and in the admin theme (claro).
theme.libraries.yml (with a few variables anonymized):
global-styling:
css:
theme:
css/theme.styles.css: {}
swiper:
css:
theme:
libraries/swiper/dist/css/swiper.min.css: {}
js:
libraries/swiper/dist/js/swiper.min.js: {}
dependencies:
- [anonymous]/global-scripts
ableplayer:
css:
theme:
libs/ableplayer/build/ableplayer.min.css: {}
js:
libraries/js-cookie/src/js.cookie.js: {}
libs/ableplayer/build/ableplayer.min.js: {}
dependencies:
- [anonymous]/global-scripts
formstone:
css:
theme:
libraries/formstone/dist/css/checkbox.css: {}
js:
libraries/formstone/dist/js/core.js: {}
libraries/formstone/dist/js/mediaquery.js: {}
libraries/formstone/dist/js/equalize.js: {}
libraries/formstone/dist/js/checkbox.js: {}
dependencies:
- miller/global-scripts
global-scripts:
js:
libraries/modernizr/modernizr.js: {}
libraries/countto/jquery.countTo.js: {}
js/animations.js: {}
js/script.min.js: {}
dependencies:
- core/jquery
- core/drupal
- core/once
handlebars:
js:
libraries/handlebars/handlebars.js: {}
underscore:
js:
libraries/underscore/underscore-min.js: {}
react-app:
js:
app/build/static/js/main.drupal.chunk.js: { preprocess: 0, minified: true }
app/build/static/js/2.drupal.chunk.js: { preprocess: 0, minified: true }
app/build/static/js/runtime~main.drupal.js: { preprocess: 0, minified: true }
prp-landing-app:
js:
landingapp/build/static/js/main.drupal.chunk.js: { preprocess: 0, minified: true }
landingapp/build/static/js/2.drupal.chunk.js: { preprocess: 0, minified: true }
landingapp/build/static/js/runtime~main.drupal.js: { preprocess: 0, minified: true }
Thanks. I'll read up on each of these issues. I figured that was the best option but wanted to see if I was missing some bit of insight that could save me the work :/
I appreciate the help. Marking this issue as SOLVED.
Thanks, gisle. This is helpful. But I should have been clearer. The example I showed was just one among many, most of which are quite different. The reported problems run a wide gamut.
Maybe the answer is that I need to research each problem to see if it's a false positive, as you pointed out with that accessCheck method.
But I wonder if there's any general rule I can infer about modules that show up in this part of the upgrade_status report--"compatible" but with reported problems. Is it plausible, for instance, that the supposed problems in this class aren't severe enough to prevent upgrading? If no general rule is correct, that's of course fine. I'm just trying to understand what upgrade_status is communicating here.
I have a question about this issue.
First, the setting: site is running Drupal 9.5.9, PHP 8.1. I just switched to ckeditor5 as part of my preparations for migrating to Drupal 10.
I am trying to apply the patch released on this thread to prevent my editor fields from auto-growing. However, I'm finding a strange bug in the process.
If I apply a very simple patch that simply adds the relevant css to editor.css (or any of the patches on this thread, but I'm trying to keep things simple), the patch applies and it has the desired effect on auto-grow. But another thing happens, too...
The file docroot/core/modules/node/src/NodeViewBuilder.php also gets changed, like so:
--- a/docroot/core/modules/node/src/NodeViewBuilder.php
+++ b/docroot/core/modules/node/src/NodeViewBuilder.php
@@ -93,10 +93,15 @@ public static function renderLinks($node_entity_id, $view_mode, $langcode, $is_i
'#attributes' => ['class' => ['links', 'inline']],
];
- if (!$is_in_preview) {
+ if ($is_in_preview) {
$storage = \Drupal::entityTypeManager()->getStorage('node');
/** @var \Drupal\node\NodeInterface $revision */
$revision = !isset($revision_id) ? $storage->load($node_entity_id) : $storage->loadRevision($revision_id);
+
+ if(!isset($revision)) {
+ return links;
+ }
+
$entity = $revision->getTranslation($langcode);
$links['node'] = static::buildLinks($entity, $view_mode);These changes--I'm pretty sure it's these changes--cause Drupal to WSOD on node saves for some, but not all, content types. The stacktrace on these errors is like so:
2023/06/07 13:53:07 [error] 1890#1890: *13713 FastCGI sent in stderr: "PHP message: AssertionError: Cannot load the "node" entity with NULL ID. in /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php on line 295 #0 /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(295): assert(false, 'Cannot load the...')
#1 /var/www/html/docroot/core/modules/node/src/NodeViewBuilder.php(99): Drupal\Core\Entity\EntityStorageBase->load(NULL)
#2 [internal function]: Drupal\node\NodeViewBuilder::renderLinks(NULL, 'full', 'en', false, NULL)
#3 /var/www/html/docroot/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array(Array, Array)
#4 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(788): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #lazy_bu...', 'exception', 'Drupal\\Core\\Ren...')
#5 /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php(353): Drupal\Core\Render\Renderer->doCallback('#lazy_builder', Array, Array)
#6 /var/www/html/docroot/core/lib/Drupal/Core/Render/Rende" while reading response header from upstream, client: 172.18.0.7, server: , request: "POST /node/add/external_headline HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm.sock:", host: "prod.local.ddev.site", referrer: "https://prod.local.ddev.site/node/add/external_headline"
[07-Jun-2023 13:53:31] WARNING: [pool www] child 21176 said into stderr: "NOTICE: PHP message: AssertionError: Cannot load the "node" entity with NULL ID. in /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php on line 295 #0 /var/www/html/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(295): assert(false, 'Cannot load the...')"Does anyone have insight into why a patch on a css file in ckeditor5 is causing changes in drupal/core?
In case it helps, I started with the patches listed on this thread. When I ran into problems, I removed them and used a minimal patch to only that single css file. But the outcome is the same: for some content types, after applying the patch, node saves bomb out.
I'd really love to disable that auto-grow feature, but so far this is making that impossible.
In case someone finds this post later, I wanted to describe how I fixed this issue.
After taking the steps recommended earlier in this thread, my kit was in better shape. If I used my composer.json file to create a fresh install, I could then upgrade to D10 successfully. However, composer continued to complain and prohibit the upgrade on my real code base. I believe there were two issues I needed to resolve.
First, there was the issue of modules that I had patched into D10 compliance. Composer didn't recognize these as valid out of the gate. I resolved this by using the composer lenient plugin. Adding the modules that didn't have compliant releases to this allowed composer to move past these.
The second issue was making sure to remove the upgrade_status module. As others have mentioned, I'm fairly sure this was blocking the upgrade.
Lastly, not sure if this was crucial, but before upgrading I removed the require-dev statement relying on core-dev 9--eventually adding in the D10 core-dev after the main upgrade.
With these steps under my belt I was able to complete the upgrade. I hope this helps others.
Thanks so much. Super helpful. This gives me a path forward.
I do have one question, though: with drupal/components and drupal/simple_timeline, upgrade_status did indeed warn about D10 incompatibility. For a variety of reasons (no D10-compliant simple_timeline version and the D10-compliant components version broke my site due to a known bug), I patched these two modules instead of upgrading them. After the patching, upgrade_status ok'ed them for D10 migration. However, composer still balked at them.
I can understand why composer errors out at these. After all, how can it know, without a full code scan, that they have been patched into compliance? However, I still wonder if it's possible for me to use my patched versions to complete the upgrade.
For instance, would it be possible for me to take the steps you outlined, then upgrade to D10, and then finally bring the patched modules back in? I guess I can try it and see ;)
But I'd be keen to hear what the general knowledge is about using patched modules to enable upgrading.
Thanks again!
thanks. good idea. i just added it to the thread.
{
"name": "drupal/recommended-project",
"description": "Project template for Drupal 9 projects with a relocated document root",
"type": "project",
"license": "GPL-2.0-or-later",
"homepage": "https://www.drupal.org/project/drupal",
"support": {
"docs": "https://www.drupal.org/docs/user_guide/en/index.html",
"chat": "https://www.drupal.org/node/314178"
},
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
"require": {
"composer/installers": "^1.9",
"cweagans/composer-patches": "^1.7",
"drupal/admin_toolbar": "^3.2",
"drupal/antibot": "^2.0",
"drupal/classy_paragraphs": "^1.0@beta",
"drupal/components": "^2.2",
"drupal/core-composer-scaffold": "^9",
"drupal/core-project-message": "^9",
"drupal/core-recommended": "^9.3",
"drupal/ctools": "^3.7",
"drupal/devel": "^5.1",
"drupal/entity_reference_revisions": "^1.9",
"drupal/extlink": "^1.6",
"drupal/fontawesome": "^2.19",
"drupal/google_analytics": "^4.0",
"drupal/honeypot": "^2.0",
"drupal/image_style_warmer": "^1.2@RC",
"drupal/inline_entity_form": "^1.0@RC",
"drupal/oembed_providers": "^2.0",
"drupal/paragraphs": "^1.12",
"drupal/pathauto": "^1.8",
"drupal/radix": "^4.10",
"drupal/redis": "^1.5",
"drupal/s3fs": "^3.0@beta",
"drupal/s3fs_cors": "^1.0@RC",
"drupal/search_api": "^1.20",
"drupal/search_api_solr": "^4.2.1",
"drupal/simple_timeline": "^1.2",
"drupal/smtp": "^1.0",
"drupal/upgrade_status": "^4.0",
"drush/drush": "^10.4",
"kint-php/kint": "^3.3"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"sort-packages": true,
"allow-plugins": {
"composer/installers": true,
"cweagans/composer-patches": true,
"drupal/core-composer-scaffold": true,
"drupal/core-project-message": true,
"dealerdirect/phpcodesniffer-composer-installer": true
}
},
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
],
"web/modules/custom/{$name}": [
"type:drupal-custom-module"
],
"web/themes/custom/{$name}": [
"type:drupal-custom-theme"
]
},
"drupal-core-project-message": {
"include-keys": [
"homepage",
"support"
],
"post-create-project-cmd-message": [
"<bg=blue;fg=white> </>",
"<bg=blue;fg=white> Congratulations, you’ve installed the Drupal codebase </>",
"<bg=blue;fg=white> from the drupal/recommended-project template! </>",
"<bg=blue;fg=white> </>",
"",
"<bg=yellow;fg=black>Next steps</>:",
" * Install the site: https://www.drupal.org/docs/8/install",
" * Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html",
" * Get support: https://www.drupal.org/support",
" * Get involved with the Drupal community:",
" https://www.drupal.org/getting-involved",
" * Remove the plugin that prints this message:",
" composer remove drupal/core-project-message"
]
},
"patches": {
"drupal/oembedProviders": {
"brittles regexes": "https://www.drupal.org/files/issues/2020-11-03/oembed_providers-scheme-validation-error-3177978-10.patch"
},
"drupal/core": {
"bad image upload in media library": "./patches/media_library_silent_upload_fail.patch"
},
"drupal/components": {
"fixes d10": "./patches/components_d10.patch"
},
"drupal/radix": {
"fixes d10": "./patches/radix_new_d10.patch"
},
"drupal/simple_timeline": {
"fixes d10": "./patches/simple_timeline_d10.patch"
}
}
},
"require-dev": {
"drupal/core-dev": "9.5.7"
}
}
Thanks, gisle. Super helpful. I'll certainly put those ideas into place.
Regarding the "view published content" permission, really it will be fine for Anonymous users to see a 403--this site is strictly for members of a small project team. Maybe I'll route that traffic to something more friendly, but maybe not. I think this solution accomplishes what I'm after.
Cheers.
Thanks. I appreciate the advice. I'll try to work my efforts into the various modules' maintenance workflow.
Cheers.
I think @kachinsky raises an interesting point, even though it's not views-specific. If SQL queries are getting built in a wonky way somewhere else (i.e. those group_by statements), couldn't that be responsible for the problem we're seeing in views?
Wanted to chime in that I have the same issue. N.B. db updates/cache clear do not resolve the problem.
For context, this is running on a site using D9.5.7 as I prepare for migration to D10.
I just uploaded the config files to this issue. Please let me know if they aren't properly visible.
As a follow-up to my last post, I tried an experiment and got interesting results.
I wanted to see if I could import the working config to rebuild the broken view, and in the process, fix the break.
So I deleted the original, broken view and then imported the configuration from the working copy, replacing the UUID, id, and label fields with the data from the original. However, when I did the import, the resulting view still had the same SQL problem. So I tried again several times, keeping ALL fields constant except one at a time.
What I found was that the "id" field in the configuration seems to be the one that causes the sensitivity. That is, the original view had the id `presidential_recording`. If I change that to, say `new_presidential_recording`, keeping all other fields as in the config file (either one, working or the original, broken config), then the resulting view is fine.
So for whatever reason, there seems to be something about how the view's "id" field is handled that is causing the problem.
No other modules have changed during this update; core is the only variable. I exported the configurations of the working and non-working versions of the view and here is the result:
diff views_working.yaml views_broken.yaml
1c1
< uuid: 00ee2f69-33e9-4795-a0c0-784c1c5b6dda
---
> uuid: 9489b3b0-8df3-473b-8776-5bb36a41eecb
22,23c22,23
< id: duplicate_of_presidential_recording
< label: 'Duplicate of Presidential Recording'
---
> id: presidential_recording
> label: 'Presidential Recording'
606a607,609
> relationship: none
> group_type: group
> admin_label: ''
609a613
> operator: '='
611a616
> exposed: false
612a618,621
> operator_id: ''
> label: ''
> description: ''
> use_operator: false
615a625,642
> identifier: ''
> required: false
> remember: false
> multiple: false
> remember_roles:
> authenticated: authenticated
> is_grouped: false
> group_info:
> label: ''
> description: ''
> identifier: ''
> optional: true
> widget: select
> multiple: false
> remember: false
> default_group: All
> default_group_multiple: { }
> group_items: { }
I'm not familiar enough with views to make much sense of this. But in case it's helpful, I built the working copy simply by using the `duplicate` function on the original, broken one.