Friendly URLs

  • I've downloaded the core to see what the backend is like before purchasing any of the apps. I have tried to initiate friendly URLs, but the test always fails. This is what I have in the htaccess file:

    <IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteBase /

    RewriteCond %{SCRIPT_FILENAME} !-d

    RewriteCond %{SCRIPT_FILENAME} !-f

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


    The test fails and states that this is configured wrong - what is wrong with this configuration? Apart the text in green the rest is what was generated from the system. Any help would be appreciated as this is currently the obstacle to my purchasing any apps.

    With thanks

  • Hello,

    The rewrite rule test dispatches requests to known valid locations if the rewrite rules are correctly set up. If the above rules have been placed in the directory of the Core itself, then this should work for Apache. Possible reasons why this could still fail:

    • You are not using Apache, an increasing number of webhosting softwares use nginx for their core services.
    • Apache is configured to not interpret .htaccess files at all.
    • The rewrite module for Apache is not loaded.

    You can test for the rewrite module by removing the <IfModule …> and </IfModule> lines. If the webserver starts replying with an internal server error, then the rewrite module is not available.

  • Definitely on Apache (checked this using phpinfo) removing the <if module> statements do not return server errors. Rewrite is working for other scripts I'm running. When you refer to the Core directory, I'm assuming that is the root as that is where the Core is installed. I've tried numerous configurations but all fail the test.

    Something I'm missing? I'm new to Woltlab so not really familiar with its workings :)

  • Yes, it must be configured for the installation directory. You can manually try to access a page by manipulating the url of a known page.

    Navigate to the members list, the URL should read /index.php?members-list/. Now change it into /members-list/ and hit return to access the page. If the rewrites are working properly, you should be redirect to the first url, because rewrites are disabled. If you see any other page, such as a generic error page of your webserver, then the .htaccess configuration is not applied.

  • Done what you said and changed to /members-list/ did not get any errors, just a blank page.

    I also tried removing the rewritebase and that did return an internal server error 500.

    Hmm, reset the rewritebase and that /member-list/ just refreshed the page and stayed there, but when I tried the same with articles-list it refreshed but went back to adding the index? part back into the URL.

    Oh my, just tried the member-list again and got page not found - this is weird.

    Edited 2 times, last by davyc (November 20, 2020 at 6:48 PM).

  • OK added display_errors to my php.ini file and there are no errors being displayed. I can't find any errors in the server logs, but then there are loads of files in that folder many with the gz extension, but I did look through those I could access and there was nothing indicating any server error cause by the .htaccess file other than that 500 internal server error that I caused by removing the rewritebase command.

  • I understand, in that case I suggest that you get in touch with your hosting company, possibly some unrelated rule is interfering with your setup. Since the regular page requests work and rewriting is just an internal process in the webserver (client asked for X, but translate this to Y), this is most likely an issue with the webserver.

  • Some additional information - hosting company states that the rewrite module is present and active. I have two other installations, one is IPS the other is Xenforo and both utilise the rewrite function and they work perfectly. Here is what is contained within the htaccess files:

    IPS first:

    And this is the Xenforo version:

    This is what the Woltlab system advises to include in the htaccess file

    Apache Configuration
    RewriteCond %{SCRIPT_FILENAME} !-d
    RewriteCond %{SCRIPT_FILENAME} !-f
    RewriteRule ^(.*)$ index.php?$1 [L,QSA]

    I've attempted to copy both the IPS and Xenforo configurations into the Woltlab htaccess file without success (I didn't think they would work, but tried anyway) so I am at a loss as to why the rewrite does not work on the Woltlab installation. This is preventing me from moving forward with purchases, so if there is anything else you can think of to mitigate this, it would be appreciated.

    With thanks

  • Yeah, they just referred me to this help document, which I tried but no luck. Help Document

    Strangely enough that blank page issue has disappeared, but when I manually change the URL to omit the index.php part I now get redirected to the homepage. My host BTW is Inonos (formerly 1and1) and I'm on their shared hosting platform - the expert package; not sure if that helps or not.

  • but when I manually change the URL to omit the index.php part I now get redirected to the homepage.

    The whole url rewriting isn't anything remotely magic, in fact is is very simple and does two things:

    1. The software will tell the browser that a page like index.php?members-list/ is available via /members-list/ instead.
    2. The webserver sees requests for /members-list/ and tells PHP that index.php?members-list/ was requested by the browser.

    So when you say you are being redirected, where does it redirect you to? The "homepage" is a pretty broad term, this could mean the start page of our software or, if the forum is running in a subdirectory, the / url of your entire site.

  • The homepage is the dashboard as it's just the core that is installed. So, if I change the URL to anything that omits the index.php I get redirected to the dashboard which is basically the first page that appears when the URL is initiated.

    If I do this with the articles URL it just changes back to the URL with index.php in it. You can try this by visiting

  • It's working now - system has passed the test, so I can only assume it was the browser cache that was causing the issue. I would say to anyone now experiencing this issue to clear your browser cache and add those extra bits to what the system tells you to add to the htaccess file.

    Thanks to Alexander Ebert for your patience and great support. This was seriously doing my head in, but it's now resolved - hallelujah :)

    Edited 3 times, last by davyc (November 21, 2020 at 4:21 PM).

  • Yes, the system now says the test has passed:

    Whenever I clicked on YES before it ran the test and kicked me out saying something wasn't configured correctly. But now that I cleared my browser cache it's working great :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!