Leaderboard

Deprecation note (06/2022): This module has been deprecated in favour of a new RockForms module that does not only use NetteForms but also comes with a GUI. You can still use this module if you want, but I will not provide any fixes or updates or support! https://gitlab.com/baumrock/RockForms It uses the great NetteForms from Nette Framework (docs: https://doc.nette.org/en/2.4/forms ) Features: Client AND Server-side validation in one go (you only need to code your rules ONCE) CSRF protection (by processwire) Honepot spam protection (custom) Helper to create PW pages from submitted forms ($form->createPage($parent, $template, $title)) Add ?success=yourform tag to url ONLY after successful submission (for analytics) Recover fields after unsuccessful submission (server side validation error) Define custom actions + message on successful submission UiKit form renderer (more can be accepted by pull requests) Sample Form Setup: <?php namespace ProcessWire; $form = $modules->get('RockForms')->form; $form->addRadioList('salut', 'Anrede', ['m' => ' Herr', 'w' => ' Frau']); $form->addText('forename', 'Vorname'); $form->addText('surname', 'Nachname'); $form->addText('email', 'E-Mail-Adresse') ->setRequired('Bitte geben Sie Ihre Mailadresse an') ->addRule(Form::EMAIL) ; $form->addSubmit('submit', 'Anfrage senden'); $form->onSuccess = function($form) { $form->createPage(1017, 'mailitem', date('d.m.Y H:i:s') . ', {forename} {surname} {email}'); // send email // do whatever you want // return success message return 'thank you for your subscription'; }; echo $form->render(); For all available fields you can look here: https://doc.nette.org/en/2.4/form-fields Validation: https://doc.nette.org/en/2.4/form-validation Rendering: https://doc.nette.org/en/2.4/form-rendering More complex form example of the screencast: Module is alpha and not well tested yet. It should be save to use, but there might be breaking changes in the future. Also I'm quite sure that not all possible situations are covered. There are some switch() statements that check for the fieldtype and I only implemented the ones I needed so far. All others are easy to add - please make pull requests if you find any unsupported fields. Thank you. LIMITATIONS: Multiform support limited Changelog: 6.8.18 add multiform support 8.4.18 v2 little bugfix + load assets automatically 19.3.18 alpha release

As the topic title says I want to share an idea I came up today: Why not track my module installations via Google Analytics? Very simple one, but huge potential and maybe somebody else has not thought of this possibility yet. It can also be used to track sent emails, submitted forms, log errors, whatsoever... $http = new WireHttp(); $http->post('http://www.google-analytics.com/collect', [ // Make sure to use HTTP, not HTTPS! 'v' => 1, // Version 'tid' => 'your-tracking-id', // Tracking ID / Property ID. 'cid' => 555, // Anonymous Client ID. 't' => 'event', // hit type 'ec' => 'myEventCategory', // category 'ea' => 'myEventAction', // action 'el' => 'myEventLabel', // label ]); You can test your setup here: https://ga-dev-tools.appspot.com/hit-builder/ Happy tracking

I agree, https://gtmetrix.com/reports/www.cmscritic.com/z8JiOUJr

Have a read here: http://daily.unitedlanguagegroup.com/stories/editorials/inside-design-language-selector-no-flags

Nice, seems you had more time on this than me on my very similar module If you (or someone else) could devote enough time I can share my module that I have already started to polish. Perhaps you could merge the two or get ideas from it:

Offtopic, Tracy praise: You can use d() to dump and if you select some lines in the console only those lines will be executed. No need for commenting out

RockSqlFinder is sooooo fast and memory friendly, even when using one page. Really nice.

As I said, I used the PW internal one https://gitlab.com/baumrock/RockForms/blob/master/RockForms.module.php#L68-75 Sorry, I don't understand your first post. Do you mean you setup an admin page and then you can render this page directly as form on the frontend? Interesting idea. This way one could use the processwire admin to build forms. Then on the frontend we could to $form->loadFromPwTemplate('myrequestform'); I think that would make a lot of sense since the page is needed for logging anyhow. Ajax: I guess you implemented a vanilla js solution? datepicker, autocomplete, autogrow, character counter Pff, no need for this at the moment. where/how do you define those settings? Add css classes Good point. I'm sure this will be useful. date/ip/lang Mhm, might make sense as well. Ok, so as soon as we start adding all those things it might also make sense to have a custom process module to handle the forms. And also install the necessary fields on installation. Should not be a big deal. The problem is, that I need to work on my Datatables module now (will be a perfect companion for this module for listing all form submissions). Then finish some client work and then I might find time for such additions. If anybody else thinks he can find time earlier feel free to take over. I think the module is already usable as is, I just wanted to share it early to start a discussion (which appearently worked out).

Module updated to version 1.0.2. The Whois information request is triggered accordingly to the module's option Thanks for the bug report @Juergen

I think I don't get your point - it is already exactly what you are suggesting. And yes I plan to maintain it, since I need forms often and it was always a pain to get them running properly. Though I will 100% stick to uikit, so if anybody needs support for any other frameworks just open a PR and add code here: https://gitlab.com/baumrock/RockForms/blob/master/RockForms.module.php#L144 Not really, but forms always bothered me for a long time (you know it), I was not really happy with my nette implementations, I knew you had one implementation lying around somewhere but then I decided to implement it on my own It was fun Your screencast looks nice, but I'm not sure if we should go this direction... I don't want to build a replacement for FormBuilder. The intention is to make it really really easy and fast (and secure) to get up and running with simple forms (like contact forms and newsletter subscriptions). This always seems to be a little request for my clients but it actually meant a lot of work for me. I've purchased and tried FormBuilder but somehow didn't like it. Maybe because I find it easier and more fun to program my own version than learning to use otherone's software What you are doing in your screenshot can already be done easily with my module: Just setup the template and fields you need and then put the code in the onSuccess() callback, for example: $form->onSuccess = function($form) { // send mail ... $mail->body = $pages->get(123)->mailBody; // multilanguage email response text field ... // redirect to any page $this->wire->session->redirect('yourpageurl'); } I don't want to define a GUI for this module since I don't think it is necessary. It would mean a lot of work and not a lot of benefits. Or even worse, it would cost flexibility. If you need a GUI for your clients it's easy to build one on your own. And it would be totally customised and not packed with features nobody needs (thats the beauty of PW imho). Having said all that, I'm happy to hear feature suggestions that you think would make sense for such a module. For example a method to render the form into a HTML table to send via mail is on my mind but not implemented yet.

You have to check from the module which has its class name stored in the modules directory. For Hanna Code this is TextformatterHannaCode (not ProcessHannaCode). For modules such as Hanna Code that contain additional sub-modules the simplest way to update is probably via ProcessWireUpgrade - then you don't need to think about which class name is the one stored in the modules directory.

So if any documentation project aimed at creating a user/admin/modules/best practices manual(s) was started up, I would be happy to help however I could. I'm more of a back-end server person, not a web designer, and I really don't understand how to effectively use pw yet so maybe I could learn something from writing stuff.

Is it a Repeater that you need? http://processwire.com/api/fieldtypes/repeaters/ https://processwire.com/videos/repeater-field-type/ https://modules.processwire.com/modules/fieldtype-repeater/ https://processwire.com/talk/topic/958-repeatable-fields/

NOTE: This thread originally started in the Pub section of the forum. Since we moved it into the Plugin/Modules section I edited this post to meet the guidelines but also left the original content so that the replies can make sense. ProcessGraphQL ProcessGraphQL seamlessly integrates to your ProcessWire web app and allows you to serve the GraphQL api of your existing content. You don't need to apply changes to your content or it's structure. Just choose what you want to serve via GraphQL and your API is ready. Warning: The module supports PHP version >= 5.5 and ProcessWire version >= 3. Links: Zip Download Github Repo ScreenCast PW modules Page Please refer to the Readme to learn more about how to use the module. Original post starts here... Hi Everyone! I became very interested in this GraphQL thing lately and decided to learn a bit about it. And what is the better way of learning a new thing than making a ProcessWire module out of it! For those who are wondering what GraphQL is, in short, it is an alternative to REST. I couldn't find the thread but I remember that Ryan was not very happy with the REST and did not see much value in it. He offered his own AJAX API instead, but it doesn't seem to be supported much by him, and was never published to official modules directory. While ProcessWire's API is already amazing and allows you to quickly serve your content in any format with less than ten lines of code, I think it might be convenient to install a module and have JSON access to all of your content instantly. Especially this could be useful for developers that use ProcessWire as a framework instead of CMS. GraphQL is much more flexible than REST. In fact you can build queries in GraphQL with the same patterns you do with ProcessWire API. Ok, Ok. Enough talk. Here is what the module does after just installing it into skyscrapers profile. It supports filtering via ProcessWire selectors and complex fields like FieldtypeImage or FieldtypePage. See more demo here The module is ready to be used, but there are lots of things could be added to it. Like supporting any type of fields via third party modules, authentication, permissions on field level, optimization and so on. I would love to continue to develop it further if I would only know that there is an interest in it. It would be great to hear some feedback from you. I did not open a thread in modules section of the forum because I wanted to be sure there is interest in it first. You can install and learn about it more from it's repository. It should work with PHP >=5.5 and ProcessWire 3.x.x. The support for 2.x.x version is not planned yet. Please open an issue if you find bugs or you want some features added in issue tracker. Or you can share your experience with the module here in this thread.

For a while now, I've wanted to expand my skills into mobile app development. Having done some Googling and watched several YouTube videos regarding native versus hybrid apps, I decided to go native. I did my homework regarding React, Ionic, etc and decided to go native. I settled on the NativeScript + TypeScript combo although it seems most tutorials are about Angular. Anyway, after watching quite a number of videos, just when I was about to dive into things, someone turned off the lights! Progressive what? PWA? Haven't you heard about this? No, I haven't! Where have you been? Let's not go there... OK, so I don't know much about mobile apps as you can tell (or even much about frontend development as my personal websites do tell, ). At first, I dismissed Progressive Web Apps as another Google tech that is bound to fail....until I read that Twitter, Blah Blah, have joined the bandwagon and the thing is gaining serious traction. It was back to more Googling. I now know (I think) what Progressive Web Apps are (or are meant to be). Naturally, my first question was Progressive Web Apps versus Native apps. So, I asked Google. Google told me to stop asking that question. To be precise, it told me (at least with the first couple of results) that that was the wrong question to ask! I tried finding out why, but the answer was hidden down some deep mobile rabbit hole that I didn't have time to fully descend into. It seems I am back to where I started. Native apps seem to be promising first class citizenship (who doesn't want that?). On the other hand, I am being told, Progressive Web Apps are the bright shiny future that will solve all our problems (and maybe even shutdown the Play Store! ). Please be gentle with my ignorant self. I have asked Google but she hasn't bothered or cannot be bothered to reply or I am asking her the wrong questions. I simply want to know if Progressive Web Apps can or will one day be able to be used to: Build apps like WhatsApp, etc? Build games like Candy Crush (what?)? Build premium apps (how would that work?) Or...are Progressive Web Apps just a replacement for mobile.domain.com? Should I ditch my NativeScript?? If someone could help me out here (once you're done laughing at my silly questions ) and/or point me to resources that will answer my questions, I'll be forever grateful . Thanks

If you're looking to do an elaborate a page builder with ProcessWire and don't want to pull your hair out, I highly recommended viewing this video: A couple notes: with the css grid specification, you can assign multiple blocks to the same grid-area but they will overlap each other. I've "overcome" this by combining multiple blocks into a parent div and assigning that instead. pretty easy to do. i didn't demonstrate it, if your blocks have a grid structure within them (like built with flexbox), you can still assign that block to a grid-area. so if your blocks themselves have a grid structure, that's ok. for example, if your css grid layout is 6 columns, but you have a block that has a grid inside of it (built with like uikit's grid that's 5 columns), you can assign that block to the grid-area. with the css grid specification, the flow of the blocks does not have to match the flow of the grid-areas. this is insanely powerful. Enjoy.

https://gitlab.com/baumrock/RockSqlFinder is already online. The datatables module is in the works but will need quite some time...

Wow @bernhard. This looks so good. Can't wait to get my hands on it. Could you give me access to the source so I can play with it? Really looking forward to this module.

Don't use relative paths. They are an artifact of days long gone (at least in regular websites - there are use cases in routed app components) and they create more problems than they solve. If you worry what happens when you move a site to a deeper directory, use PHP to prefix your links with $config->urls->root.

I'm not entirely convinced You would have to create those fields and remember their names if you need to add setRequired and such things. But it's an advantage if you willl save it to a page with the same fields.

I will try to do it, I never played with modules and multilanguage

I don't think so. It would be easy to loop the fields defined in a processwire template and add the corresponding fields to the nette form (of course not with all settings like width, required etc. but that should be done 100% by nette imho). My idea was just to setup a pw template with the fields and then render the form in the template file like this: <?php $form = $modules->get('RockForms')->form; $form->addFromTemplate('mypwformtemplate'); $form->getComponent('email')->setRequired(); ... $form->addSubmit('submit', 'Subscribe'); $form->render(); The type of the nette field could be defined via the PW field's title: text_forename (regular textfield), password_mypassword (password field), mycustomnettefieldtype_demo (custom nette field). For more complex forms there would still be the option to define the form manually (no drawback). My setup needs only one php file to define the form and to process the input, not sure why you split that into two files?

Multialguage discription works great if you have the same images for all languages. But when you need to show different images in defferent languages you could use language alternate fields. In this case you will have some fields like images images_english images_ukrainian And you don`t need possibility to enter different discription per language, because different fields will be shown per language. So I think that it would be nice to have this option overidable by template.

This is what I implemented so far: ajax submit datepicker, autocomplete, autogrow, character counter add CSS classes to controls for better CSS targetting add date, ip and language to each submission I've also added a honeypot but on larger sites it doesn't seem to be effective. I need to integrate a captcha, this is one of the reasons I haven't shared it yet.

I see your points - I started that way too. Then I realized it's much easier to handle multi-language strings like success message, etc so I added a GUI. I still think this is an improvement, I can make adjustments much easier in the admin when needed. But it's not a requirement, you can use it purely from code too. The form process part looks like this: if ($nfh->checkSuccess()) { $nfh->saveToPage($nfh->getTitle('name, email')); $nfh->sendAdminEmail(); $nfh->getResponse(); exit; } Here saveToPage, sendEmail, sendAdminEmail methods can have parameters so you don't need to use the corresponding admin page. If there's a page for it, then adding a form is as easy as $nfh = addForm(1066); echo $nfh->form; // or $nfh->renderForm() The module loads the form and form field files from page ID 1066 name. Anyway, I think I'll clean up it a bit and share as I see there's a need for it.

So no idea what happened here in the end, I solved the issue by deleting the Role, adding the role again and assigning the template as viewable. This solved it by I have no idea why (I guess there must have been a setting somewhere that was conflicting).

Love this thread. Once you make a PR for the findArray to the PW repo, please let us know, so we can upvote it. I would definitely be willing to pay if RockDatatables was released as a pro module.

Thanks @adrian. I'll look at these when I upgrade the module to PW3.x-support only. I have no ETA though, I'm afraid.

You could also use a Page Table (ProFields), available in ProcessWire's core and freely installable from the backend. You can select a parent for the items (unlike repeaters), enter the table fields you want to display in the administration panel... You could perhaps also use a Page Reference Field, choose a way of selecting that suits you, select a parent page with children pages that only have the fields you need...

@Robin S, Just realised it might be better if I uploaded some sample configurations and screenshots to better illustrate my points. I can do it once my laptop returns from repairs.

@neosin pls use jumplinks or see @kixe‘s fork above

Not sure what you mean here. When you use the feature I mentioned to select a page that will hold the default value for the image field, the image field will have the value of the default field when it is empty on a particular page. The value will be a Pageimage object or a Pageimages object depending on the field settings (and assuming you have one or more images in the field on the page used for the default value). You shouldn't need to do anything different to get the object or any of its properties (url, etc) than you would do if the field was populated on the page. In other words, you can do something like... $page->image->size(400,300)->url ...and it will work the same regardless if the image is coming from an image that is actually in the field on that page, or the default value when the field is empty.

Good catch! Just modified the module to allow loading both, thanks. (will be released later)

Ah, now I see. If there is a CKE CSS configured in the field page, then the one configured in AOS is not loaded. Thank you.

There is a feature for this built into image fields (Details tab):

v1.8.5 is available, which contains @Robin S CKEditor Link Files CKE plugin, multilanguage-ready. @theo Have you managed to solve the issue? I couldn't find any relevant info on "Browser Network Analysis". Are you sure you entered a correct path?

Hello all. I just tried to upgrade an existing profile from 3.0.95 to 3.0.96 and noticed similar behavior as it was mentioned by @theo and @Hackasacka . The upgrade was working perfectly fine on my local server and hosting, however now trying to upgrade automatically the core led me to a folder 'wire' and 'wire-3.0.96' (where 3.0.95 should be the old backup). Strange enough, this only happens with the core of PW but all other modules work just fine. I will proceed to upgrade this one manually and try to do another automated upgrade on next release to see how it would behave. P.S. Manual upgrade works perfectly fine and all I had to do was to extract from the latest version archive the wire, install.php and .htaccess and after a backup of the existing ones to place them in the root domain folder. Tested the frontend and backend - all seems to be fine and the module reports no newer upgrades.

That would be brilliant. Though @Soma might have to rename his module from Pollino to Pollissimo (it feels like it's about to outgrow the diminutive...)

Unless my memory fails me, all I did was add support for multiple answers and user-submitted suggestions. Might've made some general purpose (JavaScript/CSS?) tweaks too, not entirely sure anymore. Once the current version stabilises, i.e. I know whether the updates from @BitPoet get merged in, I could set up a new PR for these

I made this with Page Tables. It's not 100% perfect yet, but works for my demands _init.php: // Main Content if ($page->views) { $content = "<div id='views' data-uk-grid-margin>"; $contentview = ""; foreach ($page->views as $view) { $typ = $view->template; $id = $view->name; $colxl = $view->colxl; $gridcountxl = $colxl; $colsm = $view->colsm; $gridcountsm = $colsm; $colxs = $view->colxs; $gridcountxs = $colxs; $fw = $view->fullwidth; $nmnp = $view->removemargin; $border = $view->hasborder; switch ($typ) { case "Text": $text = $view->textfield; $ct = "<div id='{$id}' class='uk-width-small-". $colxs ."-12 uk-width-medium-". $colsm ."-12 uk-width-large-". $colxl ."-12'>$text"; $ct .= checkGrid($gridcountxs, $gridcountsm, $gridcountxl); $ct .= "</div>"; $contentview .= fullWidth($fw, $cv=$ct, $nmnp, $border); break; case "SlideGalerie": $bilder = $view->images; $sg = ""; $sg .= "<div id='{$id}' class='product-gallery views owl-carousel owl-theme'>"; foreach ($bilder as $b) { $bbig = $b->width(1920, $options); $bsmall = $b->size(485,325, $options); $bretina = $b->size(970,650, $options); $sg .= "<div class='g-item'>"; $sg .= "<a href='{$bbig->url}' data-uk-lightbox=\"{group:'{$view->name}'}\">"; $sg .= "<img data-src='{$bsmall->url}' data-src-retina='{$bretina->url}' class='owl-lazy' alt='$b->description'>"; $sg .= "</a>"; $sg .= "</div>"; } $sg .= "</div>"; $sg .= checkGrid($gridcountxs, $gridcountsm, $gridcountxl); $contentview .= fullWidth($fw, $cv=$sg, $nmnp, $border); break; // Case .. Case .. Case .. } $content .= $contentview; $content .= "</div>"; } _func.php /** * @param string $gridcountxs * @param string $gridcountsm * @param string $gridcountxl * @return string */ function checkGrid($gridcountxs = '', $gridcountsm = '', $gridcountxl = '') { $out = ''; if ($gridcountxs >= 12) { $out .= "<div class='uk-clearfix uk-visible-small'></div>"; } if ($gridcountsm >= 12) { $out .= "<div class='uk-clearfix uk-visible-medium'></div>"; } if ($gridcountxl >= 12) { $out .= "<div class='uk-clearfix uk-visible-large'></div>"; } return $out; } /** * @param string $fw * @param $cv * @param string $nmnp * @param string $border * @return string */ function fullWidth($fw = '', $cv, $nmnp = '', $border = '') { if ($nmnp) { $nomargin = 'uk-margin-top-remove'; } else { $nomargin = ''; } switch ($border) { case '1': $b = 'border-top'; break; case '2': $b = 'border-right'; break; case '3': $b = 'border-bottom'; break; case '4': $b = 'border-left'; break; case '5': $b = 'border-all'; break; default: $b = ''; break; } $fout = ''; if ($fw) { $fout = "<div class='full-width " . $nomargin . " " . $b . "'>" . $cv . "</div>"; } else { $fout = "<div class='uk-container uk-container-center uk-margin-large-top " . $nomargin . "'><div class='uk-grid " . $b . "'>" . $cv . "</div></div>"; } return $fout; }

Thanks adrian, I also noticed that but it seems it was too late yesterday... forgot to check if there are any closures to execute so it loaded all the page objects even if there were no closures please check the update: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L59 Very interesting (and great imho) is also this test using closures: So, of course with closures it is a LOT slower (because we load the page objects in memory), but the additional costs for each closure are less than for the first one. Thats because the page is already available in memory after the first closure: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L62-63 And finally one with "images:description" syntax: And insanely fast without the closure @all Any ideas wich character to use for image field descriptions (and maybe other fields)? At the moment I'm using the pipe, but that would lead to problems when a user uses the pipe for descriptions (see the above screenshot) For file- and page fields the pipe should be fine because we could use it directly for further selectors and files should not contain any pipes.

made huge progress on this Example query with all the features: $pages->findObjects('template=item, limit=100', [ 'title', // page title field 'field1', // regular textfield '(SELECT #data# FROM field_field1 WHERE pages_id = pages.id) AS `sql`', // custom sql query (multilanguage) 'images:description', // imagefield + description 'pagetest:status:created:templates_id', // pagefield + page status + created time + template id 'pagetitle' => function($page) { return $page->title; // example of a closure }, ]); Explanation: regular textfields can easily be queried just by defining their name as string any custom sql query is possible, even multilanguage when using #data# keyword images:description syntax works for all file fields page:status:created works for all pagefields and last but not least a very nice helper for fast and easy queries and small amounts of data: closures Output (default language): And the same query as datasource for a datatables field: This will be really, really awesome @theo I plan to add a lot of other stuff to my datatables module and that will take some time. I put the new pageFinder in a separate module. You can have a look here: https://gitlab.com/baumrock/RockSqlFinder Maybe you want to test it? Also @adrian might be interested? Currently it supports FieldtypeText, FieldtypePage and FieldtypeFile - but it should be easy to add others... Like Repeaters for example. Any other fields could be queried via custom SQL queries... And for really complex joins there will be another module

how? its a shared host, so god knows.

That is absolutely feasible. An application doesn't really care where it gets its data from, you just need to send a PWA compliant app bundle down to the client and within that app consume some APIs to get data. Whether that API is on a Digital Ocean, AWS, Linode server, or whether its written in NodeJS, PHP, Ruby, Go or whether its built on top of Wordpress, Magento, ProcessWire doesn't make much of a difference. I'm not sure how familiar you are with PWAs, but if you haven't built one yet I'd suggest you test it out without the ProcessWire part of the stack. If you can build a PWA that consumes the Github API, caches it with a Service worker and displays it offline. Then moving to a ProcessWire API Backend will be dead simple. ProcessWire is fantastic for this sort of headless/API based CMS, So you're making a good choice there

I just finished a medium sized website/SPA using processwire and vue with vue router and vuex. Has lots of nice features like server side rendering, happy to share details with people if they'd be interested. Shoot me a PM.

in regard to the public / private part, what @blynx mentioned, especially the by PW default "private fields" simply needs to be covered via accessrights on fieldlevel, set by the dev who wants to use this module. There is no need for public/private endpoints in the module. Or I'm wrong? If you build a site without that module, you are done by simply use display logic in your templatefiles to control output of fields. If you want to use the module, you additionally have to mimik the accessrights via PW fields access settings. Thats how I understand it by just reading this really valuable thread. @Nurguly Ashyrov

There is not need for different endpoint for users with different roles. The module does not have any authentication/authorization logic on it's own. The users that will be able to authenticate with this module are the same users in your ProcessWire installation. When I mentioned implementing authentication, I was talking about logging in via GraphQL api, like via AJAX. In reality it will be the same $session->login('username', 'password'), nothing more. No, no. Of course not. I am sorry for the confusion here. Legal templates mean legal for the api. It does not mean it will make it available to the public. Like I mentioned earlier the module checks if the requesting user has permissions to view, edit, create and etc. If say you select user template as legal. It does not mean it will be public. It means it is available via api to those who are authorized to view it, authorized via ProcessWire's access control system. I personally don't think there is even a need for the legal templates option. But it is helpful if you have too many templates and selecting only few can reduce the schema size and make api faster. I think there is a bit confusion about this. I want emphasize that this module does not make any data public, nor does it anything private. That is not the module's concern. The module's job is to make your data available in a JSON format, in addition providing the ability to consume that JSON data via GraphQL api. If the user does not have permissions to view a certain page according to ProcessWire's access control system then he won't be able to fetch it. The same goes for fields. When implemented the user will be able to access only those fields that he is authorized via ProcessWire's access control. But I will add an option for legal fields also, because that also could help reduce the initial schema size.

This sounds good, and that's basically everything that a "generic", publicly accessible API can do. I've got no complaints here What I've found out while playing with the WP REST API a while ago is that even though permissions are sensible, it may end up showing more than the public site. Part of it is about things like (not just page but) field level permissions, and part is about pages that exist and are publicly viewable for technical reason, but are not *intended* for public consumption, if you get what I mean. Surely it would be best to always use native permission rules to limit the visibility, but sometimes a site may have content that is viewable only if you know the direct URL, and a public API like this may make it "more public" than the developer intended. Another thing is that there may be a code-level permission check in place, and a module like this would have hard time figuring that out. That being said, have you already implemented or are you considering implementing custom selector support for such limits? I.e. allow the developer to manually define a selector that returned pages must match, or alternatively should never match? I think that could make a lot of sense from a security point of view, particularly for public API endpoints, where it might actually work best as a per-endpoint setting

You couldn't be more precise! GraphQL and ProcessWire fit each other very well. All this module does is just maps the ProcessWire's fieldtypes with GraphQL type system. It literally tells GraphQL that FieldtypeText is a StringType, FieldtypeDate is DateType and so on. And for getting the data, on average, it is less than a single line of code . Since you can access value of a page field like $pages->$fieldName all primitive fields inherit a method for accessing data from one place. I sure having lots of fun writing this module. I agree with Drupal "godfather" totally. The need for quick bootstrapping of an api service with flexible content structure is in very high demand. I had a hard time landing a job as a ProcessWire developer. So I target myself as a full-stack SPA developer in React.js/Node.js. I tried many of open source REST frameworks in Node.js that would help me get started with a project quickly. But non of them offered enough flexibility for my style of programming (I guess ProcessWire spoiled me ). At the time I figured out the best way to build REST api in Node.js I found out that REST is not flexible either. When an app starts evolving REST gets very messy. The Github built three versions of their REST api and still are not happy with it and now decided to release a GraphQL api which probably will not introduce breaking changes in the future, because GraphQL is designed that way. I think if made correctly, this module could bring a great value to many ProcessWire users. That's right. That is the main goal of this module. I will eventually implement all the features that needed to build a complete SPA with this module. I just try to move carefully and a usage feedback from community would help a lot. Just installing it and making couple queries to confirm that it works as expected would be great.

If you want to make it a little cleaner, you can do: $articles = $pages->find("template=articles, parent.status<".Page::statusUnpublished); Now you know when looking back on your code, what status you are looking for. Also, I changed the operator from != to < because the numbers that drive these status values are bitwise and are added to together. This way you could also have hidden applied to the category and it would work as expected, but if you use the != you'll get the articles returned again, because the status value will be the addition of unpublished and hidden. Here are the values: https://github.com/ryancramerdesign/ProcessWire/blob/6cba9c7c34069325ee8bfc87e34e7f1b5005a18e/wire/core/Page.php#L76 Note that 2049 is the addition of statusOn and statusUnpublished. Throw statusHidden in there as well and you end up with 3073.