ProcessWire .htaccess adding URL parameter to redirects

[FireWire]

We're launching a new version of our website and I need to create redirects from old pages to their new counterparts at different URLs. An example rule that I've created is

Redirect 301 /solar-energy-for-business /solar-energy/commercial-solar/ 

However when I visit the redirected URL it shows up in the address bar as:

https://staging.renovaenergy.com/solar-energy/commercial-solar/?it=solar-energy-for-business

We're creating these redirects for SEO purposes and they need to not have additional URL parameters being added. This line in the .htaccess file is adding the original URL as a parameter.

RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] 

Does ProcessWire use this parameter for a purpose? What is the best way to create these redirects without this parameter?

[kongondo]

28 minutes ago, FireWire said:

What is the best way to create these redirects without this parameter?

Have you tried the module Jumplinks?

 

[FireWire]

3 minutes ago, kongondo said:

Have you tried the module Jumplinks?

 

I did but it's a multi-language site and from what I understand that module doesn't support that unfortunately.

[kongondo]

20 minutes ago, FireWire said:

I did but it's a multi-language site and from what I understand that module doesn't support that unfortunately.

I see. No, it doesn't, although someone posted a workaround here, just FYI.

[FireWire]

1 minute ago, kongondo said:

I see. No, it doesn't, although someone posted a workaround here, just FYI.

Thanks for that link, I skimmed the pages but there are a few in that post haha.

I'm still curious about the it parameter though, any insight on why it exists or what ProcessWire does with it?

[kongondo]

Just now, FireWire said:

Thanks for that link, I skimmed the pages but there are a few in that post haha.

Just that and the next two posts :-). - workaround in the 2nd post.

1 minute ago, FireWire said:

any insight on why it exists or what ProcessWire does with it?

I am afraid not. 

Nice site, btw ?.

[FireWire]

2 hours ago, kongondo said:

Just that and the next two posts :-). - workaround in the 2nd post.

I am afraid not. 

Nice site, btw ?.

That solution worked like a charm!

Thank you for the compliment on the site. Looking forward to launching it on Friday!

[kongondo]

3 minutes ago, FireWire said:

That solution worked like a charm!

Brilliant! Glad it worked! 

[teppo]

8 hours ago, FireWire said:

We're creating these redirects for SEO purposes and they need to not have additional URL parameters being added. This line in the .htaccess file is adding the original URL as a parameter.

RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] 

Does ProcessWire use this parameter for a purpose? What is the best way to create these redirects without this parameter?

This "it" variable where ProcessWire internally gets the requested URL, see https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessPageView.module#L320.

If you're seeing these in your redirects, it probably means either that this Redirect is after ProcessWire's initial htaccess rules, or alternatively that Apache doesn't stop processing the htaccess file when it finds the Redirect row. I'm not completely sure if Apache should stop at Redirect or not, so you may have to use RewriteRule instead, specifying [R,L] as flags.

Edit: gave this a quick try and it seems that there's no obvious way to make Apache stop parsing further rules when Redirect occurs. Simply put RewriteRules should be used in this situation instead — or you can use a module / code approach, which of course comes with some overhead. Overall mixing mod_alias and mod_rewrite seems like a bad idea ?

[FireWire]

3 hours ago, teppo said:

This "it" variable where ProcessWire internally gets the requested URL, see https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessPageView.module#L320.

If you're seeing these in your redirects, it probably means either that this Redirect is after ProcessWire's initial htaccess rules, or alternatively that Apache doesn't stop processing the htaccess file when it finds the Redirect row. I'm not completely sure if Apache should stop at Redirect or not, so you may have to use RewriteRule instead, specifying [R,L] as flags.

Edit: gave this a quick try and it seems that there's no obvious way to make Apache stop parsing further rules when Redirect occurs. Simply put RewriteRules should be used in this situation instead — or you can use a module / code approach, which of course comes with some overhead. Overall mixing mod_alias and mod_rewrite seems like a bad idea ?

That's my conclusion as well. I didn't want to tinker with ProcessWire's internal workings so I left that redirect parameter alone. Also can confirm empirically that placing my redirect rules didn't stop Apache from parsing the document after the redirect, which while frustrating kind of makes sense given the gravity of important configurations contained in the file. And I agree about complexifying (new word) htaccess too much. Many thanks for the additional insights.

[FireWire]

Just want to spell out the solution to save any devs who see this post a little time and jump to the solution.

As mentioned Jumplinks does not yet support multilanguage URLs. Trying to redirect "naturally" using Jumplinks will have your multilanguage page redirect to the page in the default language. You will have to create a Jumplink redirect for every language on a page (sorry big site and big language devs). Here's a quick screenshot with some explanations:

Here's the gist- create your default language redirects as usual using Jumplinks as designed. For your URLs in other languages, add your source language URL as normal, but when entering the redirect destination, manually add the proper language URL and add the ? to the end of it. This "tricks" Jumplinks and creates a kind of sticky URL which Jumplinks won't replace with the default language URL.

Couple of pro-tips after working through this:

• On your source URL, I highly recommend adding the [/] to the end of your source URLs. This makes the redirect work with URLs that end in a trailing slash and those that don't. Regardless of your chosen configuration for URLs it is always a good idea to account for possible user edge cases.
• Keep SEO in mind! Ensure that your destination pages have a meta canonical URL tag. Google is very literal when parsing URLs and by adding the ? to your destination page you run the risk of fragmenting your content into 2 URLs. Without your canonical tag, Google may index them separately and it is possible that your pages will compete with each other in search results and possibly replace your nice URL with the URL you appended ?
• As always, test, test, test.

Just wanted to provide a shortcut to the solution in the Jumplinks thread. Happy redirecting!

[teppo]

30 minutes ago, FireWire said:

That's my conclusion as well. I didn't want to tinker with ProcessWire's internal workings so I left that redirect parameter alone. Also can confirm empirically that placing my redirect rules didn't stop Apache from parsing the document after the redirect, which while frustrating kind of makes sense given the gravity of important configurations contained in the file. And I agree about complexifying (new word) htaccess too much. Many thanks for the additional insights.

Just to be clear: in my opinion it's actually perfectly fine to perform redirects in Apache config files, site-specific vhost files, or even in the .htaccess file. It's just that they should use RewriteRule (mod_rewrite) instead of Redirect (mod_alias). If a new site requires redirects for old URLs, this is typically how I handle it — this way I have full control over wildcards and such, and there's very little overhead.

Nothing wrong with using Jumplinks (or ProcessRedirects), of course. That slight overhead they add (booting up ProcessWire, checking for redirects, etc.) rarely matters ?

[FireWire]

Okay- I did misread that a bit. I will admit that my .htaccess-fu is a bit lacking when it comes to more effective redirects and I'm in a timeline-bind. Should have gotten started on that sooner... Thanks again for this info. Surely will come in handy in the future!

[monollonom]

I'm going to have to do the same — migrate a website to Processwire and redirect to new pages’ url if need be — but I thought of using the Page Path History (core) module and its ability to add new redirect URLs per page.

Have you tried it ? Have anybody used it that way ?

[kongondo]

58 minutes ago, monollonom said:

but I thought of using the Page Path History (core) module and its ability to add new redirect URLs per page.

The posts I have seen were from a while back when this module didn't support multi-language sites. Good to see that it now does ?

[Violet]

I came up against this same issue recently, and I was able to find a solution at least for my case that did not require a module.

It turned out there are 2 things going on:

1. The way the redirect is set up in .htaccess

2. Browser caching

So what you would want to do is to put your redirects in section 8 of the PW .htaccess file.

Do not do this, it will give the ?it=

Redirect 301 /security.txt https://yourdomain.com/.well-known/security.txt

Instead do it like this:

RewriteRule ^security.txt/?$ $1/.well-known/security.txt [R=301,L]

 

At this point, test it out in another browser and/or on another device because you will run into issues with browser caching where it'll seem like it's still adding the ?it= but it's just from the cache. If you don't want to try another browser or device, then clear your cache on your current browser. The browser caching issue set me back for awhile until I thought to check it on another device!

 

At least, the above solution is what worked for me and for my use case. Besides using it for security.txt (where that page is not written in PW, I just created it manually and uploaded) I also use it when I'm redirecting a regular front-facing PW page to another, and it works there too. I just put all of those in section 8 of the .htaccess file and it works.

Edited March 22, 2021 by Violet
removed auto-link