Class name must be a valid object or a string in core/modules/image/src/Entity/ImageStyle.php on line 174

how can we reproduce this ?

I am getting this error too, but I'd like to know why $class is null. StreamWrapperInterface seems to be the problem.

I can't really explain the situation, but for google foo, I got this issue with the youtube stream wrapper, when I synced a prod database locally and I guess the thumbnails didn't exist yet.

Without a way to reproduce this issue, we can't write a test. And that test is needed to make sure that this bug doesn't reappear.

I uninstalled s3fs module after which I updated core from 8.3.9 to 8.5.3. Then when I reinstalled s3fs module using composer it gave me this error.

Error: Class name must be a valid object or a string in Drupal\image\Entity\ImageStyle->buildUri() (line 176 of /var/www/drupalvm/<project>/web/core/modules/image/src/Entity/ImageStyle.php) #0 /var/www/drupalvm/<project>/web/core/modules/image/src/Entity/ImageStyle.php(195): Drupal\image\Entity\ImageStyle->buildUri('s3fs://2017-04/...') 
#1 /var/www/drupalvm/<project>/web/core/modules/image/image.module(312): Drupal\image\Entity\ImageStyle->buildUrl('s3fs://2017-04/...') 
#2 /var/www/drupalvm/<project>/web/core/lib/Drupal/Core/Theme/ThemeManager.php(287): template_preprocess_image_style(Array, 'image_style', Array) 
#3 /var/www/drupalvm/<project>/web/core/lib/Drupal/Core/Render/Renderer.php(437): Drupal\Core\Theme\ThemeManager->render('image_style', Array) 
#4 /var/www/drupalvm/<project>/web/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false) 
#5 /var/www/drupalvm/<project>/web/core/lib/Drupal/Core/Template/TwigExtension.php(490): Drupal\Core\Render\Renderer->render(Array) 
#6 /var/www/drupalvm/<project>/web/sites/default/files/php/twig/5af2915de82f7_image-formatter.html.twig_Y7hawJAFpjxvpRyARJ20VB68F/-myUU6PGMLZiOZe1Y_PVuJJNT24gU1Jp0wAgRVELEgI.php(48): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true) 

There is related issue in the s3sf module version 8.x-2.0-alpha0

I hit this problem when deploying a site. Turns out I had disabled the private file setting in settings.php while trying to get an SELinux issue fixed. Making sure my private file setting was valid again fixed this for me. Would have been nice to get a relevant error, but when does that ever happen these days...

I'm having the same issue and am not using the s3fs module. I've attached a slightly updated patch that fixes an error where `$is_writeable` isn't defined.

Was having the same issue. Applying the patch in #13 worked for me.

Same problem.

I was having same issue once i upgrade from 8.6.15 to 8.7.x. Patch #13 worked for me.

Same issue without having installed any of the module described above.
Patch #13 solved the issue for me too.
It's a blocking issue, since when it appears, the Drupal installation becomes almost unusable.

Time to test deeply this patch and include it in the next Drupal release?

I've updated the IS and rerolled the patch on 8.7.x.

Ran into the same problem after upgrading to 8.7.1. Only happened when running cron for me. Patch in #19 worked.

I don't think the test-fail is related to this. In any case we would need a test.

The reason for this problem is missing configurations or files within the private folder.
I'm using D8.5.6 and here's how I fixed mine when I got this problem. It's not the right solution but this patch can let you ignore the class in case of missing info for your files.

the issue is definitely not fixed, also patch on 8.7.x does not apply.

the patch should work on. 8.7 but the problem in 8.7 the file been modified but the function stayed the same which made the patch needs some new modifications or do the change manually within another patch but 8.5 and 8.6 would never match in one patch with 8.7 because of the other changes within the file and the line number is different

just the changes 8.7 needed:

- replace the line below
$class = $this->getStreamWrapperManager()->getClass($source_scheme);

with the lines below:

if ($class) {
$is_writable = $class::getType() & StreamWrapperInterface::WRITE;
} else {
$is_writable = null;
}

Updated Patch for Drupal 8.7

@sam-elayyoub, please do NOT change the status of the issue to fixed when it's not. It needs test coverage according to #22 and also fixed means it's committed, that is not true.
Back to needs work to continue implementing tests.

@tatarbj Keeping this as needs work is a little tricky when a final patch tested on different versions and validated, then the meaning of needs work is not correct, I agree closed means committed and applied but if we keep the ticket open needs work, then it's a wasting of time for dev teams who thinks they can still apply patches and waste their time on a fixed tested ticket.

I will leave it open but to be honest, it's a core module patch and this should be fixed before releasing a new version before committing what's fixed for now.

Regards
Sam

Keeping this as needs work is a little tricky when a final patch tested on different versions and validated then the meaning of needs work is not correct,

Well, needs work means that the patch is not yet complete. Because this still needs tests before it can be committed the patch is not yet complete, so needs work is the correct state.

I agree closed means committed and applied but if we keep the ticket open needs work, then it's a wasting of time for dev teams who thinks they can still apply patches and waste their time on a fixed tested ticket.

It does not waste time. It needs tests.
It is not yet committed to 8.8.x yet either, so if you'd want to use this patch, it would still need to applied manually (or with composer-patches).

I will leave it open but to be honest, it's a core module patch and this should be fixed before releasing a new version before committing what's fixed for now.

It needs tests, then it can get committed to 8.8.x (and possibly backported to 8.7.x).

In summary, this needs tests and a clear way to reproduce this. Right now this patch only fixes the effect and not the root cause of this issue.

Hello community, I'm also facing this issue

Attached patch adds test coverage (interdiff-28-34 =2849413-34-test-only.patch).

The kernel test is indicative of the problem, since KernelTests use the vfs StreamWrapper and that isn't registered anywhere, the test fails. This is probably the same problem others are facing: a StreamWrapper that isn't registered (yet).

Since FALSE is a valid return option for \Drupal\Core\StreamWrapper\StreamWrapperManagerInterface::getClass, the code should account for it, and with this fix, it does.

Updated the IS to add the reasoning

Thanks for your work here folks, this is indeed a difficult issue to reproduce, because stream wrappers are registered in pre-bootstrap code in the kernel, so the only way you're getting into this scenario is if you have references to disabled stream wrappers in your database.

The test is a reasonable workaround that demonstrates the problem, and as @Lendude points out, FALSE is a valid return.

Adding issue credits

• @borisson_ for mentoring in core processes
• @Lendude for issue summary updates

Committed 3237440 and pushed to 8.8.x. Thanks!

c/p to 8.7.x