aberkow

Hi @vmarko,

I’m closing the ticket. Thanks for your patience while I worked that out.

For anyone who finds this later – WP_HOME and WP_SITEURL should be set to server variables rather than defined urls (e.g. 'https://' . $_SERVER['HTTP_HOST'] rather than ‘https://site.com`). Failing to do so interferes with how paths for generic mirrors are managed. On our server due to the use of configuration files to manage multiple environments, those definitions were being set incorrectly.

Hi @vmarko,

I set up a completely clean environment locally, started from scratch, and I agree that this is likely due to a misconfiguration on the server or in wp-config.php. I think looking at the way our projects got set up, someone (not me. I promise) set WP_HOME to a defined url. When I changed it to $_SERVER['HTTP_HOST]' locally, the urls were rewritten correctly. It’s late in the day for me now but I’m going to test this change on our dev server tomorrow morning. If it checks out, I’ll close this ticket.

Thanks,
Adam

Hi @vmarko,

Sure thing, but can we do this over email or some other private channel? I’d prefer not to reveal too much in a forum.

Separately (and just for clarification) images are being served from the CDN just fine. The issue seems strictly related to theme files.

Thanks,
Adam

@vmarko

Just a quick update – I’ve started testing this issue locally in docker (PHP 8.1) with a subdomain multisite setup similar to the one on our dev/prod servers. The issue is still here with the latest version (for those finding this later, that’s 2.7.5). Today I’m going to try downgrading the plugin to see if I can narrow things down a bit.

Thanks,
Adam

Hi @vmarko

I enabled the “fix document root path” option at the network level and confirmed that it holds at the subsite level. However, the result is the same. Subsites themes aren’t having their urls rewritten correctly. Since there was no change, I had to reactivate our authentication plugin.

For reference, I get the following from wp cli

wp @dev-mysite eval 'echo ABSPATH;'
/var/www/sites/com.mysite.dev/public_html/wordpress/%                                                                                                                               

On Friday I was trying to see if I could find any issues in w3tc’s Cdn_Plugin.php and Cdn_Core.php files as well. The server I’m running the site on has xdebug available so I’ll try using that to step through the code later today or tomorrow.

Thanks,
Adam

Hi @vmarko,

Thanks for getting back to me so quickly.

I’m attaching a screenshot of the general settings CDN area and advanced settings where I’ve placed the mirror url just in case.

Here are some additional debugging steps I’ve taken

• deactivated all plugins besides w3tc (both at the network and individual site level)
• activated the w3tc debug mode to check which file urls were being rewritten and how
• checked to see if there would be a different result if I force all sites to use the same configuratin
• attempted to use different themes on the subsite (just in case there was some specific theme functionality causing an issue)
• confirmed the list of apache modules available (especially for mod_rewrite)
• manually copy/pasted the htaccess config from the network install page to the main .htaccess file. NB – we use a slightly different configuration for .htaccess on the server where it’s located at /var/www/sites/site-dir/public_html/.htaccess rather than at .../wordpress/.htaccess it’s a long story and not something I can easily change right now, but that’s why I took that step.

None of these steps have resolved the issue yet, but I’m still hopeful! Thanks so much for your help. Please let me know what other information or details I can provide.

Oh you know what… the owner/group doesmatter. The error message immediately went away after I did the following

cd /{the right directory}/wordpress
sudo chown apache:apache .htaccess

I think we might be able to close this ticket, but can you help me understand this a little better?

Hi @vmarko,

Just to clarify, the document root per apache config is /var/www/sites/com.mysite/public_html.

I set permissions for /public_html/.htaccess and /public_html/wordpress/.htaccess both to 644 with no luck. The error message remains on the admin plugin page.

Does W3TC require that the .htaccess file (wherever it is) be owned by a certain user or group?

What I’m struggling to understand is – even if W3TC itself can’t write to the file, why does the error message stay even when I update the file manually?

Thanks again for your help.

Hi @vmarko,

Thanks for getting back to me so quickly.

Here’s a sketch of our filesystem. The main things to note are that we have a custom wp-config.php file which is outside the /wordpress directory. This allows us to customize our config and push WP core changes without having to manage additional files.

/public_html
|_ /content
|_ env-config.php
|_ .htaccess (I'd like to use this one and have W3TC ignore the other or recognize this one)
|_ index.php
|_ /wordpress
|_ wp-config.php (loads config files from /wp-env)
|_ /wp-env

With this set up, we can easily manage core updates separately from our config files using jenkins to push changes.

However, even when I manually added a .htaccess file with rules at /wordpress/.htaccess, it isn’t recognized.

Hi @vmarko

Thanks for getting back to me so quickly. I only needed a few settings plus some additional flexibility. I was able to resolve this by writing a class similar to this.

<?php

use W3TC\Config;

class My_Class {
  private $config;
  public function __construct() {
    $this->config = new Config();
  }

  public function is_cdn_enabled() {
    return $this->config->get_boolean('cdn.enabled');
  }

  // other methods...
}

thanks @stevejburge

oh no! I wasn’t thinking of running them side by side. I was just thinking about how I might migrate safely for our writers and editors if I need to change the settings manually. thanks for your time ??

Hi @stevejburge thanks for getting back to me so quickly.

I went down quite the rabbit hole yesterday debugging, but couldn’t find anything definitive. I can probably recreate the current Edit Flow settings in Publish Press. There aren’t so many, I just figured I’d give the import a shot first.

Have you experienced conflicts between the plugins when they’re both active at the same time and the settings are being duplicated? I’m going to test it out, but I’m thinking about when I get to my prod server and people might be busy updating/publishing articles etc.