REST API with Bedrock

bedrock
1

Having an issue where any install of Bedrock causes failures for the REST API.

#### The REST API encountered an unexpected result Performance

The REST API is one way that WordPress and other applications communicate with the server. For example, the block editor screen relies on the REST API to display and save your posts and pages.

When testing the REST API, an unexpected result was returned:

REST API Endpoint: http://xxxx.xxx/wp-json/wp/v2/types/post?context=edit
REST API Response: (500) Internal Server Error

This seems to boil down to permissions, as accessing the URL directly returns:

code	"rest_forbidden_context"
message	"Sorry, you are not allowed to edit posts in this post type."
data	
status	401

This occurs for WooCommerce api calls as well.

Is there something I missed in the docs?

2

Weird. REST API largely worked out of the box for me with Sage 10 + Bedrock. Are you using Sage 10 or something else?

Do you make any changes to the API with a hook or something?

Has it worked before or has it always been broken?

3

Yeah, it’s a super strange bug. I’m not using SAGE (will test that shortly), I’m using a super barebones starter (basically just the required files (index.php, functions.php, styles.css .etc)

This is a fresh Bedrock install, so no API changes. Other standard WP installs work fine. It’s as though there is some disconnect between the connection - the fact it says I don’t have permission despite Super Admin privileges leads me to believe there is something happening there.

If navigating too quickly, a database connection error can occur, but only briefly - see below:
chrome_yLvOa4xg4X

(If upload doesn’t work, see image at: https://ibb.co/hRfG3wrK

4

So according to the message in the screenshot, an internal server error occurred. The underlying issue should be therefore in the log.

Doing the request using a browser as shown in screenshot does not reproduce requests from WordPress on server-side.

5

Yeah, I figured it could be a SQL issue. Too many connections etc. However, nothing makes it to the log (other than a self-signed SSL warning for another dev site)

--- on 2025-03-04 00:20
2025-03-04T00:20:14.593379Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-03-04T00:20:14.742880Z 0 [System] [MY-010116] [Server] c:\wamp64\bin\mysql\mysql8.3.0\bin\mysqld.exe (mysqld 8.3.0) starting as process 22584
2025-03-04T00:20:14.760835Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-03-04T00:20:14.961692Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-03-04T00:20:15.280914Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2025-03-04T00:20:15.281350Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2025-03-04T00:20:15.318598Z 0 [System] [MY-010931] [Server] c:\wamp64\bin\mysql\mysql8.3.0\bin\mysqld.exe: ready for connections. Version: '8.3.0'  socket: ''  port: 3306  MySQL Community Server - GPL.
6

Between this and your other posts, I’m starting to think something is weird with your environment. Have you considered modernizing with something like https://herd.laravel.com/? You can use the free version on Windows alongside https://dbngin.com/ for a decent setup.

7

Yes, that does seem to be the issue. Could not replicate the error/issue with Herd + Dbngin. This is a bit of a problem, though.

I find this environment considerably slower. Loads that typically occur in 0.10s in WAMP are taking about 2s+ in the recommended environment. I could need to tweak the environment, but a quick AI question returned:

  • WAMP installs Apache, MySQL, and PHP directly on your Windows machine, while Herd and DBngin involve additional layers like Docker (for Herd) and the external database manager (DBngin).
  • The extra layer of abstraction and the complexity of communication between components (e.g., between your web server, database, and PHP services) can slow things down.
  • WAMP runs these services directly on the OS, giving it faster access to system resources.
8

Damn. As far as I know Herd uses native binaries on Windows so it’s sad to hear it has crap performance. It looks like there is a bit more discussion on it at Windows Herd Slow · beyondcode/herd-community · Discussion #801 · GitHub

Outside of Valet Linux with WSL2, I don’t have a ton of suggestions for Windows development. I’m not really sure what with WAMP causes this issue to begin with. :slightly_frowning_face:

9

I’m actually a bit sad as well - you introduced me to a far better UI interface! I was actually excited when I got Herd + Dbngin up and going haha.

I’m narrowing the issue down though.

On a default Wordpress install (no Bedrock), the issue with the path concatenation stemmed from here:

/**
     * Ensure that all of the storage directories exist.
     */
    protected function fallbackStoragePath(): string
    {
        $files = new Filesystem;
        $path = Str::finish(WP_CONTENT_DIR, '/cache/acorn');

        foreach ([
            'framework/cache/data',
            'framework/views',
            'framework/sessions',
            'logs',
        ] as $directory) {
            $files->ensureDirectoryExists("{$path}/{$directory}", 0755, true);
        }

        return $path;
    }

Specifically: $path = Str::finish(WP_CONTENT_DIR, '/cache/acorn');

Swapping WP_CONTENT_DIR for just '' got rid of the path concatenation issue. Now, this is more closely related to my other post, but at least it is progress.

10

Back on Windows I used Lando on WSL2, works well and much faster than my old setup. Very easy to setup too