🇸🇪Sweden @enzipher

I have kept this issue open to provide insight to those who might be interested, but there isn't really much to do in terms of fixes which is why I now close this one as "won't fix".

For a "no-code" solution the current recommendation is:

• Enable and use the Private file system → for all files. Note that this does require updating the settings.php file.
• Install and enable the RobotsTxt → module to handle the robots.txt file.

Thanks,

Thanks?

Overall functionality needs to be tested in Drupal 11.

Hi, thanks for the report.

That is an interesting edge case. I suppose some kind of top-domain exclusion could be added, but I'm not convinced the featured would have enough usage to validate the implementation.

I will think about this some more. What you can do in the meantime is to programmatically disable redirects for the .onion top domain. Programmatically setting any of the following module settings would allow for http traffic.

* Set 'enabled' to false - disables all redirects
* Set 'bypass httpswww redirect' permission to true - disables all redirects
* Set 'scheme' to mixed - disables https redirect

This is untested example code, but something like this in settings.php should work:

if (str_ends_with($_SERVER['HTTP_HOST'], '.onion')) {
  $config['httpswww.settings']['enabled'] = FALSE;
}

Cheers,

Hey, great job on the translations. Much appreciated!

Thanks for using the module, I'm glad it's useful to you! :)

Cheers,

I fixed the typo and updated a couple of other descriptions. See commit for details.

Thanks for the report!

Hey, and thanks for translating!

Yes, that is correct. The "Bypass" permission completely disables the redirects for users with the permission enabled. The idea behind it was that if you make a config mistake and can't access the site, it either doesn't affect you (if the permission is enabled) or you can more easily fix the issue by adding an override in the settings.php file.

Thanks for spotting the typo. I will fix that asap. Just know that if you translate the string, it needs to be translated again once the typo has been fixed (as it would be a different string). Additionally, the "preferred" wording is a bit odd. I may change that to "configured" instead.

Thanks,

You were correct about this. It's now been fixed and a new release should be available shortly.

Thanks for bringing this to my attention!

Thanks for the report! I'll be looking into this and let you know what I find.

Hey. So I've been doing a bit of maintenance and incorporated the updated texts. It's all available in the 2.1.0 release.

Now for translations, the correct way of doing it is to go through https://localize.drupal.org. I have not done this myself, so I'm not exactly sure what the exact procedure is, but I would suggest going to that site and read up on the docs. I know it involves signing up for the language specific translation team though, in your case that would be https://localize.drupal.org/translate/languages/fr.

The release to translate strings for would be version 2.1.0.
https://localize.drupal.org/translate/languages/fr/translate?project=htt...

I will mark this ticket as fixed as there's nothing more to do here. I'm not sure if I can be of any more help for the translations, but feel free to contact me if there's anything you believe I can assist with, or if appropriate, open a new ticket.

Thanks for your help!

Great, thanks!

I'll implement this along with the French translation. Also thanks for catching the typo.

I did some updates on my local. Feel free to review the attached image and let me know if it makes sense to you.

I had a quick look at the case issue, and the getHost() method is always returning a lowercase string (as per RFC 952/2181), so there will never be a case comparison issue.

Is there any particular reason why you cannot enable "Redirect to HTTPS" without also enabling URL prefix redirect?

My initial thought was that you simple shouldn't use both, but I do agree that it should be up to the user to make that decision as there might be edge cases where it's needed.

Apart from the text changes there are some changes to logic as well, which needs to be done with care to ensure backwards compatibility.

Otherwise your assumptions are correct regarding redirects. With the addition that forum.mydomain.com would actually get the www prefix if enabled. I've added a separate issue for that bug ( 🐛 The www prefix is added to sub-domains Fixed ).

Thanks,

enzipher → created an issue.