CDN image does not reflect in generated CSS
-
Hi there,
It seems that the CDN URL is not used in the generated/optimized CSS (the CSS file itself is on the CDN URL though). It still uses the main domain’s URL.
We use KeyCDN together with the CDN Enabler plugin. Also the “Basis CDN URL” option is set to the CDN URL in the Autoptimize settings.
What could this be?
-
Thanks a lot for the details, I’ll try to spin up another instance with that setup locally to see what’s going on.
Am I correct in understanding that the only thing you really needed to do to fix it on your end is to have a custom AUTOPTIMIZE_WP_SITE_URL which “just” matches home_url() instead of site_url()?
What are you doing with the cdn filter exactly and why? (otherwise the suggestion that AO uses home_url by default instead of site_url will not suffice?)
Sorry for all the questions/nags and thanks a lot for helping me pin this down further!
I’m having a hard time replicating this exact setup/problem and need help in order to find out what’s really happening here and why.
I created a new test site (using VVV, named it subskeleton, but that’s irrelevant really), and after re-provisioning I had a stock default single site installed in
{myvvvpath}/subskeleton/public_html
.At that point,
http://subskeleton.test/
worked (withtwentyseventeen
theme), andhttp://subskeleton.test/wp-admin/
worked too, and I managed to login.So, now, to actually re-create the bedrock-like/skeleton setup, I went into the VM, cd-ed to /srv/www/subskeleton, and ran:
vagrant@vvv:/srv/www/subskeleton$ composer create-project wordpress/skeleton sub
Which installed the skeleton into
sub
. Followed further instructions and created local-config.php, set it up to match VVV’s db creds etc.Then I copied over the theme and placed it into the skeleton’s themes directory:
vagrant@vvv:/srv/www/subskeleton/sub/wp-content$ cp -af ../../public_html/wp-content/themes/twentyseventeen themes/ vagrant@vvv:/srv/www/subskeleton/sub/wp-content$ cd themes/ vagrant@vvv:/srv/www/subskeleton/sub/wp-content/themes$ ll total 0 drwxrwxr-x 1 www-data vagrant 136 Nov 3 2018 ./ drwxrwxr-x 1 www-data vagrant 204 May 22 2017 ../ -rwxrwxr-- 1 www-data vagrant 0 May 22 2017 index.php* drwxrwxr-x 1 www-data vagrant 748 Nov 3 21:11 twentyseventeen/
So, now I proceed to make the switch so
sub
becomespublic_html
(as that is where nginx is serving the site from):vagrant@vvv:/srv/www/subskeleton$ ls -la total 12 drwxrwxr-x 1 www-data vagrant 340 Nov 3 21:21 . drwxrwxr-x 1 www-data vagrant 272 Nov 3 21:11 .. drwxrwxr-x 1 www-data vagrant 442 Nov 3 21:11 .git -rwxrwxr-- 1 www-data vagrant 46 Nov 3 21:11 .gitignore drwxrwxr-x 1 www-data vagrant 136 Nov 3 21:11 log drwxrwxr-x 1 www-data vagrant 170 Nov 3 21:11 provision drwxrwxr-x 1 www-data vagrant 748 Nov 3 21:11 public_html -rwxrwxr-- 1 www-data vagrant 2878 Nov 3 21:11 README.md drwxrwxr-x 1 www-data vagrant 476 Nov 3 21:24 sub -rwxrwxr-- 1 www-data vagrant 17 Nov 3 21:11 wp-cli.yml vagrant@vvv:/srv/www/subskeleton$ mv public_html/ public_html_old vagrant@vvv:/srv/www/subskeleton$ mv sub public_html vagrant@vvv:/srv/www/subskeleton$ ls -al total 12 drwxrwxr-x 1 www-data vagrant 340 Nov 3 2018 . drwxrwxr-x 1 www-data vagrant 272 Nov 3 21:11 .. drwxrwxr-x 1 www-data vagrant 442 Nov 3 21:11 .git -rwxrwxr-- 1 www-data vagrant 46 Nov 3 21:11 .gitignore drwxrwxr-x 1 www-data vagrant 136 Nov 3 21:11 log drwxrwxr-x 1 www-data vagrant 170 Nov 3 21:11 provision drwxrwxr-x 1 www-data vagrant 476 Nov 3 21:24 public_html drwxrwxr-x 1 www-data vagrant 748 Nov 3 21:11 public_html_old -rwxrwxr-- 1 www-data vagrant 2878 Nov 3 21:11 README.md -rwxrwxr-- 1 www-data vagrant 17 Nov 3 21:11 wp-cli.yml
As expected, this results in a 403 forbidden http response when going to http://subskeleton.test/
At this point, I follow further instructions from the WordPress.Skeleton readme (https://github.com/ttskch/WordPress.Skeleton#usage) about setting the DocumentRoot to /wp/:
vagrant@vvv:/srv/www/subskeleton$ sudo nano /etc/nginx/custom-sites/vvv-auto-subskeleton-provision-64948181a27c6ccea00e009cf3bbfd12.conf vagrant@vvv:/srv/www/subskeleton$ cat /etc/nginx/custom-sites/vvv-auto-subskeleton-provision-64948181a27c6ccea00e009cf3bbfd12.conf server { listen 80; listen 443 ssl; server_name subskeleton.test; root /srv/www/subskeleton/public_html/wp; # Nginx logs error_log /srv/www/subskeleton/log/error.log; access_log /srv/www/subskeleton/log/access.log; # This is needed to set the PHP being used set $upstream php; ssl_certificate /vagrant/certificates/subskeleton/dev.crt; ssl_certificate_key /vagrant/certificates/subskeleton/dev.key; # Nginx rules for WordPress, rewrite rules, permalinks, etc include /etc/nginx/nginx-wp-common.conf; } vagrant@vvv:/srv/www/subskeleton$
I reload nginx after that for changes to take effect:
vagrant@vvv:/srv/www/subskeleton$ sudo service nginx reload * Reloading nginx nginx [ OK ]
And, this is where I’m stuck — Both the home(url) and siteurl are identical, site works, I can log in to wp-admin just fine, I can poke around with wp-cli… Clearly this is not the situation you’re describing.
What’s missing? Why does home(url) have to be different? Are we talking about a multisite setup of some sort? Which kind/type of multisite exactly?
Trying all this out, I even went back and undid the /wp/ “hiding” (meaning, I re-configured nginx to serve from public_html/ and changed siteurl to include /wp/):
vagrant@vvv:/srv/www/subskeleton$ sudo nano /etc/nginx/custom-sites/vvv-auto-subskeleton-provision-64948181a27c6ccea00e009cf3bbfd12.conf vagrant@vvv:/srv/www/subskeleton$ sudo service nginx reload * Reloading nginx nginx [ OK ] vagrant@vvv:/srv/www/subskeleton$ wp vagrant@vvv:/srv/www/subskeleton$ wp option get siteurl http://subskeleton.test vagrant@vvv:/srv/www/subskeleton$ wp option get homeurl Error: Could not get 'homeurl' option. Does it exist? vagrant@vvv:/srv/www/subskeleton$ wp option get home http://subskeleton.test vagrant@vvv:/srv/www/subskeleton$ wp option set siteurl http://subskeleton.test/wp/ Success: Updated 'siteurl' option. vagrant@vvv:/srv/www/subskeleton$ wp option get home http://subskeleton.test
This all then makes the site work at
http://subskeleton.test/wp/
(and /wp/wp-admin/) but how do I now get any content (other than the default 403 forbidden nginx response) to show up onhttp://subskeleton.test/
? I mean, how do I get it to show up in that exact setup? Do I have to manually load WP in some way? Which way exactly?Anyway, thanks for any extra info you might provide…
Thanks for al the work! About your setup:
Do you have WordPress now installed in a separate/wp/
directory?Indeed, we’re using a multisite (subdir) with domain mapping (but that’s irrelevant π ).
Please have a look at this guide: https://blog.thamaraiselvam.com/how-to-install-bedrock-in-local-nginx-server-3bb27ba58ca1 (Bedrock uses the same setup)
Maybe that will work for you?Ok, that helps, thanks.
Yes, WP is installed in a separate /wp/ dir.I added index.php into document root, which just loads wp, same as bedrock’s web/index.php:
<?php /** WordPress view bootstrapper */ define('WP_USE_THEMES', true); require __DIR__ . '/wp/wp-blog-header.php';
And then I turned on Autoptimize’s CSS optimisation + added font cdn filter + set cdn to
//cdn.subskeleton.test
.Default theme appears to work (after setting up cdn.subskeleton.test dns in /etc/hosts + making nginx respond to cdn.subskeleton.test too).
Two constants are/were needed in wp-config (or whatever is customizing the config and then actually loading wp-config.php):
define('WP_CONTENT_URL', 'http://subskeleton.test/wp-content'); // This is custom, specific to WordPress.Skeleton setup that was initially mentioned. Bedrock uses something different, but similar... define('AUTOPTIMIZE_WP_SITE_URL', 'http://subskeleton.test'); // home_url() equivalent
Without those (first of which is already taken care of by bedrock probably automatically), AO is indeed getting the subfolder /wp/ within the urls that it builds, but this is expected, due to its site_url() usage (whether this can be safely changed to use home_url() instead… I don’t know (yet). It’s been like this forever, and it hasn’t changed, so it shouldn’t be the main cause of this (potential) regression.
Next step will be to create a child theme based on twentyseventeen and shove some local fonts into it and see what else is going on here…
- This reply was modified 6 years ago by zytzagoo. Reason: code blocks
Ok, created child theme and still cannot repro (after installing https://wordpress.org/plugins/selfhost-google-fonts/) — In my case the fonts are working…
<link rel='stylesheet' id='twentyseventeen-fonts-css' href='//cdn.subskeleton.test/wp-content/cache/autoptimize/css/autoptimize_single_eaa6ba9c0c0b19790f4a6450d72e7e43.css' type='text/css' media='all' />
And the contents of that css file are here: https://pastebin.com/KjLkuPJ1
But, it could be something further specific to your theme/css — I haven’t yet tried actually placing the fonts within the theme folder and referencing them from child style css using a relative path such as
../fonts/filename.woff
etc… Gonna go try that next.Tried self-hosting fonts in folder inside child theme, that works just fine too.
While doing it, realised that the only thing I really needed to change is set WP_CONTENT_URL in local-config.php since that’s what’s custom in WordPress.Skeleton (and so, in Bedrock, there really should be no need for modifying anything, it works out of the box according to my tests…)
Here’s the 2017 child theme I used: https://file.io/yEVbov
At least for single site. Multisite might be different, but I’m not entirely sure which parts would exactly be different? (meaning, different with regards to the things we’re talking about here, and what appears to be “broken” in some way…)
You mentioned you filter several things related to AO cdn-ing and whatnot… perhaps some of the problems you’ve encountered are somehow self-induced?
I really don’t know where else to look and how to reproduce the error?
As soon as WP_CONTENT_URL is defined properly, the
/wp/
“prefix” is no longer present in AO-generated css/js URLs (and the corresponding CDN-rewritten urls).First of all: I appreciate all the effort you’re putting in this!
That being said, I think we’re touching such a edge-case scenario, that we should wonder ourselves this should be fixed within the plugin, also because you can’t reproduce it.
Also I do have a solution already which is fine by us to use. When we (or you) encounter this in another setup, we know what to do.
But maybe we’d just leave this be for now and consider it as a “wontfix” π
Okey-dokey, thanks for all the help along the way and for all the info you provided!
- The topic ‘CDN image does not reflect in generated CSS’ is closed to new replies.