WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#24740 closed enhancement (invalid)

get_option does not respect WP_HOME, WP_SITEURL

Reported by: daveagp Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5.2
Component: Options, Meta APIs Keywords: has-patch close
Focuses: Cc:

Description

I believe that get_option( $option ) in option.php should use WP_HOME and WP_SITEURL when they are available. This would involve adding 4 lines,

   // about 10 lines into the function
        if ($option == 'home' && defined('WP_HOME'))
          return WP_HOME;
        if ($option == 'siteurl' && defined('WP_SITEURL'))
          return WP_SITEURL;

        if ( defined( 'WP_SETUP_CONFIG' ) ) // old code continues here

The reason this is really important is that there is no way to run a development site and a live site without doing hacks to core code or a pseudo-hacky drop-in replacement for db.php. See the discussion of line numbers in http://codex.wordpress.org/Running_a_Development_Copy_of_WordPress#Using_a_Drop-In for the details of why no non-hacky solution (such as filters) can work. But if we make this enhancement, then it is a simple matter of development sites defining these values within their wp-config.php which to me is the most satisfying and non-hacky approach.

Feedback is welcome on the exact best location within get_option to place this logic.

Change History (8)

#1 @nacin
7 years ago

  • Component changed from General to Options and Meta

#2 @nacin
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Hi daveagp, get_option() is filtered to use WP_HOME and WP_SITEURL when they are defined. See _config_wp_siteurl() and _config_wp_home().

#3 follow-up: @anubisthejackle
6 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

@nacin I'm getting a similar situation.

To replicate:

  • Take a live site and copy to localhost
  • Define WP_SITEURL in wp-config.php
  • Without logging in, visit /wp-admin

The redirect will be to [live site]/wp-login.php or the equivalent defined login page.

I understand that most other places in the code WP_SITEURL (can't speak to WP_HOME) is handled properly, but this one gets me constantly.

#4 in reply to: ↑ 3 ; follow-up: @SergeyBiryukov
6 years ago

  • Keywords close added
  • Milestone set to Awaiting Review

Replying to anubisthejackle:

  • Take a live site and copy to localhost
  • Define WP_SITEURL in wp-config.php
  • Without logging in, visit /wp-admin

You should define WP_HOME as well.

#5 in reply to: ↑ 4 @anubisthejackle
6 years ago

Replying to SergeyBiryukov:

Replying to anubisthejackle:

  • Take a live site and copy to localhost
  • Define WP_SITEURL in wp-config.php
  • Without logging in, visit /wp-admin

You should define WP_HOME as well.

I just checked my code to verify, and found that we are:

define('WP_SITEURL', 'http://site.localhost/');
define('WP_HOME', 'http://site.localhost/');

#6 @SergeyBiryukov
6 years ago

If WP_SITEURL and WP_HOME are set, I cannot reproduce the redirect to the live site login page on a clean install.

#7 @anubisthejackle
6 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Thinking I've tracked the culprit down to sunrise.php.

#8 @DrewAPicture
6 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.