Announcement

Collapse
No announcement yet.

Troubleshooting Apache rewrites

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • [Resolved] Troubleshooting Apache rewrites

    Me again.

    Our old forum was 4.2.3pl2. The new one is 5.5.5. (I will get up to 5.6.0 eventually). Until the upgrade last weekend, we had ugly URLs. Now we use friendly URLs. I'm seeing error 404s in the Apache log that correspond to Google searches looking for old posts. I want them to redirect correctly. Here's some excerpts from apache logs and the URLs they should correspond to.

    What I see in Apache Error Log What that corresponds to Where it really is on my site
    /forum/entry.php?299-Larger-tires-on-a-scooter https://www.carecure.net/forum/entry.php?299-Larger-tires-on-a-scooter https://www.carecure.net/blogs/webfoot/2669798-larger-tires-on-a-scooter
    /forum/showthread.php?115772-Regeneration-of-stem-cells-CBS-news&p=1010175 https://www.carecure.net/forum/showthread.php?115772-Regeneration-of-stem-cells-CBS-news&p=1010175 https://www.carecure.net/forum/sci-community-forums/cure/118414-regeneration-of-stem-cells-cbs-news
    /forum/member.php?9835-wheelie357 https://www.carecure.net/forum/member.php?9835-wheelie357 https://www.carecure.net/member/9835-wheelie357
    As I said before, we're on FreeBSD 12.1-RELEASEp2, PHP 7.3.16, MariaDB 10.4.12, VBulletin 5.5.5, Apache 2.4.41.

    I have mod_rewrite enabled and I have the htaccess rules as follows in my root directory:
    Code:
    <IfModule mod_rewrite.c>
    RewriteEngine On
    # RewriteBase /forum/
    RewriteRule ^css.php$ core/css.php [NC,L]
    RewriteRule ^install/ core/install/ [NC,L]
    RewriteRule ^forum/attachment.php core/attachment.php [NC,L]
    RewriteCond %{REQUEST_URI} !\.(gif|jpg|jpeg|png|css)$
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ index.php?routestring=$1 [L,QSA]
    RewriteRule ^(admincp/)$ index.php?routestring=$1 [L,QSA]
    </IfModule>
    Now you might ask why I don't have the RewriteBase set. When I do, I get infinite redirects and the site is unusable. Here's what I have in (what I think are) the relevant config options:
    vBulletin URL https://www.carecure.net
    Login URL https://www.carecure.net
    Core URL https://www.carecure.net/core
    Always use Forum URL as Base Path Yes
    Is there a way to make the old URLs work? What am I doing wrong?

    Thanks,
    Grumpy
    Last edited by OldGrumpyDad; Fri 18 Sep '20, 5:08am.

  • #2
    Related to this, I'm seeing quite a few of these in the Apache Error Log. As far as I can tell, this is related to the routestring that is part of the redirect. But it's not working correctly.
    Code:
    [Wed Apr 01 08:35:05.093119 2020] [php7:notice] [pid 76807] [client 114.119.161.167:29078] PHP Notice: Undefined index: routestring in /data/web/apache24/data/includes/api/interfaceabstract.php on line 135
    The path /data/web/apache24/data is the root of the web server and root of vbulletin.

    Comment


    • #3
      You should use the default .htaccess that ships with vBulletin 5. It will actually allow vBulletin to properly perform 301 redirects to your content based on their old URL.

      The file ships as htaccess.txt and should be renamed .htaccess. If you have vBulletin in a subdirectory, you should set the RewriteBase path at the top of the file.
      Translations provided by Google.

      Wayne Luke
      The Rabid Badger - a vBulletin Cloud demonstration site.
      vBulletin 5 API

      Comment


      • #4
        I get it. That's what I did. When I made this post I omitted all the lines about mod_deflate and mod_expires. I DID use the htaccess.txt that shipped with vbulletin. Those rules that I copy/pasted into this post were exactly what's in the standard file (minus the comments). However, as I pointed out, when I enable the RewriteBase /forum/ line, the server does an infinite series of redirects. I'm sure I've got something goofed up, but it's not the htaccess.txt that I've goofed up. Any other ideas? Any ideas for things I might turn on to get more debugging output and greater logging about what's going on in Apache and/or PHP?

        Comment


        • #5
          Looking at your site, I see that it is stored in the "webroot" directory. Most likely a directory named /public_html/. If this is the case then the rewritebase directive should remain commented out or left at /.

          The /forum/ URL on your site is a virtual URL built by vBulletin and refers to the forum channel (AdminCP -> Channel Management -> Channel Manager). It doesn't actually exist on the server. Your individual forums are children of this default channel. Blogs are under /blog/ and children of the Blog channel. Etc... vBulletin 5 takes these virtual URLs and then determines what page to build and present to the user using a Routing API.

          It seems your older version of vBulletin was stored in a /forum/ directory which is why that is in the URL and why your 301s aren't working.

          I think you need a line like: RewriteRule ^forum/.* entry.php [QSA]

          This should allow the entry to be processed properly by the Routing API.
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud demonstration site.
          vBulletin 5 API

          Comment


          • #6
            You're right on all counts. VB4 was in a folder called /forum before, but during the 5.5.5 upgrade we moved it to a (newly blank) root directory. I'm a little uncertain about the rewrite rule, though. The entry.php file that I can find (./core/vb5/route/legacy/entry.php) is not in the root directory (where the RewriteRule is). Is that going to work right? When I tried it i got error 404 on the legacy URLs, same as I was getting before. I can't tell if it's being invoked and failing, or if perhaps the 404 is because entry.php is not in the root directory. I'm happy to turn on some extra debugging or logs or whatever. Any more ideas?

            On a lark, I tried this:

            Code:
            RewriteRule ^forum/.* core/vb5/route/legacy/entry.php [QSA]
            That doesn't work. So I'm not sure what the syntax is to route the request through to the right handler.

            A small aside on .htaccess files. That last attempt resulted in an error 500 because the default .htaccess file in the legacy directory still uses Apache 2.2 syntax to deny access. (The apache 2.4 syntax is present, but commented out). When I changed it to the right syntax, I still got 403 forbidden because the .htaccess syntax is now correct.

            The aside is that it's time to change the default syntax. Instead of denying access with a 403 error, they throw an error 500. Same net effect, but it's probably time to make Apache 2.4 syntax the default. It's been out for a really long time:
            • ./core/includes/.htaccess
            • ./core/libraries/.htaccess
            • ./core/vb/.htaccess
            • ./core/vb5/.htaccess
            • ./includes/.htaccess
            Thanks for your help
            Last edited by OldGrumpyDad; Wed 1 Apr '20, 1:37pm. Reason: forgot to point out that I did fix the .htaccess syntax error and it didn't make a difference.

            Comment


            • #7
              Because /core/vb5/route/legacy/entry.php is not an entry point to the application. The online entry point is index.php.

              Everything has to be routed to index.php or the system will not work.

              Apache 2.4 is the minimum required version supported. The files you list as having problems are not valid files that ship with vBulletin 5.6.0.
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API

              Comment


              • #8
                Thanks. But the RewriteRule you provided doesn't work. All the legacy pages come up as 404s still. Any suggestions how I can get some more detail about what's going wrong? How can I turn on some more debugging and get some info? I can't tell if the old URLs aren't translating to the new node IDs, or if the Rewrite rule isn't finding its way to entry.php or something else entirely. It's still giving 404s, but I'm not sure how to get more info to help diagnose.

                Comment


                • #9
                  You can turn on debug mode by following these instructions: https://www.vbulletin.com/go/vb5debug. However I doubt it is going to provide more information because no actual error is being tossed in vBulletin. The problem is that you need to remove the /forum/ from incoming URLs completely but only if they are not actually accessing a forum on your site. If you do that, the URLs above work. For example:

                  https://www.carecure.net/entry.php?299-Larger-tires-on-a-scooter

                  Becomes:

                  https://www.carecure.net/blogs/webfoot/2669798-larger-tires-on-a-scooter?299-Larger-tires-on-a-scooter=

                  When you have /forum/ the system will specifically look for one of your forum channels. For example:

                  https://www.carecure.net/forum/sci-community-forums/brain-injury

                  I can only think of two solutions. The first solution that I can think of is going to break your site completely and make it unusable because you're trying to rewrite /forum/. /forum/ is a very specific route in vBulletin 5 and you're conflicting with that.

                  The second is to move your vBulletin installation into the /forum/ directory.
                  Translations provided by Google.

                  Wayne Luke
                  The Rabid Badger - a vBulletin Cloud demonstration site.
                  vBulletin 5 API

                  Comment


                  • #10
                    What about a an Apache ErrorDoc 404 handler? Apache allows those to be CGI, PHP, whatever. Could I write an 'error404.php' that basically takes the URL we are 404'ing on and calls just enough vbulletin stuff to figure out if it's a legacy URL we know how to translate? At that point, Apache is still going to send a 404 to the client, which isn't great for search engines. But I can put friendly text that says "this page has moved here" with a link. And I can add some javascript in the error page with the document.location() change. If humans at web browsers get the 404 web page, they'll just bounce to the right location. Web crawlers will still assume the page is gone because of the 404, but I care more for the humans than the robots.

                    I mean, I can cobble that error404.php together now by simply using curl to do a check on whether fetching the rewritten entry.php returns error 200 or 404. If it returns 200, write my friendly error page. If it returns 404, write a 404-style errorpage. Making a full HTTPS request to localhost seems like overkill (effective, but overkill) when there's probably a more efficient way to emulate entry.php.

                    Just showing me that URL (entry.php) above that actually works was SUPER helpful. I might be able to fix this!

                    Comment


                    • #11
                      As a colophon, I have actually solved this for about 95% of our old URLs. I include the 7-line patch file here. It's an ugly hack. But it is WAY better than nothing.

                      The fix is to includes/vb5/frontend/routing.php. Basically, I look to see if the incoming path is /forum/SOMETHING.php. If it is, then I just get rid of the /forum piece. That makes it appear to be a request for /SOMETHING.php and that will get routed correctly.

                      I've tested this with a bunch of URLs that had been resulting in error 404s and now they redirect properly. There's one tiny glitch that I don't really care about. An old URL like this:
                      http://sci.rutgers.edu/forum/forumdi...hp?4-Equipment
                      gets redirected to
                      https://www.carecure.net/forum/sci-c...t?4-Equipment=

                      Note the extra query string on the end (?4-Equipment=). That shouldn't be there. At the end of the day, the person gets a 301 instead of a 404, and their browser shows them the page they were looking for. So I kinda don't care. This seems to work perfectly for showthread.php, forums.php, and member.php, which make up about 95% of my old links I need to handle). I have a few URLs like this:
                      http://sci.rutgers.edu/forum/list.ph...9e43e459f75da2
                      http://sci.rutgers.edu/forum/search....&userid=335276

                      They don't end up in the right place, but it's really fine. I'm not too worried about those.

                      Showing me what the right URLs needed to be and saying the word "routing" pointed me in the right direction. Thanks a bunch, Wayne Luke !

                      Here's my 7-line patch. Note that this is against 5.5.5. We haven't upgraded to 5.6.0 yet.

                      Code:
                      --- vb5.5.5/upload/includes/vb5/frontend/routing.php 2019-12-13 10:16:15.000000000 -0500
                      +++ apache24/html/includes/vb5/frontend/routing.php 2020-04-22 20:57:31.574504000 -0400
                      @@ -90,8 +90,14 @@
                      {
                      $this->processQueryString();
                      
                      - $path = $this->getPath();
                      + $paco_path = $this->getPath();
                      
                      + if( preg_match('/forum\/([a-z]+\.php)/i', $paco_path) )
                      + {
                      + $path = preg_replace('/forum\/([a-z]+\.php)/i', '$1', $paco_path);
                      + } else {
                      + $path = $paco_path;
                      + }
                      //If there is an invalid image, js, or css request we wind up here. We can't process any of them
                      if (strlen($path) > 2 )
                      {

                      Comment


                      • #12
                        How do this work if you try to access the forum channel directly? Seems that valid vBulletin 5 URL will be broken.

                        https://forum.vbulletin.com/forum
                        Translations provided by Google.

                        Wayne Luke
                        The Rabid Badger - a vBulletin Cloud demonstration site.
                        vBulletin 5 API

                        Comment


                        • OldGrumpyDad
                          OldGrumpyDad commented
                          Editing a comment
                          It works fine on /forum and /forum/. The one place it fails is the explicit index.php (https://www.carecure.net/forum/index.php). That URL brings up a 404, which I might just have to special case.

                        • Wayne Luke
                          Wayne Luke commented
                          Editing a comment
                          I am glad you found a solution to your situation.

                      Related Topics

                      Collapse

                      Working...
                      X