Jump to content
FireWire

ProcessWire .htaccess adding URL parameter to redirects

Recommended Posts

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?

Share this post


Link to post
Share on other sites
28 minutes ago, FireWire said:

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

Have you tried the module Jumplinks?

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 😊.

  • Like 1

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
3 minutes ago, FireWire said:

That solution worked like a charm!

Brilliant! Glad it worked! 

Share this post


Link to post
Share on other sites
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 🙂

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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:

sticky_jumplinks.thumb.png.b2bc1af6a0039393d167d806b4060b58.png

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!

  • Like 2

Share this post


Link to post
Share on other sites
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 🙂

  • Thanks 1

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

1018485926_Capturedecran2020-11-26a09_49_05.thumb.png.33eae4a1e0cd665961c89c3624898e7c.png

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

Share this post


Link to post
Share on other sites
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 🙂

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Violet
removed auto-link

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By doolak
      Hello everybody,
      on a multilanguage job website I am using the following code to show up a list of job offers. 
      The site structure is as follows:
      - stellenangebote/
      -- stellenangebote/stellenangebote_de/     
      --- jobs as child pages
      The jobs are located under /stellenangebote/stellenangebote_de/ as child pages and I want to show them up on /stellenangebote/ with the following template code:
      $stellenanzeigen = $pages->get("/stellenangebote/stellenangebote_de/"); foreach($stellenanzeigen->children('stellenanzeige_kategorie=1') as $child) { ?> <h3 class="uk-text-primary"><?php echo $child->title ?></h3> <?php } ?> This works fine for the default language (german) on /stellenangebote/ but its does not work on the french url version of this page /fr/offres-demplois/ . 
      I have no idea whats wrong - has anybody an idea?
      Cheers Christian
    • By Noel Boss
      » A more exhaustive version of this article is also available on Medium in English and German «
      First, we'd like to thank the very helpful community here for the excellent support.
      In many cases we found guidance or even finished solutions for our problems.
      So a big THANK YOU!!!
       
      We are pleased to introduce you to the new Ladies Lounge 18 website. The next ICF Women’s Conference will take place in Zurich and several satellite locations across Europe. We embarked on bold new directions for the development of the website — in line with the BRAVE theme.

      Ladies Lounge 18 — ICF Woman’s Conference website on Processwire ICF Church is a European Church Movement that started 20 years ago in Zurich and since experienced tremendous growth. There are already well over 60 ICF churches across Europe and Asia. ICF is a non-denominational church with a biblical foundation that was born out of the vision to build a dynamic, tangible church that is right at the heartbeat of time.
      With the growth of the Ladies Lounge from a single-site event to a multi-site event, the demands and challenges to the website have also increased. A simple HTML website no longer cuts it.
      Simplified frontend Our goal with the development of the new site was it to present the different locations — with different languages and partly different content — under once uniform umbrella — while at the same time minimising the administrative effort. In addition to the new bold look and feel, this year’s website is now simpler and easier and the information is accessible with fewer clicks. 
      Some highlights of the new website
      Thanks to processwire, all contents are maintained in one place only, even if they are displayed several times on the website 100% customised data model for content creators Content can be edited directly inline with a double-click:  

      Multi-language in the frontend and backend Dynamic Rights: Editors can edit their locations in all available languages and the other content only in their own language Easy login with Google account via OAuth2 Plugin Uikit Frontend with SCSS built using PW internal features (find of files…) Custom Frontend Setup with Layout, Components, Partials and Snippets Only about 3 weeks development time from 0 to 100 (never having published a PW before) Despite multi-location multi-language requirement, the site is easy to use for both visitors and editors:  
       
        The search for a good CMS is over It’s hard to find a system that combines flexibility and scope with simplicity, both in maintainance and development. The search for such a system is difficult. By and large, the open source world offers you the following options:
      In most cases, the more powerful a CMS, the more complex the maintenance and development
      It is usually like that; The functionality of a system also increases the training and operating effort — or the system is easy to use, but is powerless, and must be reporposed for high demands beyond its limits.
      Quite different Processwire : You do not have to learn a new native language, you don’t have to fight plugin hell and mess around with the loop, you don’t have to torment yourself with system-generated front-end code or even learn an entierly new, old PHP framework .
      All our basic requirements are met:
      Custom Content Types Flexible and extensible rights-management Multilanguage Intuitive backend Well curated Plugin Directory Actually working front-end editing Simple templating with 100% frontend freedom In addition, Processwire has an exceptionally friendly and helpful community. As a rule of thumb, questions are answered constructively in a few hours . The development progresses in brisk steps , the code is extremely easy to understand and simple. Processwire has a supremely powerful yet simple API , and for important things there are (not 1000) but certainly one module which at least serves as a good starting point for further development. Last but not least, the documentation is easy to understand, extensive and clever .
      Our experience shows, that you can find a quick and simple solution with Processwire, even for things like extending the rights-management — most of the time a highly complex task with other systems.
      This is also reflected positively in the user interface. The otherwise so “simple” Wordpress crumbles when coping with more complex tasks. It sumbles over its apparent simplicity and suddenly becomes complex:
       
      Old vs. New — Simple and yet complicated vs. easy and hmmm … easy
          Our experience with Processwire as first-timers
      Before we found out about Processwire, we found CraftCMS on our hunt for a better CMS. We were frustrated by the likes of Typo3, WP or Drupal like many here. CraftCMS looked very promising but as we were digging deeper into it, we found it did not met our requirements for some big projects in our pipeline that require many different locations, languages and features. Initially we were sceptical about Processwire because;
      A. CraftCMS Website (and before UiKit also the admin interface) simply locked much nicer and
      B. because it is built on top of a Framework
      It was only later, that we found out, that NOT depending on a Framework is actually a very good thing in Processwire's case. Things tend to get big and cumbersome rather then lean and clean. But now we are convinced, that Processwire is far superior to any of the other CMS right now available in most cases.
      The good
      Processwire is the first CMS since time immemorial that is really fun to use (almost) from start to finish— whether API, documentation, community, modules or backend interface. Every few hours you will be pleasantly surprised and a sense of achievement is never far away. The learning curve is very flat and you’ll find your way quickly arround the system. Even modules can be created quickly without much experience.
      Processwire is not over-engineered and uses no-frills PHP code — and that’s where the power steams from: simplicity = easy to understand = less code = save = easy maintanance = faster development …
      Even complex modules in Processwire usually only consist of a few hundred lines of code — often much less. And if “hooks” cause wordpress-damaged developers a cold shiver, Hooks in Processwire are a powerful tool to expand the core. The main developer Ryan is a child prodigy — active, eloquent and helpful.
      Processwire modules are stable even across major releases as the code base is so clean, simple and small.
      There is a GraphQL Plugin — anyone said Headless-CMS?!
      Image and file handling is a pleasure:
      echo "<img src='{$speaker->image->size(400, 600)->url}' alt='{$speaker->fullname}' />"; I could go on all day …
      The not soooo good
      Separation of Stucture and Data
      The definition of the fields and templates is stored in the database, so the separation between content and system is not guaranteed. This complicates clean development with separate live- and development-environments. However, there is a migration module that looks promising — another module, which is expected to write these configurations into the file system, unfortunately nuked our system. I'm sure there will be (and maybe we will invest) some clever solutions for this in the future. Some inspiration could also be drawn here, one of the greatest Plugins for WP: https://deliciousbrains.com/wp-migrate-db-pro/
      Access rights
      The Access-Rights where missing some critical features: Editors needed to be able to edit pages in all languages on their own location, and content on the rest of the page only in their respective language. We solved it by a custom field adding a relation between a page the user and a role that we dynamically add to the user to escalate access rights;
      /** * Initialize the module. * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. */ public function init() { $this->addHookBefore('ProcessPageEdit::execute', $this, 'addDynPermission'); $this->addHookBefore('ProcessPageAdd::execute', $this, 'addDynPermission'); } public function addDynPermission(HookEvent $event) { $message = false; $page = $event->object->getPage(); $root = $page->rootParent; $user = $this->user; if ($user->template->hasField('dynroles')) { if ($message) { $this->message('User has Dynroles: '.$user->dynroles->each('{name} ')); } // for page add hook… if ($page instanceof NullPage) { // click new and it's get, save it's post… $rootid = wire('input')->get->int('parent_id') ? wire('input')->get->int('parent_id') : wire('input')->post->parent_id; if ($message) { $this->message('Searching Root '.$rootid); } $root = wire('pages')->get($rootid)->rootParent; } elseif ($page->template->hasField('dynroles')) { if ($message) { $this->message('Page "'.$page->name.'" has Dynroles: '.$page->dynroles->each('{name} ')); } foreach ($page->get('dynroles') as $role) { if ($role->id && $user->dynroles->has($role)) { if ($message) { $this->message('Add dynamic role "'.$role->name.'" because of page "'.$page->name.'"'); } $user->addRole($role); } } } if (!($root instanceof NullPage) && $root->template->hasField('dynroles')) { if ($message) { $this->message('Root "'.$root->name.'" has dynamic roles: '.$root->dynroles->each('{name} ')); } foreach ($root->get('dynroles') as $role) { if ($role->id && $user->dynroles->has($role)) { if ($message) { $this->message('Add dynamic role "'.$role->name.'" because of root page "'.$root->name.'"'); } $user->addRole($role); } } } } } With the Droles and Access Groups Modules we were not able to find a solution.
      I thought it was hard to get absolute URLs out of the system — Ha! What a fool I was. So much for the topic of positive surprise. (Maybe you noticed, the point actually belongs to the top.)
      But while we’re at it — that I thought it would not work, was due to a somewhat incomplete documentation in a few instances. Although it is far better than many others, it still lacks useful hints at one point or another. As in the example above, however, the friendly community quickly helps here.
      processwire.com looks a bit old-fashioned and could use some marketing love. You notice the high level to moan with Processwire.
      There is no free Tesla here.
      Conclusion
      Processwire is for anyone who is upset about any Typo3, Wordpress and Drupal lunacy — a fresh breeze of air, clear water, a pure joy.
      It’s great as a CMF and Headless CMS, and we keep asking ourselves — why is it not more widely known?
      If you value simple but clean code, flexibility, stability, speed, fast development times and maximum freedom, you should definitely take a look at it.
      You have to like — or at least not hate PHP — and come to terms with the fact that the system is not over-engineerd to excess. If that’s okay with you, everything is possible — with GraphQL you can even build a completely decoupled frontend.
      We are convinced of the simplicity of Processwire and will implement future sites from now on using it as a foundation.
      Links & resources we found helpful
      API documentation and selectors API cheatsheet pretty handy, not quite complete for version 3.0 Captain Hook Overview of Hooks Weekly.PW newsletter a week, exciting Wireshell command line interface for Processwire Nice article about Processwire Plugins & Techniques that we used
      Custom Frontend Setup with Uikit 3 and SCSS, and Markup Regions Uikit Backend Theme ( github ) Oauth2 login modules In-house development Login with E-Mail Pro Fields for repeater matrix fields (infos, price tables, daily routines) Wire upgrade to update plugins and the core Wire Mail Mandrill to send mails FunctionalFields for translatable front-end texts that are not part of a content type (headings, button labels, etc.) Runtime markup for dynamic backend fields (combination of first and last name) Tracy debugger for fast debugging Textformatter OEmbed to convert Vimeo and Youtube links into embed codes HideUneditablePages thanks to @adrian  
       
    • By Jennifer Stock
      Hi. I'm wondering if there is a way to add code to the Redirects module to strip the "?fbclid=" parameter from incoming links. My users have noticed that the redirect links they have established via the module are failing when used from Facebook, due to the new FB click tracking code.
    • By sins7ven
      Hi community, I am wondering if its possible to display languages based on what host/domain has been requested.
      The use case is the following: I have one installation of PW - and within this installation I set up 5 different languages (default, english, spanish, french, dutch). Now I have 3 different domains (domainA.com, domainB.com, domainC.com) and I want to decide which languages to make available based on what domain has been navigated to. 
      For example:
      domainA.com
       - default (domainA.com)
       - english (domainA.com/en)
      domainB.com
        - default (domainB.com)
        - french (domainB.com/fr)
        - dutch (domainB.com/nl)
      domainC.com
        - default (domainC.com)
        - dutch (domainC.com/nl)
      So what I want to achieve is making only these particular languages selectable in the language switcher on the frontend. Since all pages share the same templates and overall site structure I don't see the benefits of running this installation as a multisite setup or would it be better to do so? But I assume that this would be difficult to handle since the default language might change as well. (On the french version of the page, french should be the default language and so on). Any suggestions how to accomplish that? Thanks!
    • By Slideth
      Hi! I am new to processwire and really like working with it so far.
      For a relaunch project, some editors of our website need the permission to add redirect URLs while migrating the content. I already created a role "site-manager" so only a few team members have access to certain features.
      There is also the option to add redirect URLs in the page settings, but it seems to be restricted only to superusers. Does anyone know of a way to grant permission for this option to another user role?
      Since this is the first PW-Project I did not dive in too deep with the permissions yet. I also tried to add a "page-edit-redirect"-permission, but I am somehow stuck on what to do with it.
      Thanks
×
×
  • Create New...