Wrong path without domain outputted results in 404 for minified files

Hi,

Can you paste a screenshot of the “server info” tab?
Is it a multisite or single installation?
What WP version are you running?
You have removed all other “speed optimization” related plugins? (you can only use one plugin to achieve the same objective, as once the overlap, they can conflict).

—

a) FVM would never intentionally output src=”//wp-content/... , only absolute urls such as src=”//yourdomain.com/wp-content/ (that’s why the double slash is enforced). This looks like your site_url() or home_url() is not defined, or has a wrong path on the database.

—

b) If some urls are being printed without wp-content/uploads/fvm on it’s path, those haven’t been processed or are part of the ignore list. Kindly read the FAQ for “Why are some of the CSS and JS files not being merged or why is my layout broken ?” at https://www.ads-software.com/plugins/fast-velocity-minify/#faq to understand why this can happen.

I would say, you or someone edited the theme and didn’t properly enqueue the files using the recommended wordpress method, therefore some paths may be wrong, or some resources might have just been added directly to the header / footer without enqueuing… in which case, those won’t be detected by FVM or other plugins.

https://developer.www.ads-software.com/themes/basics/including-css-javascript/
https://www.wpbeginner.com/wp-tutorials/how-to-properly-add-javascripts-and-styles-in-wordpress/
https://code.tutsplus.com/articles/how-to-include-javascript-and-css-in-your-wordpress-themes-and-plugins–wp-24321

If these look complicating to you, you may need to hire a developer that understands how wordpress works. Adding css and JS files to the header and footer, while it can work, will cause trouble with other plugins in the future that expect things to have been done properly.

You can fix a hole in the ceiling with tape, but when it rains next time, it’s bound to leak.

—

c) Likewise, src=”https://domain.com/wp-includes/js/jquery/jquery.js” is not being processed by FVM. I would suspect that the file, is not enqueued properly, but rather added to the header / footer directly.

—

d) For the urls that are being outputted like //wp-content/uploads/fvm/cache , look at your domain.com/wp-admin/options.php file for the home url, and site url (it can be wrong).

You can manually define the correct url, by adding this to your wp-config.php

define('WP_HOME', 'https://yourdomain.com/');
define('WP_SITEURL', 'https://yourdomain.com/');

Purge all caches (FVM, server, some other cache plugin, etc) and you should not see //wp-content/uploads/fvm/cache anymore, but rather //domain.com/wp-content/uploads/fvm/cache

If anything else, just let me know.

For the reference I’m using Microsoft Azure server that runs a docker container, that provided a slightly tuned wp-config for the cloud environment.

I did some quick digging in the wp-config and found this in the last lines, I had not noticed before:

//Relative URLs for swapping across app service deployment slots 
define('WP_HOME','https://'. filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
define('WP_SITEURL','https://'. filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
define('WP_CONTENT_URL', '/wp-content');
define('DOMAIN_CURRENT_SITE', filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

I have not had time to test stripping that away for a moment, or overriding with a traditional config, but looks like a suspect to me.

It’s probably that, but it should work as long as INPUT_SERVER, and HTTP_HOST outputs something. If those are empty, then WP_HOME, WP_SITEURL and DOMAIN_CURRENT_SITE are also going to be empty.

I suggest you define WP_HOME and WP_SITEURL manually, like I suggested on the previous post. It should not matter if you’re on Azure, docker or anything else, once you do that.

Problem turned out to be the line:

define(‘WP_CONTENT_URL’, ‘/wp-content’);

Commenting this out fixes the problems.

The default constant for this is:
define( ‘WP_CONTENT_URL’, get_option(‘siteurl’) . ‘/wp-content’);

So a relative WP_CONTENT_URL does not work apparently

@ehau that would the same explanation as https://www.ads-software.com/support/topic/no-css-file-processed-in-multisite/

Thank you!

Maybe a simple check for some variables would lower the burden of answering so many support request of similar type? ??

There are plenty of checks in place, even for different wp-content directory names and relative urls, however… when you change WP_CONTENT_URL without changing WP_CONTENT_DIR you are going to break things.

I’ll do some tests with these settings and try to work around these limitations.