Using Folio with acorn

acorn
1

Tried using folio with acorn this weekend.

When doing wp acorn route:list I see the folio fallback route, but the code in folio that resolves routes to my pages never runs. I always get a 404 that renders the not found wordpress page.

I see that the existing 4.x acorn checks for web.php and api.php and then builds routes off of that. But it appears that folio’s addition of routes to the default Router facade a typical laravel app would resolve through the container don’t get combined with those somehow.

Any idea about how I might enable this? Basically I’d like URLs to be checked against Folio or Laravel first, then fallback to Wordpress.

2

Upon further investigation and attempts to hack both Folio and Acorn 4 to work together, it appears the problem is this:

Acorn registers a wildcard route for {any?} mapped to .* and this intercepts any Laravel fallback routes.

Folio uses a fallback route.

From my testing, it appears you can define multiple named fallback routes and they will execute in the order they’re defined.

Do you see any possibility of changing Acorn to setup the code in the registerDefaultRoute method to use a fallback route named “wordpress” instead?

It appears this would allow other fallback routes like Folio, or ones explicitly defined in web.php to work. Thoughts? Alternatives?

1 Like
3

This sounds fine. Feel free to do a PR.

4

After several approaches, I determined it’s really only possible to define one fallback route in a laravel app. And it made sense to me that rather than using that for acorn, it should be available for people to define themselves if they need it in their app. Not using a fallback route for wordpress handling also makes Folio work successfully!

So I took a crack at an approach where acorn’s request interception logic is moved into a middleware. I’m not sure what you think of this - but initial testing looks pretty good.

The way acorn works (based on my understanding) today is the laravel router is invoked through the kernel only after the entire wordpress lifecycle has finished.

This approach I came up with is a little different. It always uses the kernel to handle the request up front. Then in the middleware, if a 404 is returned (the router didn’t find a match) things are passed on to wordpress to handle rendering.

The net result is that the wordpress lifecycle of actions ends at wp_body_open (exit gets called here) for non-wordpress laravel routes. In the previous acorn, it ends at parse_request. The reason for this change, which may or may not be appropriate, is that at least in my use of acorn I’ve wanted the scripts and stylesheets to be available if I call wp_head() inside a non-wordpress blade file rendered by a laravel controller.

Anyway this is a diff of the two commits I’ve made so far to my own fork. It’s significantly different than the existing implementation, so I haven’t bothered submitting a PR yet. It seems like it could use some discussion. I know this is only for the 4.x branch - I looked at main and tried to get the wordpress processing logic to work as close to that as possible so it would be straightforward to submit a PR for both if things went that direction.