wbmnfktr

So maybe I have to play with RockFinder3 a bit even before trying AppApi. To be honest I would never ever have thought about using it just because it feels way overhead for "just a JSON feed". So... I will cherry-pick in that docs and maybe find a way to get the results I need.

That looks great! Just gave it a try and the result looks quite similar to what I get when using your findRaw() statement. But... YES! That's what I was thinking about.

It's the same here. Oh... that's interesting. I tried my query on all of my pages and... some now return details, yet I don't know what's happening. It didn't bother me in the past so I just might ignore it for the moment. That's were I was looking right now.

$restaurants = $pages->findRaw("template=restaurant", ['id', 'title', 'modified']); $json = json_encode(['restaurants' => array_values($restaurants)]); Moved this from here - to keep the other thread clean: So... yeah that little script does a really good job. While I read about findRaw() somewhere I never really cared somehow. Maybe because I haven't looked that deep into it. It does an amazing job but for a ready to use JSON feed in an external site/app/ssg parts are missing - for me. Text and textarea fields are fine and easy to use somewhere else. PageReferences are slightly different and need a slightly different subfield request with, otherwise you would just receive the IDs: 'myPageReferenceFieldMultiple.title' "myPageReferenceFieldMultiple": { "7009": { "title": "Voucher" }, "7010": { "title": "Dinner" }, "7011": { "title": "Outdoor" }, "7012": { "title": "Vegan offers" }, "7013": { "title": "Take away" }, "8574": { "title": "Special offers" } }, Image fields really only have the raw data. No url, no image details, nothing. "myImageFieldSingle": [ { "data": "logo.png", "sort": "0", "description": "", "modified": "2020-04-16 18:59:33", "created": "2020-04-16 18:59:33", "filedata": "", "filesize": null, "created_users_id": "0", "modified_users_id": "0", "width": null, "height": null, "ratio": null } ], And repeater matrix fields are yet another animal. Similar to repeater fields but more complicated to get each and every matrix entry and its details. "myRepeaterMatrixField": { "data": "8577,7060,7360,6443,6415,6414", "count": "6", "parent_id": "6399" } Amazing... so far. Ping at @bernhard @kongondo

I can't answer this for all of you but looking into my projects I work with this type of concept all the time. Just a few examples from those projects: Home ├── ... ├─ Restaurants (template: restaurants) * ├─── Restaurant ABC (template: restaurant) ├── ... ├─ Events (template: events) * ├─── dd.mm.yyyy - Let the music play (template: event) ├── ... ├─ Teachers (template: teachers) * ├─── Mr. Mister (template: teacher) ├── ... All pages marked with * are set to one page only and therefore could be an endpoint following that idea from above. In terms of complexity... no, not really at all. Should children templates be limited in this setup? Well, I do. Is it necessary not really I guess. The idea from @lokomotivan would work as well but that would already be the very first point we have to take care of input. Sure that's still low level code but already something that's not really out of the box. Based on that idea all endpoint-enabled templates and therefore the one and only page's name could be used here instead. So it could either be restaurants, events, teachers (in this example) or sOm3w31rd characters we put in the page name. Update on this as I missed the /api/v2 part: sure, for the part of this API that needs auth that's the perfect choice I guess. You actually need it and not only one but several parameters.

Can't tell anything about it just because I haven't tried it so far. And for my use cases right now I really doubt I will - even though it looks amazing. The things necessary (installation, setup, routes, auth, ...) to get what I want is just too much. All I really need is solid JSON for each of my data collections (pages, posts, restaurants, movies). No need for creating or modifying content due to user input on the frontend. No access control either. If I wanted to build my very own all-in-one setup to manage several client projects (and way bigger ones) in this matter, I'd probably give this module a very solid try and do the things necessary. Right now for a few test runs and proof-of-concept projects I pass. How do other systems do it? It depends. As always. Some have public API endpoints/ JSON feeds by default you can limit later on, similar to AppApi. Some need request tokens you/the system define right from the start. To limit it down they have custom roles and more. Very strict like the GraphQL module. You might want to take a look at Custom Roles here: https://www.sanity.io/docs/access-control Depending on your needs there are already a ton of content platforms (another word for Headless CMS for a slightly different target group) out there that provide you with various different solutions and possibilites, like author-editor-workflows and revisions. For example: https://www.contentful.com/ or https://www.storyblok.com/ While those are pretty great for newspapers, magazines with tons of content and lots of authors those features can get pretty expensive at some point, while most others have free plans that fit a good amount of users or websites. How should ProcessWire do it? I guess ProcessWire already does a great job here in how it handles such things. Reading through the AppApi docs I'd say it looks quite good how it's done there. Still a public, non-restricted JSON feed right from the start would already get the job (or at least mine) done. pw.com/api/v1/posts (public - defined by a global setting as described above) pw.com/api/v1/pages (public - ...) pw.com/api/v2/customers (with Auth to get access to restricted fields and data) pw.com/api/v2/orders (with Auth ...)

This little bit of PHP works pretty well. I'm quite surprised actually. There are still questions, but this would be a bit too off-topic here.

I doubt this will work out with ProCache enabled but I'll definitely take a closer look at this. Thanks! Yes and no... take a look here: https://forestry.io/showcase/ https://www.sanity.io/projects Even Smashing Magazine, Backlinko and Android Authority use SSG/Jamstack.

I choose a Headless CMS I create data collections (pages, posts, movies, restaurants) I add fields to match my needs in those data collections + add data/content I go to headless.cms/api/v1/json|graphql|rest Access it in my frontend and generate the pages That's the short version and yes... step 4 is for that matter missing right now as core functionality. Sure we can probably build this on our own, some already did it with a few lines of code, other with modules and even with REST API functionality, as well as with GraphQL... BUT that's always a lot of work. It's not standardized. It's a big showstopper for something you may only want to try out. SURE... being this flexible is a huge plus as well, yet I don't buy a cow to eat a steak.

I guess the most important and missing part in this thought-process might be the fact: where does the feed/API come from and how does it know what to do? Or a similar question in this direction. To give you more details and some new words, which get used quite often in these systems and setups. We will look at the data and CMS part here. The frontend isn't that important right now as it could vary from something like 11ty/hugo/jekyll or a full blown next/nuxt/react/whatever.js framework. 1. Content/API-first You need to define your necessary data collections first. These can be just posts and pages, like in WordPress, or any other kind of data you might need. Each and every data collection is, if you will, an endpoint for your API. Either JSON, REST, GraphQL, Markdown with Frontmatter, it depends on the system you choose. Some have only one option, some have multiple options available. WordPress Example: wp.domain/wp-json/wp/v2/posts wp.domain/wp-json/wp/v2/pages wp.domain/wp-json/wp/v2/yourdatacollection ProcessWire In ProcessWire there is no such thing as data collections or static endpoints. But we could easily create a template which indicates a data collection, like movies or restaurants, make the template single use only (Template > Family > Can this template be used for new pages?) and from there some kind of system field like Enable as API endpoint? or something like this. With that it would be possible to have a default URL for those feeds, like: pw.domain/api/v1/movies pw.domain/api/v1/restaurants If those are full featured GraphQL, REST APIs, or "just" JSON feeds at the end of the day doesn't matter right now. As long as they all know how to handle and output image, file, repeater, matrix, combo fields. 2. How does the system know how to handle the data? That's a thing we can already see in ProcessWire itself sometimes or in the PageQueryBoss module. ProcessWire is aware when to output an array or just data. PageQueryBoss does the same in some cases. These Headless CMSs I looked at have similar input field types like ProcessWire and therefore know how to show them in an API. Text, textarea, image (single/multi), file (single/multi), Mapmarker, even repeater and matrix like fields. The API does exactly know how to handle and what to output for those fieldtypes. Even though they are quite customizable. You don't have to hook into anything, you don't have call another function to get an array. It's already there and ready to use. If it wasn't for the frontend you never have to deal with the API/Feed itself. No loops, no functions, no hooks.

Is anyone using this module and can help with a few questions? I'm looking for a solution to retrieve an almost flat JSON result without unnecessary nesting of some kind. My query for now looks like this: // myTestingApi.php $json = $pages->find('template=restaurant')->pageQueryJson(['id', 'title', 'dateLastMod']); header('Content-Type: application/json'); echo $json; The result looks like this, which is fine, but...: { "restaurant-abc": { "id": 1234, "title": "Restaurant ABC", "dateLastMod": "dd.mm.yyyy" }, "xyz-bistro": { "id": 2345, "title": "XYZ Bistro", "dateLastMod": "dd.mm.yyyy" }, "restaurant-citycenter": { "id": 3456, "title": "Restaurant Citycenter", "dateLastMod": "dd.mm.yyyy" }, "bar-cafe-123": { "id": 4567, "title": "Bar Cafe 123", "dateLastMod": "dd.mm.yyyy" }, "paradise-food": { "id": 5678, "title": "Paradise Food", "dateLastMod": "dd.mm.yyyy" } } I'm looking for something more like this. { "restaurants": [ { "id": 1234, "title": "Restaurant ABC", "dateLastMod": "dd.mm.yyyy" }, { "id": 2345, "title": "XYZ Bistro", "dateLastMod": "dd.mm.yyyy" }, { "id": 3456, "title": "Restaurant Citycenter", "dateLastMod": "dd.mm.yyyy" }, { "id": 4567, "title": "Bar Cafe 123", "dateLastMod": "dd.mm.yyyy" }, { "id": 5678, "title": "Paradise Food", "dateLastMod": "dd.mm.yyyy" } ] } How would I get this? I guess I tried whatever I could based on what's written in this thread but maybe I'm missing details here. Anyone an idea?

I'd go a slightly different route which might be easier overall. As your result is focussed on events, rather than performers, maybe think about this solution. With this setup you can easily list all events and could later on show lists grouped by date, grouped by performer, grouped by location, and so on. Creating events that reference performers and locations are way easier to handle - in my opinion - than the other way around. Still everything is easily maintainable. The same setup I use here: https://www.axelpaetz.de/termine/ https://www.kerimpamuk.de/termine/ The event leads, while locations follow, and if necessary even the performer, which is in those settings no needed at the moment - but possible. No groups so far, besides a filter used at the first link. --- Page tree, templates, listings Home ├── ... ├── events (tpl: events) ├── event (tpl: event) ├── yyyy-mm-dd (dateStart) Performer (title) Location (ref:location) ├──performer (tpl: performers) ├── performer (tpl: performer) ├── title ├── locations (tpl: locations) ├── location (tpl: location) ├── title ├── ... ├── ... --- TPL: event Fields: title desc dateStart dateEnd url ... PageReference: performer PageReference: location TPL: performer Fields: title desc details genre ... TPL: location Fields: title desc addressDetails (city, street, zip/postalcode) url

In which scenario? Rebuilding ProcessWire in those Headless CMS or what's needed to add and import from JSON/API into those SSGs? What I can already say and show are some parts from ForestryCMS in terms of fields that are available and what could be done so far there - right now Forestry is my option for the next couple of weeks to play around with. The most interesting parts might be these... details in the docs. Including templates: https://forestry.io/docs/settings/fields/#include-template Repeatable Fieldgroup: https://forestry.io/docs/settings/fields/#repeatable-field-group Blocks: https://forestry.io/docs/settings/fields/#blocks And in terms of importing data into 11ty (the SSG I use right now) is quite easy... that's the guide I used and it worked out pretty well. https://davedavies.dev/post/how-to-use-11ty-with-headless-wordpress/ Let me know if I missed the point.

It's not really about the Headless CMS - at least not in my case. I'd be totally fine with just editing .md (content) or .njk (templates) files from the command-line. While this works perfectly fine for me, my clients aren't that keen to work this way. They love their interfaces to edit content, creating pages and such. So there is still need for some kind of interface of some kind for my clients. As I love ProcessWire and all the things I can do with it, using it as a Headless CMS would be the perfect match. Not only that but ProcessWire is way ahead compared to other CMSs, especially combined with ProModules. Yet it's not that easy to get this up and running to use it with 11ty, Hugo, Gatsby and other SSGs (Static Site Generators). Or at least it wasn't for me and still isn't. That's why used WordPress for quick solution. There is a REST API/JSON feed with everything I needed right from the start, some additional changes and I was ready to go. But as soon as I know how to get these JSON feeds from ProcessWire, I will switch that project over for obvious reasons. And the reason why this even became a topic for me: static sites are way more comfortable in terms of "release and forget". If a client doesn't change anything within a year or two, it doesn't matter at all. There are no risks, no security issues, no updates, nothing. Sure you have to maintain a ProcessWire instance even though you rarely use it but you can disconnect it from the deployment and nothing will happen to the real site. But maybe in some cases it's already enough to use Forestry CMS, which right away talks to Github - kinda awesome! @lokomotivan listed some very good reasons for static sites ans SSGs and I will go this route as soon as I can for existing projects and upcoming ones. Let alone the performance differences are quite insane, even when using ProCache. I hope to get one of my larger side-projects up and running with this kind of setup in the next months. Maybe with ProcessWire, maybe with another option (just to get a feeling for other tools). While I already get awesome numbers in performance tests, the amount of unwanted traffic through bots, spiders and a lot of script-kiddies is an issue for me. Using Netlify or Cloudflare as hosting solution this wouldn't be an issue anymore. So... while classic websites are still a thing, I'd like to add another option to my tool belt and I'd love to use ProcessWire with it.

Some additional feedback so far... The PageQueryBoss module, which @monollonom recommened looks pretty nice and works out really well so far. There are issues, but way less than before. I will use and play around with it for a bit. Maybe that's what I was looking for. In regards to those other modules I mentioned before... GraphQL In my setup I had to change each and every field to make it available for public (legal) requests. That's awesome for a setup that needs control about each and everything. But that's nothing I needed or need. Therefore changing a lot of fields without knowing anything about possible issues in other pleases, wasn't an option. Pages2Json The simple JSON feeds were easy to create but... customizing, repeater fields, matrix fields and such... were way out of focus and not that easy at that time (we haven't had a lot of budget and time to get things done)... so maybe it's a nice solution after all. I used it before and it's still in some other projects but in this special use-case... it wasn't that perfect for me. So... I can't say anything bad about the module, yet it wasn't a solution for that specific project. Another thing... While those modules work for some use-cases and in probably a lot of existing projects, they are still 3rd party (which isn't a bad thing, but...) and looking at the "last update" dates... they are somewhere between 2018 and 2021. Which isn't that bad compared to some core and 3rd party modules, yet I have to rely on those modules for the next couple of years. Changing PW versions, PHP versions and whatsoever. Some support threads are way outdated and sometimes even look "bad" with unanswered questions. Didn't and still don't feel comfortable with this - not only in this very case. Therefore I use so many ProModules for a lot of things.

Thanks @monollonom - I didn't know that module but I will have a look at it. Maybe that's more of what I need. Thanks @dragan - you are right, a Headless CMS is something completely different than a SSG. I already found a nice SSQ solution and right now I'm looking for a fitting CMS. I looked at a lot of those mentioned above, yet ProcessWire is way more advanced and more capable of almost anything. And sure... creating JSON feeds is easy until you have a more complex setup of fields, references, repeaters, Matrix fields and such. That's exactly that point @gebeer made here. In WordPress it was super easy to get it right from the start - sure still not a super complex structure, no real repeaters, but way ahead. I'm fine with going into the code, write my output but I sometimes just need something that works right out of the box. Wordpress could be a good fit but maybe even better one of those other CMS out there. This in the core, with support for (matrix) repeater, combo and all the good stuff... this would open a totally new and large user base.

Intro: Just to let you all know where this comes from... In the last few weeks I had a lot of tasks and projects in regards to SSG (static site generators), mainly some *.js frameworks. While those *.js frameworks weren't anything of my taste I started to love and enjoyed 11ty. I've already re-built some of my personal projects with it (11ty) just on static files (js/json data files), which worked really great. BUT... and this is my reason I post this here... this was hard work to move data into static files. Question: How Do You Do It? How do you handle ProcessWire as a Headless CMS for SSG projects? I tried the Pages2Json and GraphQL modules and even custom URL-Hooks for JSON output... but those solutions didn't fit any of my needs. Not even close. It could be me, but I thought about solutions that were more kind of ready-made for almost all purposes. (Yes, I know PW is more of a toolkit :D But most projects just don't have the budget to allow such custom exports of data.) As I wanted to build more complex sites (even as those are mostly only prototypes whatsoever) with way more data, as in posts, pages and such... I installed a basic Wordpress instance, used Custom Post Type UI for custom post types, I was able to get everything done within minutes. Yes, minutes. It took me 3 minutes to set everything up (5+ post types), while adding data took another 10 minutes for each post type. The result was, that I had specific JSON feeds for everything I needed. wp.domain/wp-json/wp/v2/posts ... /pages .../movies .../authors .../whatever - all in perfectly formatted JSON, even those fields that where references, like categories, topics, and other taxomonies. I'd love to see/hear about your solutions. I'm almost certain that PW should or might need an additional (instead of new) focus. As PW is able to do way more than any other Headless CMS out there... it might and should try to match up (in terms of marketing and onboard solutions). I tried Forestry CMS, DatoCMS, SanityCMS, NetlifyCMS and a lot more Headless CMS the last few weeks... all were nice but FAR away from what a basic PW instance can do. I was shocked how basic, yet praised they (other HeadlessCMS) were in the community. Even without ProModules ProcessWire is way ahead of any Headless CMS I tried/used so far. (SURE! It could be me, but I doubt it.) Maybe I'm missing something but I for sure don't wanna miss out on PW for an awesome solution as a Headless CMS. If there was a native JSON/RestAPI feed like in WordPress or any other like-minded (as in easy) solution in it... it could probably the one solution for all. So... Headless ProcessWire - How Do You Do It? Therefore, as this is way more complex than an average question, I tag some of you right here, as you may know much more about anything in terms of ProcessWire or ProcessWire Headless as me. @ryan @adrian @Robin S @horst @psy @Jonathan Lahijani @teppo @dadish@thomasaull

Kind of heckling here, yet... I didn't even know anything about this in that depth... therefore... just a THANK YOU for this insight.

Exactly that was kind of a game changer for me. I switched my config settings, kept another database for branch/tree version1 and went from there. I was able to switch between the old site and each and every new instance/feature set of it. In total 6 branches/trees but it was worth it. Relates to the last project in which I used worktrees.

I'm not using them day-to-day... that would be such an overhead. But yes, worktrees are some kind of next-level chaos at first. Still sometimes really nice. I used worktrees in some larger projects in which lots of things happened at the same time. So switching from branch to branch, stashing, half-baked commits didn't work out at all. I mapped each worktree to its own virtual host, could switch code bases whenever needed without said things, like stash or commit. Are they perfect? No. At least not in my day-to-day projects. But there have been some projects I really benefitted from worktrees. Still a tiny fraction, but still. I assume it will work out totally different in case you do C/C++, Rust, Go, TS... things like that. At least that's my impression while watching coding session similar to video linked above.

Just in case... have a look a Git worktrees. Sounds weird and complicated (especially in the setup process) yet... it could be another game changer. No stashing, deleting or workflows like the workflow from xkcd. Maybe even easier than branches to be honest, while still using branches. I keep this here... as it's entertaining and fun... Looking through that channel you might find interesting things while searching for "git" or "workflow" or "bug". Sure it's VIM-based, yet even possible in VSCode (and others) I guess - most of the time. However it's super fun to watch and to get ideas and insights.

Just a heads-up here... Had to add {all}script{all} as there were issues with some recent requests containing those. For now this works wonders.

That's my thought each and every time I miss a few weeks of @ryans posts. There is soooo much in PW we don't know but Ryan.

Sure we could trick here a bit with CSS but that would be future-proof at all. Therefore... you might try the HannaCode solution @Gideon So mentioned or otherwise add another layer with just JS. I can't promise anything... but will keep this tough in mind while doing some CSS-work. Maybe... I could come up with something. Shouldn't that be easy? I will look into it a bit more at the end of the week, as I have time then. But I guess there should be something possible. Could you provide a "final result" for what you need or something? Just drop it in my DMs if it's too "confidential" or similar.

I did for way too long. Therefore they don't like me anymore. ? But yes... it's more of a culture to work this way but on the other hand... we all are free-devs with super individual workflows. I can't and don't wanna blame anyone for this. At the end everything was fine*. * 100s of merge conflicts later, with rebase and such things. ?