Forum Replies Created

Viewing 13 replies - 1 through 13 (of 13 total)
  • Thread Starter smartysmart34

    (@smartysmart34)

    Well, OK. That was too early. I just learned that it seems to eb depending on the user I am loggen in with. The last test wase based on my WordPress Admin. Publishing an article with that user works. wp-json gives HTTP 200 like here:

    [16/Feb/2026:21:12:38 +0100] “GET /wp-json/wp/v2/tags?context=edit&per_page=1&_locale=user HTTP/2.0” 200 710 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0”

    When I am logged in as the Author User, it gives a 403:

    [16/Feb/2026:21:16:43 +0100] “GET /wp-json/wp/v2/tags?context=edit&per_page=1&_locale=user HTTP/2.0” 403 144 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0”

    wp-json in general works for both users. Logged in as the Author, the autosave feature gives the following log entry (yes, this is from a day before but is still valid):

    [15/Feb/2026:00:26:54 +0100] “POST /wp-json/wp/v2/posts/5147/autosaves?_locale=user HTTP/1.0” 200 6774 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0”

    So logged in as Author, the austosave works, but publishing gives the HTTP 403 caused by wp-json on tags and categories.

    What am I missing? Which setting in wordpress or nginx could limit the Author from having wp-json successfully updating Tags and Categories while the Admin can do so? Any hint would be welcome…

    Kind regards,

    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    Puh… I just went in to the settings of the Permalinks and – without changing anything – saved them again.

    Now, when watching access.log via tail -F… I see no new HTTP 403 being generated. It seems, this solved it…

    Thread Starter smartysmart34

    (@smartysmart34)

    One more thought: Is teh json handeled on nginx level or by php-fpm? nginx is running as one user, the wordpress php code is executed under the php-fpm pool-user, which is different. So most files in the wordpress-directory are not writeable by nginx, but only owned and writeaby by the pool-user…

    Just wondering why nginx would report a 403 on a publish….

    Thread Starter smartysmart34

    (@smartysmart34)

    I received a reply from Kelvin but it does not show up here so I can not reply. Let me do it this way then.

    The suggestion was to check if REST API was enabled or not. I DO have the Disable WP REST API plugin installed and active but this is only blocking Non-authenticated REST calls. While logged in, opening the wp-json/wp/v2/posts path of my blog gives me a valid json response with the list of articles.

    When logged off, i get the error message: REST-API limited to authenticated users

    So json / REST API should work when logged in – which I am when publishing an article.

    Having said that, the suggested config entry
    location ~ ^/wp-json/ {try_files $uri $uri/ /index.php?$args;
    does NOT exist in my nginx files.

    But I also never saw this in any example configuration. Is this a must? Somehow, despite the two 403 errors in the log, the Posts actually get published… It’s just that my IP will get blocked and I can no longer connect with the same IP…

    Thank you and regards,

    Martin

    • This reply was modified 3 months, 3 weeks ago by smartysmart34.

    Mee too. No updates sent out to subscribers.

    I am wondering: Is this a free-version issue only? Because from my perspective this renders the plugin mostly useless. Ultimately that’s what it is about for me: Sending out new posts notifications.
    I can’t believe this is still not solved by now.
    Is there any other way to automatically notify sunscribers about new articles?

    Kind regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    While I was in health-check, I also ran the Checksum verification which came back OK. Plus, in the dashboard / updates section, I reinstalled the release. So my assumption would be that the code base should be fine? Otherwise I would have expected some hint about a broken download and/or a checksum error when verifying?

    Is anyone here who could tell me, which code is specifically executed / string selected from database when clicking on that “delete article” thing? And why is it fundamentally different from deleting a user or a category? By the way: also deleting a category through the mouse-hover action works fine…

    Kind regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    Quick add:
    When using the Mouse-hover->”click delete” approach for a user, it works flawlessly. The issue seems specifically related to deleting articles this way. Which leaves me even more confused…

    Thread Starter smartysmart34

    (@smartysmart34)

    Just to let you know: I installed the Plugin mentioned above and startet the debug mode.
    Kept all plugins deactivated and went to delete an article: Same issue. So the problem seems unrelated to the installed plugins.
    Any further Ideas?

    Thank you and kind regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    But given that there are quite some messages about the site breaking and I would have to run it as admin, then I would not be able to access the backend anymore?
    Or could I create another admin user and execute the plugin from there?

    Thread Starter smartysmart34

    (@smartysmart34)

    Don’t get me wrong, I did NOT attempt to install the plugin. I just went to the Tools -> Health Check entry that was added in WordPress 5.2. And the message I got was reported by that tool.

    So this is not a “plugin install failure” but something the wordpress standard check found when running.

    Maybe I first try disabling all plugins.
    Would disabling be sufficient or do they have to be deleted in order to identify which causes issues?

    Regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    Hello Davood,

    Thank you for the recomendation. I am somewhat cautious with installing a plugin that has 30% 1-star ratings. But I found the health-check which is now part of WordPress 5.2.
    When running it I got two critical issues:
    A REST-API issue with the reeor message:
    cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received

    And a “Loopback.request could not be completed”. Message:
    cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received

    Could that be potentially linked to my problem?
    Any Idea how to solve that?

    If that doesn’t lead us somewhere then my next step would be to deactivate all plugins but the miniorange 2-factor as that for me is a must.
    In order to identify whether or not a certain plugin causes issues, is it sufficient to just deactivate it, or does it need to be deleted / uninstalled?

    Thank you and kind regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    Hello Davood,

    both, WordPress-Address and Site Address are set to:
    https://soltauhome.dyndns.org/Travelblog.
    No difference there.

    The permalink is set to “Day and Name” (2nd entry from the top):
    https://soltauhome.dyndns.org/Travelblog/2019/05/16/exampleentry/
    And they work just fine, according to google search console.

    So unfortunately this does not seem to be the issue 🙁

    But thank you for your suggestions.

    Regards,
    Martin

    Thread Starter smartysmart34

    (@smartysmart34)

    That was it…
    Thank you so much!

    Kind regards,
    Martin

Viewing 13 replies - 1 through 13 (of 13 total)