Leaderboard

This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend!

Just in case you don't know, you can do this via the parent page template's Family tab > Sort settings for children This is possible with the AdminOnSteroids module's AddNewChildFirst option which allows you to maintain manual sorting, but automatically putting new pages on top. BTW - not suggesting that something like this shouldn't be in the core - just hoping to help you out with a solution now.

Hi @MoritzLost thanks for your reply. Obviously, I'm new to workbox and really appreciate the feedback ? Probably no reason other than when I did, I got lots of errors in the console. Precaching important pages is an excellent tip, as is auto-generating workbox-config.js in PW then including it in the service worker. This is my first successful attempt with Workbox after many, many failures trying to follow the docs. Just wanted to get it working. I especially struggled with the workbox-config.js generation using the CLI. The 'publish' directory cannot be '/' - which it is in PW and when when I could get it to generateSW with the publish directory as the root, it picked up loads of unnecessary files eg in /modules/, /assets/, etc. Seemed easier to create it manually than unpick the CLI's best guesses. For me, a nicely presented page with a logo & phone number is a better UX than the ugly browser default. At least the user can call if their internet is down.

I can confirm that this method of replacing the decimal field worked on my e-commerce-Project where I tried this. No problems.

I can't recall whether it was this topic or another one but I remember someone asking where best to discuss issues/wish list, etc? In case you missed it, @ryan, I would like to bring GitHub Discussions to your attention. Maybe something worth considering.

This bit me today so I created a feature request: https://github.com/processwire/processwire-requests/issues/382 Would you guys mind giving it a thumbs up to get Ryan's attention? Thanks.

Exactly. I doubt we're going to all agree on all details of how the admin theme should look. But I hope that nobody among us is sitting there gritting their teeth because the admin isn't looking how they want it to look. Because we're all website designers/developers and we know how Cascading Style Sheets work (especially the cascading part). And it's not a difficult task to add your own CSS to the admin and override the styling of elements as you like. The admin theme markup changes very rarely and so you can spend half an hour working out your overrides for colours or whatever and then reuse those styles on all projects going forward. If you compile your overrides from SCSS/LESS then it's really easy to tweak colours for specific projects via variables.

Found the solution. Thanks @teppo for your help. Your suggestion gave me the clue I needed. Here's the fixed code: $results = ** a somewhat complex search that returns a pagearray ** $perPage = 20; $start = ($input->pageNum -1) * $perPage; $results->setLimit($perPage); $results->setStart($start); if ($input->get->f) $input->whiteList('f', $input->get->f); if ($input->get->l) $input->whiteList('l', $input->get->l); if ($input->get->a) $input->whiteList('a', $input->get->a); if ($input->get->t) $input->whiteList('t', $input->get->t); $pager = $modules->get('MarkupPagerNav'); $pager->setPageNum($input->pageNum); $pagination = $pager->render($results, [ 'nextItemClass' => 'next', 'previousItemClass' => 'previous', 'currentItemClass' => 'current', 'separatorItemClass' => 'separator', 'numPageLinks' => 5 ]); foreach($results->slice($start, $perPage) as $item) { // render the thing } echo $pagination; Basically all that was missing was that setStart() call. Makes sense, as usual.

Around 3yrs ago I got excited about Progressive Web Apps (PWAs) and found a site that magically created an offline experience with a few clicks. It worked until it didn't. Had to backtrack and remove the PWA code on lots of sites due mainly to exceeded offline cache storage causing problems. My JS skills weren't, and still aren't, up to the level of expertise needed to rectify. I still did the manifest.json thing, reduced the network load wherever possible and got some great Google Lighthouse performance results by tweaking PW especially with ProCache. 3yrs is a long time in web life. If 1 dog year = 7 human years, then 1 web year must be 10+ human years. I delved back into PWAs recently and Google Workbox in particular. The biggest hurdle I had to overcome was Google's own Workbox docs. Forget the "Import" statements and the CLI easy PWA method recommended in the docs. They don't (or I could not get them to) work with ProcessWire. They're geared to web apps like React that have a build process that publishes to a directory eg 'app'. ProcessWire doesn't work that way. So here's what worked for me: Create a template. I called mine "offline" that may only have one page, no children and does not have a trailing slash at the end of the URL. Create a page, add fields as necessary, eg 'body' and apply the 'offline' template and save as a child of "Home" Change the page url to 'offline.html' - this is the default page name for Workbox. Easier to change this than fiddle around overriding the Google Workbox defaults. For extra comfort, I made the page name 'Unique' and 'Hidden' from lists and searches. Ensure the workbox service worker javascript is NOT appended to the offline.html page On all other pages append the following to the <body> tag. I'm using Regions so this goes in my <region id="regFooterScripts"> in _main.php <?php if ($page->name != "offline.html") : ?> <script> if ('serviceWorker' in navigator) { let scrUrl = '<?=$pages->get('/')->httpUrl?>sw.js'; window.addEventListener('load', () => { navigator.serviceWorker.register(scrUrl, {scope: '/'}).then(registration => { console.log('Service Worker registered: ', registration) }).catch(registrationError => { console.log('Service Worker registration failed: ', registrationError) }) }) } </script> <?php endif; ?> Next, by hook or by crook, get the workbox library into a directory of your PW project. You can use the CLI 'copyLibraries' feature. See https://developers.google.com/web/tools/workbox/modules/workbox-cli for more info. Do NOT use any of the other CLI features! You can also download the library from gitHub. Didn't go there so please don't ask for help. I used the CLI method & saved the files to site/templates/scripts/workbox. Now you can start building your sw.js file which is saved in root directory. Here's mine using the Google Workbox docs & recipes. The big thing to remember is NOT to "Import" anything despite what the docs say. When you configure workbox to use your local copy of the library, all importing is done for you by using the 'workbox' namespace. importScripts('/site/templates/scripts/workbox/workbox-v6.0.2/workbox-sw.js'); workbox.setConfig({ modulePathPrefix: '/site/templates/scripts/workbox/workbox-v6.0.2/', globIgnores: ['processwire/**.*'] // change according to your PW admin URL }); // Include offline.html in the manifest workbox.precaching.precacheAndRoute([ {url: '/offline.html', revision: null } ]); workbox.routing.registerRoute( ({url}) => url.pathname.startsWith('/processwire/'), // change according to your PW admin URL new workbox.strategies.NetworkOnly() ); workbox.recipes.googleFontsCache(); workbox.recipes.pageCache(); workbox.recipes.staticResourceCache(); workbox.recipes.imageCache(); workbox.recipes.offlineFallback(); These are all the basic workbox features & recipes including offline.html and will probably need updating as time goes by. Up to you to add/modify/delete as you like and outside the scope of this tutorial. Good luck & have fun with Google Workbox PWAs in ProcessWire sites.

Hi @psy, thanks for the tutorial. I've implemented workbox in the Architekturführer Köln project, though I used the Workbox webpack plugin to generate the service worker (which is easier for JavaScript-applications that use Webpack anyway, not for ProcessWire sites). A couple of things that stood out to me in your guide: What's the purpose of not including the service worker on the /offline.html page? Service workers have a seperate lifecycle from individual page visits. Once registered, they will stay active until replaced or manually removed. It shouldn't matter if the registration code is repeated on the offline fallback page. One way to improve the user experience would be to precache important pages, so they will be available offline even before the user has visited them! See https://developers.google.com/web/tools/workbox/modules/workbox-precaching The list of pages to precache could even be generated dynamically, maybe have a checkbox on all pages to allow them to be precached, expose that list to the service worker and take it from there ... Seems like you're jumping through many hoops just to avoid having a simple build step for your JavaScript code. I often see people shy away from JavaScript compilation and actually make their job much harder because of this, but your code could be much simplified with a simple JS build step that would take only a couple of lines of configuration to set up. This will make it much easier to use libraries like Workbox, since you can just follow the installation and setup guides without having to, for instance, find workarounds for imports. I've written a guide on how to setup a basic JavaScript build step with ParcelJS on processwire.dev, take a look if you're interested. (Admittedly, Parcel seems kinda dead, nowadays I would recommend using Webpack 5. Or Snowpack, which seems to be all the rage right now ? ) Finally, and I know this may be personal preference, I feel like the whole "offline.html" thing is kinda ... superfluous? For an app / SPA, yes, I would expect a custom offline notification screen. But for a classic website with individual page loads, telling me I'm offline on a custom page with your logo on top doesn't really help me in any way, since it doesn't offer anything that the "you're offline" page of the browser can't …

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

Yes, it can be done using the Google Sheets API (https://developers.google.com/sheets/api). I recommend the PHP Quickstart guide at https://developers.google.com/sheets/api/quickstart/php. However, be aware of the usage limits described at https://developers.google.com/sheets/api/limits. These, combined with possible performance limitations, mean that it would probably be best to get the data into PW pages – and not to display the data directly on web pages using API calls from the template file. There are various ways you could pull the data into PW pages. One would be to run a Google API call each time the page is saved (for example, hooking on saveReady). Another would be using cron (or the PW module Lazy Cron) for regular updates.

My comments are about styling the admin, and that's done with CSS. I think you might be talking about making changes to the admin markup - or do I have that wrong?

46 you're still young Ryan ? I'm 66 this year and active as a martial arts instructor, and I still want to do it for the next 20 years hopefully. So you can maintain PW for the next 40 yrs. ?

Robin, I disagree here. I've modified the admin quite a bit to fit to my needs. The problem has always been, that I had to rely on the old admin theme source files meaning that changes would potentially break my theme or backend fixes would not apply to my old version... I hope that's fixed now with the latest admin theme updates - I'm currently locked to the latest master as the latest dev does not work with my custom admin theme. I have to investigate... But it somehow proves, that it has unfortunately not just been simple CSS 101...

I agree! With my theme I removed some of those lines already (take a look at repeaters or fieldsets). But it's still not perfect and I will further investigate how to improve this.

I also don't think the current branding is childish and it doesn't have to be in black/gray/white either. The current color theme certainly helps to create a unique and recognisable brand, but can be distracting in an UI context. I think a unique branding could also be archived with a reduced color theme and the use of unique typography and the PW logo (on the PW website). I'm aware that it's easy enough to create a admin theme of my own, but my comment was more about the future branding of PW in general. I do think there are other more important thinks to pay attention to than this. And for me this is not really an issue (I created my own admin theme). But I think it will matter to those who are new to PW and see the PW website and backend for the first time, here the first impression matters. I even had some clients choosing another CMS because they feel that PW looks to "technical".

I'd like to buy a shed there... right next to the coast or at least a lake or something... this would be even more than awesome. Offers are welcome and can be made through my public profile. :)

Sure, the admin theme could make this sort of thing easier. But it's not excessively difficult to tweak the styling now if a person is motivated. When people make comments or requests about the admin theme styling (not just in recent topics but in the forum generally) I'm never sure if they realise that they don't need to wait for Ryan to do something in order to get what they want. It's CSS101 stuff.

I use PW on multiple websites that I admin and write content for. I'm therefore often updating my PW sites, either by writing new content (most commonly) or doing template coding, or coding other features such as logic-specific ad display. Based on my experiences across all my websites, here are my thoughts on the OP topics: Flexible content or page building - I've never needed it and can't see myself using it in the future. I already have a few things set up like footer content where I write footer-left, footer-middle, footer-right content as the body of non-templated pages, and I simply code my footer to display the body content of those 3 pages using what's already in the PW core and API. Easy, and perfect. I don't see any need for anything beyond that, such as flexible content or page building (for my purposes at least). I absolutely love the CKEditor ? and I'm not sure why or what use case anyone would want for a block editor (in fact, a block editor is a reason why I moved away from WP to PW - the WP block editor was slow and frustrating and I could achieve way faster content creation with PW). I have a few page templates where there are multiple "body" contents, and I simply use additional "body" style fields in those templates. I understand the PW CKEditor is not going to be replaced, so I'm not worried there, but I'm not doing anything that ever needs more than defining fields and displaying them with a template. Admin theme improvements - a really quite massive "pain point" for me across all my sites is the inability to order the page tree in PW admin in a way other than the default ?. When you have 90+ pages of content (which I do on several of my sites and hope to on the others later), not being able to specify a default order is very frustrating. Sure, for a 20-page site, no big deal. For anything more, it's quite hard. In particular, I'd like these 2 features: It seems both features exist, although I'm struggling to find a way to combine them. The ability (or the default) to be most recently created page at top (not the oldest created page which it seems to default to - it's basically in the reverse order of what I want.) And yes, there is the "recent" menu available in Admin, but that's not as helpful as you might think. [SUBSEQUENTLY EDITED - This feature already exists in the core! - see comment below by @adrian ] The ability to put some "sticky pages" always at the top of the page tree. For me, this would be regarding specific to ads I want to show/edit frequently, but I expect there are other people with other use cases who want certain pages to always appear at the top of the page tree. This feature is of equal or higher importance to me than changing the default order. [SUBSEQUENTLY EDITED - This feature exists in the AdminOnSteroids module - see comment below by @adrian - however, I am not sure whether or not this feature can be used with a specified sort order as mentioned in the previous point] File/media manager and more file sharing options - Yes, BUT ONLY if we can somehow specify a different alt field for an image each time that a central image is used in a new page. If that's not possible, then I'd rather stay on the default of having to re-upload the same pic separately for different pages (which is what I'm doing now anyway). For me, it's crucial that the image if used freshly in a new page, has a fresh image alt tag. Because you might want to re-use the same pic for slightly different reasons in each case. External file storage - I don't use this and can't see myself ever using this, although I can see how others might want it. I purposely like having everything on one host/location. Live preview and auto-save: Auto-save is certainly nice, but ONLY IF it does not over-ride a user-specified save. I sometimes change page content around, but then decide I don't want those changes, so I purposely don't save it. In this case, auto-save could cause me big problems if it saves the page when I did not want it to. On the other hand, I've lost content before by my own fault, by forgetting to save and then going away and my session timed out after I came back. So I certainly could use autosave as long as it saves the page in another location so as not to overwrite an existing page. Preview options are already very rich, with "new tab" and "modal" options that I use frequently, so I cannot see a use for live preview for my use cases. The existing previews are pretty amazing already! That's it from me. All of that said, I love PW, and admin-ing my sites is a breeze thanks to PW and its wonderful community of people!

Necessary disclaimer: just like you, I also mean zero disrespect, and I get that this is a topic where opinions matter, and so on ? I agree with your point about that the admin should stay out of the way, and I do also share some of your concerns regarding current admin theme. But that being said, I must admit that I quite like the current colour theme: it's pleasant, professional, not at all childish (in my opinion), and brings just the right amount of personality to the theme. Also I personally find a black/gray/white colour theme rather boring — unopinionated for sure, but also boring. On the other hand one thing that I do dislike about Admin Theme Uikit is the noise created by separator lines. And, as it happens, your theme suffers from exactly the same issue: to my eyes it's still way too noisy. Opinions, right? ? Anyway, this is a topic that is definitely worth discussing further. Also Ryan has been extending our ability to customize and build upon the Uikit admin theme lately, and I'm quite interested to see where that road takes us. I feel that with some additional tweaks and customization options it could become a solid starting point. And if that could finally resolve the age-old problem with modules having to support multiple admin themes that all work differently, all the better. (Loosely related note: I seem to recall that there was some reason why Tailwind's original gray colour set was blue-gray. For whatever reason that type of thing works better for my eyes. There are probably better examples, but Craft CMS makes extensive use of gray/blue-gray/blueish colours, and their admin looks very pleasing to me. It's not opinionated, but it's also not impersonal or boring.)

What a great looking website! Everything looks/feels on spot! And Shetland does look awesome too haha. PageimageSrcst is in all my installs from the moment it releases. Can't thank enough for that module!

First off I would recommend re-reading this part of the hooks documentation: https://processwire.com/docs/modules/hooks/#conditional-hooks. If we take a closer look at your second code example, here's what it's trying to do: Add hook after the saveField() method of the Pages class has been executed ... but only if the first argument to saveField() contains string value "snipcart_item_image" Now, if you look at the definition of Pages::saveField() ... * @param Page $page Page to save * @param string|Field $field Field object or name (string) ... you can see that the first argument is actually a Page, not a string. In other words your condition doesn't really make sense here — what you're probably looking for is the second argument, which is the name of the field as a string or Field object. The conditional hooks documentation explains how to access a specific argument: $wire->addHookAfter('Pages::saveField(1:snipcart_item_image)', function($event) use($item) { Note: as you can see from the second @param definition, saveField() can receive either a string or an object. If there's a way to target both with conditional hook format, it's something I'm not aware of. I'm afraid that you're making things a bit complicated for yourself by trying to use the conditional hook syntax; it's an advanced feature that has it's use cases, but it's often easier to just hook into some method and "return" if the arguments are not what you are looking for. But, alas — there's a potentially much bigger problem here: when you save a page, ProcessWire doesn't call saveField() for each field individually. I don't know in what context you're trying to make your hook work so I can't say right away how you should write this hook, but I'd be interested to know if you gave my earlier example a try... and if so, did it do anything? If you're trying to change the value right before the page gets saved in the admin, you most likely should be hooking into Pages::saveReady. Or you could hook into Pages::savePageOrFieldReady if you also want to catch single field saves ? Edit: keep in mind that even if you hook into Pages::savePageOrFieldReady, the field name (second argument for said method) is only populated if a single field was saved. The value is not going to be there if an entire page was saved. If you take a look at my previous reply and change it the code sample to use Pages::savePageOrFieldReady, it should actually be pretty close to catching both "full page saves" and single field saves.

@ryan and others ? Sorry I'm a little late to the party. I just wanted to share my view as a designer on an update of the core default admin themes and future branding of pw in general. This is just my opinion, and I'm aware that this can be a very subjective topic. I just want to contribute to the discussion. I really like that PW gets out of the way when it comes to designing/developing a website. It's like an unopinionated frame around my projects. The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color). I wish the default admin themes and UI would act more like a neutral frame/canvas for the content. The future will probably be more about frontend stuff that gets rendered inside the backend (pagebuilders for example), so it would have less of a conflict with the frontend (that might have a lot of colors). Also I would love to have a option for a fixed header that takes less vertical space. While I know that clients love to see their logo, I don't like the Idea to do a custom branding of the backend based on the CI of the client (the client CI, logo and colors might not be working in an UI context). Instead I would prefer a solid default UI that gets out of the way. Another area where the branding and use of color gets in the way is on the showcase page of the PW website. The websites/projects presented here would benefit from a more neutral background (e.g. white, light grey, black). Imagine a museum where all the artwork from different artists and contexts, would be presented on a blue wall instead of a white wall. I recently released my own admin theme, which follows some of the ideas mentioned here. Maybe this can be an inspiration for a future default theme. Please don't take this the wrong way. I really appreciate all the work that goes into PW and this amazing community! I would love to know how others feel about this!

This sounds eerily familiar. Some situations where this might happen are if you have a "start" specified in your selector, if page numbers are not enabled for the template, or if you have multiple pagers resulting in some kind of conflict. If nothing else helps but $input->pageNum has the correct value, you could perhaps go at this the other way around — not tested, but if you instantiate MarkupPagerNav manually you can try to force the page num: $results = ** a somewhat complex search that returns a pagearray ** $perPage = 20; $results->setLimit($perPage); if ($input->get->f) $input->whiteList('f', $input->get->f); if ($input->get->l) $input->whiteList('l', $input->get->l); if ($input->get->a) $input->whiteList('a', $input->get->a); if ($input->get->t) $input->whiteList('t', $input->get->t); $pager = $modules->get('MarkupPagerNav'); $pager->setPageNum($input->pageNum); $pagination = $pager->render($results, [ 'nextItemClass' => 'next', 'previousItemClass' => 'previous', 'currentItemClass' => 'current', 'separatorItemClass' => 'separator', 'numPageLinks' => 5 ]); $start = ($input->pageNum-1) * $perPage; foreach($results->slice($start, $perPage) as $item) { // render the thing } echo $pagination;

I have a bank account, some fifty online accounts with various providers, have to look at unsave sites because I moderate forums, run a small wiki historical material, love to play with software, must run windows from time to time because some of my hardware uses drivers that won't run in Linux. I am looking very closely at this. It seems much more useful than just a Linux box with a VirtualBox inside.

Suggested roadmap candidates to improve core: One-step Page Creation: Skip "Add New" and go directly to the resulting page. Better un-global Title fields. Page urls with auto-incrementing IDs (and without Page Name parts). Easier Permissions for Users, Roles, Templates & Pages

This is EXACTLY what I had to hear. Thank you! ?? I'm open to any new approaches and improvements with .js editing/building as an option. Just don't want to lose my new, beloved home... ☺️

I have a lot of thumbs-upping to do... ? Anyway, I couldn't find related request right away. I know this has been requested and discussed on various occasions but I assume it's not such a common need that anyone would've yet opened a request for it in the "new" repository, or perhaps those asking about it here or googling for this found an earlier answer and figured that it'll be unlikely to change. Here's a new request: https://github.com/processwire/processwire-requests/issues/376.

Just my five cents (or fifty, looking at the length of this answer): There is zero interest here to move ProcessWire away from what it does now, or somehow get rid of the way it handles structured data. Absolutely zero. If you're worried that someone wants to thrash the system we now have and replace it with a Gutenberg clone, fear not: that will not happen, period. Now, as you've pointed out, there are different use cases. Almost all the sites I build and clients I work with nowadays require a "builder" approach: flexibility in terms of laying pages out. CKEditor goes to some extent here, but it's riddled with issues, and honestly the experience can be pretty horrendous: image management in particular is a lacklustre, and embedding any type of dynamic content (or anything CKEditor doesn't handle itself) gets difficult/technical (short codes with params etc.) A couple of reasons why comparing what we're doing to what WP is doing with Gutenberg makes little sense: In WordPress Gutenberg is going to replace the "classic editor", and it's also going to replace a lot of other built-in tools (such as menu management GUI) in the long term. The ultimate goal there is a "full site editor". This has very little to do with what we're discussing here. WordPress has never (natively) provided custom fields. Instead they have predefined fields and (freeform) page meta. ACF and similar plugins that make custom fields possible are popular, but page builders are even more so. It makes sense for the core team to extend the core with the tools that most users seem to want. I could get into the reasons why Gutenberg reviews are so bad — such as there being a lot of history, a lot of resistance to change, a lot of misunderstanding, likely mostly developer votes while the feature itself is aimed more at content editors, and so on — but I won't. My point is that improving the ability of ProcessWire to handle flexible layouts is not going to take anything away from those who don't want or need that. ProcessWire has many things that some users don't need or use. For an example, I've never used front-end editing for client sites. It's a feature I don't need, so I don't use it. It's as simple as that ? I'm going to cherry-pick one thing from this list: "I want to protect the entire site" ? I've worked on many completely non-public sites. While I believe I get the reasons @ryan has for not allowing the home page to be non-public, I would absolutely love for this to change. Even if it required a hook or config setting, that'd be a very nice addition. Currently I'm doing this with custom code, but there are some negative implications and I'm always a bit worried that it'll break: first of all it's (my) custom code and if something changes there's always a slight possibility that it won't work as expected, and second of all it needs to be done with hooks (to protect assets and make sure that nothing can interfere) and can thus sometimes get a bit complicated. TL;DR: if there was an option to somehow protect the entire site so that all non-authenticated requests (home page included) result in a login request, I'd be one happy user ?

@ryan, what follows is only about the idea of taking Repeater Matrix in a Bard-like direction for long-form content, as referred to in my earlier post. I don't have an opinion on the "builder" idea because it's not something I or my clients need. Looking at the Bard video you can imagine it as rich text field (i.e. CKEditor or maybe Editor.js) with Repeater Matrix elements distributed through it. You can add new Matrix items and edit them within the rich text interface. Here's a mockup of what a hypothetical "Repeater Matrix Bard" field might look like: But as far as I can see such an interface would be very difficult to implement. You'd have to somehow replicate the Matrix item interface inside CKEditor or Editor.js, maybe as plugins. [Actually, as soon as I made this mockup I suddenly had another idea for how it could be done, but I'll come back to that at the end of this post]. So when I first started thinking about this idea (back when Bard was introduced to Statamic) I wrote that option off as too difficult and turned to working with the existing CKEditor and Repeater Matrix fieldtypes. Of course this was going to involve compromises and the result was never going to be as slick as the Bard interface. My idea was to use placeholders for the Matrix items within the CKEditor field, in the form of CKEditor widgets. Each widget would correspond to a Matrix item, and a Textformatter module would replace the placeholders with rendered Matrix item output when the page is rendered for the front-end. This is easy to do via $matrix_page->render(). First I experimented with keeping the Matrix field visible in Page Edit, with the Matrix field in accordion mode. Hovering a widget placeholder in CKEditor highlighted the Matrix item (to help the user work out which placeholder is linked to which Matrix item) and clicking the widget scrolled to and opened the Matrix item for editing. But this takes the user away from CKEditor and disrupts the writing experience a bit too much. So then I changed to hiding the Matrix field in Page Edit so the user only sees the CKEditor field. When they add or edit a Matrix item a Magnific modal opens where they can work with the fields within the Matrix item. I added a dropdown to the CKEditor toolbar to let users add new Matrix items/widgets within the CKEditor field. This works okay but it's not fantastic - the main dissatisfaction I have is that my widgets are rather basic. This is because I'm no expert when it comes to CKEditor and its widget system. But looking at example widgets in a tutorial it seems that it's possible for them to have richer layouts and items like images (icons?) within them. I'm using the title attribute tooltip to show the text from the Matrix item header, but it would be great if the widget contained an icon corresponding to each Matrix type (sidenote: we really need a larger selection of icons available in the core) and perhaps some of the item content. Maybe the developer could specify code for each Matrix type that would render the HTML of the widget? I fear this is all beyond me but if you're interested maybe you could explore the possibilities of this? Or see if a similar approach would be more easily accomplished in Editor.js. A screencast of the system in action: Because the user doesn't see the Matrix field it would be possible for items to become orphaned there after their corresponding widgets are deleted from the CKEditor field. But it would be good to keep orphaned items for a short while to serve as disaster recovery. So perhaps orphaned Matrix items would be automatically removed after some period of time. Coming back now to the mockup screenshot and an idea of how to achieve it... What if there was a special rich text Matrix type available to be added to any Matrix field? This would consist of a CKEditor field in inline mode (to reduce the distraction of the toolbar) together with (optional) Files and Images fields to allow for linked files and embedded images (edit: it would be good if somehow a single Files field and a single Images field was shared between all rich text items). This matrix type would render differently within the Repeater Matrix inputfield - it wouldn't have a permanently visible header and the Files and Images fields wouldn't be permanently visible either. Instead a special toolbar would appear when the rich text item was hovered (probably at the bottom to avoid clashing with the CKEditor toolbar). This toolbar would include the standard Matrix icons (sort, copy, toggle, delete) and icons that make the Files and Images fields visible for when those need to be accessed. But when nothing is hovered it would render just as the rich text portions appear in my mockup. It would also be nice if the Matrix "add new" links were replaced by a "+" icon that appears when you hover between existing Matrix items, like in Bard. That would reduce some clutter in the inputfield and allow new items to be inserted in whatever position is wanted. This approach would not be quite as nice as a single rich text field containing Matrix items. Because I think the concept of multiple text fragments is not what users imagine for a long-form article. And it would result in more pages behind the scenes, although that probably isn't a big problem. But it seems like it might be relatively simple solution to the Bard idea.

Hi @3fingers, Both a and c are part of an internal (proprietary) GraphQL API implementation. The short explanation is: A GraphQL query is generated from the filters when the form is 'submitted' The GraphQL endpoint is queried and returns results The result is rendered b would take an age to explain properly, but basically the query string ends up in sessionStorage (JS) and the filter strip JS checks this to set the active option(s). When the filter options are changed the sessionStorage values change too so that the state is essentially retained throughout the user session. I can't give you any indication on budget unfortunately. We run the Promote Shetland contract, which is much more than just the website, so the redevelopment project is effectively 'in-house'. Timespan was just short of 6 months (design/development) I think, I wasn't involved in the early stages so can't say exactly when it began, but my involvement as developer started in August and we launched mid-November. Cheers, Chris

The field may not be necessary but I think you'll have to associate the file with a Page (it is called a Pagefile after all). You can do this: $my_files = new Pagefiles($some_page); $my_files->add('/path/to/file.pdf');