Leaderboard

Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!

Paginated forms: Looking > Forward > To > This > Alot. Thank-you!

Hello everyone, Recently I spent some time researching how I can update my workflow. I really enjoy working with TailwindCSS however, when it comes to Javascript, I often find myself having to search around to find a good package. Often I find myself having a package for lazy loading, a package for sliders, a package for animation, a package for parallax and a package for ajax. Before you know it, you are worrying about dependicies, conflicts and vunrabilities for many different packages. Since the push is to get rid of jQuery and use native javascript, often each will have their own utility classes, some of which do the same thing. This adds a lot of bulk to the website. This is what I love about UIKit, it provides plenty of functionality for a small ~130KB unminified. Not many know this, but the UIKit helper classes are exposed via the API too. So it means you will not have to worry about your javascript working cross-browser (https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md). The perfect thing would be to combine UIKit and TailwindCSS, but the best way to achieve this is up for grabs. I personally use TailwindCSS base and implement components from UIKit. I then use PurgeCSS on the CSS file to make sure anything unused by either UIKit or Tailwind isn't making it to production. I do this using Parcel JS. I have used Webpack and Gulp previously, but I find Parcel is a simple and easy way to get a project started (and it's fast!). The next thing I've found is UIKit is not always the answer. There are now more than ever better ways of achieving things in browser. Such as CSS Grid, `position: sticky`, and `object-fit` try to use these CSS alternatives where possible. Purge will always make sure that you get the smallest possible file size, so avoid using the uk-grid element where possible and use CSS Grid. I have setup a github starter template (https://github.com/TomS-/UIKit-TailwindCSS/tree/master) if you want to have a look at it. CSS Grid will introduce intrinsic design (https://www.youtube.com/watch?v=lZ2JX_6SGNI - Great series) Next will be to use WebP, there is plenty going around on the blogs now about this, but this will make a massive improvement to your Google Page Insight rating (https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.tikari.co.uk%2F&tab=desktop). I would love to hear your web manifesto - and ask me anything about mine ?

https://www.fieggen.com/shoelace/index.htm Website I bookmarked some time ago.

A neat new Github feature: https://help.github.com/en/articles/navigating-code-on-github And while I'm at it: If you're frequently navigating through GH repos, I can highly recommend this browser add-on: https://www.octotree.io/

https://github.com/processwire/processwire-issues/issues/252#issuecomment-467473684 Quote: "If a page is saved (in the admin) and errors are generated by the page editor form, the page receives a Page::statusIncomplete status, indicating something may be missing on the page. When the page is saved without error, this status is removed." There is more about it in the GitHub issue.

This module will log information about all mails that are sent via WireMail to the PW logs From PW Weekly: https://github.com/BernhardBaumrock/RockMailLogger https://modules.processwire.com/modules/rock-mail-logger/

That's Brutalism, right? Well... the design is a challenge but the estimated traffic and SEO coverage is quite nice or almost impressive to be honest.

I prefer to change the pagination style on _init.php, or _func.php, for instance, to use Tailwind classes, using Ryan's modified example:

Thanks @Sergio, @apeisa and @Tom. for bringing Tailwind CSS to our attention. Incidentally, I checked out the Tailwind screencasts and ended up picking up Vue.js as well :-). Anyway, to my first question. @apeisa, could you please clarify this statement about ProcessWire custom classes. Does it mean you use Tailwind in the backend/admin/modules or does it mean you use ProcessWire inputfields in the frontend? Thanks. Cross-posting Tom's Tailwind + UIKit + Grid resource:

@ryan any news on this? It works really great in my setup and I think this approach can open up a lot of great options for a better DEV/LIVE workflow with processwire. In my current project where I modified the core file it was really just doing a git clone myrepo.git git submodule update --init --recursive # restore db dump And I had a working copy of the site that downloaded all assets on demand while working with it! This is really awesome but it would break on every core update. I could implement some hack that does a str_replace and file_put_contents in my dev environment to prevent updates breaking this feature, but it's really just adding three underscores to one core file thanks to the ingenious hook system ? PS: I've created an issue for this: https://github.com/processwire/processwire-issues/issues/954

$wire->addHookAfter("InputfieldForm(name=form-application)::processInput", function($event) { $form = $event->object; /** @var InputfieldForm $form */ if(count($form->getErrors())) return; // do your stuff $input = $event->arguments(0); }); Something like this? See https://processwire.com/api/ref/inputfield-form/process-input/

This reminded me of endless hours making my Geocities site look perfect. And your the site looks awesome! And then I proceeded to spend an hour learning about shoelaces. ? Fascinating stuff! ?

The notes on the Settings tab of Page Edit are a good summary of what the statuses mean: Hidden and unpublished pages are both excluded from selectors (unless you override this) - the difference is that a hidden page is viewable if the URL is known, whereas an unpublished page cannot be viewed unless the user is logged in and has edit access for the page.

Tailwind CSS Framework, a utility-first CSS framework for rapidly building custom designs This thread is a place for ProcessWire developers who use (or would like to use) Tailwind CSS to share their experience, tips, frustrations , solutions, code snippets and generally discuss all things tailwind. From the creators of Tailwind CSS Moderator note: the first few posts in this topic were split from this thread. ########################## Thanks, @apeisa! Yes, Tailwind is awesome! Responsive classes are a clever idea indeed, much easier to work with. The authors did an excellent job and keep improving it. Some people may feel a little sceptical, but I fell in love with it the moment I built my first project. Although nowadays I work alone, I believe that Tailwind makes work between a frontend and backend developers much easier because it makes the HTML more declarative and you can grasp what the classes mean in a glimpse.

I've spent the last while experimenting with srcset implementation - and PageimageSrcset is the result: PageimageSrcset Provides configurable srcset and sizes properties/methods for Pageimage. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. It does not handle images rendered in CKEditor or similar fields. For an introduction to srcset and sizes, please read this Mozilla article about responsive images. Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x"); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ "320", "480", "640x480 768w", "1240", "2048 2x", ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ "320w" => [320], "480w" => [480], "768w" => [640, 480], "1240w" => [1240], "2x" => [2048], ]); // Use the default set rules with portrait images generated for mobile/tablet devices $srcset = $image->srcset(true); // Return the srcset using all arguments $srcset = $image->srcset("320, 480, 640x480 768w, 1240, 2048 2x", [ "portrait" => "320, 640", ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. On large sites this may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Portrait Mode In many situations, the ratio of the image does not need to change at different screen sizes. However, images that cover the entire viewport are an exception to this and are often the ones that benefit most from srcset implementation. The main problem with cover images is that they need to display landscape on desktop devices and portrait when this orientation is used on mobile and tablet devices. You can automatically generate portrait images by enabling portrait mode. It is recommended that you use this in combination with Pageimage::focus() so that the portrait variations retain the correct subject. The generated variations are HiDPI/Retina versions. Their height is determined by the portrait ratio (e.g. 9:16). Variations are always generated, regardless of whether the original image is smaller. Upscaling is disabled though, so you may find that some variations are actually smaller than they say they are in their filename. The sizes attribute should be used when portrait mode is enabled. Pageimage::sizes will return (orientation: portrait) and (max-width: {maxWidth}px) 50vw by default, which handles the use of these images for retina devices. The maximum width used in this rule is the largest set width. Pageimage::sizes() There is no option to configure default sizes because in most cases 100vw is all you need, and you do not need to output this anyway as it is inferred when using the srcset attribute. You can use the method for custom sizes though: // The property $sizes = $image->sizes; // Returns 100vw in most cases // Returns '(orientation: portrait) and (max-width: {maxWidth}px)50vw' if portrait mode enabled // A method call, using a mixture of integer widths and media query rules // Integer widths are treated as a min-width media query rule $sizes = $image->sizes([ 480 => 50, "(orientation: portrait) and (max-width: 640px)" => 100, 960 => 25, ]); // (min-width: 480px) 50vw, (orientation: portrait) and (max-width: 640px) 100vw, (min-width: 960px) 25vw // Determine widths by UIkit 'child-width' classes $sizes = $image->sizes([ "uk-child-width-1-2@s", "uk-child-width-1-3@l", ]); // (min-width: 640px) 50vw, (min-width: 1200px) 33.33vw // Determine widths by UIkit 'width' classes $sizes = $image->sizes([ "uk-width-1-2@m", "uk-width-1-3@xl", ]); // (min-width: 960px) 50vw, (min-width: 1600px) 33.33vw // Return the portrait size rule $sizes = $image->sizes(true); // (orientation: portrait) and (max-width: {maxWidth}px) 50vw // The arguments above are a demonstration, not a recommendation! Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: Only used if specified. Any values in the formats described above can be passed. uk-img: If passed, as either true or as a valid uk-img value, then this attribute will be added. The srcset attribute will also become data-srcset. Please refer to the API Reference for more information about this method. // Render an image using the default set rules echo $image->render(); // <img src='image.jpg' alt='' srcset='{default set rules}'> // Render an image using custom set rules echo $image->render(["srcset" => "480, 1240x640"]); // <img src='image.jpg' alt='' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w'> // Render an image using custom set rules and sizes // Also use the `markup` argument echo $image->render("<img class='image' src='{url}' alt='Image'>", [ "srcset" => "480, 1240", "sizes" => [1240 => 50], ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 1240px) 50vw'> // Render an image using custom set rules and sizes // Enable uk-img echo $image->render([ "srcset" => "480, 1240", "sizes" => ["uk-child-width-1-2@m"], "uk-img" => true, ]); // <img src='image.jpg' alt='' data-uk-img data-srcset='image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w' sizes='(min-width: 960px) 50vw'> // Render an image using portrait mode // Default rule sets used: 320, 640, 768, 1024, 1366, 1600 // Portrait widths used: 320, 640, 768 // Original image is 1000px wide // Not possible to use portrait mode and custom sets or portrait widths in render() // Sizes attribute automatically added echo $image->render(["srcset" => true]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.jpg 1024w' sizes='(orientation: portrait) and (max-width: 768px) 50vw'> Configuration To configure this module, go to Modules > Configure > PageimageSrcset. Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. Portrait Mode Set Widths A comma limited list of widths to create HiDPI/Retina portrait variations for. Crop Ratio The portrait ratio that should be used to crop the image. The default of 9:16 should be fine for most circumstances as this is the standard portrait ratio of most devices. However, you can specify something different if you want. If you add a landscape ratio, it will be switched to portrait when used. Any crops in the set rules ({width}x{height}) are ignored for portrait mode variations as this ratio is used instead. UIkit Widths If your website theme uses UIkit, you can pass an array of UIkit width classes to Pageimage::sizes to be converted to sizes. The values stored here are used to do this. If you have customised the breakpoints on your theme, you should also customise them here. Please note that only 1- widths are evaluated by Pageimage::sizes, e.g. uk-width-2-3 will not work. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Image Suffix You will see this field when Remove Variations is checked. The value is appended to the name of the images generated by this module and is used to identify variations. You should not encounter any issues with the default suffix, but if you find that it conflicts with any other functionality on your site, you can set a custom suffix instead. Debug Mode When this is enabled, a range of information is logged to pageimage-srcset. PageimageSrcsetDebug.js is also added to the <head> of your HTML pages. This will console.log a range of information about the images and nodes using srcset on your page after a window.onresize event is triggered. This can assist you in debugging your implementation. The browser will always use the highest resolution image it has loaded or has cached. You may need to disable browser caching to determine whether your set rules are working, and it makes sense to work from a small screen size and up. If you do it the other way, the browser is going to continue to use the higher resolution image it loaded first. UIkit Features This module implements some additional features that are tailored towards UIkit being used as the front-end theme framework, but this is not required to use the module. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.123 is required to use this module.

Ah, that meant just for purge css. Things like pagination markup (and css classes it uses by default) comes from core module, so if you want to use those and just style using css, you need to disable purge for that part of css.

Done! Thanks.

Sure thing, @kongondo! Let's move it to its own topic, please.

Hi @Sergio and @apeisa. Do you mind if I please hive off your Tailwind CSS discussion into one topic (say, Tailwind CSS for ProcessWire Developers)? It seems to me there is a steady interest in the framework. It would be nice to have one go-to topic where ProcessWire Devs can learn from (and contribute to) in respect of the framework. Personally, I have a few questions as well but I am hesitant to post in this topic since we'll quickly go off topic. Thanks.

Ok, then public function ___execute() { $out = ''; $input = $this->wire('input'); $modules = $this->wire('modules'); $form = $this->modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name", "form_application"); $btn_application_create = $this->modules->get("InputfieldSubmit"); $btn_application_create->attr('id+name', 'hook_accept_application'); $btn_application_create->value = "Start Student"; $btn_application_create->addClass("ui-priority-primary button_submit"); $form->append($btn_application_create); if ($input->post->hook_accept_application) { $form->processInput($input->post); if ($form->getErrors()) { $out .= $form->render(); } else { $this->addButtonsMethods(); } } else { $out = $form->render(); } return $out; } public function addButtonsMethods($event) { wire('session')->redirect(wire('pages')->get(123)->editUrl; }

Have you seen this thread? https://processwire.com/talk/topic/12723-bootstrapping-processwire-in-phpunit/ I'm getting into test-driven development with the Nette Tester module, and am learning how to bootstrap PW. If the PW instance you're bootstrapping has Tracy Debugger installed, "Tracy Logs" give meaningful realtime feedback (after page reload) on bootstrap (and other) errors. This helped me "trace" ? a tricky bug that didn't appear in Tracy "Processwire Logs", or Windows, mysql, or Apache logs. My error was caused by the fact that: While I was logged as Superuser into the admin of the PW instance I was bootstrapping AND the PHP script I bootstrapped from was in a subdirectory of that site by default PW runs bootstrapped scripts as "guest" user, and couldn't access what I wanted - a custom per-user field from the Admin "Profile" section. PW forum searching revealed that Ryan Cramer chose this sane default for security. Ryan's code in this thread solved my problem: <?php $users = wire('users'); $superuser = $users->get("YOUR_PW_USERNAME"); $users->setCurrentUser($superuser); Also be aware, as this page states:

Two sites I have build with tailwind and purge css. Other site css file was 3.4kb and other 2.5kb... I also skip purge from my own css, just tailwind goes through it. It is actually very simple. It does "scan" all the files you need. But in case of ProcessWire custom classes can come from many places, so I felt it easiest to purge only tailwind css. And I am pretty happy with the file size results...

In that case, I guess you'd have to look into using hooks. But digging deeper into @adrian's module description linked before, it seems there's an option that will do just what you are looking for: I have never used this myself, so I guess you should simply try it out and see if it works for you...

I am not sure how I feel about this... It reminds me of lings cars, but not so flashy/bad (apologies if you had a hand in this, not trying to offend anyone). However, It is awesome to see that it is responsive.

Hi, I agree it is a bit hidden, but it is here -> https://processwire.com/api/ref/page/#pwapi-methods-constants.

No problem! When I have some time here I'm planning to build a site profile using Tailwind CSS so more people can see how it can be integrated with PW. Using both the CDN version, which gzipped is around 60kb and using brotli compression goes down to less than 20kb and the webpack installation I mentioned. :)

For anyone having a similar issue, I finally resolved the issue after reading this post... https://processwire.com/blog/posts/pw-3.0.111/ Adding: $event->name = $pages->names()->uniquePageName($event->name) before: $event->save(); sorted it. Many thanks Nik

@Gadgetto My bad. I misled you a bit. I can't find it now, but @teppo made an excellent post about the executeWhatever() aspect of Process modules. In Process Modules, unlike URL segments in the frontend, ProcessWire will 'jealously guard' the first URL Segment, i.e. the Whatever part of execute....(). In other words, if your Process module has a first URL segment, it will look for a method in your Process module named executeYourFirstURLSegment(). If it doesn't find that, rather than render what is in execute(), it returns the error, Processwire: Unrecognized Path and the content The process returned no content. However, this only applies to the first URL Segment. After that, i.e. 2nd, 3rd, etc URL segments will resolve to whatever you decide based on the code you have in the method of the first URL Segment. For instance, in the case /admin/mymodule/firsturlsegment/whatever/, ProcessWire will not complain if there is no 'whatever' as long as firsturlsegment has content. Please find an example Process module below and the demo of it. The example is a bit rudimentary but you get the idea. Normally, I don't include the content of what I want the 2nd, etc URL segments to resolve to within the executeWhatever() method itself. I usually throw those in their own methods or even class. Example In this example, executeColours() is our gateway to anything we want the 2nd URL segment to resolve to. The 'red', 'green', etc segments do not exist independently (i.e. no corresponding executeXXX() methods for them). ProcessWire does not complain since the first segment /colours/ exists as executeColours(). Demo

You can take a look at this module: Or you can build your own image uploader with something like Dropzone.js and some guide from this topic: I think the main backend code to upload and save image to disk and add to page field is within this post: https://processwire.com/talk/topic/67-front-end-image-uploader-like-admin/?do=findComment&comment=3790 $size=filesize($_FILES['imageUpload']['tmp_name']); if ($size > MAX_SIZE*1024){ print 'File troppo grosso'; exit; } //copy the image in secure folder $image_name=time().'.'.$extension; $newname="../site/tmpfiles/profiles/".$image_name; $copied = copy($_FILES['imageUpload']['tmp_name'], $newname); if ($copied) { $userid = $sanitizer->text($input->post->userid); $u = $users->get($userid); $u->setOutputFormatting(false); $u->profilephoto->add("http://".$_SERVER['HTTP_HOST']."/site/tmpfiles/profiles/".$image_name); $u->save(); //delete copied image $tmpfile = $_SERVER["DOCUMENT_ROOT"]."/site/tmpfiles/profiles/".$image_name; if (file_exists($tmpfile)) { unlink ($tmpfile); } }else{ print "Errore nel salvataggio del file."; exit; }

Hi @alexmercenary - aye I didn't have the "uk-img" enabled by way of the data-src attribute. I've fixed that now, should be on the repo. Worth noting that enabling uk-img changes the src attribute to data-src, and adds a src attribute with a blank pixel: src='data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=='. The src attribute is required for valid HTML5, so I've been in the habit of adding this blank pixel for this purpose.

Hi @ryan, This is indeed an ingenious little helper! Thx for sharing this idea with us! One problem though: When I'm only in the backend, the url and filename methods get never called. Could you please make the setFilename method hookable so that this method also works when the page is just edited in the backend? It would then only need this simple hook and all files are downloaded on demand: $wire->addHookAfter('Pagefile::setFilename', function($event) { $file = $event->object->filename(); if(!file_exists($file)) { // download file from source if it doesn't exist here $src = 'https://example.com/site/assets/files/'; $url = str_replace($this->config->paths->files, $src, $file); $http = new WireHttp(); $http->download($url, $file); } }); Or is there a better way of doing it? Edit: Ryans version does of course work without issues - just make sure to have the proper PW version installed ^^

You will need: ProcessWire (of course) ProcessWire ProCache ProcessWire Modules as you like and need Netlify Account (in my case, you can use any other hosting or Github pages) Git Account (Gihub, Gitlab, Bitbucket) ScreamingFrog (free version should fit most needs) Things to keep in mind FormBuilder will not work (out of the box) 40x/50x must be defined separately Redirects must be defined separately Module-based functionality will not work GDPR/Opt-in/Cookie consent must be added differently Avoid using core/module files (UIKIT, jQuery, CSS, etc.) Where to save files and how to address them Most content and design related files can be saved in ProcessWire itself. Logos, favicon, trust icons and whatsoever. Some files can't be stored in ProcessWire - or shouldn't be stored in it - fonts and sitemaps (XML) in my case. While developing the overall site always use relative paths and URLs. Fonts and other assets need to be addressed by their web-root-based path (/site/templates/myassets/font.ttf and so on). Internal linking should be relative as well. Otherwise you have to change those link URLs manually which is PITA. Which files to copy and where you find them As we use ProcessWire we want and should use everything we can to make our webdev life easier here. Let ProcessWire and some modules do the work while harvesting the results for our benefits. While ProCache takes care of generating minified CSS and JS, SEO Maestro generates a nice and handy sitemap.xml. Depending of your installed modules you want to (at least) double check the output and results in your static site. As already mentioned FormBuilder and Simple Contact Form will not work, 404 management and redirects by the awesome Jumplinks modules will not work, too. Instead you have to create your very own .htaccess file with all redirects and error documents. Other modules like MenuBuilder, SEO Maestro and some other modules do a pretty good job even in your static site as their benefits result in already rendered HTML/pages. Autolinks, Automatically link page titles and Share buttons are some modules that will work as well. While it didn't work for me it may work for you - the Cookie Management Banner module. I had some issues and decided to install and use Cookie Consent manually. The Workflow First of all build your site. Make it perfect. Do whatever you or the client wants or needs. Whenever possible look into your rendered HTML and cached pages. Take a closer look at all the URLs and paths. It's already a good idea to run ScreamingFrog and find out if there are any files missing, links broken or pages missing. When everything is done, clear all cached files, all minified JS and CSS. Start a ScreamingFrog session and let it run. It will visit each and every page on your site it can find. Hidden pages, orphaned pages and of course drafts and pages behind JS-links will not be found and therefore cached by ProCache. Look into /site/assets/ProCache-XXX/ and /site/assets/pwpc/ now and double check that there are your pages and JS/CSS files. You will need those afterwards. If everything is fine you have to copy things around now. The Setup - folders and structure In my case the easiest way to go was setting up two local sites - one with ProcessWire and another one with the static files, assets and other things I needed. In the examples below only relevant parts are listed. project.pw.test (ProcessWire) /sitemap.xml (Generated by SEO Maestro) /site/assets/files/ (copy the whole path) /site/assets/pwpc/ (copy the whole path) /site/assets/ProCache-XXX/* (copy only the content of this folder - all files and folders) /site/templates/myassets/ (copy the whole path) project.sv.test (Static version) .htaccess (for redirects and 40x/50x error pages) 40x.html 50x.html /sitemap.xml /site/assets/files/ /site/assets/pwpc/ /site/templates/myassets/ all files and folders from /site/assets/ProCache-XXX/ As you can see there are only a few things to copy. When you're done with copying these files to the static version of your project, open it up in your browser. Check for missing files and test it. Let ScreamingFrog do the most work and check for any kinds of errors. Fix them in your ProcessWire-site and copy and test again. Check your 404s, your redirects and everything else you would normaly test. Create checkafterupdate.txt and write down whatever went wrong in your first try. This will be a great checklist later. The Final Step As everything is copied now and at its correct place you can upload it to your host. In my case the static version is a private git repository on github.com. I can commit and push my changes there and Netlify takes care of publishing the new version - most of the time within seconds. The benefit of using git - compared to S/FTP - you always have some kind of control if something brakes and you have to revert and check changes. In my case it's Netlify but you can use Github pages or any other hosting solution you want/the client pays for. Be careful with GDPR-related things as DPAs. You have to have them in most cases - Netlify did a great job here and I found everything I needed, while Github disqualified itself back then due to missing documents and kind of a sluggish support. Questions? Ask.

This is actually very easy but might be interesting for someone anyhow (and I post it here as a reminder for myself). You can use Postman (https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=de) to send requests to your ProcessWire installation and test request answers. The problem is that $config->ajax will always return FALSE. To make the $config->ajax work properly you just need to add this key-value-pair to your requests: key: X-Requested-With value: XMLHttpRequest Happy AJAXing PS: This also works inside the admin, see post 3

This happened to me today. Clean your cache/FileCompiler folder. For me its gone. .a

Technically all API access is superuser, since the API doesn't pay any attention to the user. But there is one exception: any function that returns a PageArray will filter out results that the current user doesn't have access to. That's done as a convenience so that you don't have to check access for every page that gets returned from a find() operation. It's also necessary for things like pagination to function with low overhead. These options are provided so that you can change that behavior for any given find operation: <?php $pages->find("[selector], include=all"); // include ALL results, with no access or status filtering $pages->find("[selector], include=hidden"); // allow inclusion of results that have 'hidden' status $pages->find("[selector], check_access=0"); // don't check access (roles) when finding results However, when calling find() from $users->find(), $roles->find() or $permissions->find(), it's supposed to automatically add the "include=all" for you, and it wasn't. So that was bug that was limiting access too much. I've just fixed it in the latest commit, thanks for finding it. As for making the bootstrap API assume the user is superuser for $pages->find() operations, I'm reluctant to do that just because I think whether that's desirable or not really depends on the context. If I was bootstrapping the API for use in some other application, I would still want PW to honor my permission settings in $pages->find() operations the majority of the time. But for the times you don't, add the "include=all" to your selector, or change the user to be who you want: <?php $users = wire('users'); $superuser = $users->get("apeisa"); $users->setCurrentUser($superuser);