WordPressCytoServer

Just discovered this under Site Health / File Permissions:

Shows whether WordPress is able to write to the directories it needs access to.

The main WordPress directoryNot writable

The wp-content directoryNot writable

The uploads directoryNot writable

The plugins directoryNot writable

The themes directoryNot writable

All of the file permissions are set as follows:

d r w x r-x r-x 14 user/group

Hello,

I checked my permissions and they seem to be correct.

Thanks for the suggestion.

Not sure what else to try. There were many comments I deleted but that

didn’t really matter in this situation. I’ll keep trying.

I

It was all due to a cache not being cleared out. One log in was active the entire time and I discovered that if I logged out and then back in as the admin super user all was back in order.

This is very unusual.

Anyway, thanks and it is now resolved.

• This reply was modified 1 year, 6 months ago by WordPressCytoServer.

I see from searching for this type of error message that it is not uncommon and is easily fixable.

I will reply after resolution.

Would the cause of the 403 message be due the permissions now set at 755?

I wouldn’t know of any specific security measures or how to troubleshoot that.

Thank you

Hi Niall and JNashHawkins and all who replied,

RESOLVED. There was a much deeper issue at play with this Plesk

‘hijacking’.

Without the properly configured nginx and php configuration files this

problem could never have been resolved as I posted it.

Specifically, the source of this problem was random previously unnoticed

duplicate blocks/snippets of the same code in the

**/etc/nginx/conf.d/YOURDOMAINNAME.conf** file.

Also, in this same config file was added a line of code to **listen for

port 80 ( in addition to listen to 443 for ssl )**

See below.

Here is WHAT NEEDS TO BE AT THE **HEAD OF THE DOMAINNAME.CONF** FILE

server {
    listen 80;
    listen 443;

    ssl_certificate /etc/letsencrypt/live/YOURDOMAINNAME.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/YOURDOMANNNAME.com/privkey.pem; # managed by Certbot

   server_name  YOURDOMAINNAME.com www.YOURDOMAINNAME.com;

I am sure this would never have been addressed but fortunately with my

keeping up with the configuration files by comparing an already

successfully installed other domain with the

in process not yet installed site paid off.

No more Pesky Plesky default page. Hooray.

If you could enlighten me a little on WHY or HOW Plesk’s default page was directed to

that would be great. Just a general idea would be NTK.

Jerry

Niall, I think I will contact Digital Ocean support.

Thank you again.

Jerry

Hi Niall,

This did not change the problem.

At this point I an thinking of
reprovisioning the site.

Have you other suggestions?

Thank you.

Jerry

JNashHawkins,

I added a second A record for ‘bhingssweets.com’
and still Plesk problem remains.

Also tried adding a CNAME record but error message
says “cannot share a name with another record.”

Jerry

Niall, thank you for the suggestion.
I attempted this fix without a change to
the current situation.

Checked my WP Dashboard and I don’t have
any caching plugins installed either.

Jerry

All who replied to myquestion, I resolved this by deleting the droplet and reinstalling the mysql, nginx and php7.2-fpm services.

It was the only option left after many attempted workarounds.

The problem is no longer a problem.

Thank you.

Thank you dwhite.
I tried changing the permissions with no luck.

At this point, I think it may be a MySQL issue.

I will attempt to re-install MySQL and WordPress and see what happens.

Here is my current permission on the directory that contains the
source file wp-config.php that is the installer.

drwxr-xr-x 9 sweetbhing www-data 4.0K Aug 21 14:59 wp-admin

What user would I be if I am using a form on the internet?
Possibly www-data?

Sounds like trying to change sweetbhing to www-data would help?

Thanks.

Yes, on numerous attempts.

No such thing as a ….

I’m wondering if there is any way out of this pickle without nuking the

droplet and creating a new one from scratch.

• This reply was modified 4 years, 3 months ago by WordPressCytoServer. Reason: Anecdotal comment

I checked into the install.php file in wp-admin and
this is the point in that file where I am running up against
this install stopping point.

Can anyone explain this and what needs to be done to
fix this error in the form submission?

// Check email address.
$error = false;
if ( empty( $user_name ) ) {
// TODO: Poka-yoke.
display_setup_form( __( ‘Please provide a valid username.’ ) );`
$error = true;

• This reply was modified 4 years, 3 months ago by WordPressCytoServer. Reason: formatting