Thread

Hi there;
Can somebody confirm whether this is a bug? Here’s the situation:

When I place an image via the RTE field’s buttons the directory seems to be hard-coded. In other words, when I export the database (and copy the image files, of course) over to the remote server, the src url for the image embedded in the RTE field remains that of the local server, despite the fact that my image directory path is correctly set for the remote server (I use FocusLab’s master.config system to dynamically update all such directory paths, and it works fine). To explain this another way:

If I place an image file via a file field type and reference that file in a template via a {file} tag, the src url will honour the directory path as defined in File Upload Preferences. (These paths, in turn, are auto-updated courtesy of master.config, eg. localserver/usercontent/myimage.jpg on the local server becomes remoteserver/usercontent/myimage.jpg automatically).

But if I choose to insert the image via the RTE field instead, then when the page is parsed on the remote server the image’s src url is still set to localserver/usercontent/myimage.jpg—thus the image does not display. The RTE image placer seems to bypass the File Upload Preferences path, or at least not treat it as dynamic once set. (It makes no difference whether the image placement is of an already-existing image or whether it is a brand new upload; the problem is the same).

Is there some setting that I’m missing re. the RTE, or is this a bug in the rich text image handling system?

Thanks as always.

Ker-bump(?)

Not sure if you found a solution but I’m having the same problem.

The solution I found was simply to not use the RTE for placing images. Hardly the elegant user-friendly fix I’d have hoped for, but it’s a workaround. I tend to set up a Grid field for input that needs to be a mix of text and image. The Grid columns are setup as RTE | file | text input | text input. The RTE column is for general article text, the file column is to add an image, and the two text input columns are for Alt text and Caption. The person editing the article creates a new row after each image that they insert (assuming that there is more content coming after the image).

Maybe the directory URL bug has been fixed in the latest version; I noted this bug back in February. But I’ve not used the RTE for inserting images since then, so I don’t know if it’s still an issue or not.

I have v2.9.0 - Build Date: 20140715 and the bug is still there.

Just to let you know this has been confirmed as a bug.

2.9.2, almost a year on and this bug is still hanging around? Or is it something more basic and linked to how Rich Text works? I just did an experimental install of Expresso and it does the same thing (ie. hardcodes the whole image URL rather than using the EE directory shorthand, which would be portable (right?).

Expresso is based on CK Editor, so I wouldn’t necessarily expect it to understand EE’s file upload directories, but there’s no excuse for EE’s own native RTE to fall over on this, is there? After 11 months of knowing about the issue?

As a workaround, I’m replacing the domain part of the image URL (plus the trailing slash) with the {site_url} tag, so http://example.com/library/myimage.jpg becomes {site_url}library/myimage.jpg. The result is a domain-portable image src URL (or link href). In EE’s native RTE one has to use the Source button to achieve this; in Expresso one can make the change at the point of image selection since the URL is displayed in the dialogue (a better option in general, since it also means that one can place an image located outside of EE’s upload directories, e.g. on another domain).

This workaround is good enough for entries added on the client’s behalf during development, though it’s probably a bit risky to ask clients to do this themselves unless they are happy working with code. So of course any entries added by the client after the site is moved to the production server will not be portable like those in the ‘development’ entries, which could still cause problems should the site need to move between domains.

Should such a move become necessary, however, the broken URLs could be corrected via a search and replace in the database as noted by Derek Jones in this comment on the related bug report: https://support.ellislab.com/bugs/detail/20554/#13868

One small downside of the above workaround is that images placed using the {site_url} tag do not show up in the RTE field; the editing field will show only a broken link’ image placeholder, since the URL cannot be resolved until the code is parsed in a template.