I am using WYSIWYG editor with IMCE for article description, the issue is that once i upload an image file with imce, its showing image path like


Once we hosted website from local to online server, image is not showing because now DirectoryName is changed to some other name.

Any suggestions?

  • It looks like a bug to me, it shouldnt store complete path for the file. – GoodSp33d May 13 '13 at 8:55

I think the Pathologic contributed module will do it. I have used it in the past and it's awesome. Configuration is a bit tricky, but once it's done you can forget about most file path problems. It's an input filter for text, so it can be used anywhere you can set an input format.

Configuration of Pathologic is covered here. I think it may have issues with internationalization in some cases though.

| improve this answer | |

(This answer assumes a standard setup using MySQL and Apache on linux.)

I'm afraid the best option is to do a manual search-and-replace on your database, replacing /DirectoryName/ with /NewDirectoryName/ (or /, if your production site does not use a sub directory) in all fields with the WYISIWYG editor enabled. Make sure you search and replace in the field_data tables (like field_data_body) as well as the field_revision tables (like field_revision_body).

I guess you could also add a rewrite rule in .htaccess to rewrite old image paths to new ones, but that doesn't really solve the problem and might make your site more difficult to maintain in the future.

To prevent this problem in future projects, make sure you know beforehand what the production URL is going to be. Set up your local environment with a virtual host to mimic the production URL. For instance, if the production URL will be http://www.example.com/, you can use http://dev.example.com/ for your local environment. If you know the site will run in a subdirectory, eg. http://www.example.com/drupalsite/, set up your local site as http://dev.example.com/drupalsite/.

| improve this answer | |
  • I beg to differ that a manual search and replace is better, as it would need to be repeated in future should the same problem arise again. I think that Pathologic is generally a better solution, as it can be configured to handle any changes later on. Such as moving the site from live back to local in this case. Admittedly, it's best to avoid such problems in the first place. – Phizes May 13 '13 at 9:25
  • OK, you're right, I should have mentioned Pathologic. I had some issues with it in the past, but that may be solved by now. That said, a manual search and replace does not need to be repeated if you also set up your local environment correctly at the same time and start using the altered database on local too. – marcvangend May 13 '13 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.