Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
As soon as this module is enabled, it will start redirecting admin pages to their secured counterparts. What this means is that if you don't have your secure version set up to respond properly yet, immediately upon enabling the module, the module configuration page will be inaccessible.
I haven't worked with the module much yet, since it kills my access to /admin/*, but presuming there is some way to exclude those pages from the securing, they should be excluded by default to prevent this problem.
If you've gotten yourself into this situation, you may want to: UPDATE {system} SET status = 0 WHERE name = 'securepages';
Another option is to blank the second argument in the call to variable_get for the securepages_pages variable on line 211 of securepages.module. That way you can at least explore the module's settings without having the admin pages immediately secured (or broken, if your secure server isn't set up).
To whom it may concern, yes that worked. I just changed line 211 from:
$pages = variable_get('securepages_pages', "node/add*\nnode/*/edit\nuser/*\nadmin*");
to:
$pages = variable_get('securepages_pages', "node/add*\nnode/*/edit\nuser/*\n");
(I didn't have to blank the whole second argument - I'm no PHP expert, and I figured why change more than I have to).
Now I can explore and experiment with the module on my test site (which doesn't have a SSL server connection).
Comments
Comment #1
megg commentedme, too. using 5.x with clean urls enabled, if that helps...
Comment #2
HorsePunchKid commentedAs soon as this module is enabled, it will start redirecting admin pages to their secured counterparts. What this means is that if you don't have your secure version set up to respond properly yet, immediately upon enabling the module, the module configuration page will be inaccessible.
I haven't worked with the module much yet, since it kills my access to
/admin/*, but presuming there is some way to exclude those pages from the securing, they should be excluded by default to prevent this problem.If you've gotten yourself into this situation, you may want to:
UPDATE {system} SET status = 0 WHERE name = 'securepages';Comment #3
HorsePunchKid commentedAnother option is to blank the second argument in the call to
variable_getfor thesecurepages_pagesvariable on line 211 ofsecurepages.module. That way you can at least explore the module's settings without having the admin pages immediately secured (or broken, if your secure server isn't set up).Comment #4
amitaibuSubscribe (5.x-1.3)
Comment #5
Zephinilium@drupal.org commentedTo whom it may concern, yes that worked. I just changed line 211 from:
$pages = variable_get('securepages_pages', "node/add*\nnode/*/edit\nuser/*\nadmin*");
to:
$pages = variable_get('securepages_pages', "node/add*\nnode/*/edit\nuser/*\n");
(I didn't have to blank the whole second argument - I'm no PHP expert, and I figured why change more than I have to).
Now I can explore and experiment with the module on my test site (which doesn't have a SSL server connection).
Comment #6
gordon commentedFix in latest version. Now there is a test to check if SSL has been installed.
Comment #7
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.