• Resolved OsakaWebbie

    (@osakawebbie)


    I used the Duplicator plugin to make a copy of my main https://l4jp.com site in a subdirectory “old” so I could do comparisons between versions of a theme and fix CSS problems. I can access the main landing URL https://l4jp.com/old, but any other frontend URL associated with that site (whether from navigation on the site or input directly in the browser) gets a 301 redirect to the main site (i.e. the “old/” in the middle of the URL is removed). I’ve checked wp-config.php and .htaccess for oddities, but I didn’t spot anything obvious.

    There are two pieces of evidence that it’s WordPress doing the redirect: (1) https://l4jp.com/old/wp-admin/ does not redirect – the problem is only the frontend; (2) when I ran curl -v https://l4jp.com/old/about-en/ a month ago when first fighting this, it reported the following:

    > GET /old/about-en/ HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: l4jp.com
    > Accept: */*
    >
    < HTTP/1.1 301 Moved Permanently
    < Server: nginx
    < Date: Fri, 27 Oct 2023 06:17:05 GMT
    < Content-Type: text/html; charset=UTF-8
    < Transfer-Encoding: chunked
    < Connection: keep-alive
    < Expires: Wed, 11 Jan 1984 05:00:00 GMT
    < Cache-Control: no-cache, must-revalidate, max-age=0
    < X-Redirect-By: WordPress
    < Location: https://l4jp.com/about-en/

    I don’t know what some of that means (including what expires in 1984!), but X-Redirect-By: WordPress seems pretty clear. Mysteriously, after a month with no action on my part, I don’t get exactly the same curl output now (confusing answers instead), but I assume WordPress is still involved. Suggestions on what to look for?

    The page I need help with: [log in to see the link]

Viewing 12 replies - 1 through 12 (of 12 total)
  • Aniekan

    (@anieeedet)

    Hey Osaka,

    The 301 redirect you’re experiencing is likely caused by how the Duplicator plugin replicates your site’s structure. Creating a duplicate site using Duplicator creates a copy of the site’s files and database, but it doesn’t modify the URLs to reflect the new subdirectory location.

    This means that when you access a page on a duplicate site, WordPress still tries to find the original page on the main site. Since the original page no longer exists, WordPress redirects you to the main site’s homepage.

    To resolve this issue, you need to update the URLs in the duplicate site’s database to reflect the new subdirectory location. You can do this manually using a plugin like “Search & Replace.”

    You should be able to access all pages on the duplicate site without being redirected to the main site after updating the URLs.

    Thread Starter OsakaWebbie

    (@osakawebbie)

    Did you try my site at all? All the links are correct – go to https://l4jp.com/old/ and then hover over any menu item or other link – all of them have “old” in the URL. And you don’t even need to use a link to see the problem – for example, try https://l4jp.com/old/home-ja/ or https://l4jp.com/old/kizunadb-en/ . And you wrote something about pages not existing, but nothing has been removed – both sites exist in full.

    Ashutosh Sharma

    (@ashutosharma97)

    Yes, the pages are being redirected by WP. Check .htaccess file inside the “old” directory, the RewriteBase line should be RewriteBase /old and not just RewriteBase / but if your server is only using Nginx, then the .htaccess file won’t work, and you will have to update Nginx config instead.

    Thread Starter OsakaWebbie

    (@osakawebbie)

    Thanks for the response. My /old/.htaccess looks fine – here it is:

    # This file was updated by Duplicator on 2023-10-27 01:26:38.
    # See the original_files_ folder for the original source_site_htaccess file.
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /old/
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /old/index.php [L]
    </IfModule>
    # END WordPress

    Yes, my webserver is nginx, and it’s a VPS so I have control over its config files. But since it’s WordPress that is doing the redirecting, how can nginx config files help? Even if I could write something for the config file that detects a request of l4jp.com/index.php that is the result of a redirect from /old/index.php (if that’s even possible) and rewrites it back to /old/, that would just become an infinite loop battle between nginx and WP.

    Ashutosh Sharma

    (@ashutosharma97)

    AFAIK, WordPress is handling the redirect because /index.php is being used. When you are visiting /old/ nginx finds the “old” directory, and then /old/index.php file is used. But when you have /old/some-page nginx won’t find that “some-page” in the “old” directory, therefore, the request will again be handled by /index.php. You have to tell nginx to use /old/index.php to handle the requests when /old/ is requested. Something like this:

    location /old/ {
        try_files $uri $uri/ /old/index.php;
    }
    Thread Starter OsakaWebbie

    (@osakawebbie)

    Thanks – that worked (once I finally remembered that I have to restart nginx after any changes!).

    And your previous clue about .htaccess came in handy with another site that I had to clone, running on Apache. I had to wrestle Duplicator, though – I put an .htaccess with the correct RewriteBase in the subdirectory before running the installer (in fact, I had to do that – otherwise installer.php got redirected!). But partway through the installation process, the .htaccess file got removed, resulting in a complaint from the installer that AJAX failed with a 404 error. No doubt that was the moment when .htaccess had been deleted, so the AJAX request got redirected to /. Sigh! I had to replace .htaccess several times as I retried the installation, and eventually it got all the way through the process. If Duplicator wasn’t such a well-respected plugin, I would think that their developers forgot to tell users how to deal with subdirectory installations. I’ve used Duplicator in the past (several years ago) and don’t remember having this issue. Their “Classic Installation” help page says nothing about special prep if using a subdirectory – it says any location within webroot is fine.

    Anyway, thanks for your help!

    Ashutosh Sharma

    (@ashutosharma97)

    You’re welcome! Glad that it worked out for you. Next time, try making .htaccess immutable if you have SSH access.

    Thread Starter OsakaWebbie

    (@osakawebbie)

    Ack! I’m having more problems! For the site that’s on Apache, I’m now trying to use the cloned site to troubleshoot a problem we have been having for a month: the dreaded “not a valid JSON response” error. One common troubleshooting step for that error is to temporarily turn off permalinks (set to “Plain”). Doing that caused WordPress to remove the whole mod_rewrite block from .htaccess, including the RewriteBase line. I had to do a delicate dance of steps to change the permalink setting back: (1) manually edit .htaccess via FTP to put the rewrite block in it, (2) put the “/dev/” back in the URL and navigate to Settings/Permalink (which immediately removes the rewrite block from .htaccess again, because apparently something in the database says it’s set to Plain), (3) manually edit the file again while that page is open, (4) save the setting change.

    A comment at the top of .htaccess (included by either WordPress or Duplicator – I’m not sure which) does warn:

    The directives (lines) between “BEGIN WordPress” and “END WordPress” are dynamically generated, and should only be modified via WordPress filters. Any changes to the directives between these markers will be overwritten.

    Yup, that’s exactly what is happening. What can I do about it? I searched the web hard for answers, but haven’t found anything. All advice for running WordPress in a subdirectory does what I did, which is clearly not the right approach to protect against changes to the permalink setting. Is there something I can put in .htaccess that WordPress will not remove?

    • This reply was modified 12 months ago by OsakaWebbie.
    Ashutosh Sharma

    (@ashutosharma97)

    I have never encountered a problem like this. But please check if your home URL is correct.

    If you see the code that WP uses to generate the rewrite rules, you will see that the home_url() function is used to get the value for$home_root which is then used for RewriteBase and RewriteRule.

    Otherwise, it is possible that some other plugin is using mod_rewrite_rules and modifying the rules.

    Thread Starter OsakaWebbie

    (@osakawebbie)

    Sorry to be slow getting back to this – the JSON error was resolved (Dreamhost’s firewall flagging something in the Astra theme as a false positive – that was a weird one!), so I haven’t needed to turn off permalinks since my last post here; and I had a pile of other urgent work to do. But it would still be good to solve this.

    “But please check if your home URL is correct.” Where do I check this? Can I put something like echo "<pre>HOMEURL=*".home_url()."*</pre>"; somewhere in functions.php?

    Site and Home URLs are mentioned under Settings ? General.

    You can also use functions.php to echo the output, but my preferred way is to use Query Monitor. You can add the following to functions.php:

    function check_home_url_and_root()
    {
        $home_url  = home_url();
        $home_root = parse_url($home_url);
        if (isset($home_root['path'])) {
            $home_root = trailingslashit($home_root['path']);
        } else {
            $home_root = '/';
        }
        do_action('qm/debug', "Home URL: {$home_url}");
        do_action('qm/debug', "Home Root: {$home_root}");
    }
    add_action('init', 'check_home_url_and_root');

    Then you can see Logs under Query Monitor:

    If you don’t want to use Query Monitor, you can instead do this:

    function check_home_url_and_root()
    {
        $home_url  = home_url();
        $home_root = parse_url($home_url);
        if (isset($home_root['path'])) {
            $home_root = trailingslashit($home_root['path']);
        } else {
            $home_root = '/';
        }
        if (isset($_GET['dump_data'])) {
            var_dump("Home URL: {$home_url}");
            var_dump("Home Root: {$home_root}");
        }
    }
    add_action('init', 'check_home_url_and_root');

    Open any site page, and append ?dump_data to the URL to get the output.

    Thread Starter OsakaWebbie

    (@osakawebbie)

    The URLs are confirmed correct by two of your suggested methods. In Settings->General, both “WordPress Address (URL)” and “Site Addres (URL)” are “https://japan.deafmin.org/dev&#8221;. And when I add your suggested code to functions.php and do the data dump, it says:

    string(39) "Home URL: https://japan.deafmin.org/dev" string(16) "Home Root: /dev/"
Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Cloned site in subdirectory keeps redirecting to root’ is closed to new replies.