After installing the latest Wysiwyg version 7.x-2.2, all images within my CKEditor box are broken, even those newly uploaded. On the web page itself, they display normally. The issue occurs when adding new images as well.

Updating my library from 3.4 to 3.6.4.7575 had no effect.

Clearing both my browser and drupal caches had no effect.

Comments

TwoD’s picture

Which module are you using to upload images?

B.P.B’s picture

I do not use an upload module. The image is placed into the directory manually. I then insert the code using CKEditor's image icon.

The issue occurs across all browsers.

This is what I see inside the CKEditor:
http://i48.tinypic.com/2n838kx.png

But the image displays normally on the web page after saving.

B.P.B’s picture

The bug persists despite making a fresh install of Drupal with only the standard modules installed in addition to Wysiwyg 7.x-2.2 and CKEditor 3.6.4.7575.

TwoD’s picture

Status: Active » Postponed (maintainer needs more info)

Ok, so you're not actually uploading images through the editor, just linking to images uploaded some other way (or located somewhere else).

What does the image URL look like if you click "Disable rich-text" after inserting it?
This is the markup that will be submitted to the server.
Is the URL relative or absolute?
Is it using the correct path at all?
Are you using Pathologic's filter to fix URLs during rendering?
If the URL looks OK after disabling the editor could you try using Firebug for Firefox, or a similar tool, to inspect the inserted image while the editor is enabled and compare the URLs?

B.P.B’s picture

Status: Postponed (maintainer needs more info) » Active

Just to clarify I upload the images by FTP to a files folder on the same domain.

After clicking disable rich text: (I changed some names after copying but the structure remains the same)

<p style="text-align: center; "><img alt="my alt text" src="files/mysite/article-images/photo.png" title="my title" /></p>

The browser source and firebug show exactly the same html as above.

Yes, the paths are relative and appear to be correct. The images display perfectly fine on the website, as they should, because CKEditor is outputting correct html. My only issue is not being able to see the image inside the editor box, which on large pages with multiple images is inconvenient.

I am not using the pathlogic module. Here is a list of enabled modules: http://pastebin.com/0k7tpBrw

TwoD’s picture

Does Firebug's network tab say anything about the HTTP status of the image request from within the editor?

B.P.B’s picture

While in edit mode, I opened Chrome's tool and found the file under the network tab:

photo.png
/node/5/files/mysite/article-images
GET
200
OK
text/html
ckeditor.js:13
Script
40.30KB
39.78KB
821ms
738ms

And also under console:

Resource interpreted as Image but transferred with MIME type text/html: "http://mysite.com/node/5/files/mysite/article-images/photo.png".

When I paste that URL into the browser, I get the correct page, but with a broken image, just like in the editor.

TwoD’s picture

The /node/5 part looks wrong. I'm thinking it's using the wrong base path so it's trying to request things relative to the current URL. When you request "http://mysite.com/node/5/files/mysite/article-images/photo.png", you're probably getting "http://mysite.com/node/5", but with "files/mysite/article-images/photo.png" sent as an argument to the page callback (that part gets ignored by this particular page).
So instead of getting the actual image data, it's getting the HTML page from "http://mysite.com/node/5", thus the MIME type warning.

If you type CKEDITOR_BASEPATH into the Chrome console, what exactly do you get returned as the value of that variable?

Do you know if the server has set the PHP config value allow_url_fopen=0? If so, you should also be getting warnings in the Drupal logs similar to those in #1802394: Warning: file_get_contents from 7.x-2.1 to 7.x-2.2. That would prevent Wysiwyg's small initialization script from setting the correct CKEDITOR_BASEPATH value when JavaScript Optimization is enabled on the Performance page, though I'm not sure it would have these exact consequences.
If that does appear to be the issue, try with the latest 7.x-2.x-dev snapshot, we've committed a patch there already.

B.P.B’s picture

Typing CKEDITOR_BASEPATH into the chrome console returns: "/sites/all/libraries/ckeditor/"

The latest dev has the same behavior. To be sure, I updated, cleared drupal cache and browser cache. It still gives the bad path /node/5 in console.

From php.ini: allow_url_fopen = On

I don't see any relevant errors in the drupal log.

TwoD’s picture

Ok, that base path is not an issue then.

I think the image markup you posted in #5 should have looked like
<p style="text-align: center; "><img alt="my alt text" src="/files/mysite/article-images/photo.png" title="my title" /></p> (note the slash at the beginning), otherwise it will be interpreted as relative to the current document's URL. So, if you're viewing node/5, it will try to load /node/5/files/mysite/article-images/photo.png, which doesn't exist so you'll get a 404 page and no preview.

Does it work in the editor and when viewing the page if you add the slash at the beginning of the path when inserting the image?

B.P.B’s picture

Adding the slash works, but only in the dev version. Is it safe to edit in until the next release?

TwoD’s picture

Only in -dev? That's strange since there haven't been any committed changes to the CKEditor integration since 7.x-2.2 yet.
The only change indirectly affecting CKEditor was the fix I mentioned in #8.

Yes, it's safe for use so far. Keep an eye on http://drupalcode.org/project/wysiwyg.git/shortlog/refs/heads/7.x-2.x to know what has changed since the 7.x-2.2 tag.

B.P.B’s picture

Forget what I said about 7.22 and dev. You are right. I downgraded to 7.22 from dev, added slashes and everything is ok.

I have the exact same site running both on localhost and on shared hosting. When this issue came up, I assumed they behaved the same. As of today, thanks to your insight, this is what works in regard to the directory structure.

The directory for the hosted site must be:

/files/mysite/article-images/photo.png

In localhost running xampp, the directory must be:

/mysite/files/mysite/article-images/photo.png

(its located in: C:\xampp\htdocs\mysite)

Before upgrading to 7.22 from an older version, inserting an image did not require an extra directory level and slash when working in localhost.

Migration from offline to live will be difficult as the directory structures do not match anymore.

TwoD’s picture

Hmm, if your web root on the live server is /home/myuser/public_html/ and on your local server it's C:\xampp\htdocs\mysite, and both have the "files/mysite/article-images" folder in those directories, there should be no problem.

But maybe your web root on the local server is C:\xampp\htdocs, and Drupal is installed in a "mysite" folder, with "files\mysite\article-images" inside that, you will have a path issue.

However, if you don't sync the .htaccess and settings.php files between the live and local servers (which could be a good thing since they are two different environments with different contexts, and perhaps different database credentials), you should be able to set the RewriteBase directive in your local.htaccess file to "mysite" - and perhaps change the base path variable in settings.php - to compensate for this.

Then it should be enough to make the image path look like /files/mysite/article-images/photo.png on both sites. The leading slash would then point to /home/myuser/public_html/ on the live server, and C:\xampp\htdocs\mysite on your local server.

There are a couple of good resources discussing dev/live/testing environment differences, didn't find the specific ones I was thinking about right now, but found some others touching the subject:
http://drupal.stackexchange.com/questions/9/suggestions-for-settings-php...
http://groups.drupal.org/node/24196

B.P.B’s picture

I set up aliases and the directory structure now matches on both servers. Thank you for your assistance.

TwoD’s picture

Category: bug » support
Status: Active » Closed (fixed)

You're welcome.

TwoD’s picture

We got another issue on this subject and I remembered there's a setting which may affect this; baseHref.
I've put together a minimal module in #1861174: 7.2.2 and 7.2.2dev-Version break CKEditor 3.6.2 which re-introduces a value for this setting, which we left to its default between 7.x-2.1 and 7.x-2.2. Please have a look at that issue and see if that module fixes your issue.