I have a multi-language site where both the Secure Page and language prefix are enabled. All pages including "admin" and "user" are set to HTTPS in module of Secure Page. There are two language enabled: English (default) and Chinese traditional (zh-hant). On any page prefixed by zh-hant, if I click a link to a https page, the system warned "page not found". Taking a closer look, before I actually click, the link looks fine (http://www.site.com/zh-hant/admin/content/node, etc.), but after I click, the url of the "page not found" page became https://www.site.com/zh-hant/zh-hant/admin/content/node. The language prefix repeated in the url. If disable the secure page, everything come back to normal.
Any ideas please?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | securepages.module.language-prefix.patch | 451 bytes | mrfelton |
Comments
Comment #1
michaelcrm commentedany ideas please?
Comment #2
mike_foe commentedI came across the very same problem, even though in my case 6 languages are concerned.
After having a deeper look into the module, I saw that Gordon actually provided the solution.
If you go to line 350, you'll find the function securepages_url.
function securepages_url($path = NULL, $options = array()) {
// Merge in defaults.
$options += array(
'fragment' => '',
'query' => '',
'alias' => FALSE,
'prefix' => '',
'secure' => TRUE,
);
If you add the value 'language' => TRUE, the redirection also on multi-lingual sites work fine.
So the "patched" function looks like this:
function securepages_url($path = NULL, $options = array()) {
// Merge in defaults.
$options += array(
'fragment' => '',
'query' => '',
'alias' => FALSE,
'prefix' => '',
'secure' => TRUE,
'language' => TRUE,
);
Gordon, I would suggest to include this option to the default values, as else a lot of users might just uninstall this great module.
Hope that works for you as well!
Kind regards,
Mike
Comment #3
michaelcrm commentedFixed by Mike's note!!!!!!!!!!!!!
Mike I LOVE YOU!!!
I COMPLETELY agree with Mike that this should be included into defaults!!!!!
I had to disable the module of Secure Pages after coming across this problem, and I won't reactivate this module if not seeing Mike's note!!!
Comment #4
lifepillar commentedI confirm the reported bug and I confirm that the proposed solution works for me.
I would like to add that I also had to modify Secure Pages patterns, e.g. 'admin*' becomes '*admin*', 'node/add*' becomes '*node/add*', etc..., to have pages prefixed by a language secured (e.g., 'fr/admin/...' or 'it/node/add').
Comment #5
boaz_r commentedInterestingly, I stumbled on the same issue. My solution was to alter line 435 from:
$path = securepages_urlencode($prefix . $path);
to
$path = securepages_urlencode($path);
I think both are equivalent cause AFAIK nothing other than language prefix goes into $prefix so it can be omitted altogether (since the language prefix is always pre-embedded in the $path).
Further more, the function that messes with the $options array is language_url_rewrite() and passing language=true to it as one of the $options array is not more than a workaround used to fool it.
I wonder which method is better.
Comment #6
mrfelton commentedattached is a patch which makes the change in #5 - fixes the problem for me thanks.
Comment #7
gordon commentedThis is fixed. I removed the language rewrite as this was done in the real url().
Comment #8
gordon commented