wbmnfktr

Not sure but maybe @Jonathan Lahijani or @bernhard have an idea here.

I could imagine this will help you out: If not... there a more topics in regards to this.

Wasn't there somewhere a module or setting to space out the textarea to the available space? Can't find anything in the modules directory, or maybe I am using the wrong query, but there has been such a thing. I know I used it in a project a long time ago, but that project doesn't exist anymore... so I can't look into it.

Yet another follow-up: I have started to play around with more "Headless CMS" out there and... the more I use them and the more I try with them, I imagine ProcessWire not only could but would be such a perfect and way more advanced way of using "Headless CMS" with SSGs. No need to write schemas, templates, fields, conditions in a JSON, yaml, toml, or whatever file - only if you like to do so. (which we recently had a nice discussion about) Try it on your own. Sanity, Forestry, strapi, whatever. They are nice and work really well, yet... using those I miss ProcessWire. Not only is ProcessWire way more capable of different inputfield types and more (like Matrix, Combo), it's even more suited with lots of things in regards to access control, data sets aka "collections". Another thing is... those other CMS claim they are "Developer centric/focussed", yet their API and docs are way less easy to understand than ProcessWire. (at least from my non-developer perspective) For example and without naming names: Imagine a code block that's a default for a module or default setting, but it doesn't work because it's from 2019 and doesn't work anymore since at least 4 main/stable releases of that very "Headless CMS". To be fair... we maybe could find such things here as well, yet... often most of their forums/communities and support are located somewhere on Slack, Discord, StackOverflow, Github or are overall very thin - to say it mildly. (Ignore those stars on Github) Which brings me straight back to my original question: How to export those data in a comfortable way through JSON, Rest API, GraphQL.

Looked through all of what you provided here... and I'm absolutely not sure what caused those issues. Sure there might be things in the code, the overall code for the whole website, but that would have caused more issues in the passed already. So far everything looks fine. Such kind of remote support is super weird and difficult. Where is your supporting agency or developer located? Maybe ask the developer or an agency around you to take a closer look. It should be a minor thing or maybe even only a glitch from within the input but someone might have to look at this. I use and work with ProcessWire for quite a few years now and never had these issues - ok, I have had them, but only due to my errors. Still this would match with my previous statement in regards to "errors would have occured before". Is there anyone around that can provide a full copy or access to the files on the server? Just to create a copy and test/debug it. Just in case... drop me a pn.

pictures in basic pages only shown when logged in In the frontend all I can find is this empty link: <p><a href="/site/assets/files/4121/log-dls_hepbandc_1300px.jpg"></a></p> So... How do you add images to your content field? Maybe there is an issue with it. Or Maybe even errors when uploading another image. Can you provide a screenshot from your "Inhalt" tab, please. hidden/unpublished basic pages shown in navigation The website looks quite custom made so it's probably a query for that menu that has something like include=all, include=hidden or similar in it and therefore shows more pages than necessary. Or at least that's my guess for now. So in case you have access to the source code of that site you could find the part. Maybe it's even a module that manages all those menus. Just looking at the screenshot of your backend I assume the site is already running for quite some time now and is a bit older. Which leads to the question: Did this happen before? Were there any other issues? Was something changed in the last days, weeks, or months? Right now it's all just a wild guess. And btw... welcome the ProcessWire Forums!

You are right about that. Almost standard connection with only SSL enabled.

Just used WireMailSMTP (Version 0.6.0) to send out about 1.200 newsletters without any issues. Running ProcesswIre 3.0.181 with PHP 7.4.

I assume your AdminThemeUikit settings already group notifications... therefore maybe a custom CSS to just hide them would do the trick but that's more of a workaround, not a solution. Aren't there any hooks available? As those are Core modules, maybe @ryan has an idea here.

Such a perfect hint for those that always used the blank-profile without things like that.

It works in 3.0.194. Good tip!

Probably... same with the other modules. And don't get me wrong here: I don't want to build anything here. For now. Callbacks, custom extensions, functions, fields... it's actually there in GraphQL, Pages2Json, and others. So sure... it's possible to build it, easily, still it's yet again something that doesn't come out of the box. I already struggle with your version right now as I have to add each and everyfield manually. Then an entry in _init.php for all of my image fields, all of my repeater fields, all my reference fields, matrix fields... But to be honest... in cases such like this which is somewhat a basic feature for others... I'm a bit tired at the moment. I really enjoy ProcessWire for lots of reasons but maybe I skip it right now for this adventure. Ok... wow. Reading the docs gave me the assumption it might end in a few hours to get it up and running. Wasn't there something with installing Node modules? Maybe that was another module I looked into. I will definitely keep this in mind! This could be absolutely handy in some cases. Your post just made me remember that optional header setting for different content types like JSON. But as for now - even though we could already hook into some parts there - it isn't yet a solid core feature for those default feeds I mentioned earlier. Customizing is always an option in ProcessWire. But it's the same I mentioned in regards to @bernhards RockHeadless - right now I don't feel like building anything just to test new setups for the frontend. Hence the idea to make such things a core functionality of some kind. I will still love ProcessWire even without those feeds.

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.