Using Intertia.js with WordPress server-side

[coccoinomane]

Has anybody tried, or is it against nature? 😅

I am thinking of a WordPress theme where the PHP templates fetch their data from the DB using standard WordPress API (get_post, WP_Query...) and then call Inertia::render().

I guess it would be faster than using WordPress REST APIs from the client...

Thank you! Guido

[lkraav]

Join #inertia https://discord.gg/XZw9QP I just recently kicked off the discussion there.

[coccoinomane]

Thank @lkraav! I have written on Discord about it :-)

[ajgagnon]

Might not be a good idea for WordPress front-end as it's not rendered server-side (for SEO reasons?). Unless you all are talking about on the WordPress Admin?

[coccoinomane]

Hi @ajgagnon, thank you for your contribution!

WordPress themes classically render pages server-side using the WordPress template system and use Javascript mainly for DOM manipulation via jQuery. WordPress template files are just PHP files that extract data from the database using the WordPress internal API and then echo the HTML.

The release of the WordPress REST API in 2016 and, more recently, of the WordPress GraphQL API made it possible to build pure Javascript frontends, in a setup which is called Decoupled WordPress; as an example, please refer to this guide on how to implement headless WordPress with Gatsby.

As far as I am concerned, I found the following barrier in adopting headless Wordpress: you have to implement a lot of features that WordPress already handles quite well, such as routing, authentication, authorization, data fetching... this was what prompted me to ask about a WordPress adapter for Inertia.js 🙂

[ajgagnon]

Thanks for the reply @coccoinomane! I am familiar with decoupled WordPress, but even for things like Gatsby, you'd want SSR, right? Otherwise I believe your site could suffer and SEO penalty since it requires JS to render. Google can parse SOME javascript, but it's unclear how much. Google isn't the only search engine, too.

[lkraav]

It'd probably be prudent to discuss JS-rendering SEO implications in another forum, since at minimum, SEO is not even required for some (intranet) apps. Let's keep this issue for the actual integration implementation concern.

[reinink]

So yeah, I tend to agree with some of the comments here that suggest using Inertia with WordPress (should it even be possible) isn't probably a great idea, because of the lack of server-side rendering.

If anyone ever wants to take a crack at making this work, great, but I think I'm going to close this issue for now, since I don't see this going anywhere any time soon.

Thanks everyone for your interest in Inertia.js! 🙌

[lkraav]

So yeah, I tend to agree with some of the comments here that suggest using Inertia with WordPress (should it even be possible) isn't probably a great idea, because of the lack of server-side rendering.

:question: I'm not sure what "lack of server-side rendering" means here. As far as I can tell, WP is nothing but a server-side rendered app :)

Can we keep this issue open for a while longer, so more interested parties could find it better? I still have a hunch there's a way to make it work.

[ajgagnon]

So yeah, I tend to agree with some of the comments here that suggest using Inertia with WordPress (should it even be possible) isn't probably a great idea, because of the lack of server-side rendering.

❓ I'm not sure what "lack of server-side rendering" means here. As far as I can tell, WP is nothing but a server-side rendered app :)

Can we keep this issue open for a while longer, so more interested parties could find it better? I still have a hunch there's a way to make it work.

Yes, WordPress is server-side rendered, but Inertia is not. Inertia passes server data as props to Vue/React components. Vue/React components are rendered in the browser. So basically if you visited an Inertia page with JS disabled in your browser, you'd see nothing.

That being said, maybe there's a good place for it on the WP Admin or for intranet applications? I could see this being great for creating WordPress settings pages or for apps that don't need SEO.

[boxybird]

@coccoinomane Your thoughts on using get_posts() with Inertia::render() are right on the money. It's 100% possible. I built a WordPress plugin that does just that, and more: https://github.com/boxybird/wordpress-inertia-plugin

A little demo using the plugin: https://github.com/boxybird/wordpress-inertia-demo-theme

@lkraav I agree

It'd probably be prudent to discuss JS-rendering SEO implications in another forum, since at minimum, SEO is not even required for some (intranet) apps. Let's keep this issue for the actual integration implementation concern.

Plus, the SEO discussion wouldn't be WordPress specific. The same challenges exists when using Inertia with Laravel and Rails.

[coccoinomane]

Thank you for the update @boxybird! Right now I am not working on a project that could benefit from the plugin, but I have starred it and will watch its development with interest 👍🏼 Cheers, Guido

[lkraav]

Hi @boxybird. My team is scheduling looking into this in more detail soon. I see your https://github.com/boxybird/wordpress-inertia-plugin has been updated 3 mo ago, so looks like you're relatively actively thinking about this technology.

Can you share an update what your latest thoughts are about this approach's feasibility?

[claudiodekker]

Hi @boxybird. My team is scheduling looking into this in more detail soon. I see your https://github.com/boxybird/wordpress-inertia-plugin has been updated 3 mo ago, so looks like you're relatively actively thinking about this technology.

Can you share an update what your latest thoughts are about this approach's feasibility?

Not to kill the conversation here, but I would argue it'd be better for the growth and stability of @boxybird's adapter to just open issues/PR's related to it at https://github.com/boxybird/wordpress-inertia-plugin. That way, it helps others that have similar questions, as well as that keeps that project active, which benefits everyone that wants to use it in the long run 👍

Finally, one thing I'd like to add, is that Inertia's server side adapters really don't require that much maintenance effort, as the things that they do (at least right now) are fairly simplistic and barely change at all (~90-95% of Inertia's features/changes/etc. happens in the client-side adapters), meaning that relying on community adapters is totally a decent approach even if they aren't considered "official".

@innocenzi Here's another package for your awesome inertia list :)

[innocenzi]

That's pretty cool. Added to the list. :+1:

[lkraav]

Certainly @claudiodekker that's exactly what I'm looking to find out with the message here. In case @boxybird has actually found out it's all a waste of time in WP, I'd rather keep the conclusions here in a higher visibility location.

[boxybird]

Finally, one thing I'd like to add, is that Inertia's server side adapters really don't require that much maintenance effort, as the things that they do (at least right now) are fairly simplistic and barely change at all (~90-95% of Inertia's features/changes/etc. happens in the client-side adapters....

@claudiodekker You're 100% on the money. Which is great news for adapter stability.

@lkraav "Can you share an update what your latest thoughts are about this approach's feasibility?"

I'm assuming you mean "Have I shot myself in the foot by going full Inertia in a WP theme!?" Early on I did, but not anymore.

As long as the WP project fits the spirit of Inertia's "Build single-page apps, without building an API.", then Inertia with WP is a great fit!

To put it another way... if the original plan for the WP project was to reach for a headless/SPA/API solution, then swapping it out with Inertia works.

[merijnponzo]

As a developer i work with both nuxt/vuejs and wordpress / vuejs / rest-api + the timber (twig) template system. I tested the wordpress theme from @boxybird and I must say this approach looks very promising.

I had some hard projects with the wordpress rest-api + nuxt, and it would be super to replace twig with just vue components, this would mean I can easily share my components between pure vue/nux projects and my wordpress websites.

As far for the SEO concern, I tested the wordpress inertia page with a caching plugin and i guess the data within data-page is useless for crawlers. I could add a structured data json object to the page

 <div id="app" data-page="{&quot;url&quot;:&quot;\/voorbeeld-pagina&quot;,&quot;props&quot;:{&quot;title&quot;:&quot;Voorbeeld pagina&quot;

if inertia could handle my vue components server sided I would certainly drop my nuxt + wordpress config ;-)

Keep up the great work