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.
caches disabled
enable database media storage
remove your pub/media/wysiwyg folder
magento will check wether or not the image exists and if not pull it from the database, just like it does for products
nothing happens, the image is a 404
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).
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.
Most helpful comment
still an issue in 2.1.2