In the site health check comes up with a couple of errors:
1) The?wp-content/upgrade-temp-backup?directory exists but is not writable. This directory is used to improve the stability of plugin and theme updates. Please make sure the server has write permissions to this directory
2)
Some files are not writable by WordPress:
Normally fixing these issue is a matter of changing rights and ownership from the command line, which is what I have attempted using:
find /home/admin/web/my_web_site_folder/ -type d -exec chmod 755 {} \;
find /home/admin/web/my_web_site_folder/ -type f -exec chmod 644 {} \;
This has not fixed the problems. In addition, there are other problems which are probably symptomatic of the same issue. It is not possible to upload images to the site via Workpress (although it’s no problem with FTP) and plugins will not update, failing with an error “Unable to create folder xxxx”.
I am also unable to update to the latest version of WordPress, which also fails with an error that it is not possible to create the folder.
Please help.
]]>First of all, thank you very much for having a space for our questions. I’ve been looking for a fix for about a month and I’m running out of time.
Last year I created the site inmobar.com to my digitalocean account, however, over time it was time to pass it on to its owner, so I made another account in Digital Ocean, a snapshot and then created a droplet based on this .
For a long time I thought the problem was due to poor configuration, but by making arrangements and between tickets and queries, I discovered that the site does not have problems with HTML files such as https://inmobar.com/readme.html; instead, you show problems loading the home page or any page with content.
I have found references to other migration errors regarding NGINX permalinks, I have also had experience with caching problems but none of these cases fit my case because it does not have a caching system and the NGINX configuration already worked in the previous machine and this is a copy.
So I was wondering if WordPress has a history of showing these problems, I usually use a plugin to migrate from one machine to another but I’m using a database on a cluster so said helper plugin didn’t allow me to go down that route.
I will appreciate your help to save this site before it is canceled.
]]>Not with Formidable. They know what they are doing and put the right people on the task to find a solution quickly.
]]> ------ ------------------------------------------------------------
Line wp-content/plugins/cheez/inc/admin/class-admin.php
------ ------------------------------------------------------------
80 Function plugin_dir_url not found.
80 Function wp_enqueue_style not found.
102 Function plugin_dir_url not found.
102 Function wp_enqueue_script not found.
107 Function add_menu_page not found.
108 Function __ not found.
109 Function __ not found.
126 Function add_action not found.
140 Function __ not found.
144 Function add_screen_option not found.
146 Access to an undefined property i_like_cheese\Inc\Admin\Admin::$i_like_cheese_Object.
💡 Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
146 Instantiated class i_like_cheese\Inc\Admin\i_like_cheese_Object not found.
💡 Learn more: https://phpstan.org/blog/solving-phpstan-access-to-undefined-property
A vexing situation, indeed. After quite a bit of trial and error, I ultimately realized that the function “not found” issues were a result of incorrect file permissions. The time I spent fooling around with Xdebug / PHPStan was mostly a waste, considering I should use a checklist for such a situation. That checklist should begin w/ things basic like permissions, server conf, error logs, etc. It’s not reasonable to expect that it’s just going to work, even when installing the common software in a common environment: the developer must be mindful that the possibility of a breaking oversight remains. Alas, I digress.
I thought perhaps there was an issue with my Namespace (although it was functioning properly, previously, in a different installation). That and a bit of research on $psr_4_prefix_pos (per Xdebug step debugging) led me to believe perhaps I had an error in the character cases (upper/ lower) used in my Namespace declarations. While not the cause of my errors, it’s valuable knowledge and worth learning (if you’re concerned with doing things correctly).
See: Autoloading PHP Namespaces:
“PSR-4 based Requests 2.0.0 classes in a case-sensitive manner”
https://developer.www.ads-software.com/reference/classes/wporg-requests-autoload/
Once I corrected the file/ dir permission issue, the error was gone. This is not something that I’ve encountered before, but it makes sense that WP won’t see the functions if it can’t read at the file properly, thus resulting in things being “not found”.
Cheers!
]]>It was acting wonky, locked everyone out, so I disabled and re-enabled it from command line by renaming the plugin directory.
After re-enabling it I went into the WP admin UI and into AIOWPS and reset the settings and went about re-doing them to make sure they were correct.
I manually went in via a shell and handset the permissions on the flagged files and dirs listed by AIOWPS but I think the fact it AIOWPS couldn’t do it from the admin UI points to a deeper issue.
]]>I am watching this video (at 10min mark) on how to configure the plug in.
It says to mark them all green. But my Current Permissions are about 20 higher from the Recommended Permissions (as seen here).
My question is, must I set these all to green?
Best,
Chris