TypeError: Argument 1 passed to Drupal\Core\File\FileUrlGenerator::generateString() must be of the type string, null given

I have also updated drupal 9.2.10 to 9.3.0 and facing the similar kind of issue, not sure it is related with the paragraphs or with the drupal core.

That looks like something related to a custom template, you can see that in the error message.

Same issue here. Worked fine on Drupal 9.2.10 but broken after updating to 9.3.0. Like @munish.kumar says, it could be a Drupal core issue rather than a paragraphs issue. @Berdir, I agree, it "looks" like an error in a custom template, but the template worked fine before Drupal 9.3.0, so something changed somewhere outside of the template to cause this problem.

Facing the same issue on two sites that we just upgraded. One site is using paragraphs and another doesn't. Can confirm it's not a paragraph.
Troubleshooting...

Well. FileUrlGenerator *is* new in Drupal 9.3, so that's not surprising. It looks like you have code that is calling file_create_url(NULL), you might not be properly checking if a uri exists.

That said, I can see how this might be a BC break and should maybe silently ignore NULL then for now in the old, deprecated function.

See https://www.drupal.org/node/2940031.

In drupal 9.3.0, a lot of code is deprecated especially this function file_create_url() along with others like: file_url_transform_relative(). These two functions are used by lots of contributed modules, here is the list of some that my sites are using:

• webform [docroot/modules/contrib/webform/includes/webform.theme.template.inc, line: 941]
• paragraph [docroot/modules/contrib/paragraphs/src/Entity/ParagraphsType.php, line: 185]
• google_tag [docroot/modules/contrib/google_tag/src/Entity/Container.php, line: 533]
• simple_sitemap [docroot/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityUrlGeneratorBase.php, line: 277]
• linkit [docroot/modules/contrib/linkit/tests/src/Kernel/AssertLinkitFilterTrait.php, line: 32]
• ctools_entity_mask
• google_analytics
• adminimal_theme

The deprecation is listed under the file called: file.inc [docroot/core/includes/file.inc]
Here is the link of issues used to deprecate items as listed in the above file:
https://www.drupal.org/node/2940031
https://www.drupal.org/node/515192

My solution: Revert back to the previous core version till all the contrib modules have patches available for this big change. Looking forward to other possible quick resolutions.

It's still fine to use the deprecated function, it's still there and works. The _only_ exception is apparently passing NULL to it, which I guess silently did nothing before and now it's a fatal error. You need to debug where it is called with NULL and fix that.

@berdir, Got it. Let me see if I can find it.

I believe @berdir is correct that this is unrelated to paragraphs.

I ran into this in a template that was implementing {{ file_url() }}, where the value being passed into file_url() was null. I can confirm that this was not an issue on 9.2.x. It looks like there was an undocumented change to this drupal-provided twig function.

9.2 version: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Template%...

      new TwigFunction('file_url', function ($uri) {
        return file_url_transform_relative(file_create_url($uri));
      }),

9.3 version: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Template%...

      new TwigFunction('file_url', [
        $this->fileUrlGenerator,
        'generateString',
      ]),

I guess it makes sense that this wasn't specifically documented since it was just swapping out the deprecated function calls, but given that it's apparently a BC it seems like maybe it should have been. Theoretically, I think my case should have always been broken since the $uri parameter is required in all of the functions, old and new, but something must have been falling back on the null case before. Maybe something to do with twig specifically, not sure. My suggestion for people would be to look for calls to {{ file_url() }} in the templates that are throwing the error. Even better, search your whole project for instances of this and see whether they're broken and/or have null handling.

@berdir should BCs be documented anywhere, core release notes or otherwise?

@mrweiner How did you end up fixing your templates with the file_url() calls? Did you do an if-else statement or is there a better way to do it?

Just discovered the same as mrweiner (#10), and can confirm that checking for a NULL uri before passing it to the function fixes the issue.

@albertski In a couple of cases I just removed the line, since it was some functionality that we'd gotten rid of anyway. In another case I used a ternary, as in replacing {% set imgUrl = file_url(node.field_poster_image.0.entity.uri.value) %} with {% set imgUrl = node.field_poster_image.0.entity.uri.value ? file_url(node.field_poster_image.0.entity.uri.value) : '' %} . You could also

• use if/else around the file_url() line itself
• if/else to determine the value that you're passing into file_url()
• use a ternary inside of file_url()
• set a template variable from hook_preprocess_hook() to set a $variables['file_url'] value and avoid the twig templating logic entirely.

@mrweiner, thanks for the solution.
I did a quick look at the changes and tried to patch it via handling the null condition.
Please test this patch, it still requires a lot of work. Consider it as a draft version. It should at least won't let the site down. The new interface FileUrlGeneratorInterface in core needs to be updated to handle the null checks.

Here's an alternative approach that just checks for a null $uri in the deprecated file_create_url() method. This allows us to keep the new API strongly typed.

Agreed with keeping this in the BC layer. But we also need to wrap that in the twig callback, because file_url() in twig templates calls that directly, so this patch won't actually help for calls in twig.

I wonder if we should even trigger a warning message for this. Chances are pretty high that this will not be code covered by tests, so regular deprecation messages won't really be seen on actual sites and I doubt that tools like rector can identify such a problem.

Adds a wrapper for the twig function to check for NULL.

Same issue

Thanks, yeah, that should work now, just need to decide on what kind of deprecation we want to do here.

We probably want to mark that helper method as internal so we can remove it with D10? Or do we want to keep that for twig?

Note to everyone having this problem: While it is unfortunate that we introduced this break in 9.3, a minor update, the fault is in your code and you will need to fix it. If not now then with the Drupal 10.0 update when the BC layers are removed.

yeah I agree with @Berdir. It's just a BC layer. Actuall issue is in the custom code. Now, it's fixed.

\Drupal::service('file_url_generator')->generateAbsoluteString($uri)
instead of
file_create_url($uri) // deprecated

Also, need to check the $uri is not empty.

Now, it works well.

To be clear:

> Also, need to check the $uri is not empty.

This is the important part. You can still use file_create_url(), it's deprecated, but it has a BC layer. The problem is that the BC layer did not account for this edge case that was an undocumented, unintended "feature" of file_create_url() before 9.3. That you could pass in NULL and would get back the absolute base URL. This might have caused some weird minor issues before (like trying to load your frontpage somewhere as an image or download link or whatever else that file was used for), but it didn't break. Right now, it does.

I wonder if we should even trigger a warning message for this.

I think this is probably a good idea, especially given the likelihood of the issue being encountered by site-builders/non-developers since it's related specifically to twig.

We probably want to mark that helper method as internal so we can remove it with D10? Or do we want to keep that for twig?

I'd imagine we want to keep it around for twig, if removing it means removing the twig function.

I'm not sure we should keep it. There is no valid use case for this. The return value for passing in null or an empty string or similar bogus value makes no sense and is never right. BC is one thing, but if your code is broken then it should tell you so. That said, we could consider to keep the function and change it to an exception that is more clear than the fatal error ("call to file_url() with null in template X is not valid" or so, if we have enough context there..)

I just meant that using {{ file_url() }} still has utility as long as you're passing in a valid string, so whatever change is made shouldn't remove it.

If nothing else, though, we probably want to keep it for consistency. The rest of the TwigFunctions are defined like new TwigFunction('function_name', [$this, 'localMethod'], whereas file_url in 9.3 is the only one that departs from that by not passing $this directly and using a callback that isn't defined in the same file, currently new TwigFunction('file_url', [$this->fileUrlGenerator, 'generateString']). Being able to throw an exception or whatever else would be a bonus.

I'm definitely not suggesting to remove file_url(). Just that we should not allow passing in NULL anymore in D10.

Agreed, then. I think it makes sense to keep the new method added in #18 but remove the NULL allowance before D10.

I was getting this error and patch #18 worked, but now I am getting a Twig Tweak Extension error:
TypeError: Argument 1 passed to Drupal\twig_tweak\TwigTweakExtension::drupalImage() must be of the type string, null given, called in /var/www/site/vendor/twig/twig/src/Environment.php(418) : eval()'d code on line 49 in Drupal\twig_tweak\TwigTweakExtension::drupalImage() (line 230 of modules/contrib/twig_tweak/src/TwigTweakExtension.php).

@emb03 you should open a ticket in the twig_tweak queue for that.

Check $uri is a string inside of a FileUrlGenerator::generateString() function is good. & We must return string value.

Coding standard changes

Use the patch in #18, not this. If you call the new method directly you are responsible to check the type. That change is not correct, won't work without changing the interface and will not be accepted.

yes @berdir, without changing the interface and will not be accepted.

Oh! patch has mistakenly created from docroot folder.

Hello, patch number # 34 fixes the problem, thank you very much.

#34 resolves for me as well.

#34 patch resolve problem, thank you

Thank you @mrweiner for a solution I could apply to the code I have control of, in comment #14. Not for nothing, I would say a majority of the issues I experience upgrading between minor Drupal versions revolve around the twig templates in my custom themes.

Experienced the same error when going to Config -> Media -> Image styles. Edit an existing style - WSOD.

web/core/modules/image/image.admin.inc on line 41 in Drupal\Core\File\FileUrlGenerator->generateString() (line 58 of core/lib/Drupal/Core/File/FileUrlGenerator.php).

Applied the patch #34 - which got me further (thanks!) and I now get the screen displayed but without image previews and also with the following warnings (4):

Warning: Division by zero in template_preprocess_image_style_preview() (line 51 of core\modules\image\image.admin.inc).
template_preprocess_image_style_preview(Array, 'image_style_preview', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('image_style_preview', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 64)
Drupal\image\Form\ImageStyleEditForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)

#34 resolves for me as well.

Currently i'm not sure what the best approach is to fix this issue.

There is a solution #14, but this looks inelegant. But I also think that hacking the core with a patch like this is not a good idea.

What do you guys think?

Patch 34 fixed the problem. Thank you!

#34 also worked for me, using:

• Drupal Version 9.3.2
• PHP 7.4.21
• MySQL 5.7.34

Patch #34 worked for me.

Drupal 9.3.2
php 7.4.26
MariaDB 10.4.18-MariaDB-log

This worked for me guys

replace this method

function file_create_url($uri) {
@trigger_error('file_create_url() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use the appropriate method on \Drupal\Core\File\FileUrlGeneratorInterface instead. See https://www.drupal.org/node/2940031', E_USER_DEPRECATED);
try {
return \Drupal::service('file_url_generator')->generateAbsoluteString($uri);
}
catch (InvalidStreamWrapperException $e) {
return FALSE;
}
}

with this in core/includes/file.inc

function file_create_url($uri) {
@trigger_error('file_create_url() is deprecated in drupal:9.3.0 and is removed from drupal:10.0.0. Use the appropriate method on \Drupal\Core\File\FileUrlGeneratorInterface instead. See https://www.drupal.org/node/2940031', E_USER_DEPRECATED);
try {
if($uri!=null)
return \Drupal::service('file_url_generator')->generateAbsoluteString($uri);
}
catch (InvalidStreamWrapperException $e) {
return FALSE;
}
}

Patch #34 worked for me.

Drupal 9.3.3
php 8.0

estou com este problema e preciso de ajuda, alguém aí.

The website encountered an unexpected error. Please try again later.
TypeError: Drupal\Core\File\FileUrlGenerator::generateString(): Argument #1 ($uri) must be of type string, null given, called in C:\xampp\htdocs\jupiterangola\sites\default\files\php\twig\61e979b73a9f9_node--project.html.twig_67WoFUOx5Qf8UH-B9mzSZddX6\TMCt9wx-93ajqu0mCaj3On-qQ0FCEVgjkCZ9eljsshU.php on line 50 in Drupal\Core\File\FileUrlGenerator->generateString() (line 58 of core\lib\Drupal\Core\File\FileUrlGenerator.php).
Drupal\Core\File\FileUrlGenerator->generateString(NULL) (Line: 50)
__TwigTemplate_b80d7a2dae5fd75d98ba52b6033a78f89742dcca308d5607d2cd3a44632ed7c8->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/yg_corporate/templates/node--project.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('node', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This worked for me

Drupal 9.3.3
PHP 7.4.20

Patch 34 fixed the problem. Thank you!

Drupal 9.3.3

@andreas-emer (Comment#42),

The best approach is to look at your theme twig templates and find out where you have code that is calling file_create_url(NULL). I ran into a theme on a site I upgraded from Drupal 8 -> 9 where the theme developer had called file_create_url() on a background image that was not a required field. Prior to Drupal 9.3.x, it was fine but after I upgraded to 9.3.x, it would crash on any pages without a background image. I used the approach from comment #14 to resolve the problem.

I hope that helps.

Cheers,
Andrew

#34 works great for 9.3.3

#34 worked for me too for 9.3.3

I think we have enough comments saying it works now. :-)

What we really need is someone to do a proper review and mark RTBC if its ready.

Big thanks to mrwiener (comment #14) -- you saved my bacon on Monday night, and I;m very grateful that you took up the time to write out that ternary for us less savvy themers ;)

#34 worked for me too for 9.3.3
PHP 7.3.33-1
Thanks!

Re: #54

For the record, I think #18 is a better approach than #34 for commitment into core. It's more inline with how the rest of the twig methods work/are defined, provides a deprecation notice, does not change any other interfaces, etc. #34 feels more like a shim that just gets broken sites working again, when they should probably be making changes to their templates per #14 instead. Both patches technically get the job done, so it's more of a question of approach. Not sure where that leaves us as far as RTBC goes.

Agree with @mrweiner in #57. As @Berdir mentioned #32 this is not the correct approach. I'm hiding the patch and restoring visibility of #18.

Thanks for the continued focus here. I switched my patch for #18 - composer updated drupal/core - then did:

full cache clear;

config > media > image styles;

edit any existing style;

error:

TypeError: Argument 1 passed to Drupal\Core\File\FileUrlGenerator::generateString() must be of the type string, null given, called in C:\xampp\apache\htdocs\drupal-8\neway-drupal-project\web\core\modules\image\image.admin.inc on line 41 in Drupal\Core\File\FileUrlGenerator->generateString() (line 58 of core\lib\Drupal\Core\File\FileUrlGenerator.php).
Drupal\Core\File\FileUrlGenerator->generateString(NULL) (Line: 41)
template_preprocess_image_style_preview(Array, 'image_style_preview', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('image_style_preview', Array) (Line: 422)

I've backed out #14 - and reverted to #34 for now...

Am using Seven as the admin theme

Yes, that is in core and a direct call to the new method, so the BC layer on the old one doesn't work.

We could add a check there, but it sounds like the real reason is that your preview image configuration is broken. Check image.settings:preview_image, which points to core/modules/image/sample.png by default. you seem to have lost that configuration. Right now you probably have a broken image there.

#34 work for me Thanks

The comment by @Berdir at #60 fixed up my white screen of death - and also made the preview images appear again. I've removed the patches previously applied. Thanks!

Can we get an updated patch to make it clear which one should be used (#18), I'd also suggest to add a call with NULL to \Drupal\KernelTests\Core\File\FileSystemDeprecationTest, so we have that covered with a test. Not sure if we need a twig template test as well.

#34 worked for me, on 9.3.5.

Thanks.

Here's an updated version of #18 that includes the NULL test in \Drupal\KernelTests\Core\File\FileSystemDeprecationTest. My local testing is borked right now, but I think this should work.

It feels like we should have a test for the newly added getFileUrl() as well, but I can't seem to figure out where the other twig extension methods are tested, if they are at all.

Also, we've got plenty of comments saying that #34 works for them. Probably don't need any more of those :)

#18 work for me on 9.3.5. my site have some PDF files missing, printed in a twig template for download. That is causing the null value of the uri in my case.

<a href="{{ file_url(node.field_pdf.entity.uri.value) }}">{{ "Full file" | t }}</a>

I think the best thing to do is to update the twig templates to check the existence of the URI. It would be the best thing to do in the future, but with this patch the problem is solved.

For people arriving here from Google, this is related but different:
#3264236: Fail gracefully if CKEditor plugins fail to provide file URI

I first tried patch #34 and it didn't resolve this for me. My colleague marcoscano created a patch (#6) mentioned on comment #67 and that did fix the issue. For me it was related to CKEditor. Thank you Marcos!

Drupal 9.3.5
PHP 8.0.15
Apache 2.4.52

#65 works for me.

+++ b/core/lib/Drupal/Core/Template/TwigExtension.php
@@ -272,6 +272,22 @@ public function getLink($text, $url, $attributes = []) {
 
+  /**
+   * Gets the file URL.
+   *
+   * @param string|null $uri
+   *   The file URI.
+   *
+   * @return string
+   *   The file URL.
+   */
+  public function getFileUrl(?string $uri) {
+    if (is_null($uri)) {
+      return NULL;
+    }
+    return $this->fileUrlGenerator->generateString($uri);
+  }
+

If this is type hinted to string, then it won't accept NULL - either it needs a default value of null, or the change is unnecessary. There's no test coverage of the new method.

?string $uri does work, it just means that you need to explicitly pass in NULL, but that is the case here. See https://3v4l.org/cR2tv

For test coverage, we have web/core/modules/system/tests/modules/twig_theme_test/templates/twig_theme_test.file_url.html.twig, should be easy enough to add a second line there where we pass in NULL. And the test for it is \Drupal\Tests\system\Functional\Theme\EngineTwigTest::testTwigFileUrls.

Adds an additional line to twig_theme_test.file_url.html.twig that passes nothing (NULL).

You do need to explicitly pass NULL as a value to it, for example file_url(undefined_variable), passing nothing was never allowed.

Ah I see. I'll try that.

Now it passes and gives us test coverage of this special case.

I tried to apply the patch from here but it is also giving an error Could not apply patch! Skipping. The error was: Cannot apply patch 3254245-78.patch. can someone help me with this issue

Restoring status.

@sambara323 the patch probably needs a re-roll for 9.3.x, or you might need to use patch -p1 instead of git apply. But also, changing bug reports to support requests makes it much less likely they'll get fixed.

sorry for changes didn't know it would change the whole page

#78 I have also applied this patch in 9.3.2 and it's working for me.

Committed/pushed to 10.0.x (without the file_uri hunks), then to 9.4.x and cherry-picked to 9.3.x, thanks!

1. +++ b/core/lib/Drupal/Core/Template/TwigExtension.php
   @@ -272,6 +272,22 @@ public function getLink($text, $url, $attributes = []) {
   +  public function getFileUrl(?string $uri) {
   

   I think this should have a return typehint of string. And instead of returning a NULL it should return an empty string.

2. +++ b/core/lib/Drupal/Core/Template/TwigExtension.php
   @@ -272,6 +272,22 @@ public function getLink($text, $url, $attributes = []) {
   +    if (is_null($uri)) {
   +      return NULL;
   +    }
   

   This is quite different behaviour from the path twig function. It is using asserts to ensure you have the expected values. I think we could do the same here so at least we tell people that this is happening - if they have asserts on.

     public function getLink($text, $url, $attributes = []) {
       assert(is_string($url) || $url instanceof Url, '$url must be a string or object of type \Drupal\Core\Url');
   

   So something like

       assert(is_string($uri, '$uri must be a string');
   

   And then in Drupal 10 or 11 we could change the type hint and remove the assert.

Discussed #86 with @catch - going to do that in a follow-up.

#3267078: Add return typehint to TwigExtension::getFileUrl() adds the return typehint - going to add the assert in another follow-up because that will necessitate changes to tests.

For the assert I've created: #3267079: Add an assert to TwigExtension::getFileUrl()

Hi,

I run in to a similar problem after updating to D 9.3.7. The error message is very similar but not exactly the same:
It was ::generateAbsoluteString() and array was given.

TypeError: Argument 1 passed to Drupal\Core\File\FileUrlGenerator::generateAbsoluteString() must be of the type string, array given

The error is triggered when I try to 'manage layout' for a content type that uses Layout Builder. I tried to apply the #78 patch but it couldn't be applied via Composer.

same for me, I couldn't apply the patch using Composer
Drupal Version: 9.3.9

@rollins This has been released. There is no need to patch it.

Patched 34 worked for me thanks!

https://www.drupal.org/project/drupal/issues/3254245#comment-14343645