| Project: | Pathologic |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | i18n |
Issue Summary
I've spent the last three days trying to find a robust path naming/linking scheme for my multilingual sites. The best results so far have been with Pathologic, but I feel that I still have a very long way to go...
I am working with language-symmetric paths like 'en/page' and 'de/page'.
For my links, I would like to use relative paths without language information, like href="otherpage".
From there, I would need that the language prefix get's attached magically:
- link to 'otherpage' from 'en/page' gives 'en/otherpage'.
- link to 'otherpage' from 'de/page' gives 'de/otherpage'.
Is such a thing possible? This would save me so much pain! (I really think that the authors should not have to translate every single path from 'en/somepath' to 'de/somepath', 'es/somepath', etc... This is just a huge source of errors.)
I am actually using the following modules:
- Path (Core)
- Locale (Core)
- Content translation (Core)
- Internationalization (Multilanguage)
'Public' file transfer, and 'Path prefix with language fallback' Language negotiation.
Comments
#1
Sorry, but that falls outside of Pathologic's feature set at the moment. I might be willing to add it, but as I have zero experience working on multilingual Drupal sites, I wouldn't be the best person to do so at the moment.
#2
Hmm... It's a sad truth, but it's good to finally know, that this is simply not a possibility today. I hope you (or someone else) can add this important feature some day, and, please, keep up the good work.
Thank you, Garrett!
#3
#4
Looks like the same issue.
I've just update from Drupal 6.16 to 6.17 and a couple of other modules. The images broke in other languages than the default one. English is not the default one. The paths of the images are /sites/default/files/xxxxx in the source and was modified to http://example.org/es/sites/default/files/xxxxx which is not good to get the images.
I had to disable the module pathologic and the images came back.
#5
J0nathan, I think what you're mentioning is a different issue than what the OP is mentioning, but… yes, your problem is an acknowledged one; Pathologic is currently a huge fail on multi-lingual sites. Unfortunately, I'm not really familiar enough with multi-lingual sites to know how to fix this, and I'm hoping someone who is and has some programming chops may be able to help me. Might that be you?
#6
Can we make this a base for all language issues for Pathologic? I might be able to provide skills, I would like to see a list of all issues. Thx!
#7
Subscribing.
#8
Re #1: I don't think that i18n support falls out of the scope of any module.
I'm currently working on adding i18n support for this module since I it on a project I'm currently working on.
#9
wmostrey, #1 was posted more than two years ago, when I was young and dumb. You're right; i18n should have been included from the start, but I still feel that I don't know enough about the workings of i18n sites to do it properly, so I'm very grateful you've taken up the task yourself. If you'd like CVS access so you can easily submit your tweaks, just say the word.
#10
@wmostrey Any idea about a timeframe? I am happy to help
#11
Not sure if I understand the original issue, but:
(1) Maybe you can do it with MultiLink
(2) I'd be willing to help, having done a lot of work with multi-language issues. MultiLink integrates with various other input filters that deal with links and paths - I can't see at the moment how to add any support for Pathlogic, but would be willing to do so if it might help.
#12
Patch attached.
#13
Patch seems to work for me. Thanks.
#14
Works as advertised.
#15
Perfect, thank you!
Tested with site that has 2 languages, is using i18n. Can't think of that much more to test so setting this to RTBC.
#16
Okay, I finally got around to taking a look at this…
I'm not totally satisfied by checking for "src" to determine if we should do rewriting or not. Instead, I'm seeing if we're using a valid menu writer file path, and if so, then doing the rewriting in a manner similar to meba's patch. This is "expensive" because it has to hit the database for every path Pathologic considers, but since Pathologic is an input filter and input filter results are cached, I don't mind too much if int means finally making Pathologic multi-language friendly. If you folks could revert meba's patch (use the -R flag with the patch command to revert a patch) and try my patch and let me know if it's any better or worse, I'd appreciate it.
#17
EDIT: (oops, posted in wrong thread somehow)
#18
Be careful, because the caching is not sensitive to language changes in D6 (it is in D7). I am not sure if this is relevant in the case of PathLogic, but in general you will get problems when the output of a filter is dependent on current language and caching is allowed. I addressed this issue in Language Sections and MultiLink via a patch (included with those modules).
#19
@Garrett You say "If you folks could revert meba's patch (use the -R flag with the patch command to revert a patch) and try my patch" but I don't see a patch of yours in this issue?
The clean patch in #12 has been confirmed to work by four people so it's definitely worth considering.
#20
Dammit, I forgot the patch so long ago? Here it is.
#12 may work, but I don't like the approach - if we're linking to non-Drupal things (like attached files, etc), the language bit will be attached and screw things up. Instead, we make sure we're linking to something within Drupal before we add the language bit.
#21
Pathfilter managed to do it in someway.
take a look at their code - http://drupal.org/project/pathfilter
also please take a look at this issue: Duplicate language prefix
it states the problem of duplicate language prefixes when using i18n and pathlogic.
#22
I tested the patch in #20 which is already part of 6.x-3.x-dev, and it works exactly as expected. Since it's already part of the dev release I'm marking this as fixed.
#23
Yeah, I got tired of waiting for someone besides me to test it, so I just pushed it. :P I'll go ahead and make a new release soon.
#24
Automatically closed -- issue fixed for 2 weeks with no activity.
#25
I at first thought this patch was working, but later found that some images where still be prefixed with language prefixes.
After some debugging I found the problem was the
language_url_rewrite()function. At first I assumed because it was doing aif (!isset($options['language'])) {it could not be the problem but then I realized thatisset()sees null variables as variables that are not set.By changing the
$language = NULL;in the patch to$language = '';the problem went away. I also though of changing the current language object to have no prefix or domain would also work, but I don't know what is that most correct method.#26
NaX, do you think you could try today's release (version 3.4)? It contains a patch from another multilingual-related issue which may fix your problem as well.
#27
Updating the status: needs review from the 3.4 version.
(I'm not experiencing any issues with the previous version btw.)
#28
Thanks Garrett Albright.
I have tested the latest workaround and it seems to be working as desired.
I also looked into my suggestions and this what I came up with.
You be the judge of what would work best long term.
<?php
global $language;
// Build common url() options.
$url_options = array(
'query' => $qparts,
'fragment' => isset($parts['fragment']) ? $parts['fragment'] : NULL,
'absolute' => $absolute,
// Newer versions of PHP treat all objects as references,
// so we have to clone objects we might modify.
'language' => drupal_clone($language),
);
// Check if this is not a menu item. If yes, we want to try prevent translating the path.
// On multi-lingual sites, language_url_rewrite() will be called and may
// rewrite the link in ways we don't want: drupal.org/node/961618
if (!menu_get_item($parts['path'])) {
$url_options['language']->prefix = '';
}
return $matches[1] . '="' . url($parts['path'], $url_options) . '"';
?>
NOTES:
I decided not to modify the domain variable as I cant see any reason to, but I don't have a domain based language setup available to test.
The drupal_clone() is required because we don't want to permanently modify the $language var. This is something I learned about recently on this issue http://drupal.org/node/832954#comment-3521672.
#29
NaX: I like what I see in your code, because it makes it so we don't have to temporarily reset site-wide variables like we're doing now (and as rightly pointed out in #961618: Language prefix should not be added to the path to files, is pretty crappy), but I'm kind of confused by the rest of your message. Are you saying that you've tested that code and it works?
#30
@Garrett Albright
Can you point out what you are confused about? I have tested both solutions and they both seem to work. I am currently running my solution on a live 6 language website using language prefixes. My 2 notes are related to the domain part of the language object and the need to clone objects that we need to modify. Please note I did get a email this morning from my 6 language website client about another language problem. I have not looked into it yet but I don't think it is related to pathologic. I will let you know if it is.
#31
This maybe a different issue, but I'm using the latest version of pathologic (3.4, not dev) and also Domain Access. If I write a link as
<a href="node/1">Link</a>it works fine - i.e. on .com with default language as en, it rewrites it to foo and on .ch with default language as German, it rewrites it to en/foo. However, if the link is to<a href="foo">Link</a>(as unfortunately every link on every page currently is) then it doesn't rewrite it on the .ch site, which I hoped it would.#32
OK; sorry if I'm busting in on the wrong issue or misunderstanding either a) pathologic or b) the menu system but:
menu_get_item only works on internal paths, not aliases, so aliased links weren't getting the language variable set. To get it to work then for aliases, I had to add in:
<?phpif (menu_get_item($parts['path'])){
global $language;
} elseif (drupal_lookup_path('source',$parts['path'])) {
global $language;
} else {
$language = NULL;
$orig_lang_neg = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE);
if ($orig_lang_neg !== LANGUAGE_NEGOTIATION_NONE) {
global $conf;
$conf['language_negotiation'] = LANGUAGE_NEGOTIATION_NONE;
}
}
?>
I don't know PHP's internals well enough to know if
<?phpif (menu_get_item($parts['path'])||drupal_lookup_path('source',$parts['path']))
?>
would result in both drupal_lookup_path being run even if menu_get_item evaluated to true, hence the elseif.
The main issue seems to be that it's pretty intensive to run menu_get_items and drupal_lookup_path on every link and image and pdf on a page (especially as in my, edge, case I'm turning off caching for the input format). Is there a combined Drupal function that would work for both internal paths and aliases?
Alternatively, and I know this is never anybody's favoured solution, a simple regex would do fine in my case to test for the presence of a file extension.
#33
Unfortunately the current approach also does not respect the language of a menu item if this is set via the 18n menu module. So if you access an uncached node with a wrong language domain (e.g. node is in German, but it is accessed via the English language domain), the paths are evaluated using the global $language variable and not the language used for the menu item... which results in a wrong path. After that, the cached filter of the node will then output the wrong result for all languages you access the language dependent node in.
#34
Okay, I've finally got around to working on this again. (I wanted to get the D7 branch at least somewhat functional again before I returned to working on the D6 one.) I've committed a fix which implements the improvements suggested in #28. If you guys could fetch the next dev release and give it a try, I'd appreciate it.
This is one difficult problem, compounded by the fact that I don't really maintain any multi-lingual sites myself, and I appreciate the help from everyone.
#35
@Garrett Albright
I have been running my patch on a live and active site since posting #28 without any issues. I have had a look at your dev version and have tested it on this same site and it all seems to work correctly. So I am happy from my side.
#36
I updated the code from NaX to work with Drupal 7 (drupal_clone is gone here) and made a patch out of it. Hope this helps others to get the issue fixed fast.
#37
Thank you so much ddanier! This patch is working great for me -- I thought I was going to lose my mind!
I'm developing a site locally and periodically uploading it to a temporary url to show my clients, and the temporary URL is an IP address/my hosting username (000.000.000.00/~username/), which is completely different from my local path (and the eventual URL). My image links were working fine locally, but as soon as I'd upload to the remote, almost all of my links were broken. Before your patch, I tried dozens of different combinations between the image paths I set in my nodes (/sites/default... vs. sites/default... etc) and different settings for Pathologic's "also considered local" setting. So I was testing different settings on my local English, local Spanish, remote English and remote Spanish, and it seemed that if I could get one or two to work, then the others would break. That pesky "/es/" language prefix kept popping up where I didn't want it. But your patch worked like a champ! Thank you, thank you! Hopefully this patch will make it into the next release...
I'm using:
Drupal Core 7.8
Pathologic 7.x-1.3 (with "/" added to "Also considered local" setting)
Internationalization 7.x-1.0
Maybe this will help somebody else with an image path problem: I created a spreadsheet to keep track of every node image path and Pathologic setting combination I tried with a column for Local English, Local Spanish, Remote English, and Remote Spanish nodes. Then for each test, I marked each column as OK or broken (using different colored cells for OK and Broken) and indicated how the image path was output by the browser (using Firebug to examine the images). This saved me a lot of time, because I knew exactly what worked or didn't and I didn't repeat the same settings twice.
#38
ddainer, would it be too much to ask you to include some tests with the patch? Failing that, at least a concrete, step-by-step way to cause an error which this patch fixes? Pretend I'm a total n00b to multi-lingual sites (it's not far from the truth).
SDC, if you have an older version of that spreadsheet lying around where some of the paths were still red, I'd love to see it.
#39
Patch in #36 fix an issue I had with "insert" module. Here is a simple reroll, with manually corrected filepath directly in the patch.
Maybe it would be possible to merge it with another solution I had ( http://drupal.org/node/1156720#comment-4813106 )
#40
idflood, thanks, but do you think you could help me out with #38?
#41
Hey everyone!
I do not think, that the proposed patch entirely solves the issue. The problem is, that the language of the URL is determined once and for all on creation of the page. However, what I'd suggest should happen is that the language is determined when the pages is loaded.
This means that, whatever language was active when the site was created, if the user loads the node through an URL with prefix "en", the URLs in the node should be rewritten to have the prefix "en". If the user loads with "de", it should be rewritten to "de". If the user loads with empty prefix, it should be rewritten to have an empty prefix. As I see it, this is how other links in Drupal behave (menus etc).
I guess that it'd be difficult to implement this, as not all results of Pathologic could be cached. There would have to be another pass when the node is rendered.
Cheers,
Ingo
#42
Sorry, but I only updates the patch NaX provided to work with current D7. Not sure if the way NaX fixed this issue is the right way, but it worked for me. I'll try to reconstruct what exactly failed here.
#43
This left a very sticky issue where pathologic would cache untranslated, unaliased node paths. The issue is that pathologic can run VERY early in the bootstrap process since a node is loaded as part of menu_get_item. This happens even before hook_init. So if one was to visit a spanish node at node/123, when pathologic processed it would have no idea what language it should be dealing with, so no matching alias, so would just cache the unaliased, unprefixed node/123 as the href.
This wouldn't be a big deal except that when using prefixes for language, those links would be redirected to the node's primary language version instead of directly to the version linked in the content. This happens even if using something like global reredirect since this whole transaction happens before hook_init.
When the object in question is a node, this patch adds to the other patches by checking the language of the node linked to and substitutes the language for URL alias with that of the node. It does so with a (soft) dependency on i18n, which seems reasonable, but we could also do a direct query for the node's language as well if there's any concern about that.
It also uses _menu_find_router_path to check if the path being worked on is a menu item instead of menu_get_item, which will load referenced entities in addition to checking if the path exists. In a page with a lot of internal links this can lead to quite a lot of unneeded overhead.
Sorry no tests yet but I'll try to get to that soon.
#44
Are you sure Pathologic is involved in that? Pathologic should only be running when text is filtered, which shouldn't happen unless it's about to be viewed in a web page. If a node is merely loaded, Pathologic doesn't do anything. I can't imagine menu_get_item is really rendering nodes as opposed to just loading them…
Have you verified this by way of debug_backtrace() or some other way?
#45
Believe it or not, it does. node_load calls the entity controller load which calls the field attach functions, which will load and sanitize the text. It's doing so from cache usually so it's typically not expensive. But all this happens via menu_get_item which is called as part of the full drupal boostrap, before hook_init.
I've verified this by stepping through in eclipse to try to solve my phantom, unaliased, unprefixed links, which turned out to be caused by a googlebot visiting system URLs in certain instances rather than aliased and prefixed paths, which would trigger this issue.
#46
tested #36, worked and fixed my issue with image paths
tested #43 worked and fixed my issue with image paths
thanks for the patches!
It took some searching to find the problem was caused by Pathologic
Are tests needed for rtbc?
#47
Yes, I need a test before I will commit it. However, I can probably write it myself if I could just get instructions for setting-up a multi-lingual site in such a configuration as to reproduce the undesired behavior, written in such a way that someone who's effectively a n00b at multi-lingual sites such as myself can easily follow along. Whether written by myself or someone else, though, I definitely want a test for this to go into the repo.
#48
Patch on #36 tested on Drupal 7.10 with pathologic 7.x-1.4 and i18n 7.x-1.2. At the moment solved the problem with the local images.
Thanks!
#49
Okay, let's meet halfway here. I've tweaked a local version of my personal site so that it now can do content in English and Japanese. (And man, what a PITA that was… but even outside of this, I need to brush up on my multi-lingual skills anyway, so…) I have it configged so it does the path thing, so the English page is at
pathand the Japanese one is atja/path.I can't seem to get it to behave unexpectedly, though. If I edit the Japanese page and put in a link to
path, then clear caches and visit the English version of the page, then the Japanese one, the path on the Japanese page is still properly transforming tohttp://abweb.test/ja/path. So I'm not triggering the bug.What more do I need to do?
#50
@Garrett Albright
Also try something with image paths like with IMCE, and try editing a JA node in English IE: node/#/edit instead of js/node/#/edit.
I cant remember how I triggered this, it was a long while ago. If you don't figure it out I will have a look at it again in the new year when I get time.
#51
Hi Garrett .. thanks for looking at it. Have you applied any of these patches, or are you just using the current -dev?
One issue this fixes is doubly or otherwise incorrectly linked paths to files or other non-drupal object. So add a link to a file, run it through pathologic and that field should incorrectly have a language prefix.
The other issue that I tried to fix in the #43 patch can be reproduced by:
The patch checks the language of the actual node a link is pointing to and inserts the correct prefix for that node regardless of the currently active prefix.
Clear as mud? :)
#52
I haven't applied any of the patches because, one, I still want to see the problem happen for myself first, and two, I'm going to rewrite the module so that it does less work in the regular expression and more in code. This will theoretically make Pathologic slower, but since its output is cached in all but very unideal situations anyway, I'm not going to sweat it anymore. It will also mean working with edge cases like this and all the others should be simpler. I've opened up a 7.x-2.x branch if you want to see how that's going, though I don't recommend installing it on a live site just yet (one reason being that I haven't figured out how the upgrade path will work yet).
At any rate, thanks for your instructions. I'll try to work with them tonight.
#53
Added tag.
Marked #1156720: Multilingual links in D7 and #1335412: Domain / i18n unaware: missing alias as duplicates of this issue.
I'm using field translation with the Entity translation module instead of node translation. (Aside: I strongly recommend that everyone switch to this method instead of using node translation in D7. It creates fewer problems with other modules, and is the where the community is headed.)
As expected with the 7.x-1.x branch, the translated URL aliases don't maintain their distinct language links when language switching. However, with the new 7.x-2.x branch, these links work perfectly. (Each node can have translatable fields. So in a translatable body field with English and French translations, switching between languages for that same node produces the embedded links with their proper language-specific URL aliases and domains, but only in the 7.x-2.x branch.)
Thanks for re-jigging this!
#54
Fixing settings.
#55
Colan:
…Wow. I totally wasn't expecting anyone to actually use any code in that branch yet. Thank you.
Yeah, so it turns out that the language of a bit of text can actually be passed to a text filtering function, and my function can then turn around and pass that to the url() function. Why did I not know this before? I think it's because I built the first versions of the D7 version of Pathologic before this feature was available in the API, and never bothered to look at the relevant code since then. Yay, much less guesswork!
At any rate, I would appreciate it if everyone who wants to use Pathologic in a multi-lingual environment give the new 7.x-2.0-beta1 release a try. (And maybe try it if you don't have a multilingual site, too.) Configuration-wise, there's a minor difference; the "Also considered local" field is now labeled "All base paths for this site" (and may still change yet… I still have a hard time trying to figure out what to title this thing) and if you have any domain names in there, they should now be absolute, including http:// at the beginning.
Thanks in advance to all who can give this a try and let me know how it works for you. I know that I've said that I thought I had this problem figured out in the past, but this time I really think I'm on the right track… thank you all for your patience. And thanks again to you, Colan.
#56
I've updated pathologic from 7.x-1.3 to 7.x-2.x-dev and it fixed an issue on one website (the double language code). Thanks.
#57
Looks like this is fixed then.
#58
I'd like to keep this open until I've made a full release and updated the documentation. That probably won't happen this weekend… But thanks for checking it out, and I'd still like to hear from any others out there who have given the 7.x-2.0 branch code a try.
#59
Problem with language prefix in files path still present in Drupal 7.10 + Pathologic 7.x-2.0-dev (Jan. 15)
But found this:
If I edit the node when site set in default language, and replace the broken link in the body with the correct link (even if nothing seems wrong with the link displayed in the IMCE popup window - i just confirm the link to the image)
save the node
voila... the images are visible
now if I change the site language to some other language, the images are still present
the only problem is that I must do this operation for all the nodes
#60
update to comment #59
paths to pictures and files in the body are OK only when I edit and save the node while the site is set to the default language - but only when the default language USE NO "PATH PREFIX LANGUAGE CODE".
:-(
#61
I experience the same problems as reported by @palamina in #60.
I've tried with -dev, -2.0-beta1 and git repository version.
Is there any other requirement regarding third party modules or any special configuration settings?
#62
I'm not sure, but I think that the problem might be derived from url() not able to build url without language for image files, even when we set options['language'] to ''.
I don't know drupal api well but image modules (and pathologic itself) seem to be using file_create_url() instead. So I made the following patch (to current dev) that, instead of setting $settings['langcode'] = 'und'; when we detect a file, it just returns the url.
Works for me but please take this just as a suggestion.
#63
One question comes to my mind...
Why is pathologic dealing with language prefix code ?
Its primary (correct me if I'm wrong) intent is to correct everything that come before the drupal generated link...
what I did is to simply remove the language value in the url array (line 196 in the DEV version 15.1.2012.)
$url = url($parts['trimmed_path'],
array(
'query' => $parts['qparts'],
'fragment' => isset($parts['fragment']) ? $parts['fragment'] : NULL,
'absolute' => $settings['current_settings']['absolute'],
// remove the language prefix code
// 'language' => isset($langs[$settings['langcode']]) ? $langs[$settings['langcode']] : NULL,
'language' => '',
)
);
'language' => ''and I got a working (at first sight) page
patch from comment #62 is partially ok - it fails with links inserted via linkit module
PS I'm not a developer, all I'm trying to do is speak my thoughts out so maybe someone smarter will come out with a solution
#64
@palamida
I think that was looked into long ago, but I cant remember. I think stripping the language creates other problems. I commented about it in #25, but like I said I cant remember. Also most of this thread has been about D6. Maybe things are different in D7. I am not using D7 in product much yet and I have not done a multi language D7 site yet so I cant really comment. I suggest you test it your links in in more than one language and try editing a node in a different language than your current. EG: link to nodes of different languages.
When it comes to Linkit. I don't use it so I cant test, but maybe post the raw link code that gets inserted, maybe somebody will be able to help.
#65
I should probably mention that, in case you're not aware, just swapping in a new version of Pathologic will likely not cause links in your content to magically work. Since Pathologic does its thing right before content is cached, you'll need to clear your site cache so that Drupal will have to run your cotent through filters again and then Pathologic will have the chance to modify the content differently than it has in the past, if that makes sense. Since that cache is also changed when a node is changed and saved, that may explain the behavior you're seeing, palamida.
As for your suggestion in #63, this was more like how Pathologic worked before this 7.x-2.0 branch. The problem (among many) with this is that Drupal's URL building functions would use the "current" language to build the links. So if you had a node written in language A, but someone viewed it while language B was active in Drupal, all the links would try to link to the node using the language B prefix, and then cache that so it was broken for everyone. Since Drupal 7 now gives text filters a way to know what language a bit of text was written in when it goes to filter it, we use that to avoid the problem. Clearly there are still kinks to work out, but I think this is going to fix the big problem.
jmones, there would be problems if, for example, there were query parameters on that file path - like
<img src="image.jpeg?foo=bar" />. This is rare, but sometimes useful and I don't want to break it. And as I said above, I bet palamida's problems could be solved with a simple cache clear - but, of course, I've been wrong before.And because it needs to be said now and then… Thank you all for helping test and improve Pathologic. You are all wonderful and attractive people.
#66
#62 patch worked for me using pathologic-7.x-2.0-beta1
#67
#62 patch works for me. Thanks!
#68
cleared the cache...
tried both 2.0-beta1 and 2.0-dev...
created a new node with different links in body
the problem is still present - language code prefix added to all links in body
in beta1 version the node language prefix code is being added to links
in dev version the active system language prefix code is being added to links
i'll try with a fresh new installation of drupal 7 and pathologic
#69
D7.10, pathologic-7.x-2.0-beta1. #62 has fixed the issue with files, thanks. Can somebody please confirm that this is the final solution?
Still having issues with linkit 7.x-2.1 + pathologic, but I think this is being investigated as part of #1221606: Test 7.x-2.x with multi languages..
#70
I stumbled upon this bug again with the 7.x-2.x. Here is a patch that adds a test to highlight issues with language_prefix.
On a side note the pathologic tests were failing even on a clean install so I created an issue for that #1426928: Make all tests pass, couple of changes
#71
Here is two more patches.
- The first one add a little fix for the double prefix. But since the tests are already broken it doesn't works well on it's own. It is working only if this is combined with the patch proposed in #2 of #1426928: Make all tests pass, couple of changes
- The second patch is simply a combination of the first patch with the patch in #70 that adds the test.
edit: #3 of #1426928: Make all tests pass, couple of changes has a patch combining the seconds patch with the patch #2 of #1426928.
#72
@idflood - what about the patch at #63, are your patches compatible with that? Please see also my comments at 69. It looked to me that 7.x-2.0-beta1 with #63 had fixed the issue, although I have not tested it extensively and others seem to still have a problem. Thanks.
#73
I've done some different combination testing and found one another solution. Here is a summary of what happened:
without patch (only applied the one with the test in #70):
57 passes, 6 fails, 0 exceptions
result: "http://localhost/d7/fr//qux/abc/fr/a6RStY9w/oranges"
expect: "http://localhost/d7/fr/a6RStY9w/oranges"
with change proposed in #63:
57 passes, 6 fails, 2 exceptions
the two new exceptions are 'Trying to get property of non-object' in locale_language_url_rewrite_url():423
result: "http://localhost/d7//qux/abc/fr/msCu3c2y/oranges"
expect: "http://localhost/d7/fr/msCu3c2y/oranges"
with change proposed in #63 and patch #2 of #1426928: Make all tests pass, couple of changes:
63 passes, 0 fails, 2 exceptions
two same exceptions as before
the two new exceptions are 'Trying to get property of non-object'
result: "http://localhost/d7/fr/kdPIr8wp/oranges"
expect: "http://localhost/d7/fr/kdPIr8wp/oranges"
since there are just these two exception let's pass an object instead of '':
63 passes, 0 fails, 0 exceptions
result: "http://localhost/d7/fr/iH2qaQpH/oranges"
expect: "http://localhost/d7/fr/iH2qaQpH/oranges"
Here is a patch that include the test from #70 and the fix proposed above. It still require the patch #2 from #1426928: Make all tests pass, couple of changes to work completly.
#74
I did a clean installation BEFORE PATCHES FROM #70, #71 and finaly #73
Drupal 7.12
Pathologic 2.0-beta1 and 2.x-dev
the problem was still present
I applied the patch #4 (ONLY THAT ONE. am I wrong ?) from #1426928: Make all tests pass, couple of changes
and pictures are now ok
I must do some more testing with the linkit module
#75
Thanks for all the work, idflood and everyone. I'm sorry I haven't been able to take a look at it, but my work flow has been kind of heavy recently. I'll try to get this looked at this weekend.
#76
after applying the patch #4 from #1426928: Make all tests pass, couple of changes to 7.x-2.0-beta1-dev everything seems ok
Most of the tests I did on a clean installation... pictures and links are ok
I tried with additional modules:
Linkit 7.x-2.1
Internationalization 7.x-1.4
IMCE 7.x-1.5
Wysiwyg 7.x-2.1
Global Redirect 7.x-1.4
Redirect 7.x-1.0-beta4
Pathauto 7.x-1.0-rc2
...
and so far so good
#77
If there are multiple problems here, perhaps we should close this one, and open more specific issues?