sadhaka

If I make a fresh WordPress installation into the root of my domain https://example.com, would it interfere in any way with the separate installation in https://example.com/john ?

(I would use the same database as used by https://example.com/john but with a different prefix.)

I realise that I would have to refrain from allowing any category or similar in the root installation to be named /john, but other than that, might I experience any other unforeseen problems?

I think I’ve now tested all variants of server paths, absolute and relative, with specific or regex-style suffices, and none seem able to enable W3TC to cause the targeted files to be hosted with the CDN.

I suppose I shouldn’t be too surprised at this, since these files do after all reside outside the WordPress environment, but it was worth a shot.

Unless anyone reading this has another suggestion that I haven’t thought of, then I guess my only option is to copy/move the files in question to a directory in my child theme, and rewrite the paths in the referring pages to suit.

Thank you @vmarko – by “file path” do you mean a server path?

Also – I know that you can use placeholders for common WordPress directories, but I’m not sure how I could use a placeholder for my own directories that I have created outside the WordPress installation.

@vmarko – do you mean via the email exchange that you started with your above reply? I haven’t heard anything else but that, and the issue continues.

This will not work properly for the site root however. If your “Front Page” (home page/root) is a WordPress page, then excluding it in the in-page panel’s “advanced” section in the page does give it a “robots noindex” but it nevertheless still appears in the xml sitemap.

(I have a particular reason for excluding my root/home page – it is only a video with navigation and therefore very “thin” content for Google and likely to be penalised if submitted.)

How do I set up a multisite that will include the root directory while my existing installation with its established SEO is in a subdirectory? Anyone?

One thing I find rather confusing on the network guide page is the advice which says, “If you plan to run WordPress out of its own directory, do that before activating Multisite.”

Much of the linked guide page on that talks about moving WordPress to a subdirectory – but mine’s already in one.

But, my root has no WordPress install (in fact it has nothing at all yet), so should I move the existing subdirectory WordPress installation to there (root), before changing to the network/multisite? (I have a feeling this sounds right; if it is, is there a good guide for doing this?)

• This reply was modified 4 years, 11 months ago by sadhaka.

Thank you @catacaustic. Your advice is to the point and makes sense.

I think subdirectories will perhaps be best for my purposes.

I also take your point about preferring a multisite network over separate installs, so now I must study the best guides for transforming the existing single subdirectory installation into a network that will accept other installations into other subdirectories – and the domain root, for that matter (it’s been rather left dangling since the single existing subdirectory install started out as a kind of experiment that turned out quite well).

As you can see I have much to learn here. But thanks again.

Thank you. I’m now looking at that option.

It looks a tad daunting at first, and difficult to choose between subdomain and subdirectory/subfolder. I’m wondering what the pros and cons of each are as they might be applicable to my idea.

Also the pros and cons of a multisite vs multiple WordPress installs in subdirectories.

I’m anxious not to destroy the SEO from the existing subfolder installation.

I found these PHP errors in my server error logs, which might give additional clues:

[18-Dec-2019 15:03:11 UTC] PHP Fatal error:  Uncaught Error: Class 'W3TC\PgCache_Plugin' not found in /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php:29
Stack trace:
#0 /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php(163): W3TC\Root_Loader->__construct()
#1 /[server-path]/wp-content/plugins/w3-total-cache/w3-total-cache.php(67): require_once('/[local/serverpath]/...')
#2 /[server-path]/wp-settings.php(360): include_once('/[local/serverpath]/...')
#3 /[server-path]/wp-config.php(92): require_once('/[local/serverpath]/...')
#4 /[server-path]/wp-load.php(37): require_once('/[local/serverpath]/...')
#5 /[server-path]/wp-blog-header.php(13): require_once('/[local/serverpath]/...')
#6 /[server-path]/index.php(17): require('/[local/serverpath]/...')
#7 {main}
  thrown in /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php on line 29
[18-Dec-2019 15:03:11 UTC] PHP Fatal error:  Uncaught Error: Class 'W3TC\PgCache_Plugin' not found in /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php:29
Stack trace:
#0 /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php(163): W3TC\Root_Loader->__construct()
#1 /[server-path]/wp-content/plugins/w3-total-cache/w3-total-cache.php(67): require_once('/[local/serverpath]/...')
#2 /[server-path]/wp-settings.php(360): include_once('/[local/serverpath]/...')
#3 /[server-path]/wp-config.php(92): require_once('/[local/serverpath]/...')
#4 /[server-path]/wp-load.php(37): require_once('/[local/serverpath]/...')
#5 /[server-path]/wp-blog-header.php(13): require_once('/[local/serverpath]/...')
#6 /[server-path]/index.php(17): require('/[local/serverpath]/...')
#7 {main}
  thrown in /[server-path]/wp-content/plugins/w3-total-cache/Root_Loader.php on line 29
[18-Dec-2019 15:03:14 UTC] PHP Fatal error:  Uncaught Error: Class '\W3TC\ModuleStatus' not found in /[server-path]/wp-content/plugins/w3-total-cache/Dispatcher.php:16
Stack trace:
#0 /[server-path]/wp-content/plugins/w3-total-cache/Generic_Plugin.php(281): W3TC\Dispatcher::component('ModuleStatus')
#1 /[server-path]/wp-includes/class-wp-hook.php(288): W3TC\Generic_Plugin->admin_bar_menu(Object(WP_Admin_Bar))
#2 /[server-path]/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters(NULL, Array)
#3 /[server-path]/wp-includes/plugin.php(544): WP_Hook->do_action(Array)
#4 /[server-path]/wp-includes/admin-bar.php(86): do_action_ref_array('admin_bar_menu', Array)
#5 /[server-path]/wp-includes/class-wp-hook.php(288): wp_admin_bar_render('')
#6 /[server-path]/wp-includes/class-wp-hook.php(3 in /[server-path]/wp-content/plugins/w3-total-cache/Dispatcher.php on line 16

I checked, and yes, the file ModuleStatus.php does exist at that path.

Anyway, if it happens again, I’ll try your recommendation.

However, I notice that the ModuleStatus.php on the server and the one in the download are identical..

• This reply was modified 4 years, 11 months ago by sadhaka.

Well the site just came back as normal, without any intervention from me, so I don’t know what happened there.

The error occurred roughly an hour or so ago.

I have made no significant updates to the site recently.

The W3TC plugin version is listed as version 0.12.0, if that helps.

I don’t know if any of this gives you a clue to you as to what might have occurred.

Sa?a – not sure I get what you mean entirely, but I find now that the posts page does seem to be excluded from the sitemap if I specifically exclude it by using the “advanced” Yoast setting on the page and choosing “No” (and not the default, which actually was “No”, but that didn’t work). It didn’t seem to be excluding it at first, but now it looks like it is (I can’t see it in the sitemap, anyway). Maybe some cache or similar wasn’t purged.

• This reply was modified 4 years, 11 months ago by sadhaka.

I thought I had excluded it by the method above, but it’s still appearing. This is buggy …

Ah – I think I got rid of it from the XML sitemap by using the “advanced” Yoast setting on the page, and explicitly choosing “No” – instead of leaving the “Default for pages, currently: No”, which should have excluded it, so there’s a bug there … perhaps every to-be-excluded page needs checking like this ? Otherwise I can see Google getting confused about this.