Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#7050 closed defect (bug) (fixed)

Patch for WP_CONTENT_URL

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

Description

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 17 years ago.
7050.patch (580 bytes) - added by ionfish 17 years ago.

Download all attachments as: .zip

Change History (11)

#1 @Viper007Bond
17 years ago

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

Looks good to me.

@ionfish
17 years ago

#2 @ionfish
17 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.

#3 @sambauers
17 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.

#4 @ryan
17 years ago

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

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

#5 @ktdreyer
16 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.

#6 follow-up: @DD32
16 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/

#7 in reply to: ↑ 6 @ktdreyer
16 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?

#8 @ktdreyer
16 years ago

  • Cc ktdreyer added

#9 @DD32
16 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.