Chris

Hi threadi,

I still don’t understand enough about WordPress plumbing, however, I’m pretty sure that I have a leak. When I request

https://wp.tryx.org/wp-json/wp/v2/types/post?context=edit

with my browser, which is my 100% repeatable, minimum example, I get “401 – Unauthorized”. This happens after I delete all cookies since the beginning of time, in which case it would be true, and after I have successfully logged-in, which I believe to have been successful because I get the “Admin Dashboard” as a response. So, it’s a hard denial.

I don’t understand enough about REST API authentication, but I would expect that if a request were to determine the user was not authenticated, that the user would be challenged with a login prompt. But maybe that is not how WordPress is designed, and the unauthorized user is simply denied. In either case, I’m pretty sure that I am authenticated, so the question is why does this REST API think I am not?

Can you suggest any reason why REST API would not recognize me as having been authenticated? Or, maybe you know the code where user authentication is confirmed, and I can step through it.

Thanks for the help,

Chris.

Hi threadi,

As described above, there are 2 reasons why the update process may ask you to enter FTP access data:

• The file system is not writable for WordPress because the web server user under which WordPress is running does not have sufficient permissions.
• The FS_METHOD constant is set to exactly this behavior.

Just to drive a wooden stake through the heart of this whole “file permissions” canard, I set everything 777 and I disabled SELinux. That makes this a wide open installation. No file system restrictions whatsoever.

Your persistence and patience is to be admired. Update worked perfectly with no FTP intrusion. I am, frankly embarrassed. The site needing update was “objuan.tryx.org”, and I have been focusing my attention on “wp.tryx.org”. Regardless, update now works without FTP. However, with zero file permissions restrictions, “Themes –> Add New Theme” still produces “An unexpected error occurred. Something may be wrong with ww.wp.xz.cn or this server’s configuration. …” and updating plug-ins Produces: “Update failed: {“success”:true,”data”:{“update”:”plugin”,”slug”:”akismet”,”oldVersion”:”Version 5.0.1″,”newVersion”:”Version 5.3.3″,”plugin”:”akismet\/akismet.php”,”pluginName”:”Akismet Anti-Spam”}}”

Whudda wanna bet both of these update mechanisms rely on REST API?

Thanks for the help,

Chris.

Hi threadi,

My first question is, “If REST API is not working, how is [almost] everything else working correctly, including, specifically, The Block Editor?”. My second question is, “How does anything outside of WordPress have anything to do with WordPress REST API?”. These are not rhetorical questions designed to start an argument; these are the questions I am asking to try to determine where to look for the cause of this. It is either WordPress or it is not.

I stepped through:

public function get_test_rest_availability()

You probably know this code, so you know that it will construct this URL:

https://wp.tryx.org/wp-json/wp/v2/types/post?context=edit

and collect a lot of values that I can’t interpret, like cookies, nounce, and so on. I see a call and the return. I would have control over “cookies”, but the necessary cookies were collected. How do I have any control over any of the rest of that? How does my system configuration have any control over the rest of any of that?

When I ask for the above page with my browser, I get a message, “SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data”. Now, this is interesting, because this is exactly the same complaint I was getting before I set ‘CONCATENATE_SCRIPTS’ = false; when wp-admin and descendants were not being “styled”.

I think that error is a red herring because there is nothing syntactically wrong with the page as presented. “{” is an invalid first character of JSON data?

I have had some dialogs with WordPress REST API. Let me summarize:

• No difference between “http://” and “https://”
• GET fails with “rest_forbidden_context”.
• POST fails with “rest_no_route”.
• Neither failure is the result of a configurable condition.

$ curl -X GET http://wp.tryx.org/wp-json/wp/v2/types/post?context=edit
{"code":"rest_forbidden_context","message":"Sorry, you are not
allowed to edit posts in this post type.","data":{"status":401}}

$ curl -X GET https://wp.tryx.org/wp-json/wp/v2/types/post?context=edit
{"code":"rest_forbidden_context","message":"Sorry, you are not
allowed to edit posts in this post type.","data":{"status":401}}

$ curl -X POST http://wp.tryx.org/wp-json/wp/v2/types/post?context=edit
{"code":"rest_no_route","message":"No route was found matching the URL and request method.","data":{"status":404}}

$ curl -X POST https://wp.tryx.org/wp-json/wp/v2/types/post?context=edit
{"code":"rest_no_route","message":"No route was found matching the URL and request method.","data":{"status":404}}

I think there’s a bug here. Actually, I’m sure there’s a bug here; I’m pretty sure I have identified it. I just don’t yet know enough about WordPress to find it, but the REST API test looks like a minimal expression of the problem. You suggested I go to https://jobs.wordpress.net/, but as the URL suggests, they are looking for a job, and I am not looking to hire anyone for this personal project. If this is a bug, then I want to work with some developers to solve it. I think I can be a benefit. How do I contact developers?

Thanks for the help,

Chris.

Hi threadi,

• The directory and file permissions in your hosting are set incorrectly. WordPress cannot write here. Under Tools > Site Health you should also find a message if this is the case. In this case, contact your hoster’s support.

I find no complaints in “Tools > Site Health”. httpd runs as user “apache”. File permissions are all set appropriately and consistently over the complete site: owner apache:apache RWXR-XR-X for directories and RW-R–R– for files. All directories are labeled as SELinux context of https_sys_content_t, except wp-content which is httpd_sys_rw_content_t. These SELinux context settings permit httpd to write to wp-content and descendents and prevent writing anywhere outside of wp-content and descendents.

• The FS_MODE is set incorrectly in the wp-config.php file. Look at the file via FTP and search for something that looks like define('FS_METHOD', 'direct'); – remove this.

find /var/www/vhost/wp.tryx.org/ | xargs grep "FS_METHOD" 

… found three references and zero definitions.

Thanks for the help,

Chris.

Hi threadi,

I got distracted by who know what and I never tried your suggestion. I have since tried it and it works. It seems to me like there is a clear bug there somewhere.

As posted in the aborted and re-directed thread I did discover that setting SCRIPT_DEBUG true also corrected what ever this problem is, much to your surprise because semantically it should not do anything absent other configurations changes. Well, it does. So, it seems tome that there is clearly a bug around here somewhere.

Thanks for the help,

Chris.

James Huff (@macmanx):

This is a fresh install, so if this is caused by extensions, then there is a problem with the product, not my configuration.

threadi (@threadi)

Yes. Birds flock because it confuses predators, and bugs do likewise. I have selected a single problem to create focus. Clearly wp-admin/site-editor.php should not be complaining about jQuery not being loaded, and I suspect that this is my root problem.

• This reply was modified 1 year, 7 months ago by Chris.

Hi threadi,

In the meantime you have changed the permalinks to pretty links. They cannot be called up at all.

Yes. You mentioned “Pretty” links, so I thought it was worth probing that area to see if it changed anything. It didn’t. The failure to see anything is more likely a collision with me and xdebug. Do you have any experience debugging WordPress with xdebug?

Check whether the .htaccess file exists in the root directory and was created by WordPress. … Also check the permissions of your folders in the vhost.

It is, but changing the Permalinks did expose one problem. WordPress likes to install into sub-directory “wordpress”, which works out well. Setting DocumentRoot makes a place above wordpress to store things like the .tar.gz I had file permissions correct:

• chown apache:apache -R wordpress
• chmod 755 for directories
• chmod 644 for files
• chcon -t httpd_sys_content_t for everything except wp-content
• chcon -t httpd_sys_rw_content_t for wp-content.

I had to change “wordpress” to httpd_sys_rw_content so .httaccess could be written. I did so, and found no difference. It was clearly a misconfiguration, although one of very little consequence, generally, and of no consequence for this particular problem.

Also check whether the Apache module mod_rewrite is activated.

Done. Is and was.

Also check the error log from the server to see if any errors appear there, and if possible there should be nothing in the WordPress debug.log.

Much to my disappointment, I have never been able to find anything in wp-content/debug.log despite my efforts:

• define( ‘WP_DEBUG’, true );
• define( ‘WP_DEBUG_LOG’, true );
• define( ‘WP_DEBUG_DISPLAY’, false );
• error_reporting(-1);

I really wish I could get this working, as a further step toward diagnosing the style-sheet problem.

So, all of this could be explained by jQuery failing to load. I want to set break point there and watch what happens.

Thanks for the help,

Chris.

Thanks very much. You have been generous with your time and you have completely answered all my questions. I look forward to great improvements to my WordPress sites with your plug-in.

Thanks for the help,

Chris.