Problem
"Redirect from http > https > non-www is now 2 steps, should be one (https://prnt.sc/qbyzyf)
Check if this can be fixed in the default htaccess for rocketship.

Internally someone answered:
Right now the htaccess has 3 blocks, one for each redirect, to www, to non-www and to https:

  # Set "protossl" to "s" if we were accessed via https://.  This is used later
  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{ENV:HTTPS} on
  RewriteRule ^ - [E=protossl:s]

  # Uncomment the next two lines to redirect to HTTPS.
  # RewriteCond %{ENV:HTTPS} !on
  # RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # uncomment the following:
  # RewriteCond %{HTTP_HOST} .
  # RewriteCond %{HTTP_HOST} !^www\. [NC]
  # RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment the following:
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

What you are suggesting to reduce the redirect count would require expanding the template with each possible combination of the redirects to www, nonwww and HTTP / HTTPS. It would add additional complexity to the template and therefor to the golive, I'm not opposed to this but would ask you to first discuss this in the architect guild if the change is worth it.

Taking a closer look it would just appear that the following snippet is redundant and enabling that would cause the additional redirect. Ill see what I can do to change the process both in the documentation and the template.

# Uncomment the next two lines to redirect to HTTPS.
# RewriteCond %{ENV:HTTPS} !on
# RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

My take on this was
In the opinion of Nick Veenhof this is a nonissue if you correctly configure the sitemap, the times where you have the worst-case scenario with an additional redirect is trivial. We did, however, make a ticket in the backlog to update our htaccess_live system so that it keeps up to date #100443
And if I remember correctly, this is more of an issue with bigger sites, causing slower crawl times by google.
This is however a very small issue so I agree it shouldn't be picked up urgently and is more a nice to have.

Our SEO expert answered
this is indeed not a critical issue, but I would call it a should have rather than a nice to have.

Fewer redirects means quicker page loads (for the user and for Google) and quicker indexation of new website content. So this update only has advantages. The sitemap does indeed list all (hopefully) correct (in theory) website URLs, but we've seen time and time again in the past that the sitemap was messed up in some way or another. It's also possible content editors enter a "wrong" URL, or a website switches from "www-preferred" to "non-www" preferred, etc etc. All cases which can cause redirect-chains. The more we minimise the possibility of redirect chains, the better, so if this is not an impossible ticket I'd advise adding it to the queue. I see no reason not to do it really :)

Questions
Please provide a patch to include with https://git.drupalcode.org/project/dropsolid_rocketship/-/blob/8.9.x/etc...

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Nick_vh created an issue. See original summary.

nick_vh’s picture

Issue summary: View changes

L_VanDamme made their first commit to this issue’s fork.

grayle’s picture

Status: Active » Fixed

Fixed in alpha29

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

anybody’s picture

Hi @Grayle & @Nick_vh, just came here and wondered why this shouldn't better be fixed in Drupal Core, where a lot more people could benefit from. Sadly the commit fix doesn't seem to be linked correctly here.

Could you tell the reasons why this wasn't proposed against Drupal Core? Shouldn't we do this then as follow-up?

Thanks :)

anybody’s picture

anybody’s picture

And here's the core issue that could benefit from your work and experience on this :)

anybody’s picture

BTW the change to the ExipresDefault value in core is discussed here:
#3311406: .htaccess ExpiresDefault (2W) is much too low. Should be ~1Y

Would be nice, if you could review it, as you're using it for over a year now :)

anybody’s picture