Magento2: database media storage: cms-images are not being loaded on demand (but product images are)

Created on 28 Jul 2016  路  13Comments  路  Source: magento/magento2

when using the database as the media storage one can adhoc fetch product-images from the database when they are requested for the first time and they dont exist on disk. it would be fair to assume this is also true for images of the cms.

Preconditions

  1. magento 2.0.7
  2. caches disabled

    Steps to reproduce

  3. enable database media storage

  4. upload an image to the cms/wysiwyg
  5. remove your pub/media/wysiwyg folder

    Expected result

  6. magento will check wether or not the image exists and if not pull it from the database, just like it does for products

    Actual result

  7. nothing happens, the image is a 404

Fixed in 2.2.x Fixed in 2.3.x Clear Description Confirmed Format is valid Ready for Work Reproduced on 2.1.x bug report

Most helpful comment

still an issue in 2.1.2

All 13 comments

i know that there is a cron involved, but scaling magento, the question how the images are being synchronized is important, and even though the cron might eventually synch these images, for products it works in a better way, so why not for the cms?

was on the wrong track but still the same problem
magento evaluates catalog images server-side while rendering, however wysiwyg images are being fetched on demand via .htaccess mod_rewrite and get.php
but this is also not working because the wrong path is being evaluated:

so it tries to determine if the request media/wysiwyg/Bildschirmfoto_2016-07-27_um_14.32.10.png can be fulfilled but it expects the path to be relative to media, its checking wether the beginning of this requested path matches a number of known folders...

differently broken than what i though first, still broken though

my fix was this:
in get.php drop the media/ from the relative path by adding:
$relativePath = preg_replace('/^media\//', '', $relativePath);

Internal jira ticket - MAGETWO-56436 has been created.
Thank you for your bug report.

Can reproduce. This is a critical bug. get.php is not working at this moment.

This issue actually Makes database media storage useless for where images are not pre-generated as a part of some explict logic that does image generation.

This is not only for wysiwyg images, but for ALL resources through get.php (making the get.php non-working).

  • if you remove e.g. media/catalog from filesystem - all catalog images can not be generated by the database blob...
  • If you remove custom uploaded logo image it's not regenerated...
  • etc.

Magento: 2.1.0 GA
Mode: Production
Server: nginx
Nginx conf: same as nginx sample config.
All caches enabled
Varnish cache

Critical bug, also having this issue when saving custom things aswell in the media directory. I have created a custom module that allows the user to download some pdfs. I have a custom path ( not wysiwyg but pdfs, so the the path is /media/pdfs/zzzz.pdf .

This bug happens with the database media storage enabled. This is a bummer since the database media storage is required for scalable solutions.

*_Workaround by ludwig works for me. ( Removing media/ from the $relativePath variable) *_

Edit 24.08.2016 - Possible fixes below
this seems also to affect all other database-media storage related files.
Basically $relativePath should not contain media/ because then it can not match the resource_config.

A safe fix can also be (without regex):

$relativePath = ltrim($relativePath, 'media/');

or even be done in

Magento\MediaStorage\Model\File\Storage\Request as that seem to be some kind of proxy for a media request.

I can see there that this is used: str_replace('..', '', ltrim($request->getPathInfo(), '/')); in 2.1.0. This can be fixed with:

    public function __construct(HttpRequest $request)
    {
        $this->pathInfo = str_replace('..', '', ltrim($request->getPathInfo(), '/media/'));
    }

still an issue in 2.1.2

still an issue in 2.1.7

@ludwig-gramberg, thank you for your report.
The issue is already fixed in develop branch, 2.2.0

Did this fix actually make it into the final version of 2.2.0 or in my case 2.2.2? I'm seeing the exact same issue referenced here and in the following post.
https://github.com/magento/magento2/issues/8065

Big issue for us when storing media in the database. We plan to have two magento web nodes and if these images aren't downloaded to the 2nd web node automatically it really makes it a pain in the butt to edit any kind of non-catalog/product related content. (ie. pages,blocks, etc.)

I also see this is 2.2.4

@gwharton please open a new issue if this is the case.

I also see this in 2.2.3, not sure why it says fixed in 2.2.x - where exactly was the fix done?

Yep, seeing this issue on 2.2.4 as well, strangely only on one of two sites.

Was this page helpful?
0 / 5 - 0 ratings