local URLs don't work when Drupal is in a subdirectory

Could you ensure that you're using the latest release of Pathologic (7.x-2.11)? The code sample you posted no longer exists in the code base, so it sounds like you're using an outdated version somehow.

Okay, my mistake - I was looking at the wrong thing somehow.

At any rate, it's strange for things to be bailing out there. How have you configured the filter settings for Pathologic?

I believe I'm running into the same or a very similar issue. All my relative links (e.g. 'node/45') are ignored by pathologic which bails out at the same place.

Pathologic is configured as the final filter (Filtered HTML), full URLs, and no base paths. My site runs under the '/d7' subdirectory and always has.

I suspect this last bit is the key to my problem. If I add '/' to the base paths, everything starts working as expected, presumably because the condition on line 286 starts "finding" a match. It would appear that relative paths are not found unless the base paths include '/', which does not happen by default if the site is running under a subdirectory.

A simple fix I came up with is to augment the check on line 292 to not bail out if the path is relative. Something like:

  // If the path is not within the drupal root return original url, unchanged
  if (!$found && substr($parts['path'], 0, 1) === '/') {
    return $matches[0];
  }

Please let me know if I can provide any further details to help!

Nice sleuthing, joachim. I've applied your patch to both the 7.x and 8.x branches.

Unfortunately, I don't use Drupal in a subdirectory on my dev machines (and indeed, perusio's config for Nginx doesn't seem to allow such a thing), and I don't know of any sane way to test for it using Drupal's testing infrastructure. So other subdirectory-related bugs may have snuck through besides just this one…

That still doesn't work with the Nginx config, though - it tries to find the "subsite" menu item under the standard domain name.

Maybe I'll ask in the Nginx group on Groups.Drupal.org if there's a way to do it, since my Nginx configuration skillz are still pretty n00bish compared to others.

thank you for this fix/patch in #7.
I am new to pathologic and was pulling my hairs out wondering why it didnt seem to be working the way the all the rave reviews said it would ;) I am developing in a subdirectory. I read all the other subdirectory related issues I could find, and none seemed to help (trying adding various paths into the "consider local" config).

But with this patch as mentioned above
node/xx is working
/node/xx works
AND ALSO the final piece for me -- imce generated paths to images/files are now working as well:
/drupal_dir/sites/default/files/xx

thanks!

@joachim

Thank you so much for the patch to pathological at #7 I was tearing out what hair I have left trying to sort this. I had a test installation of drupal 7.24 in a subdirectory to make sure it was working before going live and of course it wasn't working because it was in a subdirectory...

Have you sent the patch to the pathological maintainer?

Thanks again, Peter

peterthevicar;

I am the developer of Pathologic. The patch in #7 is already in the codebase, and has been for some time, though I haven't released a new release in quite a while - looks like it's overdue.

Thanks for trying Pathologic!

Amazing I found this issue while in progress on a custom fix :)

I have tested this out, and am still seeing problems when one of the configured previous sites was in a subdirectory.

I do not believe it is related but I am also correcting for the filesystem site name not being replaced properly. E.g., file is referred to as sites/www.example.com/files/taco.png even though it should now be sites/default/files/taco.png

Adam! Long time no see. *brofist*

Could you give me more info about the circumstances where this isn't working? Or, of course, a patch would work too. :P

My use case is a bit odd (you'll see a new issue on it in just a bit), so I'm not sure if it's easy to dice into a patch. Let's explore the problem first.

The site rig, with serial numbers filed off:

• Current Site: adam.example.com
• Old Site: adam.example.com/drupal

The content, via Media module, rendered through pathologic 7.12:

• Link to the image: //adam.example.com/drupal/files/1
• Image src://adam.example.com/drupal/sites/adam.example.com.drupal/files/styles/medium/public/img_2364.jpg?itok=r6_g2Hne"

Expected content:

• Link to the image: //adam.example.com/files/1
• Image src://adam.example.com/sites/default/files/styles/medium/public/img_2364.jpg?itok=r6_g2Hne"

/**
 * Implements hook_pathologic_alter().
 */
function noc_pathologic_alter(&$url_params, $parts, $settings) {
  // Initially planned as settings.php config because of the broader use case.
  // Going to submit a patch that will end up simplifying this,
  // including so I don't have to re-write the logic below. 
  $original_base = variable_get('original_base', 'drupal');
  $original_conf = variable_get('original_site', 'adam.example.com.drupal');
  $main_conf = variable_get('main_site', 'default');

  // This seems to be working to fix the files path.
  $url_params['path'] = str_replace($original_conf, $main_conf, $url_params['path']);
  // This strips off the base path.
  $url_params['path'] = preg_replace('/^' . $original_base . '\//S', '', $url_params['path']);
}

I also am having an issue which I believe is related.

I have updated to the latest release, but in my config I'm getting relative paths to other sites (same server - multisite installation) are getting appended to the current page.

So for example, I'm on a page like:

http://www.example.com/site1/page

if I have a link on that page to "/site2" the link gets printed as http://www.example.com/site1/page/site2 when it should print as http://www.example.com/site2.

Turning off pathologic fixes the problem. I'm set to use Relative links, but none of the settings seem to help.

dpfitzsi, that is strange behavior that I can't replicate. It looks like the output of your final path might just be "site2" instead of "/site1/page/site2." Do you think you could confirm this by looking at the output HTML? Devel Input Filter may help with this if you have a testing site you can install testing modules on.

@Garrett Albright

Thanks for the information about the Devel Input Filter module, I will try that out to see if I can figure out where the issue is coming from. I'll post back with results.

@Garrett Albright

I did some testing with Devel Input Filter and I'm still having the issue with the site name being adding to the link when Pathologic is enabled.

I did some tests with and without a wysiwyg enabled. It doesn't seem to matter as long as Pathologic is enabled for that input filter. The site name will always get added to the front of the link.

I've attached two screen shots of what the output looks like for me, I hope this helps:

dpfitzsi, I assume your site is installed in a subdirectory named "ittraining", so the full base URL of the Drupal site is something like "http://example.com/ittraining/", correct? If so, what I'm seeing in the screenshots looks like correct behavior. What were you expecting to see?

Using just "link" as your href attribute differs from the example you gave in comment #19, where you implied the attribute was something like "/link".

@Garrett Albright,

You're right, I do have the site at http://www.example.com/ittraining. When I want to link to a different site on the same server, lets say http://www.example.com/site2, the url should be able to be entered as /site2. When pathologic is disabled the site assumes that site2 is a different site since I didn't lead the url with /ittraining/.

When pathologic is enabled I would get the behaviour you see above (the link prints as http://www.example.com/ittraining/site2).

Okay, I'm guessing, since you have a WYSIWYG editor, that you have a slash entered in your "Also considered local paths" field in the filter configuration form. If so, then unfortunately, this is still expected behavior; Pathologic removes the slash from "/link", then treats the path as just "link", resulting in the behavior above.

Does your WYSIWYG editor create paths to "/ittraining/something" when you just try to link to "something"? If so, try removing the slash from that configuration field and putting in "/ittraining/" instead. Then you should see the expected behavior. If not, see if you can configure the editor to work that way.

@Garrett Albright

It's true, I generally use a WYSIWYG editor. But, even if I don't use the editor on a node the same behaviour seems to happen.

Backdating to 7.x-2.11 seems to fix the problem.

dpfitzsi, did you try the part in my last post about adjusting your "also local" path settings?

Sorry, yes I did. I tried entering / and /ittraining/ and neither seems to do anything.

Is this fixed or this this a glitch on d.o?

The commit on this thread says it is from September 2013. Is this actually a new commit to code? This functionality is still broken in a multi-site installation. I have reverted to pathologic-7.x-2.11 and paths render correctly now.

Unfortunately, dpfitzsi, I still can't replicate your bug. :( As long as I have proper paths in "Also considered local," paths in Drupal sites in subdirectories are working fine for me.

Hi Garrett,

I'll have to do a new round of testing to make sure I get the same result. However, this solution still doesn't work when you have a feature-driven enterprise level installation. The only way I could get something like this to work is if token support was allowed in the "also considered local" field.

#33: second that, just filed a feature request for it over at #2396221: Support tokens in the "also considered local" field