#7050 closed defect (bug) (fixed)
Patch for WP_CONTENT_URL
Reported by: | 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)
Change History (11)
#2
@
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
@
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.
#5
@
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:
↓ 7
@
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
@
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?
#9
@
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)
Looks good to me.