ContentBlocks and wrong media source paths on multilanguage sites

Summary

On a few websites I’ve recently updated to MODX 2.8.1 (via sitedash) I’m experiencing a series of issues regarding media paths when adding images to contentblocks fields.

These websites are multicontext/multilanguage with Babel and XRouting.

The main language has path / while the others are set to use /en/ /it/ etc, the issue only appears on these.

The issue only seem to appear on modx 2.8+ and might also be related with upgrating SQL to version 5.7 on the hosting machine (this update caused a lot of issues on itself especially with the Gallery plugin).

Medias (both images or files) may or may not be called with a pthumb filter, doesnt seem to matter.

All the CB fields are setup to use a custom media source that points directly to assets/uploads/ to avoid the client’s access to the full filesystem

The issue seem to affect just media used in ContentBlocks, medias in normal TVs work as expected.

I have no idea how to tackle the situation.

Step to reproduce and Observed behavior

Case 1 - Visible error
In this is example i use a repeater with file, text and image fields, the image field automatically opens a crop selection.

  • On a resource of the secondary context (/it/) i select from the media browser the image i already uploaded in the primary context (/)
    1.1
  • The automatic crop window opens and upon saving you get an error that the file path is not found. Important to notice that the path includes the context folder
  • By ignoring the crop i can see the thumbnail in the backend but i get a broken image in the frontend.
  • The error does not appear if the image is uploaded from scratch, crops goes fine. Obviosuly this creates a copy of the image on the server
  • The path of the image is correct, but the file field path still shows the context folder.

Case 2 - Just the path error
In this example the CB field is just a simple image. No crops involved.

Expected behavior

Context folder should not be added to the media path.

As an example on another site that uses the exact same configuration as the one of Case 2 but is still on MODX 2.7.2 the issues is nonexistent. Any media in any context is shows as the media source path starts from /assets/

Environment

MODX Revolution 2.8.1 - Apache server - MySQL 5.7
Tested on Firefox and Chrome
.htaccess file has the instruction:
# Redirect all requests from /xy/assets* to /assets*
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (en|fr|es|it|ru|cn|nl|de|)/assets(.*)$ /assets$2 [L,QSA]
allowing the images to be visible in the frontend.

On all the sites i’ve talked about the custom media source has these setting, i’ve tried to add/remove / or change to absolute path with no success:

Please see the base url mode setting:

The setting is on relative as per default in the Case 2 website, and that’s how it’s generally setup on every other website, changing it to either absolute or full and then saving the resource, emptying the cache, or rebuilding the whole content from CB doesn’t seem to have any effect at all.

CB rebuild also throw pThumbs errors in the process, but in the frontend the images work properly.

In the Case 1 website it’s set to full, but images from CB are outputted with a relative path anyway…

The base tag in the head is set to on every project but even forcing it to exclude the context folder doesn’t change the result.

Multi-context sites that route based on a subdirectory require special handling and the relative mode may not work as expected because of that extra path that doesn’t physically exist.

While your htaccess rewrite patches that and allows images to be loaded in the front-end, that only really masks the underlying problem which is that the path the media source returns is incorrect. The different base url modes try to help, but can’t cover every use case.

Please set your media source with an absolute url (prefix baseUrl with a slash, set baseUrlRelative to false) and if you still can’t get it to work after that please email support@modmore.com (link back to this thread to avoid having to copy all info).

1 Like

This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.