404 only on main site of subdomain multisite

  • Resolved kagsundaram

    (@kagsundaram)


    3 years, 7 months ago

    I have had this multisite successfully running for several years, and have been using this plugin also successfully for several years.

    A few months back, a curious problem cropped up.
    (Interestingly, I notice in the change logs the word “multisite”; the problem seems to have shown up at about that time.)

    Context:
    Although the main site (the site ID 1) shows publicly as kag.to, the WordPress instalation is not in the root, but one level deeper. And instead of being folder “wp”, it is folder “site2wp”. One more method of hiding from bad bots.

    Using WPS Hide Login, my login page is https://kag.to/gatekeeper/ for the main site, and https://subdomainname.kag.to/gatekeeper/ for each subdomain.

    What works:
    On any subdomain, using the standard dropdown from the admin bar, choosing a subdomain and clicking on “Dashboard”, it goes there correctly.
    And if I deactivate WPS HIde Login, it works for the main site also.

    The Problem:
    With WPS Hide Login active, when I click on Dashboard for the main site in the admin bar dropdown, instead of going to https://kag.to/site2wp/wp-admin/, it goes to https://kag.to/site2wp/gatekeeper/, which is a 404 error.

    When I attempt the same thing using the dropdown in the admin bar dropdown of a handy admin links plugin, it works fine to https://kag.to/site2wp/wp-admin/

    Also, as I noted above, the Dashboard links of all the subdomains work correctly.

    [Per the Forum Guidelines we ask you NOT bump posts. We use the ‘no replies’ search on these forums regularly to find people who still need help. By bumping, you remove yourself from that list and make it HARDER for us to find you!]

    • This topic was modified 3 years, 7 months ago by Yui. Reason: dont bump please

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

Viewing 7 replies - 1 through 7 (of 7 total)

  • I saw this the other week but left it be for the plugin author going there might be a good answer there for you.

    The only fix I could come up with would be to reinstall the site properly via running from the root directory or else using the documentation to install and run from a subdirectory as if installed in the webroot.

    You can get tricky with directories and such but you need to keep in mind WordPress was designed to run in certain ways and one-off installs may keep the desired plugin(s) from running without resorting to redirects.

    That said, You might want to consider a redirect for just that single admin URL but that will expose that actual address for what is the main site.

    One other idea might be to create an HTML page at that ‘gatekeeper’ address for the main admin page with some obfuscation warning or error messages and a hidden link (under a smiley or image) pointing to the proper admin link.

    Hope this helps.

    Thread Starter kagsundaram

    (@kagsundaram)

    There is nothing improper about the way the site is installed.

    It does make use of all of the sophistication which WordPress provides.

    Yes, subdomain installs are tricky. It took me many weeks to get it right when I first set it up a decade ago.

    It was working fine with this plugin for years, until a few months ago, which was, as I noted, the same time that the changes log for this plugin notes a change in the way multisite is handled.

    I have found it common for plugin authors to fail to test their plugins in all legitimate configurations of WordPress; it requires have multiple testbed sites. The plugin that I am currently writing, my fourth, is on two sites, and will be tested on three others, with different configurations, before being offered to the public.
    However, it is clear that Nikolas has indeed taken the time and effort to test on multiple configurations; but this one little problem is an easy one to miss in testing.

    Plugin Author NicolasKulka

    (@nicolaskulka)

    The changes were made because of this ticket:
    https://www.ads-software.com/support/topic/fix-for-multisite-my-sites-menu/

    Thread Starter kagsundaram

    (@kagsundaram)

    Thanks for the the link, @nicolaskulka

    I looked at the original ticket (and the website of the post author), and, as I expected, the original poster (and author of the fix) seems to have a subfolders multisite rather than a subdomain multisite.

    I will be looking at that fix (as soon as I can break free of the software of my own plugins) and see what I can do to improve on it, so that it will work for subdomain multisites as well.

    Again, thank you for the link.

    oK, @kagsundaram, I tried to give you my best take on what you might consider in the hope that something I might say might trigger an idea for you or a response from the author (or someone else involved with that plugin).

    Seems to have worked to bring out a pointer to an explanation of what was done and also handed you my thoughts on what I might do or have you consider.

    I appreciate the points you made but this ‘making’ “use of all of the sophistication which WordPress provides” has left you with a slight problem. I won’t argue with you.

    • This reply was modified 3 years, 7 months ago by JNashHawkins.
    • This reply was modified 3 years, 7 months ago by JNashHawkins.
    Thread Starter kagsundaram

    (@kagsundaram)

    “…a slight problem…” due to the incomplete testing of a plugin fix, which solved somebody else’s problem, who was also using a quite sophisticated multisite setup, and, like my clients, required high security.

    Not that I blame anyone, it is a rather obscure problem. Many hours of poring through 20-KB trace dumps has narrowed the problem to occurring only on the primary site of a multisite installation, only if, as a security measure, the installation folder is one level deep and does not begin “wp…” in the folder name, and then only if the administrator of the prime site has set a WPS Hide Login alias from that site (as opposed to setting it from the network admin panel).
    That is a very obscure and unlikely set of conditions to be testing for.

    For the vast majority of WordPress users, having a WordPress installation bought for a small fraction of the hourly rate they would need to pay a senior software engineer is the best way to go, it serves their needs well.
    For others, more is needed. One of my clients is running a campaign for the presidency of a nation through secure multisite WordPress installation I created for him. A simple site was inadequate.

    I do appreciate the desire and attempt to help; it was good advice for the average WordPress installer, no one had any way of knowing from my initial post my level of expertise, or that I had designed, built and programmed my first computer when John F, Kennedy was president.

    • This reply was modified 3 years, 7 months ago by kagsundaram.
    Thread Starter kagsundaram

    (@kagsundaram)

    @nicolaskulka, I have a work-around which is simple, reasonable, safe, and adequate for my purposes, so I am setting the pursuit of a real solution aside for a while.

    The conditions engendering the problem are quite obscure and unlikely.
    The problem seems to require all of the following:

    * multisite
    * subdomain
    * WordPress Address (WordPress installation) one level beneath the root
    * Site Address (public URL) is root (i.e., https : / / myroot . com)
    * WordPress folder name does not begin “wp” (myroot.com/myalias/)
    * the prime site (site 1) has set its own WPS Hide Login alias

    The last condition is highly unusual, as the prime site would usually rely on the alias set in the Network Admin.

    The work-around is this:
    In the database, in the table mydbtables_options (wp_options):
    * delete the entry “whl_page”

    This is simple and reasonable, because because on a subdomain multisite installation, the Network Administrator (who usually owns the prime site) can be expected to be comfortable using phpMyAdmin or equivalent.

    It is safe, because the the WPS Hide Login alias for the entire network will still be active from its home in mydbtables_sitemeta (wp_sitemeta), and the individual aliases (if any) of all of the other sites are undisturbed in mydbtables_##_options (wp_##_options).

    The problem should be fixed in software someday, a minor tweak, I would expect, to the 1.8 change, but it can be a very low priority, now that there is a work-around.

    ICYMI @eceleste

    • This reply was modified 3 years, 7 months ago by kagsundaram.
Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘404 only on main site of subdomain multisite’ is closed to new replies.