Leaderboard

Eh nothing, all is ready, we have even more with JWT implementation. It's just missing a function which return the pages tree. Something like less than 10 lines of code. Already shipped with : - Authentication - Three different authentication-mechanisms are ready to use. - Access-management via UI - Multiple different applications with unique access-rights and authentication-mechanisms can be defined And you can generate your own routes dynamically by just adding a simple hook. Installation will/should be required in every case, even with a core module. But you should give a try to the AppApi module, you can start in less than two minutes, check : Enregistrement #27.mp4

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

Interesting. So, with this approach we only need to register the template via a setting (on the template edit screen) and that same template can be used to output either HTML or JSON, right?

@wbmnfktr, @kongondo I just want to throw in a thought about a point I read somewhere above, regarding (native) endpoints in PW based on templates. If you think about the possible different processes only upon the access methods of an URI, reflected by $config->ajax (true|false). You can define an output of text/html or application/json for an template. In PW, the default is text/html. Within a general hook you we can check for registered templates and then switch the output processing according to AJAX or FETCH access. Does this make any sense to you? Or have I missed the point? EDIT: also upon the access method, we dynamically can switch the processing filename of the templates, not only the output type.

Have you guys tried combining findRaw() with url hooks - https://processwire.com/blog/posts/pw-3.0.173/ ? I find it a really easy way to take care of this stuff.

@rash Besides filesize, how does the visual quality of both images compare? Do the WebP images look better, worse or the same as the JPEG files? If you have a slightly larger filesize for a much better image, that might still be a good trade-off. That said, uploading pre-compressed JPGs and then converting them to WebP is not a good idea. Re-encoding an already heavily compressed image will always result in a garbled image and larger filesize, regardless of format. You want to upload high-quality JPGs (Quality setting of 90~100) and then generate compressed variants in JPG / WebP based on the source image. In fact, you'll want to generate multiple variants in different resolutions for different screen sizes. See my tutorial on using responsive images in ProcessWire for details. This one only talks about JPG, but you can use a <picture> element with two <source> elements, one for WebP and one for JPEG. Another thing to consider if you're seeing wildly different results on two different servers, maybe those just use different settings. WebP can encode lossless images, maybe the 'bad' server is doing that? Or if you're doing lossy compression, maybe you just need to set the WebP encoding to a lower quality level – WebP lossy encoding also has a quality setting between 1 and 100, same as JPG. There's also a range of other options to tweak to get optimal results, so maybe play with that a bit before you give up on WebP altogether. squoosh.app has a nice interface for WebP options – open a test image, select WebP in the compress menu and play around with the settings a bit. You'll be surprised at the tradeoffs between image quality and filesize you can achieve.

No matter what I try I end up with an empty decimal field. I tried inputting 1.5 as well as 1,5. I also tried both settings for the input-type (text/number). Decimals is set to 2. I can only store integer numbers. Could you please try that so that I know if I should invest more time? Thx!

Hi @Sava, I'm not sure I get your question... do you want to know how to get a URL of the QR code to be able to download it ? In the unformatted output the QR code is already in the form of an <img> (or <svg>), but I went ahead and added a "raw" key in the unformatted output. You can download the latest version and try to do something like... $qrcode = $page->getUnformatted("qrcode_field"); foreach($qrcode as $qr) { $filename = $sanitizer->snakeCase($qr["label"]); $label = "Download QR code for \"{$qr["label"]}\""; echo "<a href=\"{$qr["raw"]}\" target=\"_blank\" download=\"$filename\">$label</a>"; } Hope this helps!

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.

I haven't experienced that. I don't often use tables and can't remember if I've seen that. Fluency wouldn't be able to change how a field is rendered.

Yep. Padloper2 ?.

@rash Do you use Imagick or GD to convert to WebP? For GD, the imagewebp function accepts the quality level as the third parameter. For Imagick, Imageick::setImageCompressionQuality should be the equivalent. Other options can be set with Imagick::setOption, see this post on Stack Overflow. No idea if ProcessWire's image API supports those, check the documentation or read through the source code to find out … Both of those are defined in code, so it shouldn't differ between servers. However, there are some possibilities why it might depend on the server: Different PHP installations with different default settings. Or different PHP versions with different levels of optimization / encoding efficiency. Maybe ProcessWire doesn't use GD/WebP at all, but calls the underlying C-libraries directly. In this case, the default parameters used by those libraries might be different.

@MoritzLost I agree. Unfortunately, it’s the other way round until now: slighty better images with considerably larger file sizes. But I’m working on it ? I already use a picture element with different sources and want to establish responsive image sizes in the next step. And I already know your tutorial and find it pretty helpful – thanks for it! I’m not giving up yet, just had to whine a bit yesterday, because everything appeared so sadly. Regarding your settings proposal: Where could I set quality levels on a shared server with limited access to it’s settings? It‘s indeed annoying me to have either WebP or not WebP without knowing how to affect the result.

hi, honestly this kind of things is usually due to the path you've set to those css files (nothing to do with pw or not actually) a simple way for you to check, start emptying the cache (module page render) then look at the page source code and click on the css file link, you'll see if your run into a 404 or if you see the file source simple thing to take into account, this may depend on if you're working with a vhost/domain or juste pointing to your hosting root and if your links start with a root / or not hope it'll help haves a nice day

The first one of those was basically due to index issues in my DB - running optimize on all tables fixed it, although I still found some significant improvements to speed that could be implemented. The second one is very weird - certainly seems like findMany seems some attention.

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.

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

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

Hello community, on a site with a simple blog, I am using Pages for blog categories. Therefore I created a template blog_categories as the categories PARENT page and another template blog_category for the CHILD pages. I configured blog_categories to only allow blog_category as children – and vice versa – blog_category to only allow blog_categories as parent. Having that set up, i created a field of InputfieldPage and configured it to have my (already added) blog_categories parent page as allowed parent and set template blog_category for selectable pages. I also checked "Allow new pages to be created from field". For the super-user this works as expected: Categories (pages using blog_category) can be created within the InputfieldPage field while editing a blog post. For my editor roll, i set up the following template permissions (beside the default view-permission): blog_categories – add children blog_category – create pages – edit pages Logged in as an user in editor role, I am able to create new categories in the page tree (as child pages to the categories parent). But when the the same user tries to create a new page from within the InputfieldPage, I get the "No access to add [template-name] pages to [path-of-parent]" error on no page is created. After digging a little in wire/modules/Inputfield/InputfieldPage/InputfieldPage.module, I found that $page->publishable() returns false in the corresponding check. But I don't understand why this returns false. In the page tree, the user in editor roll is able to publish/unpublish pages – also also to edit pages so it SEEMS there is a glitch in the permission check. Note: I didn't install the predefined sytem permission "page-publish" because – as far as I understood – if not installed the page-edit permission should also indicate the permission for publishing a page. On another site, using an slightly older version of ProcessWire, the same setup works fine. On the site in question, i am using 3.0.193 dev (DEV branch) – maybe that's the problem? Or I'am doing something wrong? I am glad for any hint in the right direction!

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

A tiny update: I replaced the wire directory with the one from the current MASTER branch (v 3.0.184) an now it works as expected. So maybe there is an issue in the DEV branch only (wich may or may not make the way in an upcoming release). @ryan FYI (Let me know if you need any more information about this)

I could not agree with a "small percent of users"... Front-end is moving and has moved from the "traditional" approach. But let's hope in 2022 some opinions could be changed :).

Let's hope then this is the year! ?

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 ?

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.

Yes, it would for sure. I recall that Ryan was talking about making the PW API available through JS some years back. That would be exactly what we need. A RESTful API like the WP REST API in ProcessWire. This should ideally be available as an optional core module and support all Pro fields.

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.

.I guess the reason why @wbmnfktr resorted to WordPress is that you have the JSON feeds readily available without any coding. And I often thought that it would be really awesome if we had something like this in PW. With all the modules mentioned AppAPI GraphQl etc you still need to write code to get the desired output at the desired endpoint. WordPress handles this out of the box. And this makes it attractive. PW would definitely benefit and get more attention if there was a module that automatically creates RESTful API endpoints following the page tree structure.

As far as I understand, Headless CMS and SSG aren't the same thing really. So which one do you really want? If you'd like to use an SPA framework like React, you'd probably want headless. If you'd like to automagically create static pages, it's a typical SSG setup. For headless, I'd try the AppApi module. For SSG, I'd use Pro Cache. I'm not sure what to make of your example comparison with WP and taxonomies. In PW, you create your own taxonomy or data model. It's easy to create JSON output from your PW instance. Use URL segments, and handle each /json request to your own script. It's ridiculously easy to create JSON feeds (just a bunch of URLs that match your selector). Is that all you really need? Sorry if I misunderstand you, but there's way more to a headless CMS than just having a URL feed. Again, I don't get what you really want in the end. If you need static sites, what good are "JSON feeds" for you?

Update: The solution is to upgrade (paid) to MAMP PRO 6, this version comes with WebP support. The upgrade costs a lot less than all the time I've spent chasing this bug.. ? Edit: it took really long to convert all images, and I figured out a faster way using the command line. Read more in the tutorial.

Thought I'd share this quickly as it helps me get to grips with whether I'm looking at the dev site or live site when working on any client project. Dev site only has AdminOnSteroids module. I add the below to sites/templates/admin/admin.css and add that url the admin css field in the module. Currently only works with default adminTheme. #masthead{ background: rgb(153, 12, 94) !important; } #logo:before{ content: 'DEV '; color: white; margin-right: 1em; vertical-align: middle; display: inline-block; font-size: 1em; letter-spacing: 0.05em; margin: -15px 0.6em 0em 0; } Simply adds a DEV string and changes the header color so I can see I'm on Dev not live. I guess you could do the opposite if you wanted adding content: "LIVE" instead in the CSS.

Wicked! If you happen to stick it up on github I'll use it for sure!

You can do something similar for the frontend: body.dev::before { content: 'DEV'; display: block; position: fixed; bottom: 0; left: 0; color: white; background-color: red; padding: 3px; font-size: 2rem; z-index: 99999; } (If you add a body class .dev when in dev mode) similarly, you could add a few breakpoints, and display stuff like "sm", "m", "l", "xl" so you always know on which viewport you are, while debugging your frontend...

@adrian tyvm if anyone needs example of insert custom field before other form fields: wire()->addHookAfter('ProcessPageEdit::buildForm', function($event) { $pp = wire('pages')->get(wire('input')->get->id); $form = $event->return; $field = wire('modules')->get("InputfieldMarkup"); $field->label = 'TEST'; $field->value = $pp; $field2 = $form->get('title'); // Field to find and insert new field "before" it $form->insertBefore($field,$field2); });

This https://www.mail-tester.com helped me with my e-mail. I got it from someone here on the forum i think.

Wow! Well, that was a can of worms I opened! ? OK, let me come clean and say that I have actually tried - many times! - to load PW on various platforms before. Always Linux based - and let me also say that I have never succeeded. I'm not really interested in a Laragon - Windows approach. I really wanted to get it to run correctly on a Linux based platform. I've tried nginx as well as Apache as the server platform, and neither have set up correctly despite following all the comments and suggestions (except, as I've said before, the 'unzip software' which is, I believe classed as a 'nice to have but not essential'. This time, after yet another frustrating and initially unsuccessful attempt, I thought 'b***r it - I'm going to see what the community can make of this!' Now, despite comments about everything in the one folder, that is NOT how I have things set up. I have an 'index' file in the /var/www/html directory that links to a number of useful applications - node-red; php-lite-admin; webmin etc and these are, of course, in their own sub-folders. And work!! The obvious, and apparently sensible approach, with PW was to put this in a sub-folder, too. No-one ever suggested that wasn't the correct approach! My comments are, then, based on an actively and apparently correctly working web-server and a - supposedly - fool-proof and 'simple to install' CMS and, I'd still argue it wasn't. OK, I accept that my server knowledge isn't that of a professional web designer - but I was 'encouraged' that that wasn't apparently necessary with PW. And, yes, a knowledge of virtual hosting is something I could obviously improve on. But - and I reiterate - that isn't what PW advises me. It tells me 'you are ready to go!' and yet only the front page shows. Now, OK, thanks to the patience of many people here, I ultimately get it working - and I understand the comment 'it wasn't PW - it was your server set-up' because clearly PW was ready to go....but only after making Apache changes. And I'd argue that PW could have better informed me that would be necessary. I really like Jan Romero's remarks, and agree that PW, whilst good, could be made better for less experienced users with an unblinkered look at the install process. And - if that takes place (and it would have to be by persons far more experienced than me!), then.....well, I may have achieved one of my unstated objectives! Thanks again for all the patience, comments and advice - Mike