SpamSpan prevents Extlink mailto image

Thanks, I'm not really sure what can be done to fix this problem, since making the e-mail links on the page hard to find is what SpamSpan is intended to do. If SpamSpan adds a specific class to replacements (I believe it's actually a setting) then ExtLink could in theory try to target those elements as well. But at the same time, since you already have a specific class, there's no reason why your own theme's CSS couldn't place the icon.

Actually SpamSpan does add the "spamspan" class to all generated links - this is not a user-configurable option, so we can count on it being there. Thus, I propose the following simple patch - let me know if this works for you. It seems to work perfectly on my site.

To do this really properly, I suppose we should test for the SpamSpan module first, but I'm not sure how to do that in conjunction with the CSS file, and it seems like overkill for such a trivial CSS modification.

Maybe it is just a matter of the order in which the corresponding javascript functions are called.
Spamspan should be first. Extlink should be second.
Unfortunately I do not know how to control that, because I am quite new to Drupal.

I could be wrong - I am fairly new to JS in Drupal as well - but I think what you are looking for is a way to define your script's "weight". Unfortunately, I don't think that feature exists in the D6 API (though it will in D7). (see http://api.drupal.org/api/function/drupal_add_js)

That's why I think tweaking the CSS is the next-best solution.

Is anybody able to test this patch and verify that it works (or provide alternate solutions?) It works fine on my site, and is pretty foolproof IMHO.

@quicksketch: Will you please either commit this and mark as fixed or let me know if more work needs to be done, so I can get it out of my queue. Thank you.

Hey Dane, this patch will affect mail links even if the option to add the "mail" icon next to mailto addresses is disabled. I think a better approach would be to have the JavaScript add an extra "mailto" class to all spamspan links if that option is enabled.

Ah, good point. I don't know why I didn't think of that problem. I'll look into getting the necessary JS in place.

JS and jQuery are not really my forte; I tried adding the following code in extlink.js at line 57, but it breaks the script - "this" is undefined. Can you tell me what I'm doing wrong?

$("span", context).each(function(el) {
  try {
    var url = this.className.toLowerCase();
    if (url.indexOf('spamspan') == 0) {
      mailto_links.push(this);
    }
  }
  catch(error) {
    return false;
  }
});

Nevermind - that code seems to work fine now. Maybe I just forgot to clear my cache or something. See attached patch.

So I installed SpamSpan today to test this out, and I realized we're going about it in a strange manner. SpamSpan should work automatically with External Links as long as the two following things are true:

1) SpamSpan uses Drupal.behaviors like it's supposed to: #361440: Breaks on ajax view filters
2) External Links runs *after* SpamSpan (so the the mailto: links are in place). This can be done by setting the External Links weight to 1 in the system table.

So we need some collaboration here. Extlink needs to make a .install file an set its weight to 1, SpamSpan needs to apply that patch to use Drupal.behaviors.

Actually this problem seems to be fixed on my site just by installing spamspan-6.x-1.x-dev . Can anyone confirm this? (I'm afraid it could just be a fluke from caches not getting flushed properly)

I can't confirm that it works out-of-box for me. But with #361440: Breaks on ajax view filters fixed on the SpamSpan side, it's fairly easy to get it working for External Links. Just setting the weight of the module to 1 makes everything work for me.

UPDATE system SET weight=1 WHERE name = 'extlink';
TRUNCATE cache;

So now I think a extlink.install file is necessary to actually set the module weight on install/update, then everything should be good.

Yep, that fixes it! I've never had to make an install file before, does this look good? (You'll have to remove the .txt extension, obviously - d.o wasn't happy about the .install extension)

Works, at least the idea does. Thanks =). However, while I'm not the module maintainer or anything, it needs a bit of work I think

1) should be a patch and not just the file (google for creating patches site:drupal.org).
2) needs an an hook_update_X so people don't need to completely reinstall it for it to run :P

(I could do it, but, 1) feeling very lazy atm, 2) creating patches form svn that contain new untracked is annoying, and 3) can never seem to get the _X right. Bad me :( ).

I've committed this patch which adds the update function.

This issue is still with Drupal 8... Is there any solution too?