Additional notes about the problem described above:
After uninstalling drupal/minifyhtml (2.0.4) and removing the drupal/minifyhtml code from the project ...
The error regarding - 'minifyhtml' is not a supported key - still appears (see screenshot on drupal slack)
[composer update run, showing drupal/minifyhtml removal]
vendor/bin/drush state:set system.maintenance_mode 1
composer.phar update --with-all-dependencies
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 2 updates, 4 removals
- Removing drupal/minifyhtml (2.0.4)
- Removing drupal/minifyjs (3.0.1)
- Removing matthiasmullie/minify (1.3.73)
- Removing matthiasmullie/path-converter (1.1.3)
- Upgrading mglaman/phpstan-drupal (1.2.7 => 1.2.8)
- Upgrading phpstan/phpdoc-parser (1.26.0 => 1.27.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 2 updates, 4 removals
- Downloading mglaman/phpstan-drupal (1.2.8)
- Downloading phpstan/phpdoc-parser (1.27.0)
- Removing matthiasmullie/path-converter (1.1.3)
- Removing matthiasmullie/minify (1.3.73)
- Removing drupal/minifyjs (3.0.1)
- Removing drupal/minifyhtml (2.0.4)
- Upgrading mglaman/phpstan-drupal (1.2.7 => 1.2.8): Extracting archive
- Upgrading phpstan/phpdoc-parser (1.26.0 => 1.27.0): Extracting archive
Deleting /modules/minifyjs/ - deleted
Deleting /modules/minifyhtml/ - deleted
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
vendor/bin/drush -n -y updb
[success] No pending updates.
vendor/bin/drush -n -y cr
The same error:
'minifyhtml' is not a supported key.
appeared on the Home > Administration > Configuration > Development page today while maintaining one of our sites.
A problem that appears similar the problem described throughout this thread occurred after updating a site to D10.2.4.
After the 10.2.4 update, The "available updates" report displays only about 5 out of 60 or more installed contrib modules and themes.
None of the suggestions provided in this thread have solve the problem.
-
1. When the "available updates" report broke, it continues to list a few modules, but not all.
2. Modules installed after this problem began appear correctly in the "available updates" report.
3. executing the following command via drush does not repair the problem:
php -c ./php.ini vendor/bin/drush php:eval "\Drupal::keyValue('update_fetch_task')->deleteAll();"
4. installing the https://www.drupal.org/project/update_narf → module does not repair the problem.
5. the following drush command displays all the contrib modules. Obviously drush is doing something different from the "available updates" report.
php -c ./php.ini vendor/bin/drush pm-list --type=Module --no-core --format=list
5. Does anyone have any additional suggestions or insights about this problem and about how to repair it?
6. applying the patch below does not repair the problem. However, the patch does not appear to break anything.
diff --git a/core/modules/update/src/UpdateProcessor.php b/core/modules/update/src/UpdateProcessor.php
index a07a47c8f5..c4de5df0a3 100644
--- a/core/modules/update/src/UpdateProcessor.php
+++ b/core/modules/update/src/UpdateProcessor.php
@@ -121,7 +121,7 @@ public function createFetchTask($project) {
if (empty($this->fetchTasks)) {
$this->fetchTasks = $this->fetchTaskStore->getAll();
}
- if (empty($this->fetchTasks[$project['name']])) {
+ if (empty($this->fetchTasks[$project['name']]) || $this->fetchTasks[$project['name']] !== $project) {
$this->fetchQueue->createItem($project);
$this->fetchTaskStore->set($project['name'], $project);
$this->fetchTasks[$project['name']] = REQUEST_TIME;
diff --git a/core/modules/update/tests/src/Functional/UpdateSemverCoreTest.php b/core/modules/update/tests/src/Functional/UpdateSemverCoreTest.php
index 4573cff6c0..87fc2f03a9 100644
--- a/core/modules/update/tests/src/Functional/UpdateSemverCoreTest.php
+++ b/core/modules/update/tests/src/Functional/UpdateSemverCoreTest.php
@@ -193,12 +193,12 @@ public function testFetchTasks() {
$this->assertEquals(2, $queue->numberOfItems(), 'Queue contains two items');
// Try to add a project again.
update_create_fetch_task($project_a);
- $this->assertEquals(2, $queue->numberOfItems(), 'Queue still contains two items');
+ $this->assertEquals(3, $queue->numberOfItems(), 'Queue still contains three items');
// Clear storage and try again.
update_storage_clear();
update_create_fetch_task($project_a);
- $this->assertEquals(2, $queue->numberOfItems(), 'Queue contains two items');
+ $this->assertEquals(4, $queue->numberOfItems(), 'Queue contains four items');
}
/**
diff --git a/core/modules/update/update.install b/core/modules/update/update.install
index b77654d622..b067b788dd 100644
--- a/core/modules/update/update.install
+++ b/core/modules/update/update.install
@@ -87,6 +87,8 @@ function update_uninstall() {
$queue = \Drupal::queue('update_fetch_tasks');
$queue->deleteQueue();
+
+ \Drupal::keyValue('update_fetch_task')->deleteAll();
}
/*
The terms - allow-list - and - ban-list - seem appropriate.
Many related modules have IP address whitelist entry features.
It is absolutely imperative that this module have an IP address whitelist management feature.
No drupal site builder wants to get IP banned from their own website while working on it.
-
When this module IP banned me, I was fortunately, able to quickly pop into my VPN (generating a fresh IP address) and was then able to remove the erroneous IP ban the drupal IP ban module list.
It is my experience as well that switching to [source] mode to insert a fontawesome icon into a ckeditor5 edit block, and then switching out of [source] mode causes the entire drupal page to lockup. This bug causes the page to hammer CPU usage, and to use all available memory until the web browser page crashes with an "Error code: RESULT_CODE_HUNG" error.
Below is the test text with a fontawesome icon that I used to crash an entire web browser page during /node/add/{contenttype}
<p><i class="fa-solid fa-envelope-circle-check"> </i> this is some text with a fontawesome icon at the left.</p>
With notes above lasting for over a year, why couldn't the maintainers of these various modules have coordinated better with each other so that users of these modules aren't left with the glaring "Not Supported!" in their site's available updates.
There are about three dozens reports now above about the difficulties users have experienced trying to migrate by hand from "media library them reset" to the newly support layout_builder_iframe_modal module.
Note that #33 is just three days old, but the problem reports date back as far as an entire year.
--
This type of lack of planning, and lack of coordination, is part of why the Drupal user base keeps getting smaller and smaller and smaller.
Thank you for your suggestion @cilefen.
The update runs correctly when executed via {site}/update.php.
This problem with drush compatibility seems somewhat important since many drupal site builders are using shell scripts to run code updates, including composer.phar module updates that also include running drush updb and drush cr.
Might the conclusion to reach be that there is some kind of problem with the code path that drush uses to execute the updates?
websiteworkspace → created an issue.
Thanks @ diamondsea → for your solution above to this problem.
Based on the code provided in 2018 by diamondsea → , below is an updated version that works for Drupal 10 (running on 10.2.0).
This template needs to be placed in the templates directory for the theme one's drupal site is using.
for example in a folder much like the following:
{site base directory}/themes/custom/snazzycustomdrupaltheme/templates
where {snazzycustomdrupaltheme} would be replace with the name of your drupal site's theme.
The relative file path would be the following:
{site base directory}/themes/custom/snazzycustomdrupaltheme/templates/item-list.html.twig
{% extends "item-list.html.twig" %}
{#
/**
* @file
* Theme override for an item list of search results.
*
* Available variables:
* - items: A list of items. Each item contains:
* - attributes: HTML attributes to be applied to each list item.
* - value: The content of the list element.
* - title: The title of the list.
* - list_type: The tag for list element ("ul" or "ol").
* - attributes: HTML attributes to be applied to the list.
* - empty: A message to display when there are no items. Allowed value is a
* string or render array.
* - context: An list of contextual data associated with the list. For search
* results, the following data is set:
* - plugin: The search plugin ID, for example "node_search".
*
* @see template_preprocess_item_list()
*/
#}
{%
set classes = [
'search-results',
context.plugin ~ '-results',
]
%}
{% set attributes = attributes.addClass(classes) %}
{% set empty = empty|merge({'#value':
"
<h4 class='no-search-results'>Your search didn't yield any results</h4>
<ul>
<li>Check that your spelling is correct.</li>
<li>Try removing quotes around phrases to search for each word individually. <em>bike shed</em> will often show more results than <em>'bike shed'</em>.</li>
<li>Consider loosening your query with <em>OR</em>. <em>bike OR shed</em> will often show more results than <em>bike shed</em>.</li>
</ul>
"
})
%}Note that the template code change just above is based on the following code in the current SearchController.php code, where the array that needs modification is now named #value:
$build['search_results'] = [
'#theme' => ['item_list__search_results__' . $plugin->getPluginId(), 'item_list__search_results'],
'#items' => $results,
'#empty' => [
'#type' => 'html_tag',
'#tag' => 'em',
'#value' => $this->t('Your search yielded no results.'),
],
'#list_type' => 'ol',
'#context' => [
'plugin' => $plugin->getPluginId(),
],
];
the big pipe module seems to be causing some of the blocks on the current site I'm working on to disappear as well.
-
In this example, the block is - basic block - containing just copyright declaration text.
When logged in, the block is replaced by a following span element
<div class="region region-sub-footer-first">
<span data-big-pipe-placeholder-id="callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=cscs_block_subfooter_copyright&args%5B1%5D=full&args%5B2%5D&token=5lVI4mHWyZIwLY6wWm5pTSMuev7kcD5R5ljc1PnhoYU">
</span>
</div>
When logged out (anonymous mode) the block displays as it should, as follows:
<div class="region region-sub-footer-first">
<div id="block-cscs-block-subfooter-copyright" class="clearfix block block-block-content block-block-content4e8b2554-2f43-45f8-b73a-fb2ac44c0812">
<div class="content">
<div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item">
<div class="text-md-start text-lg-left">Copyright © 2023 - <a style="text-decoration:none;" href="https://www.someurl.net/">www.placeholderurl.com</a> - All rights reserved
</div>
</div>
</div>
</div>
</div>
Is there a way to repair this problem?
Just a guess ... however, might the PHP crash problem documented above be related to the following code in the source file:
PlyrSharedTrait.php
// if ($provider === 'vimeo') {
// // @adjust when needed, see https://github.com/vimeo/player.js/#embed-options
// $vimeo = new stdClass();
// $vimeo->muted = TRUE;
// $vimeo->background = TRUE;
// $settings['vimeo'] = $vimeo;
// }
if ($provider === 'youtube') {
// @see https://developers.google.com/youtube/player_parameters#Parameters
$settings['youtube'] = $this->youtubeNoCookie();
}
return $settings;
}
public function youtubeNoCookie(): stdClass {
$youTube = new \stdClass();
$youTube->noCookie = (bool) $this->settings['youtube']['noCookie'];
return $youTube;
}
websiteworkspace → created an issue.