Jump to content
mediamar

Problem with 301 Redirects

Recommended Posts

I moved an old site to processwire and want to redirect the old URLs with php-filenames to the new folders via .htaccess to match the new structure.

I tried:

RedirectMatch 301 /filename.php http://example.com/filename/

The Browser end up like this:
http://example.com/filename/?it=filename.php

Its interfering with that Processwire .htaccess rule

# ----------------------------------------------------------------------------------------------- 

  # Pass control to ProcessWire if all the above directives allow us to this point.
  # For regular VirtualHosts (most installs)
  # ----------------------------------------------------------------------------------------------- 
   RewriteRule ^(.*)$ index.php?it=$1 [L,QSA]
 
If i comment that out the redirect in the URL is ok, but every Klick on a websitelink is showing the homepage.
 
Any idea how i can fix this?
Thanks
 
Andreas

Share this post


Link to post
Share on other sites

Just redirect before the mentioned .htaccess rule. But I'd also suggest looking into ProcessRedirects or Jumplinks, which are GUI modules, where you can set up redirects.

Share this post


Link to post
Share on other sites

Thank you for the quick response. I already tried to apply the rule before, but same result. Is there one of the modules you can recommend?

Andreas

Share this post


Link to post
Share on other sites

Ok. I tried Jumplinks and it works like charm. Thanks again for the quickest support ever seen and http://modules.processwire.com/authors/mike-rockett/.

Have a nice day.

Hi Mediamar,

I'm sure you've already begun digging into the documentation, but you can use the following redirect to match all URIs using a php extension:

Source: {path}.php

Destination: {path}/

Glad you like the module. :)

  • Like 1

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 RDC
      Is the right way to get Processwire to skip a folder (ie not process it as its running a different CMS) to put
      RewriteCond %{REQUEST_URI} !^/shop/.*$
      just before 
      RewriteRule ^(.*)$ index.php?it=$1 [L,QSA]
      in .htaccess?
    • By Spiria
      I am writing here instead of the ProCache forum because I have the impression that several nginx experts could solve this. In its new version, Procache proposes new .htaccess rules that are difficult to translate into nginx rules. We currently have a problem with the trailing slash of URLs which gives us a bad score in SEO analysis tools such as semrush.com. 
      Indeed, a canonical URL is either without or with "/", but cannot be served by both options. Although ProcessWire without ProCache respects this rule, ProCache has no difficulty serving both, which is considered an SEO optimisation fault. I believe that ProCache version 2 solves this problem with these new rules, but I can't understand the following. Does anyone have any idea how to translate this into a nginx rule?
      Attached also the whole proposed .htaccess for ProcessWire.
      # PROCACHE v2/31885be14d6cfb4b2b0d3e533260bded -------------------------------------------------- RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} !.*=.* RewriteRule ^.*/$ - [E=pwpcstep:pour,E=pwpcname:index] RewriteCond %{ENV:pwpcstep} "=pour" RewriteCond %{HTTP_COOKIE} !^.*(wire_challenge|wires_challenge).*$ RewriteRule ^.*/$ - [E=pwpcstep:stir,E=pwpcpath:%{DOCUMENT_ROOT}/site/assets/ProCache-00478359c5e65dbada1075bfbd4] RewriteCond %{ENV:pwpcstep} "=stir" RewriteCond %{ENV:pwpcpath}/$0/%{ENV:pwpcname}.html -f RewriteRule ^.*$ - [E=pwpcstep:drink,E=pwpcfile:$0/%{ENV:pwpcname}.html] RewriteCond %{ENV:pwpcstep} "=drink" RewriteRule ^(.*) %{ENV:pwpcpath}/%{ENV:pwpcfile} [L] <ifModule mod_headers.c> Header set X-PWPC "ProCache" env=pwpcstep Header set X-Powered-By "ProcessWire CMS, ProCache" env=pwpcstep </ifModule> RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$" # /PROCACHE -------------------------------------------------------------------------------------  
      .htaccess-procache
    • By theoretic
      Hi guys and ladies! And thanks for Processwire!
      It appears i've got an interesting issue concerning the template-settings-based PW redirects dealing with access control. Any PW template has some access control options i.e. "Login redirect URL or page ID to render". If this option is used for a page having a template with this option filled, a redirect will occur if user is not logged in and/or has insufficient access rights.
      I like to hook PW events. In one of my current projects i decided to write an addHookBefore('Session::redirect', ...) which should store the page we are being redirected from. With "regular" redirects like $session->redirect('/somewhere/') this hook works like a charm. But it was strange to see that it doesn't work with the template-settings-based redirect.
      I'm too dumb to dive deep inside PW and to examine the whole PW session mechanism. But it could be rather logical if ANY redirect ( no matter template-settings-based or using $session->redirect() ) could be hooked in the same manner.
      Okay okay i can forget about template-settings-based redirect and write my own. Just a couple of lines of code, and it works. But it's less elegant than hooking the template-settings-based redirects.
      So am i missing something? It this behavior a bug, or is it intended by PW team? Thanks in advance for any comment!
    • By daniel_puehringer
      Hey,

      so we all know about SEO and the importance of performance. Basically we do it, because if no one finds the website we just built, it´s frustrating. We all try to write clean markup, css and js code and most might have a webpack/gulp/whatever pipeline to minimize css&js.
      But when thinking about it, optimizing your pipeline might save you a few (hundreds) of kb, compared to loading an image with 1 mb that´s literally nothing and frankly just ridiculous.

      Don´t get me wrong, frontend pipelines are great and should be used, but let´s shift your "I will optimize the shit out of that 3 css lines" focus to something different: try to serve images as fast as possible, this is where the performance boost really happens.

      I´m no pro on processwire so far, but I built a very easy to use picture element, which some of you could find interesting:

      1. the picture comes with 3 different sizes: one for mobile (keep in mind the double dpi, therefore width of 828px), one for tablet and one for desktop
      2. the picture generates a webp version and the original file extension as a fallback
      3. the filesize of each element is rendered within the "data" attribute
      4. lazy loading(sooo important!!!) is done via the native 'loading="lazy"' attribute.


      Please try it out and see the difference 🙂

      I posted this so others can easily optimize their images, but I would also like to hear your suggestions in making it better. Maybe you could decrease the rendering time or maybe you have some easy improvements.

      Please let me know.

      Greetings from Austria!


       
      <picture> <source data="<?php echo($oElement->repeater_image->width(828)->webp->filesize);?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(828)->filesize) ?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->width(767)->webp->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(767)->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->webp->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->webp->url) ?>" type="image/webp"> <source data="<?php echo($oElement->repeater_image->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->url) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> <img data="<?php echo($oElement->repeater_image->filesize) ?>" class="img-fluid" loading="lazy" src="<?php echo($oElement->repeater_image->url) ?>" alt="<?php echo($oElement->repeater_image->description) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> </picture>
    • By Peter Knight
      Can anyone tell me which .htaccess directive might be blocking a site import feature from scanning my public_html folder and listing all files and folders.
      These would be both PW files/folders but also some non PW folders which my PW site references for media.
      Latest .htaccess file on Github
      I can see various options from Section 15 onwards (# 15. Access Restrictions (v301)) but nothing that would block both SSH and FTP scans my VPS site import file uses.
      When I point the same site import tool at a non PW site on the same directory it works.
      I could disable htaccess temporarily but it's a busy and active site.
      Thanks
      P

       
       
×
×
  • Create New...