Leaderboard

While the version remains at 3.0.181 this week, there have been several core updates committed to the dev branch containing a mixture of issue fixes, new features, core optimizations and upgrades. This is likely to continue for another minor version or two while we prepare for our next master branch release. The most visible improvements this week can be found in ProcessField and ProcessTemplate (aka Setup > Fields, Setup > Templates). The main list of fields (Setup > Fields) has been improved with some new supported icon indicators that now identify fields that have template overrides/context settings, among others. All of the existing icon indicators have also been updated with contextual links so that clicking them takes you to the relevant part in the template editor. My favorite update here though is that the "Type" column in the fields list now indicates the Inputfield type in cases where it matters. For instance, rather than saying "Textarea" for the "body" field, it now says "Textarea/CKEditor". Likewise, Page and Options fields indicate what kind of input is used (i.e. "Page/AsmSelect" or "Options/Checkboxes"), as do some other types. Clicking on the "Templates" quantity now takes you to the "Add/remove from templates" field, rather than just showing you a list of templates. Similar updates were made to the ProcessTemplate main list of templates (Setup > Templates) though there wasn't as much to do there. Once you are actually editing a template, the instructions on the "Basics" tab have been improved to clarify what you can do on this screen. For instance, many don't know that you can click a field name/label to edit it in context, or that you can click and drag the percent indicator to adjust the field's width in the editor, all from this tab in the template editor. Now the description outlines these features. When you select a new field to add to your template, it now reveals a note that clarifies you must save before the field becomes editable in the context of that template. These are minor updates, but combined I think they add significant clarity, especially for new users. Stepping outside of the core, I've been working quite a bit this week on the PagesSnapshots module I told you about a couple of weeks ago. It lets you save or restore snapshot versions of pages, and it doesn't have any notable limitations in terms of fields. At this stage it is working fully with repeaters, matrix repeaters, nested repeaters, Page Tables and even paginated Table fields with thousands of rows. It can restore to the original page, to a new page, or to another page of your choice. And it is very fast. Eventually ProDrafts will use its API to handle saving and publishing of draft versions. Initially I plan to release it in one or more of the existing module sets (like ProDevTools or ProDrafts or both), and longer term it may be added to the core. I've got another week or two of work to cover with it, but at this stage the API is fully functional and working well, so I'm now beginning to focus more on the Process module (user interface) side of it. Thanks for reading and have a great weekend!

10 templates is definitely not going to be a problem. There's no particular number of templates that you should never go above, but I've asked Ryan about this topic in a Pro module forum and he said: ...and in reply to my proposal of a strategy to reduce the number of templates needed in a project... On that particular project I currently have 51 templates and there are no noticeable performance issues.

I'm very much looking forward to the Snapshots module ?

I loved Svelte too. For the routing part I mostly use Laravel and now ProcessWire (With the Inertia Module) with the https://inertiajs.com/ Inertia adapters. That simplify greatly the flow and you got the best of backend and frontend ?

I typically start with the raw HTML output design and as I work I notice elements that I use often and break those into partials. In my _main I typically have the spacing and grid scaffolding for most items with the understanding I may embed nested structure as part of my individual page template, and then I will load includes into those embedded areas as needed. I see _main as the foundation and outer walls of the house. I see the page templates with their regions as different layouts of walls/rooms within that house. I see the furniture and features of the rooms of the house as partial includes. Whether you choose for the rooms themselves to be adaptable or not is really up to you. It isn't necessary to use partials at all, but I find it cuts down a little bit on the template counts. A common tradeoff seems to be between the amount of code you put into your template file region replacements/append/prepend etc vs the number of different templates you have, and whether you want the presentation routing to be directed more by the selection of the templates or programmatic responses to data in the fields your templates use. It is possible to have very few template files that reroute and alter the display based on tons of selections made on the pages themselves, or it is possible to have individual templates for all of the different scenarios you may want to come up with - but for complicated sites I tend to prefer fewer templates, more function controls. I would say that for the end user having lots of templates and transparent choices/structure on the pw backend is safer with clients. Because you can control a lot of things about adding new content, etc. it is less likely that the user may alter some value and cause some other glitches on the site that you don't expect unless you are pretty strict with your unit testing. But if you have code content that is really never anything the client is going to have to be actively involved in, bringing stuff like that into the code side keeps down the clutter. Hanna code sits somewhere in the middle and I always feel like it is playing with fire but that's a pretty happy bridge between the two worlds if you want to try to give placement control to the client but want to maintain logic control.

Reputation count is now back next to post count ?

I'll see what I can do about the rep count - in the meantime I've done something someone else asked for (and my older eyes needed) - increased font size on mobile. I haven't gone too far with it but it's a lot better than 13px ?

Pete and I have been using Postmark in some PW based projects at reasonable scale (>13k emails a month) and have found it to be an exceptionally good API-based transactional email provider with fast delivery times and great availability. It seems strange that there is no WireMail offering (as far as we know of anyway) that supports Postmark, so we thought we'd throw one together in case anyone else in the community wants to give Postmark a try. NB: This is not the code we use in our production systems, just a rainy-day project to fill a gap in the WireMail ecosystem. However, it should be sufficient to get you going with Postmark. We hope you find it useful and please let us know if you find any issues. WireMailPostmark module on Netcarver's github account. Screenshot from my test account:

Inertia Adapter ProcessWire Module Hello! Long time no see. I created this module so you can use Inertia.js (https://inertiajs.com/) with ProcessWire. Description Inertia allows you to create fully client-side rendered, single-page apps, without much of the complexity that comes with modern SPAs. It does this by leveraging existing server-side frameworks. Inertia isn’t a framework, nor is it a replacement to your existing server-side or client-side frameworks. Rather, it’s designed to work with them. Think of Inertia as glue that connects the two. Inertia comes with three official client-side adapters (React, Vue, and Svelte). This is an adapter for ProcessWire. Inertia replaces PHP views altogether by returning JavaScript components from controller actions. Those components can be built with your frontend framework of choice. Links - https://github.com/joyofpw/inertia - https://github.com/joyofpw/inertia-svelte-mix-pw - https://inertiajs.com/ Screenshots

Restaurant Blechnapf Neumünster - https://www.restaurant-blechnapf.de/ Fine culinary dining combined with a similar fine setup of design and webdev can be found at Blechnapf, Neumünster. One of our oldest partners in crime culinary highlights. Classic german dishes, experimental dishes based on classic dishes and even very own creations of all-time classics. Even though they are officially targetting your taste buds you can find a lot of more adventures there. They offer support for all kinds of experiences from readings, poetry slams, business meetings and even weddings (just in case you are around this wonderful place). Design details A classic modern setup of goodness (which got a very recent visual upgrade with way more and bold colors) - as someone described it already. Nothing super fancy, yet classic, modern, and with a very personal own style. Website, printed menue cards and even vcards come in the same style. Guess what was first. ;) Technical details PageHitCounter RepeaterMatrix (Pro) Import Pages from CSV Markup Sitemap XML PrivacyWire Simple Contact Form The team behind this: Muskaat for the technical part (yes, I'm part of Muskaat) https://www.muskaat.de/ Polimorf for the design part https://www.polimorf.de/ I hope you'll enjoy this site as much as I do!

I have a web app with over 50 templates and over 150 fields (holiday cottage booking system). I don’t find that a problem, although there are not many users. I use page classes extensively with the templates as I find that is the best way of handling the business logic. Process modules for most of the admin user views. This is mostly a back-end admin system. The front-end public website is a separate PW instance with its own (smaller number) of templates and fields, interfacing the admin system via an availability calendar. There may have been better ways of doing it, as I am still learning about PW, but I find this a manageable approach.

Hi @BillH Thanks for you kind hint. It was the file permission of the assets and modules folder causes the error. It is fixed now. Gideon

@kongondo keep up the great work. For me it would just be great to play around with this and service the ecommerce requests that I get, even in a basic capacity knowing that a fuller feature set will come later so I am not too fussed about advanced features at this stage.

Some unusual stuff happening on Freenode since the change in ownership (https://lwn.net/Articles/857252/). I got banned from freenode as a spammer just because I mentioned the word 'libera' in a room. Libera (https://libera.chat/) seems to be the place where the Freenode staff channels are are moving to & I've opened up a channel there. Please join!

Quick update... Finally figured out to get React/NextJS to work with a basic (minimal field types to convert to JSON) PW site. Giving self a pat on the back when I discovered Svelte ? Svelte felt (I'm a poet & didn't know it ?) so much more like PW - JS, HTML & CSS with 'state management' and no shadow DOM. The only problem was routing. I'd spent far too long figuring out React/NextJS routing and Svelte offered no immediate solution. The old (like 2yrs) way of routing was called Sapper. Development on Sapper has ceased with all efforts now focussed on the new way, SvelteKit which is in pre-beta (? ). Anyhoo, went with SvelteKit and got it working. I've only scratched the surface on what's possible with React/NextJS and Svelte. Both offer Server Side Rendering (SSR) making the site SEO friendly & fast-loading. Given a choice, I'd choose Svelte every time. With both React/NextJS and Svelte using @Sebi's AppApi with customisation depending on the framework, I: created a home page that pulls the data from the PW home page created a 'slug' page that pulls the data from the PW page url and displays it in a component based on the PW page template as returned in the page JSON, and shows the correct route in the URL from a nav menu In both cases, the page layout is not a PW template but a conditional component file. Anyone else tried Svelte with PW? Your thoughts & comments welcome

Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud

I'd like to thank LostKobrakai for this excellent tutorial included in the Dec 25, 2015 blog post regarding custom page types. If you haven't read it yet, please do so. It is contributions like this by the senior members that prove selecting ProcessWire was the correct decision for this ProcessWire-Newbie. I am impressed at what I have learned within the functionality of ProcessWire, and discovering avenues I hadn't yet thought about. It is indeed a merry Christmas. I also want to thank all staff members. They deserve our gratitude for the time they dedicate to helping us learn ProcessWire, and the many avenues available with each project. For example, kongondo contribution is another great example of the team in place here. My hat is off to Ryan and his team for giving of their time and sharing their knowledge. In addition to the regular staff, there are many members, such as Kixe, Tom, (and too many others to name them all here) that also deserve recognition for their contributions and assistance. It is greatly appreciated. I am certainly looking forward to ProcessWire 2016 ;-)