If I save a node through the admin interface (which is always run securely with https) and then open the saved page as a normal insecure http request, the links in the node stay with https.
Pathologic should change the protocol address depending on whether the request is being made through http or https.

Comments

Garrett Albright’s picture

Under the Pathologic section of the filter settings for the text format(s) you're using, try selecting "Protocol relative URL" from the "Processed URL format" field. That should show you the behavior you're expecting. Please give it a try and report back here if it does the job for you.

mileski’s picture

This is what I give in CKeditor (viewed in source mode) : src="sites/introcode.com/files/public/images/tuev-rheinland-282x73.jpg"

This is what I get after saving the page: src="//www.introcode.com/de/sites/introcode.com/files/public/images/tuev-rheinl..."

All the image links are broken.

And secondly, the language prefix is being added for English as well as German, which it shouldn't do, because this link is a file.

p.s. Thanks for the fast response.

Garrett Albright’s picture

Huh, that's a different problem. Were you still having that same prefixing problem before you changed the settings as I suggested above? If you're not sure, do you think you could change the settings back and check?

Pathologic does its best to determine if you're giving it a path to an existing file and not allow the path to be prefixed with a language code in that case, but it sounds like it's failing for you at the moment for some reason.

mileski’s picture

Title: Pathologic does not change https to http and reversed » Pathologic adds language prefixes to files when all languages have language prefix

The setting that I've changed, so it will build the links without https, so it won't mix up http and https is solved.

The thing is, pathologic stopped working with images at my site when this happend:

I upgraded from 7.x-2.6 to 7.x-2.9

and

in the beginning, I've set up my site to use the default language without any prefix. Afterwards, I changed this behavior, so that English pages get /en prefix, and German pages get /de prefix.

Pathologic was working when there was no prefix for at least one language. But, as soon as I put lang-prefixes for all of them, now this is happening.

Every link gets the lang-prefix, unfortunately. I'm debugging your code at the moment, but I don't know if I can find the problem. If you like to reproduce this behavior, I suggest you install multi-lingual drupal, with two languages. Set the other one as default (not English) and put language prefixes on all of them.

Can you help me with this issue?

Garrett Albright’s picture

Unfortunately, I can't replicate the problem, so I can't determine the cause very well. All I can guess is that Pathologic is failing to detect that what you're linking to is really a file on disk.

Do you think you could go to admin/reports/status/php and tell me what PHP is reporting for the _SERVER['DOCUMENT_ROOT'] value? (It will be near the bottom of the page.) There may be a hint there. Feel free to email it to me or /msg me on IRC if you're not comfortable sharing that publicly for whatever reason.

mileski’s picture

php shows the _SERVER['DOCUMENT_ROOT'] under /var/www/..., but Drupal install is in /usr/share/drupal/current. I have an alias for the "/" to point to the Drupal root in my Apache conf.

Do you think that pathologic is searching in this path instead under drupal root path? Because if it is, than we have a problem. The files are not under the _SERVER['DOCUMENT_ROOT'] folder.

Can this be the problem? Btw, why doesn't pathologic only consider the base_path() function from drupal?

Garrett Albright’s picture

Okay, if $_SERVER['DOCUMENT_ROOT'] is not telling the truth for whatever reason, that's probably the problem, yes. I don't quite understand, though - you're saying you have Drupal installed in a path outside $_SERVER['DOCUMENT_ROOT'] but you've symlinked it in? It might be helpful if you give me more info on what sort of setup you've got going on there and why.

base_path() returns the base URL path of Drupal. I need the base filesystem path of the web root, and base_path() doesn't give me enough info to work with in that regard.

hass’s picture

I do not have any $_SERVER['DOCUMENT_ROOT'] customizations like this and the issues reported in the other case.

mileski’s picture

I did not say I have symlinked the drupal root. I have only created an Apache Alias from "/" to "/usr/lib/drupal/current/".

The virtual host for the Website is under /var/www/vhosts/sitename.com/httpdocs/.

This is actually a normal configuration in many systems. Because, look, people use drupal to "show" the website. But, there are other things running on one's website. For example, you have paths that are not part of drupal. If you go to some address like http://sitename.com/somepath/ - drupal shouldn't get involved here.

The problem lies in the beginning. The root server was installed with parallells plesk, and I didn't change the DOCUMENT_ROOT. After installing drupal as a multisite setup, I have aliased the "/" path to the drupal install. But, I still think that you should consider only paths that are under the drupal base_path(), and not DOCUMENT_ROOT.

Garrett Albright’s picture

I recently accepted a patch which may solve the problems you're having. Could you try downloading the most recent dev release and let me know if it fixes the problems for you?

Garrett Albright’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +pathologic-multilingual

Adding pathologic-multilingual tag and marking as more info pending further reply.

Garrett Albright’s picture

Possible duplicate of https://drupal.org/node/1927990 … Is this bug still happening?

axe312’s picture

Issue summary: View changes

Yes it is, using "Protocol relative URL" fixes this for me!

Garrett Albright’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)
basvanderheijden’s picture

I'm still experiencing this problem.

Garrett Albright’s picture

basvanderheijden, is it the same issue you mentioned in the other issue? If not, please create another issue for it, as this issue is very old and was filed against old code.

basvanderheijden’s picture

It's the same problem. But in the other issue I've supplied a patch.