The scenario:
This question relates to WordPress theme development on a local environment via MAMP.
In order to enable mobile device testing via xip.io, I have modified my local WordPress wp-config.php
file with the following:
require_once('b5f-browsers.php');
if( b5f_browser_check('mobile')) {
define('WP_HOME','http://mysite.dev.'.$_SERVER['SERVER_ADDR'].'.xip.io');
define('WP_SITEURL','http://mysite.dev.'.$_SERVER['SERVER_ADDR'].'.xip.io');
}
NOTE: Credit for this solution goes to brasofilo in this related post.
The problem:
My custom theme’s HTML head and footer blocks contain calls to CSS and JavaScript files using the standard bloginfo('template_url')
function. This works normally when browsing on the host computer.
But on mobile devices, the main site base domain as defined under WP Admin > Settings > General is used in the ‘template_url’ instead of the conditional override as specified in the wp-config.php
file above.
So I get lines like this:
<link rel="stylesheet" href="http://mysite.dev/wp-content/themes/mytheme/style.css">
Instead of this:
<link rel="stylesheet" href="http://mysite.dev.HOST-IP-ADDRESS.xip.io/wp-content/themes/mytheme/style.css">
A workaround:
Interestingly, I noticed that bloginfo('wpurl')
returns the correct xip.io URL for mobile, and other core WordPress functions such as bloginfo('rss_url')
obey the URL override. But bloginfo('template_url')
just doesn’t seem to want to do it.
So as a workaround, I am using bloginfo('wpurl')
then adding the full path to the theme directory instead:
<link rel="stylesheet" href="<?php bloginfo('wpurl'); ?>/wp-content/themes/mytheme/style.css">
But this doesn’t seem like the right way to go about it…
The question:
Is there a better/correct way to handle this?
Found the solution… the problem was due to placement of the conditional statement in the
wp-config.php
file.It needed to be inserted before the
require_once(ABSPATH . 'wp-settings.php');
line near the bottom of the default config file, otherwise the constants are already defined and cannot be redefined.So final section of the
wp-config.php
file now looks like this:My quick guess (that code is rather nightmarish to follow) would be that you need to define
WP_CONTENT_URL
as well, since issue seem to be about content directories.