Hi there,

I guess a similar request has come up before already, but it seems that all other issues relate to TinyEditor, so I thought I'd open a new one.

Basically the issue that I'm encountering (using Wysiwyg + CKeditor 3.5.2.6450) is that when a logged in user edits content, he'll normally be accessing the site via HTTPS. So when he uploads an image inside the CKeditor, the absolute path is somehow stored, so with the https:// prefix.. And then when an anonymous user accesses that piece of content, the image path will be also with https:// in the source.

I guess for the case above, things still kind of work, but this might be more annoying for people trying to move their sites around. Anyway, it certainly sounds like a bug, though I really don't understand where the path is stored like that. If I look at the source of the HTML content, there I see this [[{"type":"media","view_mode":"media_large","fid":"1004","attributes":{"alt":"","class":"media-image","height":"230","style":"width: 307px; height: 230px;","typeof":"foaf:Image","width":"307"}}]] and if I look in the DB file_managed table, I see 1104 1 mini.JPG public://mini.JPG image/jpeg 45467 1 1335429999 be1b4c68-57f1-eac4-9935-2a3e1045a8aa image so nothing indicating https:// anywhere.. So basically, how dos it even remember the absolute path that the image was uploaded with??

Anyway, would appreciate if you could take a look and/or suggest where this is happening at least so that I could possibly provide a patch or hack around on my site.

Cheers

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Project: Wysiwyg » D7 Media
Version: 7.x-2.1 » 7.x-1.0
Component: Editor - CKEditor » Miscellaneous

I don't think it explicitly "remembers" that anywhere.
When content is rendered for viewing a node, that long string is passed through Media module's output filter for building the markup. Somewhere in there, calls are made to transform the internal "public://mini.JPG" path to an external URL pointing to your public files folder. ("public://" is automatically recognized as referencing a file in there by one of Drupal's built in stream wrappers)
Since this happens while the markup is created for a node view, and I can't see anything in Media module's tag indicating http/https, I don't think Wysiwyg has anything to do with it. All it adds to the content is that long string generated by Media module's editor plugin during editing. I'm not sure if it's Media module's responsibility to ensure the URL gets the correct protocol in the end, but they should know that so I'll move this issue there.
Maybe it's a cache issue? Since the output of text filters can get cached, it's possible that the content the anonymous users see was cached when the authenticated user viewed the saved node. I haven't checked if filter caches are allowed to cross the authenticated/anonymous "border" though.

arski’s picture

arski commented

I just cleared all the caches manually in the db (truncated all cache_ tables) to make sure that if I do it as https-logged admin, that doesn't affect anything. Also checked the body revisions of the page node in question and there the images are stored as described above, with the [[..]] placeholder..

So now really the big question is how on earth does Media remember that the image was uploaded via https? It must add some sort of path entry I guess? Can't possible be storing this in the variables table..

arski’s picture

arski commented

Also checked the full db dump for mentions of "https" and nothing there connected to images..

And I double checked the site that it's not in fact all images that are sourced with the https protocol on the site via some .htaccess setting or something like that.. the ones that were added before SSL was installed on the site are all linked to via http.. so weird. :)

craujax’s picture

craujax commented
Priority: Normal » Critical

I am having the same problem since last Friday, 4/27 in Drupal 7.12 in at least five different and unrelated sites. The sites have a combination of CKEditor/IMCE/WYSIWYG/Media.
I have been troubleshooting and found out that past following solutions for this kind of issue don't change the problem:
. Editing filter to convert media to tags.
. Installing different editors.
. Commenting out "magic_quotes_gpc = Off" in .htaccess.
. Editing magic quotes to off in php.ini for incoming GET/POST/Cookie data.

The sites are mostly in HostMonster & BlueHost.
All modules are up to date.
PHP 5.2.17
PHP register globals Disabled
Database system MySQL, MariaDB, or equivalent is OK
Database system version 5.1.61-community-log
Cron & Caches are run in a regular basis.

There are other open issue tags concerning the same issue.
Here is the most recent: http://drupal.org/node/1554546

Thanks for the help!

devin carlson’s picture

devin carlson commented
Status: Active » Closed (duplicate)

This is a duplicate of #1352182: Media assets should have relative paths for wysiwyg editors.