Join dev team of pathfilter!

Hi, hass.

Hmm, I was unaware that module existed. It predates mine by quite a bit, too. I wish I had known…

Oh well. I'm less than anxious to merge my work with that module, though, for two reasons; one, mine is a little bit more capable than that one with its capability to "undo" absolute paths (that begin with http://example.com/…), and two, because if that issue has been an issue for that long, I somehow feel that the developer must be a little resistive to making changes to it -- I can relate, though.

What I would be willing to do, though -- and what would be relatively trivial to do -- is add Path Filter compatibility features to Pathologic. Basically, this would be a matter of telling Pathologic to ignore the "internal:" at the beginning of a path, if such is found. That way, you and other Path Filter users could migrate to Pathologic and start typing paths without "internal:" without having to go back and remove all the "internal:"s from your older content. Does that sound good to you? Do you think you could test it for me if I made such changes?

It's no good idea to maintain two modules doing the same. The issue stayed long in queue as nobody taken up the todo. That's all. The maintainers agreed it would be nice to have this feature.

You should collaborate with them and not creating a fork what confuses many new people. It's normally a rule on d.o not to create same projects with the same target :-). And it would not only save your time...

Aside your module is a performance killer... calling url() on every URL creates a BUNCH of load on the DB, often not required.

@hass: Pathologic is not a performance killer — like any filter, its output is cached. And by the way, Pathfilter (or any filter of this kind) has to call url() too.

Pathologic calls url() ~5 times more and in senseless places, too than pathfilter - therefore performance killer. Not every page is cached. Logged in users are never cached for e.g.

Pages may not be cached for logged-in users, no, but the output from input filters still is.

Pathologic calls url():

1. When generating the regular expression to search for possible local URIs in content.
2. For each href or src attribute it finds which it thinks is local.
3. Once on the input filter configuration page.

That means for content with six links or images in it, url() will be called at most seven times, probably less -- and this will only happen once, as the output of input filters is cached for everyone, as mentioned above.

Besides, what url() does really isn't all that intensive.

Of course, this is an open-source project. You're free to inspect the code yourself and see what exactly it's doing.

url() is one of the functions with heavy load in Drupal. Try to use Drupal with 180.000 url aliases and you will understand what I'm talking about. I inspected the code of pathologic and it called (when I've done the review) the url function on every URL, nevertheless it was an alias or not and full url's, too. It doesn't have a filter for node/*, user/*, admin/*, etc url's. It simply searches for all href's an executes the URL function nevertheless it makes sense or not (calling on admin/* never makes any sense). This could have been changed, but nevertheless the module is a fork as it only duplicates the much older "pathfilter" project. There was already a case about such a filter and this is what I'm complaining about here. Nothing else - simply don't fork other projects and don't reinvent the wheel, please.

Pathologic is also not a fork since it has been developed independently from Pathfilter, as Garrett has explained. It might still be a good idea to merge the two, but I wanted to straighten the fact.