I have SecurePages set to secure every page except for a list of exceptions. I am having a hard time making exceptions for regular pages. Here's an example:

I have a blog section. The /blog page is rendered by a Panel. It lists individual blog posts. Using the following settings, I would expect that /blog and all of the individual blog pages (under /blog/xxxx) would NOT be forced to a secure version:

blog
blog/*

The blog listing page works fine, but each individual blog post is using https (meaning the exception is not being caught).

I have also tried to exempt individual blog posts by adding their alias to the exception list, and that fails.

Looking at the code, it appears that $path_alias = drupal_get_path_alias($path); is never called in if ($page) check, so $path_alias is never populated.

I will supply a patch for this shortly.

CommentFileSizeAuthor
#3 securepages-pathauto_issues-2347127-1.patch592 bytesWinn
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JuliaKoelsch’s picture

Actually, it's just missing one character:

line 254 in securepages.module is

$path_alias = isset($path_alias) ? drupal_get_path_alias($path) : $path_alias;

and it should be

$path_alias = !isset($path_alias) ? drupal_get_path_alias($path) : $path_alias;

Winn’s picture

The fix proposed in #1 has allowed us to use our site in mixed mode (http & https).

Winn’s picture

Winn’s picture

Patch from #1

pjcdawkins’s picture

Status: Active » Needs review

The patch looks good to me. Setting to 'Needs review'

mcdruid’s picture

Title: Pathauto issues » Pathauto issues (url_alias paths don't match)
Status: Needs review » Reviewed & tested by the community

The simple patch in #3 (negating the ternary check) makes securepages work with paths which are a url_alias.

Marking as RTBC as I'm the 3rd person to confirm this fixes the bug.

jennypanighetti’s picture

Works for me as well. I really wish the dev of the module would be updated more recently than 2013.

DuneBL’s picture

#3 plays nicely for me!