I just installed the beta 3 5.x pathologic module and it seems like it is messing with the image tags.

For example:

<a href="link/tofeed"><img width="128" height="128" src="images/feed-icon.png" /></a>

When I hit preview, the img tag is gone but the a href is converted properely.

How can I fix this? Other than that problem, this module works great. It's just what my Drupal installation needed.

Very useful module.

Will it convert img links as well? That would be awesome.

Comments

Garrett Albright’s picture

Hmm, I can't replicate this behavior…

…unless I select the "Filtered HTML" input filter from the "Input format" fieldset on the editing page, which removes img tags by default. Might that be what's happening here? Select "Full HTML" instead, or add <img> to the list of tags that "Filtered HTML" will accept (Administer, Input filters, configure in the Filtered HTML row, Configure tab), and let me know if you see the same behavior.

As for fixing image paths… That ought to be possible. I'll probably set it up as an optional feature.

Thanks for trying Pathologic!

gmclelland’s picture

I think that was the problem. Sorry for the trouble, I didn't realize the img tag gets removed with FilteredHTML input format.

Having the img paths fixed would be a great option.

Looking forward to it.

Garrett Albright’s picture

Title: Messes with Image Tags » Can Pathologic work with image tags?
Assigned: Unassigned » Garrett Albright
Category: bug » feature
Priority: Critical » Normal

After thinking about this for a bit…

Pathologic is basically a wrapper for Drupal's url() function. What this function does is takes a bit of text and turn it into a Drupal path. This won't always work well for images, though, especially if you don't have Clean URLs enabled. If Pathologic worked as it is on SRC attributes in addition to HREF ones, the code above would come out looking like…

<a href="http://example.com/index.php?q=link/tofeed"><img width="128" height="128" src="http://example.com/index.php?q=images/feed-icon.png" /></a>

So the link would work, but the image would appear broken. Epic failure.

That doesn't mean handling SRC attributes can't be done, though; it just means we'll have to implement a different strategy for handling them. Perhaps over the weekend I'll hammer something out.

gmclelland’s picture

If you wanted to, you could expand the Pathologic Module to include HREF, SRC, and ACTION conversions.

HREF attribute works for the A, BASE, AREA, LINK, and SCRIPT elements.

SRC attribute works for the IMG, INPUT, IFRAME, and FRAME elements.

ACTION attribute works for the FORM and INPUT elements.

Just a thought. That should provide full functioning content in a development and production environment. Sweet!

What do you think? If not, image src conversions would still be cool.

-Glenn

Garrett Albright’s picture

Version: 5.x-1.1-beta3 » 5.x-1.1-beta5

Okay, I've just released a Beta 5 version with support for src attributes. Please give it a try.

gmclelland’s picture

Just curious, is it possible to link to an image file within the node's body in non-theme specific way without the php filter enabled?

I am trying to replace the following code with pathologic's way of linking.

<img src="<?php print base_path() . path_to_theme() 

/images/feed-icon.png" alt="Feed Icon" />
?>

I want the src to always look for the image file in the themes images folder.

I was thinking I could use pathologic to give me links that don't break between dev and production, and I was trying to find a way to link to static images in way that won't break if I change the theme. Do you know of a way to accomplish this without having to use the php filter?

What's your thoughts?

Garrett Albright’s picture

In the interest of avoiding feature creep, I'm going to say that that's probably not something Pathologic will ever do.

Three ways I can think of to solve that problem are;

  1. Move such images out of a particular template directory, and into a more stationary location, such as in the files directory.
  2. If your web server will allow it, set up a symbolic link ("alias" in Mac OS parlance; "shortcut" in Windows) with a name like "current-theme" which points to the directory of whichever theme you're using. Then the src attribute can be something like "current-theme/images/feed-icon.png." You may have to do this from a scary command line, and you'll have to update the symlink whenever you change themes, but this way, you won't have to use the same theme on the dev and production servers.
  3. Find another text filter that does something like this. Maybe just one that does simple string substitution will suit you; have the image's src value be something like "[TPLPATH]/images/feed-icon.png," then have the text filter replace "[TPLPATH]" with the template path. When you change the template the site uses, change the replacement path as well. Heck, if that doesn't work for you and you absolutely must have a filter that'll print the path dynamically, I'll write you one (it might take all of half an hour); I just don't think it's something that needs to be in lean-and-mean Pathologic.

I can think of another way, but it'd involve some programming that I'm guessing you don't want or know how to do. Hope you can find another solution soon…

gmclelland’s picture

Wow, thanks for the write up. I didn't even think of using symlinks. Symlinks would work great on linux and mac machines, but would you have to setup hard links on windows which is a little more involved. Good point about using symlinks with separate themes in dev and prod.

Writing the filter and doing the custom programming is a bit out of my knowledge until I get more familiar with Drupal. Although, I do think a filter like what you described would be helpful. Something like [THEMEPATH].

I just didn't want to have to give users privileges to execute the php filter just to reference some images.

Again, thanks for your help.

Garrett Albright’s picture

Status: Active » Closed (fixed)

Pathologic has been working with SRC attributes for a while now, and the most recent version now supports "relativizing" absolute URIs, so… closing this issue.