TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given

I've created MR from the patch.

Thank you!

Alternatively you have the option of changing your code not to pass a null.

Issue summary is incomplete.

But also need some more investigation, what's being passed here that's null. If caused by custom code then seems the custom code is wrong.

In fact, in these cases the log messages would make no sense without values in placeholders.

May be related: #3352384: Add Exception for TypeError Argument must be String in Drupal Component Utility Html escape{}

I had the same error trying to access a simplenews page (admin/config/services/simplenews/settings/subscription) and this patch solves the issue.

I had the same error trying to access to admin/reports/status in a site with a lot of module contrib but only after the upgrade drupal 10.4.7
-> 11.1.7

Please see supplied patch which should apply cleanly in 11.1 and probably 11.2 which solves the issue. Relaxes the string requirement allowing for a null argument, and returns an empty string on null.

11.2.2 made some changes that made patch #14 not work correctly. These are the same changes in patch 14, just applied to different line numbers.

For whatever reason, though, neither install properly with composer, but install properly when run manually with git apply.

I was attempting to test the patch from #14, but patching is affected as well. Insidious little bug, this one.

• PHP: 8.3
• Drupal: 11.2.2
• Original Triggering Action: I attempted to enable the Gin Admin Theme as the default theme on a clean new Drupal 11 site. I then tried to install the patch as a fix for the null text error I recieved. All pages on the site now display it.
• Error Message: While using composer install, this was returned:

Gathering patches from patch file.
  Gathering patches for dependencies. This might take a minute.
    - Installing drupal/core (11.2.2): Extracting archive
    - Applying patches for drupal/core
      fix-type-error-null-text.patch (Fix type error null text)
  
  In RemoteFilesystem.php line 105:
                                                                                                                       
    [TypeError]                                                                                                        
    Composer\Util\RemoteFilesystem::copy(): Argument #1 ($originUrl) must be of type string, null given, called in /v  
    ar/www/html/vendor/cweagans/composer-patches/src/Patches.php on line 388                                           
                

I've attempted to apply it using extra.patches.drupal/commerce, extra.patches.drupal/core, extra.patches.drupal/core-recommended, all of which fail.

patch "-p4" --no-backup-if-mismatch -d "M:\development\projects\react-safe-drupal/web/modules/contrib/commerce" < "C:\Users\User\AppData\Local\Temp/686448b16b77a.patch"
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/web/core/lib/Drupal/Component/Utility/Html.php b/web/core/lib/Drupal/Component/Utility/Html.php
|index 1a53a8de..e4426fe4 100644
|--- a/web/core/lib/Drupal/Component/Utility/Html.php
|+++ b/web/core/lib/Drupal/Component/Utility/Html.php
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
2 out of 2 hunks ignored

   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2025-07-01/fix-type-error-null-text-3523317-15.patch

I have attempted with both patches.

Ok, I think I resolved the issue with it. Specifically, the file pointers.

When composer is installing, it's installing from web/core. The patch points to web/core/lib.

It should look like :

diff --git a/lib/Drupal/Component/Utility/Html.php b/lib/Drupal/Component/Utility/Html.php
index 1a53a8de..e4426fe4 100644
--- a/lib/Drupal/Component/Utility/Html.php
+++ b/lib/Drupal/Component/Utility/Html.php

Instead of

diff --git a/web/core/lib/Drupal/Component/Utility/Html.php b/web/core/lib/Drupal/Component/Utility/Html.php
index 1a53a8de..e4426fe4 100644
--- a/web/core/lib/Drupal/Component/Utility/Html.php
+++ b/web/core/lib/Drupal/Component/Utility/Html.php

As an added note, I think this patch creates issues with fields with "Unlimited" cardinality. When trying to root out the issue (couldn't create new fields with unlimited cardinality or save forms with existing fields with unlimited cardinality and "add another item" would fail, as the index values for the weight/order were coming in as null/empty strings.

Oddly enough, after removing this patch from my installation, I did not continue receiving the error noted in this ticket when attempting to install commerce, and the functionality of fields with unlimited cardinality returned.

I manually applied the changes in patch at #15, it seems to have worked.

The problem with the patch from #15 is that it considers zero symbol as empty that breaks sorting of multiple field elements and I believe not only it. So we should check if the input text is 0.

Changes in patch #15 seems to have caused problems with the weight variable throughout the site. Reverted this patch, which seems to have resolved the weight problem, then manually applied patch #21. Seems to work.

Summary update and steps to reproduce still appear to be missing

Can confirm manually applying #21 resolves the issue on our test site.

Can confirm patch in #21 works.

#24 is still needed and this needs to be reviewed

@smustgrave as for my case the origin of the error was custom entity (extended from EditorialContentEntityBase) that had no label key defined and thus the standard method $entity->label() returned NULL that caused fatal error at least on the entity edit page (method editTitle() from EntityController class). I have not found similar entity types in the core - all entities without label (e.g. PathAlias) provide overriden label() method that allows to avoid the error.

It would be awesome if someone found way to reproduce the error basing on the core only.

Add https://www.drupal.org/project/drupal/issues/3515019 as a related issue

Unsure if this helps - I'm trying to debug some issues with Entity Share Client/Server. While enabling/disabling json api extras I got this error while trying to edit the entity_view_display--entity_view_display resource config from disabled to enabled.

(/admin/config/services/jsonapi/resource_types/entity_view_display--entity_view_display/edit?destination=/admin/config/services/jsonapi/resource_types)

I applied #21 to setup and it resolved the issue. Unsure how to debug to find the root cause but this patch did address being able to access that edit field.

@alezu Same here, probably, but I do havel a label() function for my entities. My log complains about undefined array key "description".

I know. Whatever fields you have with entity_keys, they need both setLabel() and setDescription() in the field definition, even if you don't need them. Stupid, if you ask me. :-)

This is happening adding a view pager following these steps:
- create a view of type block
- delete "Items per block" value during creation
- save the view
- add a pager
- from now on the error will forbid the view editing

Confirming that #21 worked.

After install module pathauto, go to /config/search/path to get a list of paths. Then I get an error "TypeError: Drupal\Component\Utility\Html::escape():…".

In use: PHP 8.3, Drupal 11.2.4

After install patch #21 the error is no more.
Thanks!! For the hard work.

Just experience on Drupal 11.2 with PHP 8.3
If I change pagination from all items to full pager I get this error on the view

Could be because of the new heading level or somewhat.

Patch #21 worked for me

Think we need a test case showing the problem and figure out why the value might be null

Drupal 11.2.4 / PHP 8.3 had this issue on: /admin/config/search/path
Confirming #21 worked for me

Had the same issue after replacing a field under Views Fields...
Drupal 11.2.5 / PHP 8.3.23
Confirming #21 worked for me

Drupal 11.2.5 / PHP 8.3.6

#21 solved a problem with dblog view, after some custom logs were produced.

Thanks.

This issue was a worth opponent. In my case it was caused by the "rabbit_hole" form displayed on the sidebar of node add/edit pages.

This commit https://git.drupalcode.org/project/rabbit_hole/-/commit/18b07d6c45f0bcc7... (committed in a dev version) was all it took to fix things.

I'm pasting it here so that other people get to a fix faster than me.

I have not yet manually tested the bug. In the IS steps to reproduce it says

..configure items per page as per the number of content items.

Not sure what that means. I took it to mean in the test to create x nodes and set the view pager to x items per page. The test is currently passing, so I could be misunderstanding?

Thank you @bserem! Our Drupal 11 upgrade was running into this error, but we weren't sure where it was coming from. Ours was also the rabbit_hole module, and it was fixed by resaving our node type configs. Apparently some values were set to null. This comment in the rabbit_hole issues is what fixed things for us.

For me, the error occurred when accessing my list of fixed blocks.

I’m encountering this error in Drupal 11 when attempting to reload the core of the search server using the Search API module. The patch #21 fixed the issue.

I’m encountering this error in Drupal 11 in my custom modules for custom entities. But error message did't say where error was.

Added steps to reproduce with Vanilla Drupal 11. Strange enough error happens only when logged in.

In that Vanilla Drupal DDEV installation from the issue description, as soon as I remove the field_tags from the article teaser view mode the issue is gone.

ddev drush field:delete node article --field-name field_tags

I am also having issues upgrading to Drupal 11, with the custom-made theme we use hitting this bug. I can confirm the patch in comment #21 works correctly for us.

I have added new changes, but I am getting an error in the Spell-checking pipeline job.

It looks like it's an infrastructure issue with moving files between devices during the CI/CD process.

mv: inter-device move failed: '/build/core/node_modules' to '/builds/issue/drupal-3523317/core/node_modules'; unable to remove target: Directory not empty

More a note to myself than anything else as I ran into this issue already for a second time and it left me scratching my head.

Make sure your custom entity has a label() function!

Encountered this today and wanted to document what happened on a real life site:

We have remote videos from Youtube as a media entity. Sometimes admins paste wrong URLs, or sometimes videos get taken down, or some are set to private. In such cases the media entity gets saved without a label. This was ok on Drupal 10, but after upgrading to Drupal 11, the media library broke because some of the media entities don't have a label. I've traced the errors back to this issue and the patch at #21 fixes the issue.

to add to my above comment: The media edit page is getting the same error too.

Patch #21 solved the issue for Drupal 11.3

There’s 2 MRs now but both appear to be failing.

@samit.310 why did you open a 2nd MR? If you’re proposing a different solution it’s good to leave a comment and put into the proposed solution section the different options so reviewers can easily tell

This went through a design decision in #3255637: Deprecate NULL values in Html::escape(), ::decodeEntities(), and FormattableMarkup::placeholderFormat() to make it easier to upgrade to PHP 8 to deprecate and remove NULL as an allowed value.

The last test is green with this change. As @cmlara said in #61 this was changed in the other issue #3255637

Is there a way we can get feedback from @alexpott @catch or some of the others that worked on that issue?

Suddenly I got this when opening /admin/reports/dblog using Drupal 11.3.3. It didn't happen five minutes ago.

I checked the log with drush watchdog:show
In my setup I suspect webform module is not sanitizing the log. I have a field named Contracta'm and there are some new lines on the log:

ID Date Type Severity Message
10657 10/Feb 11:35 php Error TypeError: Drupal\Component\Utility\Html::escape(): Argument #1 ($text) must be of type string, null given, called in xxx/web/core/lib/Drupal/Component/Render/FormattableMarkup

10656 10/Feb 11:26 webform_submission Error Contracta'm webform remote post (completed) to
10655 10/Feb 11:26 webform Notificació Contracta'm webform sent Correu electrònic email.
10654 10/Feb 11:26 webform Notificació Fibra 1.000 Mbps + Telèfon fix: Submission #26 created.

We upgraded from Drupal 10.5.6 to 11.3.2 and started facing this issue, any content type that had remote video using oembed with media library use to give this ajax error blocking the media library window to open, the patch in #21 did work for us.

Previous issue on this subject was in the Base system which is managed by the Framework Managers. Tagging them to look at this.

Someone may want to comment in #3255637: Deprecate NULL values in Html::escape(), ::decodeEntities(), and FormattableMarkup::placeholderFormat() to make it easier to upgrade to PHP 8 as well if it hasn’t already been done.

IMO reverting the previous work would allow bugs like this to persist, there was time given for deprecation, silently ignoring this would be a step backward and work should instead be put towards identifying flaws. Contrib and Core could potentially detect causes of this by using PHPstan.

Came across this issue today after upgrading from D11.2 to D11.3.3 - On the Reports DBLog UI, randomly happening when filtering output with a selection type and when using the pagination (this always triggers the error, making dblog useless).

Encountered the same error with D11.3 and #21 solved it.

Also reproducible via scheduled_transitions module with D11.3 and #21 solved it.

Can we move this to 'Needs review'?

The test that is added here is a very, very roundabout way of testing this, we should be able to easily test this method directly? We can keep this one I guess as well.

But this first thing we should do is seek consensus if we should even attempt to do this, since it's a (partial) revert of an earlier issue.

My understanding from https://project.pages.drupalcode.org/governance/core/drupal-core/#faq-ti... is that a Framework Manager is expected to respond within 1 week (7 days) once the “Needs framework manager review” tag is added to an issue.