WP_SITEURL & WP_HOME

I migrated one of my sites to WPMUDEV hosting today. In wp-config.php I set the constants WP_SITEURL & WP_HOME to their respective canonical values. However, later when I changed my primary domain in the hosting hub, both lines were removed from wp-config.php. So, if I shouldn’t use those constants, what is the proper way in php to get/set the canonical domain for my site?

  • Neel Gajjar
    • Product Manager

    Hello Matthew,

    how are you doing today?

    When you change the Primary Domain in our Hosting > Domains tab. There is a script which is executed which updates the new domain URL in the Database.

    It changes the value in Database > wp_options table for siteurl and home

    with the new domain name.

    [attachments are only viewable by logged-in members]

    So you don't need to add any constants in the wp-config.php file while changing the primary domain of any WordPress site hosted with us.

    In very rare cases if you can not access the site with the new domain name after updating it as the primary domain.

    You can try to Flush Object it should fix the issue.

    To clear Object Cache Visit Your Hosting Panel > Tools > Click on Flush Object Cache.

    [attachments are only viewable by logged-in members]

    Hope this helps.

    Feel free to reply here if you've any more questions or concerns.

    Kind Regards,

    Neel Gajjar

  • Neel Gajjar
    • Product Manager

    Hello Matthew,

    My Apologies, I missed that part.

    I was able to replicate the issue. The constants are removed when the Primary Domain is switched.

    So what I did is I switched the Primary Domain first and then added those constants in the wp-config.php file.

    After adding the constants I cleared Object cache, Did some basic operations in WordPress and the constants were not removed from the wp-config.php

    So you can first change the Primary Domain and then add the constants and give it try.

    Will this is something work for you?

    Let me know what other constants you want to add so that I can consult with my Hosting team once for any other suggestions if the above solution does not work for you.

    I’m looking forward to hearing from you and resolving this issue as soon as possible.

    Kind regards,

    Neel Gajjar

  • Matthew
    • Design Lord, Child of Thor

    So you can first change the Primary Domain and then add the constants and give it try.

    That’s the workaround I’m using at the moment, however it appears that there are other processes that delete those constants as well (for example syncing to staging), I really don’t want my site to end up broken because some process deletes those settings when I don’t realize it.

    I was using those constants as part of building the value for WP_CONTENT_FOLDERNAME. I can hard code that value directly, but it’d be better to pull the base url from whatever WordPress thinks it is.

  • Neel Gajjar
    • Product Manager

    Hello Matthew,

    I’m really sorry for the delay over here.

    I have escalated your query to our Hosting team for testing the same constants in various processes and environments in our Hosting.

    As soon as the testing is done they will reply back on this thread.

    We appreciate your patience on this.

    Kind regards,

    Neel Gajjar

  • Kostas
    • CTO

    Hey Matthew ,

    WP_HOME and WP_SITEURL are meant to be used only if you want to bypass what is set in the database. Essentially they tell wordpress to not read the home and siteurl entries from the _options table but instead use whatever is set there.

    Those 2 constants are “protected” in our environments and that’s why they are getting reset whenever an action that is related to wp-config or domain happens. As an example when you want to “reset” your wp-config it most likely means that your website is broken so we actually reset the constants as well to make sure that the domains are loaded properly in case something was mistyped.

    This only affects WP_HOME and WP_SITEURL all other constants would be ok between syncs etc.

    What I can propose is doing the change like this if that helps, instead of using WP_HOME or WP_SITEURL you can use a custom variable or constant like so:

    $custom_home = 'https://' . $_SERVER['HTTP_HOST'] . '/';

    define( 'WP_CONTENT_FOLDERNAME', 'custom_uploads' );
    define( 'WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME );
    define( 'WP_CONTENT_URL', $custom_home . WP_CONTENT_FOLDERNAME );

    Tell me if that helps or if you need any further information :slight_smile: .

    Regards,

    Konstantinos

  • Matthew
    • Design Lord, Child of Thor

    Two additional follow-ups to this solution:

    1. References to $_SERVER cause errors when running wp tools commands from the cli. This is minor and can be mostly fixed with some error checking.

    2. When in the staging environment functions such as get_template_directory_uri() return urls based on the production siteurl. This causes incorrect references when loading the staging site.

  • Kostas
    • CTO

    Hey Matthew ,

    $_SERVER returns the domain that the request was made from, so it correctly returns you the “requested host” and not the default host.

    You can try $_SERVER as well that would read the server-side settings instead of the request values.

    I’m also not sure what you mean about the get_template_directory_uri() .

    By using the snippet I gave you above for wp-config and doing an error_log( get_template_directory_uri() ); my return path is https://wpmudev-sls.staging.wpmudev.host/custom_uploads/themes/twentynineteen , that is correct as it uses the custom path as well .

    As a note, we are using our own custom mu-plugins as well on our environments so changing the default filesystem structure isn’t advisable. If you do so please inform me so we can adjust the systems mu-plugins as well in your environment.

    Regards,

    Konstantinos

  • Matthew
    • Design Lord, Child of Thor

    You are correct on the get_template_directory_uri, I figured out I had hard-coded the value elsewhere (to workaround this issue) which was causing that and other functions to return the ‘wrong’ path.

    The only filesystem structure change I’ve made is to rename the wp-content dir to app. This is to match the structure at my old host.