Why is nothing in an EEv4 WordPress installation in the place all plugin developers expect, and where it used to be in EEv3???
Two of the WordPress plugins I have installed expect basedir to be in “/var/www/htdocs/” which means they both fail on installation.
Is this a bug or a feature and if so, how do I handle it? Is it a question of rewriting the .htaccess file or is there some other trick buried in NginX?
@verry – did you get confused with another question which asked where the WordPress root directory is in EEv4, because that’s not an answer to my question. Not even close. Plugin developers seem to be hard coding to a standard NginX directory structure, which EEv4 no longer has, due I guess to Docker. So the question is, what’s the work around?
This is definitely where EE4 will be installing new WordPress installs from now on.
So either contact your plugin developer or find a plugin that doesn’t hardcode a directory structure in a simple WordPress plugin (that sounds unprofessional in the first place)
Or, you could go through the code of said plugins and make the directory structure changes yourself
I understand that’s where WordPress installs from now on, but I am still getting an error message.
The plugin in question is Amazon Associates Link Builder by developed by Amazon.
The latest version lets me set the download folder. This folder will be used to save files downloaded by the plugin (e.g. The MaxMind IP2Country Database) for local use.
The Absolute path is required. Default value: wp_upload_dir()['basedir'] 'amazon-associates-link-builder/'
But when I use /opt/easyengine/sites/seatingatwork.com/app/htdocs/wp-content/uploads/amazon-associates-link-builder/ it fails with the following error message ~
ERROR - WordPress does not have permissions to write to the “Downloads Folder” (/opt/easyengine/sites/seatingatwork.com/app/htdocs/wp-content/uploads/amazon-associates-link-builder/). Please grant permissions or pick a different folder from the Amazon Associates Link Builder plugin’s settings page, otherwise your links to Amazon might not display correctly.
The permissions and ownership are the same for that directory as all the other WordPress directories [www-data 40755], so that’s the question I need to answer.
Any ideas?
Now I have another example. I try to load the GeneratePres child theme and I get this…
Warning : mysqli_real_escape_string() expects parameter 2 to be string, array given in /var/www/htdocs/wp-includes/wp-db.php on line 1102
When you mention that you use /opt/easyengine/sites/seatingatwork.com/app/htdocs/wp-content/uploads/amazon-associates-link-builder/ are you hardcoding that in the plugin’s options?
What if you simply use amazon-associates-link-builder/ so that the actual path becomes
wp_upload_dir()['basedir']. 'amazon-associates-link-builder/'
Nope, thanks, but that didn’t work either. Same problem. Different URL (amazon-associates-link-builder/) in the error message.
Check your wpconfig.php and make sure no directories are hardcoded. This is not normal with generatepress I use it. This is not an issue with the plugins, somewhere else you have the directory hardcoded in wordpress settings. Wordpress can be stored anywhere /var/www/htdocs is just one possible place, no plugins would work if this was required.
Nope, that’s one of the places I checked first. I’ll just need to keep on looking.
Now that I’m trying out the latest easyengine I’m having the same issue as you with a plugin, and my site previously didn’t run on /var/www/ so it can’t be anything to do with my wordpress that I’m migrating. I was noticing under the sites /config/nginx/conf.d/main.conf it has this root /var/www/htdocs; But changing that breaks the site. Anyone have any ideas?
Hi All,
Sorry for inconvenience you faced. We are unable to reproduce issue.
Any code must not reply on absolute path as they can change.
From WordPress perspective - it is installed in /var/www/htdocs/. This is for each EE site. They all think they are only site running on the server!
If you need to poke around filesystem from WordPress perspective, we recommend using jumping into a site specific shell by running:
ee shell example.com
I am curious about this issue and we will be happy to fix it on a high priority if it needs any change in EE codebase.
Thanks for jumping in Rahul.
Here’s a funny thing. I updated the RC2 install to the full release and still found the same problem.
So, I changed the directorey back to /var/www/htdocs/ and it worked. No permission problem any more!
No idea what fixed it but its solved for me by changing the directory back to the one WordPress things its looking at rather than the one it really is, if that makes sense.
That’s because WP runs inside a Docker container; it has its own filesystem (think of Docker as a special kind of virtualization).
The physical path (where you store your files, and so on) relates to the host system; /var/www/htdocs is the same for every WP because every one of them has it’s own filesystem; from inside de container, /var/www/ is mounted on top of the physical directory of the host.
Actually, it shouldn’t be a problem. But who knows how programmers think?
I think our problem is just because of a misunderstanding of how easyengine is working, the plugins report that they can’t write to /var/www/htdocs, so I assumed the error was because it was trying to write to the wrong location. I found out it was actually a permission error, once I fixed it the issue went away. I bet it’s the same issue for the original poster. Wordpress is just virtually installed in /var/www/htdocs so that is what the plugins report. I bet if you fix your permissions the issues will go away.
Yup, that was it. Once fixed the “wrong” path is not a problem.
I’m having a similar issue. I restored a v3 website into a brand new v4 installation and I’m getting some errors about file permissions when trying to update plugins or installing new ones.
How did you guys fixed it?
Try the nuclear option:
cd /opt/easyengine/sites/example.com
chown -R www-data:www-data app/*
Or:
ee shell example.com
… and chown from there.
That did the trick. Thanks