whitemw

Good news problem solved. I went to PHP 7.2.22. After trying to update Mysql to default to utf8 that did not change anything so I punted. I was trying to stay in the Centos 7 distributions but they were just too old to keep my WordPress up-to-date. I already had Mysql 8.0 and thinking back that happened because Lentos 7 defaults to Marian DB. Heck I retired from Oracle and also worked for Sun must use Mysql for that reason, my neurosis. So being new to Centos didn’t’t really know how to control software versions so I got 8.0. In this exercise I learned all that which is really critical going forward. Still wondering why php 5.4 worked and 5.6 didn’t, the engineer in what’s that info but I ran out of time and had to make it work. I found an interesting web site about making php 5 work with Mysql 8.0:

https://severalnines.com/database-blog/how-run-php-5-applications-mysql-80-centos-7

I do want to thank everyone that commented on this post, each every one of you had usable and explorable information to pass on.

This really all occurred because I am a software engineer and not a sysprog. While I am well aware of software version interaction I didn’t pay attention here because this process is new to me and I am just hacking along with everyone else on this project.

But my WordPress version has been updated!

FYI I have the following in place to fix the SHA2 issue:

default_authentication_plugin=mysql_native_password

Ok, tried the remi 5.6 which didn’t help. Then I went to answer the first commenters post The WP version I am on is 5.0.1 and the Theme I’m using is Twenty Thirteen. I was not able to get the version in the admin panel because it would only display the version to upgrade to: 5.2.3 so I looked at version.php which told me the version of php and mysql I need. So I looked up the mysql version I need and it is mysql 5.6 and I have 8.0.16 so that’s not it.

After all is said and done I went back to php 5.4 and everything is working again.

Don’t think it is the rpm, still something I need to do that I don’t know about??

Will keep looking.

Ok agree with the SELinux theory. I have not set SELinux to permissive, and don’t want to. I already set the wp-content directory to a rw context and am able to update plugins and themes. So since I can’t update to 5.0 I’m thinking at least wp-admin directory needs its context changed to httpd_sys_rw_content_t. Have not had a chance to do research on directories updated. I have checked the SELinux logs but nothing, which does not surprise me because I think WP is just checking for authorization which might not create a log entry. At this point I really want to know what is blocking me and make sure I make the correct change. Going to review the code and instrument it to get the exact location it can’t write to. Took a quick look at the link you supplied regarding php-fmp. Seems like your saying it allows me to separate update permissions for WP from apache.

Will post my results after I come to a conclusion. I might have some more questions later.

Ok checked ownership in update-core.php which is the file in control during failure. Both functions report apache as the owner now. Changed the owner back to apache:apache. No change of course. Hoping to figure this out without having to instrument a bunch of code.

ownership is now root:apache

Ok I checked the user by coding a php file: <?php echo exec(‘whoami’); ?>
and ‘apache’ was the answer. So still looking.

Thanks for the update, have been working with those links and they are really good. Of course part of the process of development is sharing issues and many times that process triggers a light to come on and one did. I realized that viewing my theme through live view adds live view markup so I used live view to make sure the page would display and then activated my theme and then view the source and was very happy to see my html. It does contain some red lines, I assume attention is needed so progress has been made.

Again thanks for your post.