Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi!
The download on the project page has the 7.x-1.0-beta2 from 2013-Nov-06 in green as the recommended version. Drush also agrees:
drush dl --select securepages
Choose one of the available releases for securepages:
[0] : Cancel
[1] : 7.x-1.0-beta2 - 2013-Nov-06 - Security, Supported, Recommended
[2] : 7.x-1.x-dev - 2013-Oct-12 - Development
However, there is this big yellow warning "D7 Status" block on the project page:
D7 status
The 7.x-dev release should be working for most uses. There are a few core bugs that are holding up a full release:
Steps to install Secure Pages 7.x-dev
- Set $conf['https'] = TRUE; in settings.php.
- Apply these two patches:
- #961508-71: Dual http/https session cookies interfere with drupal_valid_token()
- #471970-13: DrupalWebTestCase->getAbsoluteUrl should use internal browser's base URL
Despite these issues still exist in Drupal 7, and are unlikely to be resolved, we are now working towards a stable release of Secure Pages.
From this it almost looks like the project is suggesting to use the 7.x-dev with patches.
I am just looking for some clarity on what is the best version to install on a production system. Is it the 7.x-1.0-beta2 or the dev version with patches?
Thanks for your help in advance!
Frederick
Comments
Comment #2
bisonbleu CreditAttribution: bisonbleu commentedSame question.
Project page info appears to be outdated and contradictory on certain aspects i.e. the dev version dates before the current release.
Can someone clarify/explain?
Comment #3
Tabestan CreditAttribution: Tabestan commentedGlad I checked the issue queue for the same thing. :)
Is there an update on this?
Comment #4
frederickjhI see in an issue related to a Drupal 8 version that one of the main developers had an accident in 2014. https://www.drupal.org/node/2196315#comment-8487709
The developer may be still having medical issues.
Last commit to this project was in 2013
Comment #5
bisonbleu CreditAttribution: bisonbleu commentedRef.: #961508-294: Dual http/https session cookies interfere with drupal_valid_token()
I've been thinking about this for a while now and believe that in 2017, with the Let's Encrypt of this new world, mixed mode http/https session no longer makes sense. HTTPS 24/7 i.e. on every page and at all times, is the way to go.
Comment #6
Tabestan CreditAttribution: Tabestan commentedI agree but I'm in a difficult situation here, we pull videos and images from a non-secure site.
Comment #7
frederickjhIt is possible to redirect sections of the site to https without this module. It may take careful planning of the site's paths. You can use redirects in a .htaccess file. I have used this module on Drupal 6 site for its easy of use. I have never tried setting up redirects for only portions of a site. I normally do all or nothing.
In the Drupal 8 issue there was a group that was working on porting the Drupal 8 version but that does not help much with the Drupal 7 version. Maybe someone should reach out to the other maintainer, grendzy that is on the security team. Maybe he knows what is up with gordon and the project in general.
How to force HTTPS using the .htaccess file
http://www.inmotionhosting.com/support/website/ssl/how-to-force-https-us...
To force all web traffic to use HTTPS insert the following lines of code in the .htaccess file in your website’s root folder.
Important:If you have existing code in your .htaccess, add this above where there are already rules with a similar starting prefix.
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
Be sure to replace www.example.com with your actual domain name.
To force a specific domain to use HTTPS, use the following lines of code in the .htaccess file in your website's root folder:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R,L]
Make sure to replace example\.com with the domain name you're trying force to https. Additionally, you need to replace www.example.com with your actual domain name.
If you want to force SSL on a specific folder you can insert the code below into a .htaccess file placed in that specific folder:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} folder
RewriteRule ^(.*)$ https://www.example.com/folder/$1 [R,L]
Make sure you change the folder reference to the actual folder name. Then be sure to replace www.example.com/folder with your actual domain name and folder you want to force the SSL on.
Comment #8
bisonbleu CreditAttribution: bisonbleu commentedI just downloaded both versions 7.x-1.0-beta2 and 7.x-1.0-beta2+0-dev and searched for differences.
Guess what? I could not find any except for version name and timestamp in the .info. Can someone confirm this?
Now, about the 2 patches that are recommended on the project page:
Conclusion: use 7.x-1.0-beta2 and apply both patches and you should be good to go.
Hope this helps :-)
Comment #9
Tabestan CreditAttribution: Tabestan commentedI can confirm it works. I contacted Acquia a few days ago and they told me this module is the way to go for mixed-mode.
Thanks everyone.
Comment #10
DamienMcKennaJust to explain it, dev release version numbers follow this format: [previousrelease]+[numberofcommits]-dev. For example, I'm using Backup Migrate v7.x-3.1+6-dev. This means that it is "7.x-3.1" plus six more commits. For Secure Pages, "7.x-1.0-beta2+0-dev" means "7.x-1.0-beta2" plus.. zero extra commits, i.e. it is identical to "7.x-1.0-beta2".