Leaderboard

It's not about having the tools, its about having it already build and "standardised". // get the single data example.com/api/v1/page/123 // get child pages data example.com/api/v1/pages/123 // use get varable as selector example.com/api/v1/pages/?template=product // filter child pages example.com/api/v1/pages/123?category=tv // get user example.com/api/v1/user/123 // get users example.com/api/v1/users/?role=custumer etc... Edit: yes, this responds with json. Looking it from the back-end perspective, nothing is missing. If you try to look at the things from the front-end, it might look different. What others are doing, is just providing external api out-of-the-box, which attracts new users especially front-end developers, and make things easier for people who are not experienced with building apis, or want to save time, so instead of processwire choosing other platforms, because they have this functionality built in.

What about this? https://github.com/baumrock/RockHeadless

Not sure, but it seems like it might be further away: https://caniuse.com/jpegxl I feel like it's the mid 2000's again and I am waiting on browser support for SVG!

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.

I had a similar experience with WebP - most often not significantly smaller, and often larger, so I kinda gave up and am waiting on AVIF to be supported widely enough to start using: https://caniuse.com/avif

Same here. I feel like we have everything and try to understand what is missing and what others to differently (better)...

Could you please explain how this would look like? E.g you visit /mysite/admin/rest/ ? and that responds with JSON? My feeling is that we already have the tools to do this. Just trying to think of the practical implementation.

I admit that this functionality could/should be included in the kernel (but disabled by default) as I personally use it for every installation, but still I didn't feel the need for it (getting it in the core) as I find the flexibility provided by the module AppApi made by @Sebi more interesting. Just include this module in your setup and you are ready. Anyway the argument is really good about that it will excite new users who have not yet tried ProcessWire but want to give a try when they see that they can use/build an API out-of-the-box.

Not sure if I'm missing something... No module, 2 lines of code: $restaurants = $pages->findRaw("template=restaurant", ['id', 'title', 'modified']); $json = json_encode(['restaurants' => array_values($restaurants)]);

This is what I meant: I install Forestry on my host Then I create Template XY Then I add fields X, Y, Z to the template Then I add Module X to get JSON Feed Then I create a Frontend and access this feed Steps 4+5 are missing in ProcessWire

$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

Or you use RockHeadless ? Referencing to the other post...

v0.0.4 adds callbacks to easily define the returned values of your selected fields: <?php // in site/init.php $rockheadless->return('rockblog_cover', function($page) { $images = $page->rockblog_cover; if(!is_array($images)) return; $file = $images[0]['data']; return "site/assets/files/{$page->id}/$file"; }); I think this should make it really simple to get a quick API while still being easy to customize.

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.

Hehe. In fact I had started adding the below but thought to save it for another day. But I'll add it here and then stop this OT business! I was saving above for a Blog post when Padloper stable is released...but oh well. And now, I shut up ?.

Why? Were you not aware of RockFinder? Sorry, OT ?

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 ...)

Thx @wbmnfktr that helps So what is missing with the AppApi module? I've never used it, but I like the topic and it sounds like it would be fun to build a module for it... so I'll try to understand better. How do the other systems handle access control? How should that be done by PW? On a template level? On a field level? I understand that. I'm a huge fan of standardizing things ?

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 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.

Got it & thanks again! ⬇️⬇️⬇️

No - I was just looking at the old version and did not instantly understand it, so I thought I'd change it a little bit. But there are still 1000 other options ? In terms of performance I don't think that there is any noticable difference between both versions.

?? Just checked it - works properly as well. Any particular reason of resigning from 'find' in $event? My programming skills ends somewhere around 'if' statements and playing with PW selectors... ? Efficiency in queries? Structure of methods?

@adrian Thanks for your feedback, glad to know I’m not alone. Meanwhile I did a bit more testing and found a clear correlation to the JPG compression rate. In Photoshop, a quality setting of 70 (of 100) and better leads to fairly or even much smaller WebPs, while the saving decreases with lower quality until there happens a turnaround to even bigger WebPs, approximately at 60. (The Photoshop value 70 seems to correspond to 65 in Lightroom, a bit more than 80 in Affinity Photo and something around 90 in Pixelmator Pro. The "good" JPGs on server 1 were produced by Lightroom with setting 70 and therefore match the pattern.) All things considered, the advantage of this "next-gen format" is hard to detect. To achieve a noteworthy saving in the WebPs, you have to produce unreasonably big JPGs first, but the resulting WebP will be bigger than your more realistic old-school JPG before. Measured in figures you might have better image quality, but I doubt that the difference will be recognized by the average user. So there’s a good chance that I will join your waiting-for-avif-club.

Dear @bernhard & @Noel Boss, I LOVE this wonderful hook! Works perfectly. Huge thanks! ?

@horst THX for the quick fix! Unfortunately my client already made the change to PHP 7.4. and I do not have a php 8 environment to test this at the moment. I will report back once I setup a local test environment.

I tired to make a workflow example using SSG and headless CMS, in previews post... Again, what is missing is REST api "out of the box". There is no steps, you get access to all your data via end points. You create a content using proccesswire admin, u get the json feed, u update the content, json feed updates... You can take example of GraphQL module, just built in the core, and i would prefer REST. And as @flydev ?? mentioned, AppApi is a good example.

I'm still curious how that "out of the box" would look like and how other platforms are working in that regard... As a detailed step by step use case.

Everything comes down to the content management needs. I personally like managing content with markdown files and front matter, but obviously not ideal solution or non-technical non-dev users. Also, theres clients that want you manage content for them, and content is rarely changed. In this case you dont really need a cms, but when you need it, this is where headless cms comes into play. And can work very well. Use headless cms to add/manage content Fetch content with SSG and build front-end with favorite generator / framework. Deploy your static site to the preferred service (github, cloudflare, netlify, vercel....). Use webhooks, or github actions to trigger rebuild when content is changed. As re-generating static site takes a bit of time, and compute, this is not ideal for all situations and needs. It depends on how frequent content is changing. If you have a directory for example, and visitors can publishing content, obviously this would not be a good solution. There's a lot of headless cms-s out there, but non of them from my experience is good as processwire. What pw is missing is is "external headless" features, REST api. Yes, we can build it our self, and can make json feeds fairly easy, but having it out of the box would be great. Im not an api or security expert, dont know implications, but from what i see most/all of the cms (especially headless) out there have this...

Is SSG not mostly being used by coders, git-users, documentation, etc. ? Is SSG really something to use for a client website ?

@wbmnfktr this module is for you : https://processwire.com/modules/blackhole/ Then add the 3 `wp-` magics folders and you will get rid of most bots :

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

https://github.com/processwire/processwire-issues/issues/1533

I found this nice tool that helps generating SQL and diagrams https://www.dbml.org/home/#intro Example Table makers { id int [pk, increment] name varchar(100) } Table cars { id int [pk, increment] maker int [ref: > makers.id] // # one maker -> * cars model varchar(100) about varchar(100) image_url varchar } Maybe useful for ProcessWire site planification too ?

Same idea, but personally I've never used it or seen anybody using it here on the forum ?

GET variables are automatically added to MarkupPagerNav links when they are set to $input->whitelist(). In this case you are dealing with an array value, so the input variables should probably be passed through $sanitizer->array() first before you do anything else with them. $y = $sanitizer->array($input->get('y')); // There are also other ways you can apply sanitizers to input variables If you do that then the sanitizer will give you an an array value from input in the format of "y[]=bar&y[]=baz" or "y=bar,baz" (these should be encoded when in a URL though). Then you would set: $input->whitelist('y', $y); By default MarkupPagerNav uses the comma separated form in its links, but if you prefer the square brackets then you can set: echo $results->renderPager(['arrayToCSV' => false]); But you won't get the exact format you showed because square brackets are typically encoded in URLs.

?? At first I thought my version was better readable. But I quite like this one: $this->addHookAfter('ProcessPageList::find', function (HookEvent $event) { $event->return->find([ "template!=" => ['admin', 'basic-page'], // keep them ])->each(function($p) use ($event) { if(!$p->editable() AND !$p->addable()) $event->return->remove($p); }); });

I refactored your refactored code ? One could also remove the pages that should be excluded beforehand… $this->addHookAfter('ProcessPageList::find', function (HookEvent $event) { $excludePagesByTemplate = ['admin', 'basic-page']; $event->return->find(["template!=" => $excludePagesByTemplate])->each(function ($p) use ($event) { if (!$p->editable() && !$p->addable()) { $event->return->remove($p); } }); });

OK, so reinstalled from scratch and all is good now. I'll start a new thread for new q.