susanwrotethis

Is it possible that it isn’t WordPress but either the server itself or something else you have installed there that’s creating the folder? That’s one possibility to eliminate.

The fact that it’s reappearing during a given time frame suggests that it’s a product of a cron job (a task scheduled to take place on a specified schedule). There’s a plugin called Crontrol that you can install to see what WordPress-specific cron jobs are scheduled. Activate it on each site and look at the list of jobs (you’ll find it under Tools in the admin menu). If a job is scheduled around 1:30, that may be what’s creating the folder. If you find something likely you can post the job name, and it may help resolve your issue.

The server also runs cron jobs independently of WordPress, so again, you’ll need to be sure it’s not the server or some other software creating it. I assume your hosting service will know if it’s being created by the server.

In short, it sounds like you’re good to go with the update.

WordPress multisite, because of the way it evolved, tends to confuse everyone at first because of the way it uses the word “site”. In WP technical lingo, “site” means the multisite network, whereas “blog” refers to what most people think of as sites — that is, the individual entities within the multisite.

For future WP core updates, I’d recommend that you go to the Updates page in the Network Admin menu and perform the core update from there. Once that’s done you may see a message that the update was a success and that you should now upgrade the network. Use whatever button or link is provided there; you don’t need to run the update on each blog on your multisite individually.

When you create a new site (or in WP terms, “blog”), that info is stored in the wp_blogs table and has nothing to do with wp_blog_versions. Nobody needs to interact with wp_blog_versions, which is there for WP’s own reference.

That’s a difficult question to answer without knowing a lot more about the sizes and uses of the sites and whether they would play well together in one installation. When you have many similar sites with similar purpose, content, function and design, multisite can perform well. You can certainly preserve space as well as maintenance effort if you have only one set of themes, plugins, etc.

If you’re a developer trying to consolidate a lot of unrelated things in one place to make them easier to manage, it can become a nightmare. A tool such as InfiniteWP or ManageWP may be a better solution. They wouldn’t change performance or affect server resources.

If you haven’t read this yet, you may want to check out https://premium.wpmudev.org/blog/ultimate-guide-multisite/, which I hope will help you assess whether multisite is a good fit for your sites.

With the structure you’re describing, a 301 (permanent) redirect is probably what you need in terms of SEO. If you want to do this without touching anything on the server, a 301 redirects plugin would do the job.

The more efficient approach would be to put a 301 redirect in your .htaccess file on the server. There’s an explanation of this at https://www.rapidtables.com/web/dev/htaccess-redirect.htm. The reason it’s more efficient is because visitors to your site will be redirected before WordPress starts loading, while if you use a plugin, it happens afterwards. This takes up more time and server resources.

The place where the blog id is associated with the subdirectory path is in the wp_blogs table. If the data is correct there, then it seems unlikely that it’s a problem with the core code (the handling of data in wp_blogs would be in files specifically for multisite) because all your sub sites would be messed up.

Do you have a plugin or other custom code running just on that one site giving you trouble? It almost sounds as though a plugin that was written for single-site use is activated on the site and that somewhere in its code it’s assuming that it’s connecting to wp_posts, etc., instead of wp_4_posts, etc.

Hi there, I can’t say for certain without looking at everything in context, but I think you may be doing your updates the long way around. The reason I’m thinking this is that user meta on a multisite isn’t stored in a different place for each site. It’s all in a single table, wp_usermeta, which is shared by all the sites. So if you add or update the meta for one, it should by its nature be synchronized across all sites.

The only time you’d need to get the blogs of the user in question is if you were storing user meta that was going to be different for each blog — which is the opposite of what you’re describing. And even then you wouldn’t need to use switch_to_blog() unless you’re storing user-related information in a specific table for that blog, which doesn’t appear to be the case here.

All your code should need to do when a custom user profile field is updated is:

1. Check that the data exists and is valid (for instance, check that an email field contains a properly-formatted email)

2. Use add_user_meta() if the field is new or update_user_meta() if it’s just an update to existing data. This will update the entry in wp_usermeta, which in turn should populate all your sites with new info.

I don’t know if this will help you at all, but you may want to look at https://justintadlock.com/archives/2009/09/10/adding-and-using-custom-user-profile-fields and see if it’s useful.

When you change a single site to multisite, the single site becomes the root site of the installation. The only thing that comes to mind that you may want to check on is whether any of your current plugins don’t work well on multisite.

If you haven’t read them yet, the Create a Network (https://codex.www.ads-software.com/Create_A_Network) and Before You Create a Network (https://codex.www.ads-software.com/Before_You_Create_A_Network) pages in the Codex will answer many common questions.

In the Network Admin menu, go to Users and find the account you want to upgrade to Super Admin. Click on the Edit link for that account. In the options for the user there should be a checkbox that says “Grant this user Super Admin privileges for the network”. Check it and save the update. If they’re logged in when you do this, they’ll need to log out and then log in again for the update to take effect.

You may want to try network deactivating it and then activating it on each site individually. Some plugins not built specifically for multisite only set up the root site when they’re network activated. Theme My Login may be one of them.

If any of those links that have a class, id or other selector in their HTML, you could use it as the hook for a JQuery script. I couldn’t find a ready-made solution,, but I can outline what you’d need to do.

1. Create a .js file to store the JQuery you’d need. A code sample (replace someclass with the actual class of the link):

$(document).ready(function(){
$(‘a.someclass’).click(function(){
window.open(this.href);
return false;
});
});

2. Create a PHP file with a function to enqueue the .js file; for details, see https://codex.www.ads-software.com/Plugin_API/Action_Reference/admin_enqueue_scripts.

3. Upload the files (I’d put them in the mu-plugins directory), then test and debug your work. The two tricky parts are making sure the path to the .js file is correct when you enqueue it and then being certain that the JQuery selector is good.

All that said, this is not necessarily something you should do, and I think this feature has been suggested and rejected as an addition to WP. If you have a small number of users and you provide training and/or documentation, you can include instructions to right-click on a link and choose Open in New Window. Then they have the power to choose how they want to view the page.

I run multisites with 70 and 100 sites respectively without any trouble. How large the sites are in terms of pages/posts, how many users you have, how much traffic you expect and the performance of your themes/plugins are all points to factor in. A single poorly-written plugin can drag your sites down even if everything else is running well.

A system administrator with multisite experience can provide insights on points such as server space, memory allocation and database optimization. Have a plan for periodic database cleanup to keep it from becoming bloated with orphaned tables, options for plugins that are no longer in use and so forth.

If you have two sites using the same domain name, regardless of whether one is on multisite, that’s certainly an issue that needs to be resolved. By all means delete the standalone if you’re sure you no longer need it. The alternative would be renaming one site or the other.

Before you do, make absolutely sure that when you’re not logged in and you load that domain in your browser that the correct site (the one on multisite) is what shows up.

If the standalone is what loads, have a backup ready and be prepared to move quickly in case nothing at all shows up when you delete it. In your situation I’d touch base with my hosting service in advance to see if there are any related server-side changes that need to be done as part of the transition.

The call_user_func_array() is a PHP function, and parameter 1 should be the name of a function that it’s supposed to call in turn. In extremely simplified terms, it’s most likely that one of your plugins is using what PHP considers bad grammar and is getting flagged for it. You may not see anything broken, but it would be good to track it down and report it to the developer if possible.

If you have the ability to search the code in your plugin’s PHP files, try searching for orddd_plugins_loaded to see what it turns up. You can also try turning off plugins one by one to see if the error goes away.

Check this out and see if it helps: https://www.ads-software.com/support/topic/multisite-change-root-blog?replies=10

If you need to explore a more sophisticated solution, you may want to look into the FeedWordPress plugin and/or the WP Rest API.

It’s not technically impossible to show a single annoucement across all the sites in a situation such as a weather-related closing, but I don’t know of a plugin that does this. It may require custom code.