Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#7050 closed defect (bug) (fixed)


Reported by: msi08 Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version: 2.6
Component: General Keywords: has-patch tested
Focuses: Cc:


I am using WP in a different folder than the domain root. There is a problem with the Theme's path and stylesheet. I fixed it with this line

define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');

"siteurl" instead of "home". A patch is attached.

Attachments (2)

wp-settings.diff.php (549 bytes) - added by msi08 7 years ago.
7050.patch (580 bytes) - added by ionfish 7 years ago.

Download all attachments as: .zip

Change History (11)

@msi087 years ago

comment:1 @Viper007Bond7 years ago

  • Keywords has-patch added
  • Milestone set to 2.6
  • Version set to 2.6

Looks good to me.

@ionfish7 years ago

comment:2 @ionfish7 years ago

  • Keywords tested added

I was a bit puzzled this morning when my site's stylesheet disappeared, looks like this is the culprit. Attached a patch without the .php filename so the Trac syntax highlighter picks up on it.

comment:3 @sambauers7 years ago

I wrote the original patch. In my setup the blog lives in root but the wordpress files live in a directory called "wordpress" and the original code worked fine for me. It still works after this patch too.

comment:4 @ryan7 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [8006]) Use siteurl instead of home. Props msi08. fixes #7050

comment:5 @ktdreyer6 years ago

This breaks our Wordpress setup, because we need stylesheet_url() to return a URL from get_option('home'). Our siteurl is an internal-access only server, so stylesheet_url() never loads for our public URL in get_option('home').

I don't want to re-open this since I'm new to WP's Trac, but am I understanding this correctly? If "siteurl" should be location of the admin interface, and "home" should be the public-facing URL, why use "siteurl" here?

Incidentally, we had to patch get_bloginfo('pingback_url') to draw from get_option('home') for similar reasons.

comment:6 follow-up: @DD326 years ago

you'd be better off filtering the links at some point to replace the public url with the private url.

get_option('home') doesnt always reflect the installation path, ie, for me:

get_option('home') = http://dd32.id.au/
get_option('site_url') = http://dd32.id.au/wordpress/
(wp-content is http://dd32.id.au/wordpress/wp-content/ not http://dd32.id.au/wp-content/

comment:7 in reply to: ↑ 6 @ktdreyer6 years ago

Replying to DD32:

you'd be better off filtering the links at some point to replace the public url with the private url.

Thanks for the reply. Our problem is that internal links are showing up in the external site, so we'd actually want to replace the private URLs with the public URL.

Here is our setup:

get_option('home') = https://internal.example.com/press/
get_option('siteurl') = http://www.example.com/press/

So our wp-content is at both https://internal.example.com/press/wp-content/ and http://www.example.com/press/wp-content/ . Is there a way we can make WP_CONTENT_URL more robust for our setup?

comment:8 @ktdreyer6 years ago

  • Cc ktdreyer added

comment:9 @DD326 years ago

You'll be best adding a filter to the option_home and option_site_url filters (You'll need to check theaccessing exact format of that filter..), And checking based on the IP address thats accessing it.

ie. if internal user is accessing, change it to internal.example, else leave as www.example

Another option might be to filter on site_url() in hope that the rest of WP uses it (Which i think it is used in many places)

Note: See TracTickets for help on using tickets.