Changing from VHOST declaration in wp-config

  • cmale

    (@cmale)


    10 months ago

    Bear with, this is a bit long but I wanted to try and get all relevant info in.

    At work, I inherited a pretty old networked install of wordpress and while testing the upgrade to PHP 8 get the following notice:

    Deprecated: Function define() was called with an argument that is deprecated since version 3.0.0! The constant VHOST is deprecated. Use the boolean constant SUBDOMAIN_INSTALL in wp-config.php to enable a subdomain configuration. Use is_subdomain_install() to check whether a subdomain configuration is enabled. in /public_html/wp-includes/functions.php on line 6031

    I know things still work now but I have read this would be fatal error in later versions of PHP so ideally I’d like to resolve before things break.

    It’s using the latest version of wp core and all our plugins etc are up to date. It is a sub directory setup.

    I think the VHOST line is an old way of doing the network install? On our dev server I tried replacing define('VHOST', 'no'); in the wp config with the following:

    define('WP_ALLOW_MULTISITE', true);
    define( 'MULTISITE', true );
    define( 'SUBDOMAIN_INSTALL', false );

    I also had to add define('WP_ALLOW_REPAIR', true);

    Once it had gone through the db repair, I got the following:
    wp_posts: Table 'wp_posts' doesn't exist
    wp_comments: Table 'wp_comments' doesn't exist
    wp_links: Table 'wp_links' doesn't exist
    wp_options: Table 'wp_options' doesn't exist
    wp_postmeta: Table 'wp_postmeta' doesn't exist
    wp_terms: Table 'wp_terms' doesn't exist
    wp_term_taxonomy: Table 'wp_term_taxonomy' doesn't exist
    wp_term_relationships: Table 'wp_term_relationships' doesn't exist
    wp_termmeta: Table 'wp_termmeta' doesn't exist
    wp_commentmeta: Table 'wp_commentmeta' doesn't exist

    I think these tables do actually exist but with the prefix wp_1_ instead – based on the fact the content in the the top level/root site is in these tables.

    Would I be right in thinking we could rename those tables to correct the setup? What are the implications of doing this? Is there a better option instead?

    We also have the line define('BLOGID_CURRENT_SITE', '1' ); in the wp config for this network. On other ones I’ve seen the 1 is not in quotes. Is that something we should also change or can we ignore?

    We don’t have proper in-house wordpress support (I come from a design background) and while I have access to DbA’s they don’t know wordpress-specific stuff so any thoughts or suggestions very much welcome.

Viewing 3 replies - 1 through 3 (of 3 total)
  • threadi

    (@threadi)

    The existing database tables indicate that this is a multisite installation. Separate database tables are created for the individual websites in the installation – preceded by a number prefix. This is also how you get “wp_1_”.

    There should also be tables for the main page – without the number prefix. Presumably these are missing.

    This raises the question for me: how old is this WordPress? Can you find out the version? E.g. via the readme.txt, wp-includes/version.php …

    BLOGID_CURRENT_SITE expects a string, with inverted commas it would be correct. However, this constant is already deprecated …

    Thread Starter cmale

    (@cmale)

    Thanks for the reply. Sorry yes, this is multisite (wordpress uses network in the GUI and I can never remember the usual term of reference) so I am aware each site has its own set of tables in the database and the prefix correlates to the site id.

    I have had a look at the database in phpMyAdmin and can confirm the tables wordpress is looking for are definitely missing. I also believe the root site tables are the wp_1_ prefixed tables. In another multisite install we have, the tables for the root site are wp_posts etc (ie, don’t have a number) which is why I’m wondering if we could rename the wp_1_ tables and thus create the tables wordpress is looking for in this install?

    If I remember rightly, the install was originally setup circa 2010. I’m not exactly sure which version of wordpress it originally started on but I assume a WPMU version from 2010ish. Possibly this why we have odd legacy bits despite the core having been updated over the years. It’s currently on the latest version (6.3.2).

    Thread Starter cmale

    (@cmale)

    Typo, we’re actually on 6.4.2

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Changing from VHOST declaration in wp-config’ is closed to new replies.