Stopped working on new WP image file structure

Glad to help:

“because the file structure being called does not match the installation files for WordPress.”

Can you elaborate a bit more on this? I tried reading that page you linked, but could find anything specific about WordPress file paths. And why they would even think about modifying, etc.

Basically in order to resolve any issue, I need to know how to repeat the error on *default WordPress*. Bitnami is not something I am too familiar with or can support (just not enough time in the day). But if you can provide a specific error message, or something that describes more technically the issue at hand, I will do my best to investigate and try to implement a solution in a future update.

Hi Jeff,
Thanks for getting back to me. Okay so it’s probably worth my noting that Amazon EC2, Oracle Cloud, Azure and Google Cloud all use bitnami stack packages to install WordPress. More details about what bitnami does are on Wikipedia: https://en.wikipedia.org/wiki/Bitnami

Up until about 2 months ago the stacks were effectively the same as a self install direct from WP. But as a result of a bunch of security issues, many host servers offering a kind of wizard-based install of WordPress as a default webhosting package (or pre-installation), have elected to explore a different base file structure for WordPress. Bitnami is one of these.

The most significant change is that the wp-content directory is placed in a completely different subdirectory of the server, and only a shortcut or virtual directory is placed in the same directory as wp-includes and wp-admin. This is essentially breaking everything. Existing installations will be fine. Any new installations are having massive issues with the functionality of plugins because so many script functions have hard-coded directory references that don’t exist under the new file structure.

It’s a complete ballache. I mean, I get it. It’s designed to sequester wp-content from the wp-admin directory specifically to act as a barrier to any security breaches which might be designed to take control of the installation. But it means effectively recoding a lot of plugins.

This is just a heads-up. Much as I would like this issue to be resolved, I don’t have high expectations that every plugin author is going to commit to rewriting their plugin functions just yet. And because there will be different installations for some time – probably years – it’s not going to be resolved any time soon. But over time this new file structure will probably become the norm, and some hosts are likely to require its use as a security policy.

Sorry to be the bearer of this bad news, but as we install multiple WP instances all the time, it’s something we’ve discovered the hard way!

Thank you for the information. So it sounds like this is the crux of the issue:

the wp-content directory is placed in a completely different subdirectory of the server

Would it help if I added a filter hook that enabled you to specify the location of /wp-content/? That should resolve the issue, unless there is some other/better way.

That would be brilliant! Yes please! Thanks for your kindness ??

Just to follow up with this. I tried implementing a filter for the file path, but it won’t run before WordPress is loaded. So it’s not possible at this time, unfortunately. I thought it would work, should have tested first before suggesting. Apologies @jjdisruptor.

Really appreciate you following up Jeff. Thanks for trying!
Kind regards,
jj