When adding images to wygwam with the CI plugin, the images have the url hard-coded in their SRC attribute. When moving from “example.dev” to “example.com” this causes major headaches. Would it be possible to either use a slash (e.g. /?ACT=50&fid;=...) or instead of the ACT insert the real imagepath with a {filedir_x} (Wygwam handles images and inserts filedirs rather nicely)

Regards,
GDmac

(When i have added images in a wygwam field with the CI plugin. Then click submit causes javascript errors. Because of this the menu’s don’t work anymore. If you reload that page it is fine. Editors might wonder what is wrong.) (Chrome issue with javascript)

Have you tried just changing:

http://www.domain.com/url/to/images/

to

/url/to/images/

This should work for you.

Brad

You mean in the upload preferences?

Yes.

Brad

Did it solve you issue?

Just so we know and can close this thread

Nope, that doesn’t work. The image-url still contains the dev-domain.

What is the reason the ACT= is used?
If you link to an image upload directory, then wygwam will replace part of the url with {filedir_x}

Well the reason is simple..
Channel Images also handles S3/Cloudfiles so placing {filedir_x} in there wouldn’t work for those.

I tested your issue out on one of our other servers and it also happens there.
And fixing that would be hard.

Your solution of /ACT=x would work fine on most installs.
BUT, would not work if ExpressionEngine is installed in a subdirectory.

This really limits our options.

I see the problem when you have a new entry, uploaded some images, and start inserting them immediately into a wygwam field. The entry_id directory is not yet made, and still you want to add those images.

A possible solution would be to change the storing procedure. Store the images in the image upload directory under the channel-images id, instead of under the entry-id. The module already keeps track of all the necessary info like author, channel and entry-id in the db-table. This would also open a possible passage to using channel-images in other contexts like low-variables or member-images.

Brad, what i meant is to decouple Channel-images a bit more from the channel part.
- As mentioned, Channel images itself already keeps track of the entry info in its own table
- Channel-images would store its images in the upload-location under its own ID (e.g. ci_213) not entry_id
- If stored under ci_ID you can easily use the images immediately in WYGWAM.
- The image identifier and settings should make the difference between remote vs. local unambiguous.
- Have a small managing interface in the module_mcp to manage and clean up unlinked dirs etc.

With these changes i think channel images can act even more as a module, and manage its own assets. The fieldtype will maintain the tight link to channel-entries for deleting etc. This approach would also open the door to using channel-images under low-variables etc.