Leaderboard

I work every day with ProcessWire as 90% of our websites are built with it. We have a base install that we use for every new project, if anything from the weekly updates is an improvement on what we use in there, then we update our base install which will have the improvement on our next project. We also have a lot of retained clients who pay monthly to keep things running smoothly, again if there are any improvements in the weekly updates, we can slowly apply these to the retained projects going forward. The last major improvement in our workflow was the combo field which we use on all our latest projects, we wouldn't know about that if the weekly updates didn't exist. You mention being productive which I think is the best thing about ProcessWire. We have installs from years ago that are still running, and we don't have to worry about them, or care how they were built even if the client is not on a retainer, we just leave them. However, the client may come back and request some updates, we can start with running all the upgrades knowing that we have had very few issues in the past with just running upgrades, and we already know that behind the scenes there will be improvements in doing this, and improvements if we wish to use them with our coding. I guess what I am trying to say is you don't need to worry about the weekly updates if they don't have an impact on you, but the next time you check the documents you may see something that you can use as an improvement. I am sure nobody remembers all the improvements, I don't, nobody uses all of them, I don't, but they are there to use if you want and know about them. Everything still works with a site that you have already built if you just run an upgrade. There may be 51 weekly posts in a year I have no interest in, but 1 weekly post which is golden, I will take that for something I don't pay for (other than through the Pro modules). How does it make me learn coding, every day is a school day and seeing how things are done in ProcessWire makes me think in different ways when I am using other tools, I suppose that is what will happen when 90% of our websites are built with ProcessWire.

@pwired sure, here you are. site/templates/fields/sections_next.php This file is responsible for outputting rendered HTML for the field called `sections_next`. It's called with the `$value` set to the value to be rendered, which in this case is a field of type PageTableNext. <?php namespace ProcessWire; /** * @global Page $page * @global PageArray $value * @global Field $field * @global Pages $pages * @global Config $config */ ?> <div style="margin:1rem;border:solid 1px yellow; background:#ffffe0;padding: 1rem;"> This is sections_next.php <?php if(!($value instanceof PageArray)) return; foreach($value as $contentElement) echo '<div style="border:solid 1px #fc0;background:#eefff8;padding:1rem;margin:1rem;"> The following is rendered by ' . $contentElement->template->name . '<br />' . $page->renderValue($contentElement, ($field->pathToTemplates ?? '') . $contentElement->template->name) . '</div>'; ?> </div> site/templates/fields/sections/hero.php This file and the one that follow are two example possible section/paragraph/block types. For my proof of concept, I created a "hero" one and a generic "section" one. This hero one crudely renders a big background image with some big text over the top. <?php namespace ProcessWire; $image = $value->background_image; $thumb = $image->size(1920, 700); ?> <div style="background-image:url(<?php echo $thumb->url ?>); padding: 4rem;margin: 0 0 2rem 0;min-height:60vh;"> <p style="color:#fc0; font-size:3rem; font-weight:bold; text-align: center; line-height: 1.4;"> <?php print $value->title; ?> </p> </div> site/templates/fields/sections/section.php The 'section' type has a body field and a select field letting the user choose Blue/Mauve/None for the background colour. <?php namespace ProcessWire; // here, $page is the main page tht was requested; $value is the Page object being rendered, the 'section'. ?> <?php $map = ['Blue' => '#0284ea', 'Mauve' => '#f0ddff', 'None' => 'transparent']; $selected = $value->background_colour->title; $bg = $map[$selected ?? 'None']; ?> <div style="border:solid 1px #cf0;background:<?php echo $bg; ?>; padding:1rem;margin:1rem;">This is section.php, rendering <code>$value</code> <h2>title: <?php print $value->title ?></h2> <p>colour: <?php print $value->background_colour->title ?></p> body: <?php print $value->body ?> </div> Other files Now the instructions for PageTableNext (ptn) tell you to copy some other files into your templates dir, but I've not figured out why! e.g. The instructions made me copy a file from the module to site/templates/PageTableNext/ptn.php, however I put exit() at the top of that file to test whether it was ever used and I've not found it to be doing anything, so I don't understand that! Here's my demo page content: In the editor it looks like this: ➊ shows the three blocks/sections/... that I've added (with the buttons at ➌). I clicked the arrow to 'open' the third section and you can see it at ➋ rendered using just the site/templates/fields/sections/section.php file. The UI is pretty nice; you can edit each section, move them around etc. Oh, one other thing, in the main page template (e.g. basic-page.php) you need to render the field that contains all the blocks/sections/etc. like so: <?php // If using 'delayed' output: $content = $page->render->sections_next; // If using 'direct' output echo $page->render->sections_next; One interesting thing is that if you use delayed output then your site/template/{page-type-name}.php needs to populate $content (or whatever vars you use in _main.php). However, the field templates all just use echo/print because they are rendered with output buffering capture. Hope this helps! It might help me too when I come to actually make a site with PW instead of just playing!

This week on the core dev branch we’ve got some major refactoring in the Page class. Unless I broke anything in the process, it should be more efficient and use less memory than before. But a few of useful new methods for getting page fields were added in the process. (A couple of these were also to answer feature request #453). Dot syntax You may have heard of dot-syntax for getting page fields, such as $pages->get('parent.title') where “parent” can be any field and “title” can be any field that has subfields. This is something that ProcessWire has supported for a long time, but it doesn’t get used much because it was disabled when output formatting was on. So it wasn’t something you could really count on always being there. Now you can — it is enabled all of the time. But it’s also been rewritten to be more powerful. When using dot syntax with a multi-value field (i.e. any kind of WireArray value) you can also specify field_name.first to get just the first value or field_name.last to get just the last value. i.e. $page->get('categories.first'); will take a value that was going to be a PageArray (‘categories’) and return just the first Page from it. Bracket syntax With bracket syntax you can call $page->get('field_name[]') with the (‘[]’ brackets at the end) and it will always return the appropriate array value for the type, whether a PageArray, WireArray, Pagefiles/Pageimages, or regular PHP array, etc. This is useful in cases where you know you’ll want a value you can foreach/iterate. Maybe you’ve got a Page field that set set to contain just 1 page, or maybe you’ve got a File/Image field set to contain just 1 file. But you want some way to treat all of your page or file/image fields the same, just append “[]” to the field name in your $page->get() call and you’ll always get an array-type value, regardless of the field settings. This bracket syntax can also be used for getting 1 value by index number. Let’s say you’ve got a page field named “categories” that contains multiple pages. If you want to get just the first, you can just call $page->get('categories[0]'); If you want to get the second, you can do $page->get('categories[1]'); This works whether the field is set to contain just one value or many values. Using the first index [0] is a good way to ensure you get 1 item when you may not know whether the field is a single-value or multi-value field. Another thing you can do with the bracket syntax is put a selector in it to filter a multi-value field right in the $page->get() call. Let’s say you want all categories that have the word “design” in the name. You can call $page->get('categories[title%=design]'); If you want just the first, then $page->get('categories[title%=design][0]'); What’s useful about using selectors in brackets is that this does a filter at the database-level rather than loading the entire ‘categories’ field in memory and then filtering it. Meaning it's a lot more memory efficient than doing a $page->get('categories')->find('title%=design'); In this way, it’s similar to the already-supported option to use a field name as a method call, for instance ProcessWire supports $page->field_name('selector'); to achieve a similar result. Dot syntax and bracket syntax together You can use all of these features together. Here’s a few examples from the updated $page->get() phpdocs: // get value guaranteed to be iterable (array, WireArray, or derived) $images = $page->get('image[]'); // Pageimages $categories = $page->get('category[]'); // PageArray // get item by position/index, returns 1 item whether field is single or multi value $file = $page->get('files[0]'); // get first file (or null if files is empty) $file = $page->get('files.first'); // same as above $file = $page->get('files.last'); // get last file $file = $page->get('files[1]'); // get 2nd file (or null if there isn't one) // get titles from Page reference field categories in an array $titles = $page->get('categories.title'); // array of titles $title = $page->get('categories[0].title'); // string of just first title // you can also use a selector in [brackets] for a filtered value // example: get categories with titles matching text 'design' $categories = $page->get('categories[title%=design]'); // PageArray $category = $page->get('categories[title%=design][0]'); // Page or null $titles = $page->get('categories[title%=design].title'); // array of strings $title = $page->get('categories[title%=design].title[0]'); // string or null // remember curly brackets? You can use dot syntax in there too… echo $page->get('Page “{title}” has {categories.count} total categories'); I’m not going to bump the version number this week because a lot of code was updated or added and I’d like to test it for another week before bumping the version number (since it triggers the upgrades module to notify people). But if you decide to upgrade now, please let me know how it works for you or if you run into any issues. Thanks for reading, have a great weekend!

@Pavel Tajduš and I have fixed the windows issue in v1.17.20 ?

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

I have setup a starter kit for developing PW sites with Tailwind CSS. You can find it at https://github.com/gebeer/tailwind-css-webpack-processwire-starter I know, I'm a bit late to the party with Tailwind. In fact I only discovered it a couple of months ago and found it to be a very interesting concept. It took quite some time to get a pure webpack/postcss/tailwind setup that features live reloading dev server, cache busting, supports babel as well as autoprefixing and works well with PW. For the cache busting part I developed a small helper module that utilizes webpack.manifest.json to always load the assets with the correct file hashes for cache busting. No more timestamps, version numbers or the like required. The little helper can be found at https://github.com/gebeer/WebpackAssets Having used it for the first time in production on a client project I have to say that I really enjoy working with Tailwind. The concept of using utility classes only really convinced me after having put it to practice. During the work on the client project, some quirks with webpack-dev-server came to surface. I was able to solve them with the help of a colleague and now it is running quite stable in both Linux and Mac environments. I am fascinated by the fast build times compared to using webpack/gulp or gulp/sass. Also the small file size of the compiled CSS is remarkable compared to other frameworks. So this will be my goto setup whenever I am free to choose the frontend framework for a project. If anyone feels like they want to give it a try, I shall be happy to get your feedback

Would be interested to hear what the other 10% are and why they are not ProcessWire as well ? Factual question - no offense in any way.

Thanks @AndZyk. I am using dependent selects. So it needs check_access=0 in the input tab as you suggest for InputfieldPage to get it. However for dependent selects, ProcessPageSearch is called to populate the options and strips out the 'check_access'. Then, when the options don't include the already-selected item provided by InputfieldPage, it is removed ? I think perhaps I should raise this as an issue or feature request.

I was referring to the selector string options of a page field under the input tab. If your case is more complicated than that, sorry I don't think I can help you. ?

Two words: quality control Too many cooks spoil the broth 20 chefs all working on the same soup, makes a crappy soup Someone has to to be the ringleader to perform quality control on every pull request, rather than to just add it in because "it works and a net positive feature set" Unless you want it to be like other open source projects, where anything and everything gets added in, just because it works and provides a net positive for the feature set, like [[[----insert other CMS here ----]]] ??‍♀️

What about we make this some kind of universal profile which works with webpack, bun, npm, yarn, vite... whatever. Or at least use this a guide for setting up all of those different setups. I never really used any of these tools - at least six months or so ago - right now I use NPM due to other tools I use now and therefore kind of started to like it (and as it's super portable through all OS I use, have to use or play around with). As soon as I am back at home I could provide a NPM/TailwindCSS/AlpineJS/browser-sync setup. Pre-Version of the mentioned above can be found here: https://github.com/webmanufaktur/processwire-addon-tailwindcss-alpinejs-barbajs

Hi @gebeer. Using webpack nowadays feels a little bit outdated for me, because with vite (from the creator of vue.js) setup is so much simpler and faster, and it comes with first-class support for most frameworks like Tailwind or vue out of the box. But it can't do all things webpack does (not yet). Two or three years ago I used a similar approach to what you did now, as you can see in my jmartsch/acegulpandpack: A set of gulp tasks with JS transpilation, webpack, SVG Sprites and minification (github.com) repo. With vite you use native ES modules instead of transpiling and bundling every time something changes. This makes the development process much (MUCH) faster. If you ever seen it in action, you would not like to go back to webpack. If you guys are interested in a modern build environment for your CSS and JS, I could see if I find the time to write a tutorial for it.

Page Table was developed/intended as a part of the ProFields bundle, but later bundled with the core package, so "ProFields" in the name is kind of a nod towards that history ? There are many ways to handle rendering, but here's one solution that may help you: Create a shared root for your content elements — something like /blocks/ or /content-elements/, perhaps. Configure your Page Table field to save new items below aforementioned root path, and make sure that you only enable templates that you've created for this purpose. You don't want to allow a "regular basic-page" (or anything like that) in your Page Table field as a "content element". For each of your "content element templates", leave template file empty (so that these pages can't be reached with their actual URL). Now even though your content elements will be actual pages in the page tree, they won't be reachable by visitors. You can render them in any way you see fit, but here's one approach using ProcessWire's native field rendering feature that, in my opinion, works pretty well. Here I've assumed that the Page Table field is called "blocks", and it's used on template called "basic-page". /site/templates/basic-page.php <?php namespace ProcessWire; ?> <?= $page->render('blocks') ?> /site/templates/fields/blocks.php <?php namespace ProcessWire; ?> <?php foreach ($value as $item): ?> <div class="block"> <?= $item->render(__DIR__ . '/blocks/' . $item->template . '.php') ?> </div> <?php endforeach; ?> /site/templates/fields/blocks/block_template_name.php <?php namespace ProcessWire; ?> <h2> <?= $page->title ?> </h2> <?= $page->content ?> Anyway, as I mentioned that's just one approach ? I'm not entirely sure what you're referring to here, but if you mean the processwire.com website, then yes — that's technically proprietary. In my experience that's a common thing for open source projects. API reference, on the other hand, is automatically generated from ProcessWire's source code, so that is technically open source ?

This week we’ve got a new core version on the dev branch (v3.0.204) and a new version of FormBuilder (v53) posted in the FormBuilder board. Relative to ProcessWire 3.0.203 version 3.0.204 has 23 commits containing a mixture of feature improvements and issue resolutions. While there aren't major feature additions here there are a lot of worthwhile improvements and fixes, and I'd recommend the upgrade if using the dev branch. See the dev branch commit log for more details. The new FormBuilder version includes various improvements but the biggest is a new version of the included InputfieldFormBuilderFile module that supports file/image uploads in forms. It has been improved with a preview option (for images), the ability to collect a description for each file, improved multi-file inputs, and more. The new options appear on the “Details” tab when editing a file field in FormBuilder. This new version (v53) is available for download now in the FormBuilder board. If you upgrade an existing installation with file fields, I’d suggest testing out those forms after upgrade, and also review the new options to see if they make sense for your form. Thanks for reading and have a great weekend!