Notice: Undefined index: title in Drupal\update\ProjectSecurityRequirement

Same her, and I was also playing with taxonomy on my side.
I'm on a drupal 8.8.5, on a recent project.

Update : The problem disappeared after "manually checking for available updates." (link here : /admin/reports/updates )
Must have been a temporary data recovery issue.

Hi
i had the the exact same issue, that just spawned,
it disappeared by itself after visiting admin/reports/updates

Same here. Solution/workaround in #5 works.

Same problem here with

Notice: Undefined index: title in Drupal\update\ProjectSecurityRequirement::createFromProjectDataAndSecurityCoverageInfo() (Zeile 107 in /web/core/modules/update/src/ProjectSecurityRequirement.php).

I further debugged this and added the following debug output:

if(!isset($project_data['title'])){
  kint($project_data);
}

in line 106 of \web\core\modules\update\src\ProjectSecurityRequirement.php

$project_data is the following

array(11)
    'name' => string(6) "drupal"
    →'info' => array(6)
    'datestamp' => integer0
    →'includes' => array(53)
    →'project_type' => string(4) "core"
    'project_status' => boolTRUE
    'existing_version' => string(5) "8.8.5"
    'existing_major' => string(1) "8"
    'install_type' => string(8) "official"
    'status' => integer-2
    →'reason' => Drupal\Core\StringTranslation\TranslatableMarkup(5) 

So there is no "title" key for Drupal core which leads to the notice.

MIGHT be related to #3118087: If any extension has a missing or invalid version, Update manager throws errors and is confused about site update status

I did not see this error before, but now after new version 8.8.6 is available, I also see it.
#5 works.

I had the same error until I checked for updates manually as suggested by jorisInsign in comment #3

Thanks @the_glitch, that might be a good hint to find the reasons for the issue in code. Anyway the user shouldn't be forced to to that to solve the issue. Code should prevent this from happening.

Well most users aren't really forced to do that because most users probably don't even know that doing that is a solution at all. And yes it's bad UX even if everybody does know what to do.

This is now happening to me. Drupal core 8.8.6.

+1 D8.8.5

Present on 8.8.5 too

@Anybody Re: #8: Thanks for the debugging info, very helpful! However, this is extremely weird and concerning:

    'status' => integer-2

In the code, that corresponds to:

interface UpdateManagerInterface {
  ...
  /**
   * Current release has been unpublished and is no longer available.
   */
  const REVOKED = 2;
  ...
}

🤔That makes no sense. 😉 Even if you're on 8.8.5 and 8.8.6 is now available, 8.8.5 shouldn't be getting marked as "Revoked". That should only happen if either Drupal core itself is unpublished, or the 8.8.5 release is unpublished. https://updates.drupal.org/release-history/drupal/current shows that we have 0 core releases that have been unpublished. So I have no idea how your site got into that state. If you grep for 'REVOKED' you'll see it's only used to set the status in 2 places.

I've tried recreating this locally with my net connection off, clearing caches, drush ev "\Drupal::keyValueExpirable('update_available_releases')->deleteAll();", etc. I only get the warnings that the site failed to fetch available update data, I never get this weird partial state where there's incomplete data, missing values, etc.

I wish someone (anyone) could come up with reliable steps to trigger / reproduce this. Without that, I really have no idea how to safely solve this.

Meanwhile, we can obviously do something trivial to silence the warning, but that's almost certainly going to be masking a deeper bug that we should really understand before this issue is fixed. Or we fix the obvious thing now and open a follow-up to try to understand the deeper problem. Not up to me to decide.

Anyway, digging deeper:

1. This was new code added in #2991207: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases and follow-ups. Over there, I raised concerns that this class is basically written to assume Drupal core, but only partly. It's a mix of "This only works and is used for core", with "it might be used for any project someday".
2. Looking closely, the class never uses the protected $projectTitle member. At all. :( So, we're generating these warnings and causing all the traffic in this issue to correctly set information we completely ignore.
3. Until that class is extended to handle multiple projects, and invoked by core for multiple projects, it's kind of pointless to figure out why $data['title'] is empty for core so we can set a variable we never use.

- - -

So, here are 2 possible patches to "solve" this problem:

A) Stop pretending that the label 'Drupal core' will ever change and that we should be relying on the release history XML feed to get the right value. If we only instantiate this object for core, let's just hard-code the value we know we want.

or

B) Completely purge self::projectTitle from this class, since it's all dead code, anyway. Thanks to #3116198: Make ProjectCoreCompatibility class final and internal the class is marked @internal, so I believe we can freely ignore any BC implications of changing the signature on the constructor, etc.

No idea if either of these would fly with the core committers. ;) But at least we can get started on a solution to this bug that's clearly impacting live sites.

same issus started on my D8.8.5 after editing a view.
#5 fixed
So weird, but so good so far

@all: If you hit this warning, before visiting admin/reports/updates can you try the patch in #16 to confirm it works for you and comment here with the results?

Thanks!
-Derek

@dww

I applied this patch. I did not visit admin/reports/updates.

Patch applied:
3132426-16B-remove-dead-code.patch

... and the problem seems to have resolved. I have been working on and navigating through the site for a couple of hrs with no issues. Thanks

Note that I could not run both patches listed. Please remove one of them. I used the 16B patch.

This problem occurred while I was working with taxonomy terms and the group module.

@hga77 re: #19: Thanks for testing! Glad to know #16B solved your troubles.

Re:

Note that I could not run both patches listed. Please remove one of them. I used the 16B patch.

Right. They are 2 separate approaches to solving this bug. They can't both be applied. But I'm not going to "remove" one until a core committer specifies their preference on which path to continue down.

Thanks again!
-Derek

#16B removed the notice for me.

Patches #16A and 16B applied and tested. Works well so far. Thanks @dww

Patch #16A also works for me. Both have been tested by a few people, so a core committer should decide on approach.

Drupal 8.9.0
Screen: https://prnt.sc/suyyew
Not sure, but it seems to me that #5 helped me.
P.S. I not use any patch from this issue.

I had the same issue after reading the comments and visiting admin/reports/updates it disappeared.

visiting admin/reports/updates doesn't fix the problem, after some times the message is back

i did apply the patch 16A on drupal 8.9.0 and the message disappeared

    'status' => integer-2

  const REVOKED = 2;

About this strange REVOKED status, I would suggest digging it in a separate issue. This is a real bug, so hoping that it gets committed ASAP personally.

From the feedback in #17, #19, #21-#25, and #27, the two patches in #16 are both valid, so I do not have to do a manual test again.

+++ b/core/modules/update/src/ProjectSecurityRequirement.php
@@ -62,8 +53,7 @@
+  private function __construct(array $security_coverage_info = [], $existing_major_minor_version = NULL, $next_major_minor_version = NULL) {
     $this->securityCoverageInfo = $security_coverage_info;

B) Completely purge self::projectTitle from this class, since it's all dead code, anyway. Thanks to #3116198: Make ProjectCoreCompatibility class final and internal the class is marked @internal, so I believe we can freely ignore any BC implications of changing the signature on the constructor, etc.

I prefer the patch 3132426-16A-hardcode-core-title.patch which got no chance to have BC issues compared with 3132426-16B-remove-dead-code.patch even which is @internal and should not have any BC issues too.

RTCT-ing to have opinions from committer(s). Tagging "Bug Smash Initiative", pend tagging "Needs followup".

I think given the class is both final and the constructor is private doing remove dead code patch is fine. But what still gives me pause is that we don't understand why this array key is not set. Given this is about the data we use to upgrade sites understanding that feels important and not something we should solve without taking stock.

Moving back to needs review to take and installing 8.8.5 myself to see what happens for me.

It's a real shame that #8 doesn't contain the contents of 'reason' => Drupal\Core\StringTranslation\TranslatableMarkup(5) as that would have given us a bit more to go on.

The status is -2 not 2 so the actual status is const UPDATE_UNKNOWN = -2;.

Okay I can reproduce the fail... it's kinda fun.

1. \Drupal\update\UpdateFetcher::fetchProjectData() change to return NULL to simulate a failed update get.
2. Install standard
3. Visit admin/reports/status
4. Visit admin/structure (this is not actually necessary but it is important you no longer visit admin/reports/status because doing so rebuilds a cache you've just set and we don't want that to happen.
5. Fix \Drupal\update\UpdateFetcher::fetchProjectData() to return $data.
6. Use drush - drush ev "\Drupal::keyValueExpirable('update_available_releases')->deleteAll();" - this ensures we'll get the available updates again.
7. Use drush to run cron - this will get the available updates - drush cron
8. Visit admin/structure and BOOM!

So why does this happen - well the available updates state and the \Drupal::service('update.manager')->projectStorage('update_project_data'); get out of sync.

So the fix is to do \Drupal::keyValueExpirable('update')->delete('update_project_data') - when we fetch fresh update data.

Patch attached fixes the issue. Maybe @dww knows the test coverage well enough to know if this is testable?

Note there is a workaround to clear the error - if you visit admin/reports/status it'll rebuild the cache and everything will work as expected. Or you can run drush ev "\Drupal::keyValueExpirable('update')->delete('update_project_data');" from the command line.

#5

Fixed for me, just visited admin/reports/updates fixed the issue

@Mohamed.Osama yep this is expected - see #31 explains why.

Migrated content type from D7 to D9.0.1 and ended up with the same notice.
drush ev "\Drupal::keyValueExpirable('update')->delete('update_project_data');"
Made it go away.

New migration project in its early stages but I should be able to re-produce this.

Here's test coverage. The test coverage is the interdiff.

random unrelated test fail.

Thanks for getting to the bottom of this, and providing test coverage! 🙏 Huzzah. 🎉

I agree with the analysis in #30 and the fix to clear the stored projects after any successful fetch task makes sense. If we had the info split up and cached per project, we should only need to clear the info for 1 project. But that's not how it works. 😉

Only a few tiny doc nits in the test:

1. +++ b/core/modules/update/tests/src/Functional/UpdateCoreTest.php
   @@ -862,6 +862,44 @@ public function testRevokedRelease() {
   +    // Use update xml that has no information to simulates a broken response
   +    // from the update server.
   

   a) s/xml/XML/
   b) s/simulates/simulate/

2. +++ b/core/modules/update/tests/src/Functional/UpdateCoreTest.php
   @@ -862,6 +862,44 @@ public function testRevokedRelease() {
   +    // again and before the state used by
   

   needs 'is' btwn state and used.

3. +++ b/core/modules/update/tests/src/Functional/UpdateCoreTest.php
   @@ -862,6 +862,44 @@ public function testRevokedRelease() {
   +    // This cron run will retrieve fixed updates.
   

   s/will/should/ ? ;)

Since it's only doc cleanups, I'll post them myself, and I think I'd still be okay to RTBC...

A couple of thoughts...

+++ b/core/modules/update/src/UpdateProcessor.php
@@ -192,6 +192,10 @@ public function processFetchTask($project) {
+    // Delete any stored project data as that needs refreshing when
+    // update_calculate_project_data() is called.
+    $this->tempStore->delete('update_project_data');

Is this really the correct place to do this? Because it's an UpdateProcessor - so it's theoretically changeable. No contrib does this mind you - http://grep.xnddx.ru/search?text=UpdateProcessorInterface&filename= - the whole architecture of the Update module seems a bit too flexible to me. It's all these layers that make it hard to reason about and maintain.

Anyhow there isn't really other place to do this because this needs to happen when the queue item is processed and other kind of global stuff that other implementations would have to do are done here - for example:

     // Whether this worked or not, we did just (try to) check for updates.
    $this->stateStore->set('update.last_check', REQUEST_TIME + $request_time_difference);

So I guess this is okay.

God bless #34. A simple Drush command.

Re: #42 -- yeah, I agree it's too flexible.

<aside class="ranting history">
It was originally written without OO. As the "Update Manager" aspects (not just "Update Status", but the whole installing / updating functionality) was moving into core, it was the earliest days of core's acceptance of OO, and @JacobSingh was really excited about OO-ifying things. We didn't know much then about how everything was really going to pan out, we were victims of non-YAGNI thinking, and we made some bad decisions. Then I peaced out for a few years (to get my first album out, among other things) and Update Manager floundered along with D8 porting and conversions without any clear maintainer or direction. Everyone just did whatever they thought was best at the time without a real big picture plan.

All sorts of other subsystems changed out from under it, things got more and more complex and flexible, and we never stopped to take a close look at the architecture and what we wanted.

Now that the auto updates initiative is a thing, plus the Composer-ification of the DrupalVerse, it seems like it'd be a waste of time to pour too much effort into refactoring and reorganizing all this. I argued many months ago that instead of investing huge effort into supporting contrib semver and compatibility with multiple branches of core that we should just kill it and cut our losses, but folks pushed back that we still need this module, even with composer and friends.

So, yes, it's too flexible, the architecture doesn't fully make sense, some things are pluggable that shouldn't be, some things that should be pluggable are not, etc.
</aside>

Anyway, as you point out, there's no other real place to make this fix. I believe this is the best we can do given the circumstances.

I'm going to RTBC #41, even though I posted it, since 98% of the patch is @alexpott's work, and all I did was some trivial doc cleanups.

Thanks,
-Derek

Although, giving this a final once-over:

+++ b/core/modules/update/tests/src/Functional/UpdateCoreTest.php
@@ -863,6 +863,43 @@ public function testRevokedRelease() {
+    $this->drupalLogin($this->drupalCreateUser([
+      'administer site configuration',
+      'access administration pages',
+    ]));

Not totally sure we need this, since UpdateCoreTest::setUp() does this:

    $admin_user = $this->drupalCreateUser([
      'administer site configuration',
      'administer modules',
      'administer themes',
      ]);
    $this->drupalLogin($admin_user);

Seems bizarro that the main $admin_user for this whole class doesn't already have 'access administration pages' ;) Maybe we should just add that perm to the setUp() user and then this particular test method doesn't have to worry about creating another user and re-logging-in? Or maybe we don't need it at all?

Given that the workaround mentioned in #31 and #34 fixed it, shouldn't there be an hook_update_N that does that and we're out?

@leymannx: Sadly, no. That's a 1-time fix to temporarily fix the symptoms. Doing that in hook_update_N() wouldn't help at all. The patch here actually fixes the underlying problem, so 1-time workarounds aren't needed. Instead of manually doing that clearing via drush, or only once when you run update.php, we need to do it each time we get new data. That's what the patch here is for.

Cheers,
-Derek

Ah yeah, I see. Thanks for clarifying! 💙

+++ b/core/modules/update/src/UpdateProcessor.php
@@ -192,6 +192,10 @@ public function processFetchTask($project) {
 
+    // Delete any stored project data as that needs refreshing when
+    // update_calculate_project_data() is called.
+    $this->tempStore->delete('update_project_data');
+

Do we really need to do this for every project, or could we do this in the caller of this function so that it happens once?

The caller is the queue system

Isn't it in UpdateProcess::fetchData() and UpdateManager::fetchDataBatch()?

Oops sorry @catch I posted from my phone and used my fallible memory.

Looking at the two suggested places - \Drupal\update\UpdateManager::fetchDataBatch - before that is called in \Drupal\update\Controller\UpdateController::updateStatusManually() we call \Drupal\update\UpdateManager::refreshUpdateData() so that does not need this. But I've improved the docs to say that calling fewtchDataBatch without doing that is not recommended. There's more than just this reason for that - you need to call it to create the tasks.

So that leaves \Drupal\update\UpdateProcessor::fetchData() - add indeed we can optimise there and also the test passes so yay. Thanks @catch.

Random JS fail.

* Message appear on /admin/reports/dblog/confirm page.
* Applied patch (Drupal 9.0.2) and the message was still there after clearning the caches until I removed patch and then reapllied it.

Error

Notice: Undefined index: title in Drupal\update\ProjectSecurityRequirement::createFromProjectDataAndSecurityCoverageInfo() (line 103 of /www/web/core/modules/update/src/ProjectSecurityRequirement.php)
#0 /www/web/core/includes/bootstrap.inc(301): _drupal_error_handler_real(8, 'Undefined index...', '/Users/vladimir...', 103, Array)
#1 /www/web/core/modules/update/src/ProjectSecurityRequirement.php(103): _drupal_error_handler(8, 'Undefined index...', '/Users/vladimir...', 103, Array)
#2 /www/web/core/modules/update/update.install(47): Drupal\update\ProjectSecurityRequirement::createFromProjectDataAndSecurityCoverageInfo(Array, Array)
#3 /www/web/core/modules/update/update.module(96): update_requirements('runtime')
#4 /www/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(336): update_page_top(Array)
#5 /www/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(135): Drupal\Core\Render\MainContent\HtmlRenderer->buildPageTopAndBottom(Array)
#6 /www/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#7 /www/vendor/symfony/event-dispatcher/LegacyEventDispatcherProxy.php(78): Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy))
#8 /www/vendor/symfony/http-kernel/HttpKernel.php(163): Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#9 /www/vendor/symfony/http-kernel/HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#10 /www/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /www/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /www/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /www/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /www/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /www/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /www/web/core/lib/Drupal/Core/DrupalKernel.php(705): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /www/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#19 {main}

@VladimirAus - the patch does not fix the error if you currently are experiencing it on your site. It will stop it from happening. In order to fix the message you can visit admin/reports/status which will rebuild the erroneous state entry. For what it is worth - the longest you'll experience the error is 1 hour because after that the state will become invalid.

Thanks @alexpott

Same issue on 8.9.2 after running /upgrade - for the fourth time after some patches to fix problems with Commerce Migrate. First three runs it did not appear. Added product on old site to test if it would import text and after ignoring the error and running the upgrade - the import of the new product worked because of the patch, and then I found this and applied patch 52.

Error did not go away until running /admin/reports/update page

Seems to be gone now after the patch

I ran into this error, I tested the patch and it did not make the error go away on it's own. I will leave the error around for 1 hour and see if it disappears on its own with no patches applied.

@ccjjmartin re: #59: See #56 from @alexpott:

- the patch does not fix the error if you currently are experiencing it on your site. It will stop it from happening...

The patch doesn't try to clean up the situation on live sites. It's about preventing it from happening in the first place.

Sorry, still haven't (don't) have time to carefully review #52,but hopefully I can RTBC this soon.

Cheers,
-Derek

FYI, I got the same error message as the OP when I added a new image style:

../admin/config/media/image-styles

Once I deleted the newly added style, the message went away.

I am using Drupal 9.0.3

Solution #5 works like a charm. Thanks. :-)

Solution #5 work fine for me.

Same here, #5 worked (Drupal 9.0.3)

Strangely, after applying #52, I now have this random file chilling out:

I am applying the patch via Composer Patches so it seems like the path in the patch is actually wrong.

@GuyPaddock that looks like a bug in composer-patches to be honest. If I apply the patch in #52 to core I see

M  core/modules/update/src/UpdateManagerInterface.php
M  core/modules/update/src/UpdateProcessor.php
A  core/modules/update/tests/fixtures/release-history/drupal.broken.xml
M  core/modules/update/tests/src/Functional/UpdateCoreTest.php

This looks related to https://github.com/cweagans/composer-patches/issues/234

Just saw this bug in 8.9.6 manually updating removed as in #5

Faced same issue while adding menu link on Drupal 9.0.6
#3 solved the issue.
i.e. just visit /admin/reports/updates page

Two identical codebases local / stage

but a bit different infrastructure
local Drupal 8.9.7, 5.5.5-10.3.22-MariaDB, nginx/1.17.10, PHP 7.3.23
stage Drupal 8.9.7, 5.5.65-MariaDB, Apache, PHP 7.3.23

local was giving no problem
but stage had the warning appear on node/add/link (custom content type)

Applying the patch from #52 clears the warning

Discussed this issue with @catch we agreed that my changes in #52 are sufficient to address #51 and #49. Given that this can be rtbc.

Finally had a chance to carefully review #52. The comment makes sense and the patch looks great. Test coverage is solid, and it's working as expected. If I run it locally in test-only mode, I get:

% ./vendor/bin/phpunit -c core/phpunit.xml ./core/modules/update/tests/src/Functional/UpdateCoreTest.php --filter testBrokenThenFixedUpdates
PHPUnit 8.5.8 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\update\Functional\UpdateCoreTest
E                                                                   1 / 1 (100%)

Time: 1.22 minutes, Memory: 4.00 MB

There was 1 error:

1) Drupal\Tests\update\Functional\UpdateCoreTest::testBrokenThenFixedUpdates
Behat\Mink\Exception\ResponseTextException: The text "There is a security update available for your version of Drupal." was not found anywhere in the text of the current page.

/.../drupal-9_1/vendor/behat/mink/src/WebAssert.php:785
/.../drupal-9_1/vendor/behat/mink/src/WebAssert.php:262
/.../drupal-9_1/core/tests/Drupal/Tests/WebAssert.php:892
/.../drupal-9_1/core/modules/update/tests/src/Functional/UpdateCoreTest.php:899
/.../drupal-9_1/vendor/phpunit/phpunit/src/Framework/TestResult.php:691

ERRORS!
Tests: 1, Assertions: 17, Errors: 1.

Summary is accurate / current.
No API or UI changes.
No CR needed.
Nothing left to do but commit. $RTBC++; 😉

Thanks!
-Derek

Committed/pushed to 9.2.x and cherry-picked back through to 8.9.x, thanks!

Hi Guys, I just got this same error on Drupal core 9.1.3. The patch does not apply.

Went to /admin/reports/updates

And the notice is gone. But I know it will be back just like the Terminator "AiL Bee Baauck"

Hi Terminator, instead of using "Hi guys," consider one of these several alternatives:

* Hi everyone,
* Hi folks,
* Hi all,
* Hi friends,
* Hi team,
* Hi y'all,
* Hi people,

💙

@leymannx, thanks for your input. Instead of a Fedora can I suggest one of these several alternatives:

* Ascot cap
* Akubra
* Balaclava
* Balmoral bonnet
* Baseball cap
* Bearskin
* Capotain
* Cappello romano
* Chengziguan
* Deerstalker
* Homburg
* Kolpik
* Montera
* Sun hat
* Turban
* Rasta cap
* Wizard hat
* Umbrella hat

You can try a "peach basket hat". That should work too. Thanks again for your valuable input.

You are funny. And clever. So I think you got the point. Sorry @all for the noise.

Solution #5 worked for me too. Thanks ericdsd.

Solution #5 worked for me too. Thanks ericdsd.

I'm using Drupal 9.4.8 and PHP 8.1.6

Using Drupal 9.4.8 on PHP 7.4.32, surprisingly #5 still helps!

Issue reproduced on 9.5.3.

Just got this in Drupal 10.0.8 ...

#5 still works. on a 9.5.9 , php 8.0.27
best solution for a long time ;)

Happened to me today with 9.4.15 but as the crowd suggests, #5 is still working.

Workaround in #5 just worked for me on 9.5.5.

Workaround in #5 just worked for me too on 9.5.9.

Workaround in #5 just worked for me too on 9.5.9.

Still happening in 10.1.2.

Just happened to me in Drupal 10.1.5 like @ressa described. Perhaps we should reopen this?

The strange thing is, that the installation was not changed, when it appeared! No projects were updated or something like that. Definitely didn't show up yesterday.

And it happened to me yesterday again. So yes, it has resurfaced, and the issue should be re-opened. Or maybe it's best to create a new issue? Sometimes rebasing old issues can be a messy situation :-)

It has happened to me as well in Drupal 10.1.5. The Drupal $project_data array does not contain 'title' key. As far as I understand it should be 'Drupal core'.

Should we ask maintainers to re-open the issue and change the priority too? I think that the problem is important when the error appears on the site randomly.

Btw, the updating to d10.1.6 has fixed the issue.

Just got this in Drupal 10.2.0 as well.

I just got this on 10.2 and everywhere I went the same WSOD Warning popped up.

Ran command: composer update -W

It went away. Everything back to normal.

Mine disappeared as soon as ! ran "check for updates"

I got same error on Drupal10.3.5.
I got this error just after adding and removing title field to the replacement pattern on views. The error still remains after deleting title field. Clearing cache does not work. But after editing Admin pages, it dissapeared.

#5 also worked for me. Drupal 9.5.10

#5 also worked for me. Drupal 11.2

Just got this in Drupal 11.2.8, #5 solved it.

#5 also worked for me on Drupal Version 11.4.4