Merge with 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?

@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.

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.

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.

I am obviously late to the dance here, but going to add my penny's worth any way.

1. Caches are cleared often enough that even input filters should take some care for performance.
2. URL aliases are a problem everywhere. Take a look at the block page, calling url aliases on the "configure" link - stupid waste of cycles. Many people, when getting to that many aliases, simply begin to abandon their use. It is not the SEO-killer it once was.
3. The simplest solution is for one or the other module to make sure it supports all functions of the other and has an upgrade path, if needed. Then the lesser-functioning module can be abandoned. I don't care which it is. Perhaps creating a comparison page will help identify the differences as well as helping users decide which to use.
4. This issue is now two years old, it needs to die or be addressed.

Maintainers of both modules have done great jobs. :-)

Drupal guidelines recommend maintainers to join forces (whenever modules offer similar functionality): http://drupal.org/node/23789

Advantages of joining forces:
1) As development effort is focused on ONE module (a SINGLE codebase), solving issues happen faster and (functionality, security and performance wise) better.
2) No incompatibilities can arise between similar enabled modules.
3) Less effort is needed from the maintainer and the rest of the module community (incl. submitting and processing issues and feature requests).

So, please:
A) At least, reference each other's projects on both your project pages and (online) documentation, as some responsible maintainers have done in similar cases: http://drupal.org/node/532278
B) Become co-maintainers of each other 's project. Stop adding new features to the newest module and add those features to the oldest module (if they are not already implemented in the oldest module). In the meanwhile continue fixing new issues in the newest module, until the oldest module offers all the features of the newest (obsolete) module.

Now, let's see really which maintainer is cooperative here. ;-)

@'hass': I suggest you submit your suggestion (http://drupal.org/node/267882#comment-874098), regarding url() performance in Pathologic: http://drupal.org/project/issues/pathologic

BTW: Isn't a fundamental difference between the modules that the one (Pathfilter) does and the other (Pathologic) does not require a custom prefix ("internal:") to local URL's and thus an input filter? Or is this prefix an optional/ configurable requirement in Pathfilter? More info: http://drupal.org/node/819512#comment-3229180

I don't necessarily agree with B. Sometimes it's better to go with the newer module just to get rid of baggage from older releases.

I will reiterate: A good first step is a comparison page (see http://drupal.org/node/298397), linked from both module's project pages. I have no experience with Pathfilter because I've never needed it. Pathologic was my boss' choice and it works well for us. But I would like to see a side-by-side listing of features to see if we should switch.

BTW, let's not forget URL Replace Filter.

Merging URL Replace Filter into Pathologic has been discussed, although no decision appears to have been taken yet. See #873728: Change ownership of URL Replace Filter.

not and Nancy, if you check out the project page for Pathologic, there's a comparison between it and other similar modules at the bottom. It's been there for some time, though it may be a bit out of date.

Yes, I did see that on the project page. However, a better thing to do is to move that into than handbooks where multiple maintainers can update the comparison when their modules change as is the case in the example I provided. BTW, in marketing terms, it also gives you another venue to "sell" your module.

In project management, we often call these comparions a "gap analysis" - I'm sure you've heard the term. If one wishes to get from point A to point B, one first needs to find the path. A comparison page could help in identifying the differences.

As for merging into the older module, I'm not sure that is appropriate here, as the Pathologic code is a marvel in PHP engineering. I learned a few new things in looking at it.

In the case of Web Links, we did these comparisons and tried to include all the functionality into the one module. Some of the other maintainers just didn't want to cooperate, or no longer actually maintain their modules, so we just made them obsolete. In one case, I actually became the owner of one module, made a few fixes, and then referred all new users to Web Links. That's the reality of Drupal sometimes.

People need to stop trying to shoehorn developers together that are obviously on different wavelengths.

Look how many updates to functionality pathologic has gotten since its initial release, then look at path filter.

Any time you force people together, it creates social loafing and the project dies. If they have a desire to work together, then that is another story.

There really is no such thing as "overlapping effort" just because two lines cross the same path at some point if the outcome is completely different.

Pathologic should have an option to save URLs in the database as internal: or files: like Path filter does. I want to switch to Pathologic because it has a stable Drupal 7 version, but I don't want the URLs of my development or testing sites to be saved in the database, and don't particularly want to configure the Pathologic URLs each time. Merging the code in pathfilter_6.x-2.x-dev that replaces the current domain with internal: on node save, and replaces internal: with the current domain on node load is the only thing that is missing from Pathologic. I would drop Path filter in an instant if Pathologic did this.

Sorry, Pathologic is not going to modify a node's content when it's saved or loaded. Pathologic is only an input filter, and input filters don't modify content.

That being said… input filters don't modify content, so the only way that paths of your dev or testing sites would be making it to your live site would be if you are transferring the content of the cache_filter database table from site to site. You shouldn't migrate the data in that table, or an any of the cache tables, really. Aside from causing these sorts of problems, it will also slow down the migration process unnecessarily, since the data in these tables is redundant by definition. If it's not possible to stop migrating that table's content, then simply clearing the site cache when the migration finishes should do the trick.

I'm with Garret on that point. There is no need to alter the content. Further, as he said, doing so is against Drupal guidelines (filter on output).

Path Filter has not released a Drupal 7 version, and the project page points people towards Pathologic instead. This has been resolved.