Headless ProcessWire - How Do You Do It?

[Fuzen]

On 3/6/2022 at 4:25 PM, Sebi said:

I just released a new extension module AppApiPage (waits for approval), which handles the initial steps from my post above completely automatic.

I hope that this makes it even simpler to add a full-blown JSON api to new and existing pages.

This is amazing. This might finally get me started with APIs in the comfort of my favorite CMS/CMF.

[toni]

@wbmnfktr thanks for starting this topic, very interesting! After reading all replies I think I get your point.
 I mostly develop with Django (Python) where DRF gives a powerful standardized API centered around models.
Still, as you said, while working with other systems I always miss processwire for it's flexibility ;)

From what I understood other systems include a REST API out of the box (more or less) where processwire "forces you to write some lines of codes"
… and I guess that is the strength of processwire. It does not force you into a one fits all solution.  

My two cents:
For an upcoming project I tested different solutions. 
With AppApi indeed I got resonable results in not 2 but 15 minutes. With JWT included, nice! (thanks @Sebi)

For smaller needs URL hooks …
for bigger needs –without auth– PageQueryBoss …
–with auth– appAPI,
is my way to go.

But yes +1 for a core integrated solution that publishs pages based on standards .
Doing so it would even be easy to get a clear, understandable and standardized API Documentation.

 

[flydev]

On 2/21/2022 at 10:57 AM, flydev said:

If you are interested I can take the time to publish a draft of a profile which you could use as starting point, and IMO it's better and easily than other solution that I could have tested. Basically it use a modified version of InertiaAdapter made by @clsource and let you code your app inside ProcessWire's template and using pages for everything fetched dynamicaly and internally, as JSON.

 

You can see it "in action" in this example url: https://blog.sekretservices.com/

(Do not take care of the issue while refreshing the blog post due to hanna codes, it's an old version)

 

For example, from your template you build the page properties as a simple PHP array, let's say I want to fetch the title of the page:

$component = "Home/BlogPost";
$properties = [ // accessible from app components with $page.props
    'name' => $page->name,
    'title' => $page->title,
    'subtitle' => $page->subtitle,
    'content' => $page->body,
    'author' => ucFirst($page->createdUser->fullname[0])."."." ".ucFirst($page->createdUser->surname),
    'date_created' => $page->created,
    'date_relative' => $datetime->relativeTimeStr($page->created)
];

Then from a component BlogPost.`{svelte, vue, react}` (or whatever) you can simply retrieve the page's props like:

(Svelte example)

<script>
  import {inertia, page} from '@inertiajs/inertia-svelte';
  export const { title:title, body:body } = $page.props
</script>

<div class="blog-post">
  <h1 class="font-sans mt-8 text-center font-bold">{@html title}</h1>
  <div>{@html body}</div>
</div>

 

Look at this sample, at the page's tree and the routes prop from the console :

 

About the workflow, it's not really different from what you should be used to. You write your logic in template in PHP then write some HTML/JS in your component.

Also, hot module replacement (HMR) is working ?

A word about server side rendering (called SSR and which is needed to get best SEO results), it's working for React and VUE, still a WIP for Svelte ?

Get a note of ?on every lighthouse performance.

Bundled with ViteJS, powered by ProcessWire, I am glad to say that it's the best stack I have ever built and used ??

 

Edit:

A small note, but the better one. You don't have to build your app again on every change on the backend, I mean for example when you add a new page, it's work out-of-the-box, you create and page, and it's available to your JS components.

Edit2: 

To understand better, here we can achieve what you already used/saw with Laravel. Having a `src` folder with the JS things, another folder with the Laravel `app` and running artisan and some npm command.

Here, in dev mode, you run `yarn dev` and you are ready. Simple as that.

 

 

 

[ryangorley]

I'm sorry to resurrect this old thread, but it seems to be the most recent and authoritative discussion on this topic. I've been using an open source alternative to Webflow called Webstudio a lot more lately, especially for landing pages and microsites. It has no CMS, but can hook into any Rest/GraphQL API to serve dynamic content/pages instead. I've done that once now for a client using WordPress and the WPGraphQL plugin. I would much rather use ProcessWire as a headless backend for many reasons, not the least being its superb multilingual capabilities which I need.

Is anyone currently using any of the solutions suggested in this topic, especially with multilingual content?

It seems that some of these solutions have been abandoned. I don't even need an API per se, but just JSON formatted content, so at worst I suppose I can just write page template files to do that. But if someone has a better, tested method, I'd love to hear what you're using. Thanks!

[markus-th]

12 hours ago, ryangorley said:

Is anyone currently using any of the solutions suggested in this topic, especially with multilingual content?

It seems that some of these solutions have been abandoned. I don't even need an API per se, but just JSON formatted content, so at worst I suppose I can just write page template files to do that. But if someone has a better, tested method, I'd love to hear what you're using. Thanks!

I think URL hooks can be a good solution for this case: https://processwire.com/blog/posts/pw-3.0.173/

[wbmnfktr]

On 3/17/2025 at 7:39 PM, ryangorley said:

Is anyone currently using any of the solutions suggested in this topic, especially with multilingual content?

Back when I started this thread I tried multiple ways, modules, and custom exports. From JSON to AppApi to GraphQL and everything in-between.

I still use basic JSON in some projects or just grab what I need via HTMX nowadays.
I pull in only simple data via JSON I might need on build time or fully rendered HTML with HTMX in my AstroJS projects.

Whenever I start a new project and need a MVP-like skeleton of it, I go with static content in Markdown/MDX in AstroJS, later on I'll migrate to 100% ProcessWire in most cases. It just works, I feel home, know how to handle stuff, have everything I need and with ProCache, LoginRegisterPro, and FormBuilder I can keep everything on my server and don't need things like Supabase, Neon, FormSpark or whatever.

So to finally answer your question: no, not anymore

[ryangorley]

Thanks @markus-th and @wbmnfktr. You've given me good feedback to consider.

I had an issue today with the headless WordPress site I referenced above that has me thinking about this differently. In short, the WPGraphQL plugin broke from an update and I decided to try converting what I had over to REST with Claude AI. In addition to a lengthy prompt I fed it JSON of all of the custom fields and GraphQL queries I was using on the site. That worked really well and only required minor fixes to completely rebuild what I already had.

ProcessWire has great documentation, has been around for a long time, and can export templates and fields in JSON format. I just need structured data of each page, nothing wild. I'm going to see how well the machine can generate what I need and if it seems repeatable. If anyone cares I can post how it goes.

If you're tired of the "LoOk aT WhAt i MaDe wItH Ai mOm!" posts, then I'll keep it to myself 😉

[Jim Bailie]

On 3/19/2025 at 3:37 PM, wbmnfktr said:

Whenever I start a new project and need a MVP-like skeleton of it, I go with static content in Markdown/MDX in AstroJS, later on I'll migrate to 100% ProcessWire in most cases.

@wbmnfktr I've been looking at AstroJS lately and am intrigued by your comment above.

How are exactly are you using Astro? Are you using it as sort of a template engine, then moving the final output into a PW instance?

Or are you using Astro as an application itself and talking to PW via endpoints? If this is the case how are you positioning both Astro and PW on the same server?

[wbmnfktr]

11 hours ago, ryangorley said:

"LoOk aT WhAt i MaDe wItH Ai mOm!" posts

Put those posts here in the Dev Talk in their own topical threads. I personally love those posts and looks behind the scenes. So... a +1 from me here.

[wbmnfktr]

23 minutes ago, Jim Bailie said:

How are exactly are you using Astro? Are you using it as sort of a template engine, then moving the final output into a PW instance?

Or are you using Astro as an application itself and talking to PW via endpoints? If this is the case how are you positioning both Astro and PW on the same server?

I'm a bit short in time right now so I might have to write a follow-up to give you a real and more complete answer here. But in the meantime - a short summary:

• each and every client/side project of mine get's a click-dummy of the final product to see how it could work out, what's needed and so on.
   
• I use Astro JS for that as it's super flexible to work with, I can deploy it somewhere at Netlify, Vercel, or Cloudflare. Each commit is a new build. I can share it with everyone - frontend and backend-wise. It's more or less just HTML, CSS, JS - some parts of it might have a TailwindCSS or AlpineJS flavor but still super basic. And the big plus: ALL build steps (TailwindCSS, AlpineJS, ...) are already in place.
   
• If needed I can connect it to an API to fetch articles, news, or whatever kind of data to make it look more real or to go super fast - especially when migrating from WordPress where there is a RestAPI or GraphQL almost always in place already. For sideprojects I connect to api.domain.tld, grab JSON and render out either pages or just parts of the project on-build.
   
• for side projects in very early stages that would be the state for the next 3 to 6 months to see if the project get's some kind of traffic - for client projects this is the base to start the real work.
   
• from there I take all the component and move them from .astro to .twig - the difference is so minimal I could use Regex to make the changes most of the time.
   
• feeding all layouts, components, partials, blocks, however we want to call those code snippets into ProcessWire is pretty easy, when you know where things have to go and most of the time you only change the parts that define the source - so from a JS fetch() to a $pages->find('...') - and of course you have to build out the ProcessWire backend stuff, hooks, automation, and whatever you need or want.

 

Some would say there are a lot of unnecessary steps in this process and they could be right, but I prefer to test projects early on and hate to look at Figma files or Illustrator screenshots. So there is that. I always worked that way and that will probably never change.

On the technical site you have think about 2 systems running side by side.

1. Astro JS on Netlify, Vercel, Cloudflare or a VPS with NodeJS and ... lots of other stuff
2. ProcessWire with database and everything it needs on a sub-domain.

You could fit everything onto one server but it can be quite painful to get this up and running so I use a regular hosting provider for ProcessWire and one of those mentioned above for Astro JS.

The output is, most of the time, 100% static and build on-demand with data and content available at that moment. You could make it more dynamic with AlpineJS or HTMX but only for small parts, and not for articles and news - as those wouldn't exist within the static build.

 

As this turned out to be broader as expected please feel free to ask about more details where needed.

[Jim Bailie]

45 minutes ago, wbmnfktr said:

Some would say there are a lot of unnecessary steps in this process and they could be right, but I prefer to test projects early on and hate to look at Figma files or Illustrator screenshots.

@wbmnfktr Amen to that! I think I like your approach here.

I also think I may experiment with using Astro as the application and making PW available for build time data retrieval via 127.0.0.1:port# and the same PW instance available via a subdomain for post-page load endpoint requests and other tasks if needed. 

For reference, there are a few articles discussing this sort of approach using Wordpress headless.