404 Error Using TSML_UI on Flywheel

[bolsol]

Hi,

Thanks for a great plugin!

I'm not sure if anyone else has encountered this. I tried this on a few sites, and it only happened on sites hosted on Flywheel (managed Wordpress hosting, heavy caching, shared WP code). When using the Legacy UI everything looks OK, but as soon as I switch to TSML UI or use the [tsml_ui] shortcode I get the error, "Error: not found (404) when loading data.". This does not happen on LocalWP (local dev environment for Flywheel).

Tried different browsers and devices. Tried the "permalink" fix. Tried the "wordpress.com fix" code from this post. Tried with PHP 7.4 and 8.2. Tried with Wordpress 6.3.2 and 6.4.2.

I set up a clean site to test this out without worrying about messing up production sites or getting interference from other plugins/themes.
https://yfcdevtest.flywheelsites.com/meetings
(I can provide Administrator access - including Tools>Plugin file editor - if helpful)

When I look at the inspector/console, it shows a 404 error on this request (the random characters vary):
https://yfcdevtest.flywheelsites.com/www/wp-content/tsml-cache-0c40d9d76e.json?1702937673

Note the "/www" before "/wp-content". The cache file is there, but the plugin can't find it because of the path/url.

I'm not an expert, but I dug around a little in the code and created a temporary workaround (for the production site I needed this for), but I would love to have a more permanent (and professional :)) solution moving forward if possible. I'm not sure if this is a Flywheel issue (though I have not encountered this issue before with any other themes or plugins, or with the TSML Legacy UI), or if there is something specific to how this cache file gets accessed at runtime (it gets created just fine).

I found that the issue (the extra "/www" getting added to the url/path) was coming from the WP_CONTENT_DIR constant. I am VERY hesitant to declare/change this constant for the whole site (like I said - never had issues before, and I don't want to risk breaking anything else that may depend on it), so for now I replaced WP_CONTENT_DIR in line 140 of /includes/shortcodes.php with a hard-coded path (without the "/www") and that seems to do the trick for now.

I'm not sure if anything can/will be done about this, but I thought I'd at least bring it up so you're aware, and in case you have any permanent solutions. Or maybe I'm missing something very obvious, or a simple setting somewhere, or an entry in the documentation - but as long as it works I don't mind looking the fool for asking. :)

Thanks in advance.

Patrick

[anchovie91471]

Hi @bolsol! Sorry you're having issues. This does sound like some unexpected values for constant values on Flywheel. Do you happen to know the values of WP_CONTENT_DIR and also ABSPATH for the server that you're having issues with? We'll take a closer look.

[bolsol]

Thanks @anchovie91471. I've been in contact with Flywheel as well and they are also having a look. I echoed WP_CONTENT_DIR and ABSPATH on the page (https://yfcdevtest.flywheelsites.com/meetings) so you can see them, but here they are:

ABSPATH: /wordpress/
WP_CONTENT_DIR: /www/wp-content

[bolsol]

Here's the response from Flywheel:

The presence of /www in the path is correct, as all site-level code resides within this folder on the server. This path isn't used on the front end of the site though.

Here's a list of commonly used pathing functions, constants and variables along with their paths:

Functions:
get_home_path(): /www/.wordpress/
plugin_dir_path(): /www/wp-content/
get_theme_root(): /www/wp-content/themes
get_stylesheet_directory(): /www/wp-content/themes/themename
get_template_directory(): /www/wp-content/themes/themename

Constants:
ABSPATH (path to the WordPress core): /www/.wordpress/
WP_CONTENT_DIR: /www/wp-content
WP_PLUGIN_DIR: /www/wp-content/plugins

Variable:
$_SERVER["DOCUMENT_ROOT"]: /www

For any plugins that are unable to produce the correct path, such as by including /www in any URLs, we can add some server-side code to automatically trim out the /www segment. If you'd like this applied to the site, please let us know and we can get it added.

EDIT: I see the str_replace looks to remove the ABSPATH from WP_CONTENT_DIR, but in Flywheel's case, the paths/folder names are different ("wordpress" and "www"), so nothing gets removed from WP_CONTENT_DIR and that's probably where I'm getting the error.

I'm just wondering if that line 140 in shortcodes.php needs to be using WP_CONTENT_URL (instead of _DIR) when loading the cache file?

? WP_CONTENT_URL . $tsml_cache . '?' . filemtime(WP_CONTENT_DIR . $tsml_cache)

Instead of:

? get_site_url() . str_replace(ABSPATH, '/', WP_CONTENT_DIR) . $tsml_cache . '?' . filemtime(WP_CONTENT_DIR . $tsml_cache)

Again, I know this probably just affects my specific situation - I'd understand if this line of code affects other situations I'm not aware of.

P.

[anchovie91471]

Thanks for the update! This is really helpful!

We're looking at a code change very similar to this, but need to ensure we don't break things for other users. I'll update the ticket when we push out a fix.

[bolsol]

Awesome. Thank you for your help!

[bolsol]

Just noticed an update available (3.14.33). Tried it on the test site (and the prod site) and it works. Thanks for fixing this!

Edit: assuming we don't need to have the test site available anymore, I will delete it.

P.