Leaderboard

Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.

Hi everybody, having worked mostly in the backend for the last weeks and having an upcoming project where I need some frontend stuff soon, I played around with a new concept of creating frontend themes for ProcessWire. That idea is not new... Nico built WireThemes back in 2014 and @teppo has recently launched WireFrame. I've also built two websites using this module (screencast) but that turned out to be too complicated and it was also working only with the uikit frontend framework. But still, it feels like I'm doing a lot of unnecessary work with every frontend project: Getting the framework Setting up the design Setting up the menu Setting up the correct dependencies (scripts, fonts, icons, etc) Setting up the config (markup regions etc) Setting up site settings (logo upload etc) etc, etc A lot of this stuff is the same for every site, so I'd really like to have a solution that is plug&play where I just have to do the customizations and not reinvent the wheel over and over again with every project. Also, I'd like to have everything in place so that I can just git clone a theme and share one theme across multiple projects (just think about the site header with favicon, seo and social tags!). Meet RockThemes ? As you can see in the video, the process is quite straightforward. Just install RockThemes and copy your theme to the templates folder (and set $config->theme to point to that folder, which was already in place in the video). The current status is quite promising: Themes stay entirely in the templates folder One year ago I decided to create themes as PW modules. That makes things complicated because assets are blocked by .htaccess from direct public access! Now themes live in /site/templates and assets are easily accessible for the public. The module uses Markup Regions by default They are great and offer so much flexibility and power. They are perfect for such a module ? The template files stay clean and easy, eg the footer file of the theme: <region pw-replace="footer"> <p>Powered by <a href="http://processwire.com">ProcessWire CMS</a> &nbsp; / &nbsp; <a href="/admin/">Admin Login</a></p> </region> Or the basic-page template (that gets the date from the site profile's template file and just populates the regions): <?php namespace ProcessWire; $sidebar = null; include("../basic-page.php"); ?> <region pw-replace="mainleft"> <h1><?= $page->title ?></h1> <?= $content ?> </region> <region pw-replace="mainright"><?= $sidebar ?></region> Themes are extendable This means that you can build one default master theme that you share across your projects and then create one custom theme per project that only contains the files that you need to change. The module supports any CSS framework I've built a base module that can be extended for every framework. The base module will consist functions that every project needs (eg for rendering favicon markup or SEO tags). The framework version will then extend this module with framework specific functions like rendering a menu or rendering paginations. Switching layouts is as easy as changing one file default.php <div class="uk-container"> <section id="header"></section> <hr> <section id="main"> <div class="uk-grid-divider" uk-grid> <div class="uk-width-expand"> <div id="breadcrumbs"></div> <div id="mainleft"></div> </div> <div class="uk-width-1-3@m" id="mainright" pw-optional></div> </div> </section> <hr> <section id="footer"></section> </div> colorful.php <section class="uk-background-primary uk-light"> <div class="uk-container" id="header"></div> </section> <section class="uk-background-muted"> <div class="uk-container"> <div id="breadcrumbs" class="uk-margin-top"></div> </div> </section> <section class="uk-section-small" uk-height-viewport="expand: true"> <div class="uk-container" id="mainleft"></div> </section> <section class="uk-background-muted uk-section-small" pw-optional> <div class="uk-container" id="mainright" pw-optional></div> </section> <section class="uk-section uk-background-secondary"> <div class="uk-container" id="footer"></div> </section> All other files are unchanged! This of course only works if the regions are named exactly the same. That would lead to the challenge of having the same region names across our themes. I guess that's the case for all CMSs that have theming support? I can remember the times when I worked with joomla (content-top, top, header-a etc). Would it make sense to create a master layout that can be used for almost every project? What regions are you using in your projects? I think such a frontend framework could open up a lot of possibilities. It would for example be a lot easier to develop helper modules for the frontend (think of RockTabulator or something like FREDI) because we would finally have at least a very basic standard how things are done (eg how to add assets to the <head>). It could also be easier to work on projects in a team, because everybody would know how things work. Though, I'm still not sure if such a module would make sense for the public at all. I'd be especially curious what @teppo thinks about that and how you see that approach compared to WireFrame (I wanted to use it before I started this module, but it did not feel right for me). Maybe that's exactly the problem: When it comes to frontend framework / theming approaches things just don't feel right, because everybody is so used to his workflows. So what do you guys think? Would such a module make sense to you? Would you be using it? If yes, what would be necessary features? What would be no-go's?

@ryan Oh WOW, a dream comes true! ? ? ? ? ? ? ? ? ? ? ? ? ? ?

@wbmnfktr thanks for the tips ? Version so old, cache had only one folder LOL Tested in a staging environment. Upgrade of PW core - almost 150 versions from 2.3.0 to 3.0.141 - worked first time. Gotta love it! Couple of modules needed upgrading and most went smoothly. Solved issues with ProcessCustomAdminPages. Couldn't upgrade so recreated the admin pages and assigned the necessary templates Now resolving a few hiccoughs with custom template code and confident I'll get through

Try hooking after ProcessPageEdit::buildForm. ProcessPageEdit::buildFormContent only contains the page template fields and not the fields from the Children, Settings, etc tabs. Another hurdle is that the value of InputfieldPageAutocomplete is always an array, and ProcessPageEdit expects the value of the parent_id field to be an integer. This seems to be working: $wire->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->return; $orig_pi_field = $form->getChildByName('parent_id'); $attrs = [ 'collapsed', 'required', 'label', 'icon', 'id', 'name', 'value', ]; $new_pi_field = $event->wire('modules')->get('InputfieldPageAutocomplete'); $form->insertAfter($new_pi_field, $orig_pi_field); $form->remove($orig_pi_field); foreach($attrs as $attr) { $new_pi_field->$attr = $orig_pi_field->$attr; } $new_pi_field->maxSelectedItems = 1; }); $wire->addHookAfter('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); if($form->id !== 'ProcessPageEditSettings') return; $pi_field = $form->getChildByName('parent_id'); if(!$pi_field || !$pi_field->isChanged()) return; $parent_id = $pi_field->value; $parent_id = (int) reset($parent_id); /* @var Page $page */ $page = $event->object->getPage(); $page->parent_id = $parent_id; });

Hey folks! I'm happy to finally introduce a project I've been working on for quite a while now: it's called Wireframe, and it is an output framework for ProcessWire. Note that I'm posting this in the module development area, maily because this project is still in rather early stage. I've built a couple of sites with it myself, and parts of the codebase have been powering some pretty big and complex sites for many years now, but this should still be considered a soft launch ? -- Long story short, Wireframe is a module that provides the "backbone" for building sites (and apps) with ProcessWire using an MVC (or perhaps MVVM... one of those three or four letter acronyms anyway) inspired methodology. You could say that it's an output strategy, but I prefer the term "output framework", since in my mind the word "strategy" means something less tangible. A way of doing things, rather than a tool that actually does things. Wireframe (the module) provides a basic implementation for some familiar MVC concepts, such as Controllers and a View layer – the latter of which consists of layouts, partials, and template-specific views. There's no "model" layer, since in this context ProcessWire is the model. As a module Wireframe is actually quite simple – not even nearly the biggest one I've built – but there's still quite a bit of stuff to "get", so I've put together a demo & documentation site for it at https://wireframe-framework.com/. In addition to the core module, I'm also working on a couple of site profiles based on it. My current idea is actually to keep the module very light-weight, and implement most of the "opinionated" stuff in site profiles and/or companion modules. For an example MarkupMenu (which I released a while ago) was developed as one of those "companion modules" when I needed a menu module to use on the site profiles. Currently there are two public site profiles based on Wireframe: site-wireframe-docs is the demo&docs site mentioned above, just with placeholder content replaced with placeholder content. It's not a particularly complex site, but I believe it's still a pretty nice way to dig into the Wireframe module. site-wireframe-boilerplate is a boilerplate (or starter) site profile based on the docs site. This is still very much a work in progress, but essentially I'm trying to build a flexible yet full-featured starter profile you can just grab and start building upon. There will be a proper build process for resources, it will include most of the basic features one tends to need from site to site, etc. -- Requirements and getting started: Wireframe can be installed just like any ProcessWire module. Just clone or download it to your site/modules/ directory and install. It doesn't, though, do a whole lot of stuff on itself – please check out the documentation site for a step-by-step guide on setting up the directory structure, adding the "bootstrap file", etc. You may find it easier to install one of the site profiles mentioned above, but note that this process involves the use of Composer. In the case of the site profiles you can install ProcessWire as usual and download or clone the site profile directory into your setup, but after that you should run "composer install" to get all the dependencies – including the Wireframe module – in place. Hard requirements for Wireframe are ProcessWire 3.0.112 and PHP 7.1+. The codebase is authored with current PHP versions in mind, and while running it on 7.0 may be possible, anything below that definitely won't work. A feature I added just today to the Wireframe module is that in case ProcessWire has write access to your site/templates/ directory, you can use the module settings screen to create the expected directories automatically. Currently that's all, and the module won't – for an example – create Controllers or layouts for you, so you should check out the site profiles for examples on these. (I'm probably going to include some additional helper features in the near future.) -- This project is loosely based on an earlier project called pw-mvc, i.e. the main concepts (such as Controllers and the View layer) are very similar. That being said, Wireframe is a major upgrade in terms of both functionality and architecture: namespaces and autoloader support are now baked in, the codebase requires PHP 7, Controllers are classes extending \Wireframe\Controller (instead of regular "flat" PHP files), implementation based on a module instead of a collection of drop-in files, etc. While Wireframe is indeed still in a relatively early stage (0.3.0 was launched today, in case version numbers matter) for the most part I'm happy with the way it works, and likely won't change it too drastically anytime soon – so feel free to give it a try, and if you do, please let me know how it went. I will continue building upon this project, and I am also constantly working on various side projects, such as the site profiles and a few unannounced helper modules. I should probably add that while Wireframe is not hard to use, it is more geared towards those interested in "software development" type methodology. With future updates to the module, the site profiles, and the docs I hope to lower the learning curve, but certain level of "developer focus" will remain. Although of course the optimal outcome would be if I could use this project to lure more folks towards that end of the spectrum... ? -- Please let me know what you think – and thanks in advance!

Robin, you're my hero. this works definitely out of the box. thank you.

I don't want to derail this thread, but just want to say thanks so much for mentioning this. Coincidence or not? Just today someone on a client project mentioned SonarCube (which is basically the same, but installed locally, and also from the same company), and now I took a look at SonarLint, which can be added to IDEs as plugins. I will definitely try out their IntelliJ plugin. Judging from the SonarCloud results for WireFrame, it really sounds like a great tool. Sort of like ESLint, but on steroids :-) The estimated "time to fix" and references to rule (definitions) are a nice touch.

Hi @nabo See the example for changed order status here: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks You know about Tracy? ?

Just played around with your example and did a little refactoring ? Thx for sharing your code! $this->addHookAfter('ProcessPageList::find', function(HookEvent $event) { $pages = $event->return; $excludePagesByTemplate = array('admin', 'basic-page'); $pages->each(function($p) use($pages, $excludePagesByTemplate) { if(!in_array($p->template, $excludePagesByTemplate)) return; if(!$p->editable() && !$p->addable()) $pages->remove($p); }); $event->return = $pages; });

It looks like a hook to ProcessPageList::find is working. Here is the code $this->addHookAfter('ProcessPageList::find', function(HookEvent $event) { // Get the object the event occurred on, if needed $ProcessPageList = $event->object; // An 'after' hook can retrieve and/or modify the return value $return = $event->return; // Get values of arguments sent to hook (if needed) $selectorString = $event->arguments(0); $page = $event->arguments(1); $excludePagesByTemplate = array( "newsletter-clinic", "sender_2016", "sender_2016_collab", "inside-news-folder", "basic-page", "event-clinic", "domain_root", "brandportal-index", "key-figures", "jobs", "news", "media-mirror", "worker", "xmlexport", "weekly-menu", "intranet_domain_root", "weekly-menu-index", "daily-menu", "daily-menu-index", "benefit", "benefits-index", "pdiatres-de-garde-index", "xml-feed-index", "courses-index", "help-doc", "stocks-index", "dictionary", "iPad-PDF-Index", "pkb-pikettdienst-index", "heisser-stuhl-index", "heisser-stuhl" ); if($return instanceof PageArray){ foreach($return as $p){ if(in_array($p->template->name, $excludePagesByTemplate)){ if(!$p->editable() && !$p->addable()) { $return->remove($p); } } } } $event->return = $return; }); KR Orkun

@bernhard Thanks!

The page add step is skipped because of your settings that you linked to above. Not really: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks (2015 ? )

You can set the title and name after the page was added: // site/ready.php $this->addHookAfter("Pages::added(template=yourtemplate)", function($event) { $page = $event->arguments(0); $page->setAndSave('title', 'foo'); $page->setAndSave('name', 'foo'); }); You might want to make sure that the name is uniqe (https://processwire.com/api/ref/pages-names/unique-page-name/)

I loved doing that. Especially with my own projects. No matter how long they have been online. 2 years or 2 weeks. The slightest change and I started a rebuild. I try to stop this behaviour as it costs too much time. In case of a client project there is most of the time neither the money, nor the time for going this way. But... yeah, starting with a fresh copy is always great.

@bernhard would definitely do that if I had the option. The AWOL developer did a fabulous job and the code is beautifully written. I need to do the upgrade first to prove myself to the client. The rebuilt site will use the old data and redesigned to take advantage of the power of today's PW - hopefully mainly template work with a few new modules. Client has used WP in the past and couldn't believe the PW2.3.0 site still worked and hadn't needed one security update in all that time

It should be possible. You can use the methods of InputfieldWrapper on the return value of buildFormContent, retrieve the field by name, create the new Inputfield and insert that in the place of the original one with insertBefore()/insertAfter() and remove(). //... $wrap = $event->return; $origFld = $wrap->get('parent_id'); $newFld = wire('modules')->get('InputfieldPageAutocomplete'); $newFld->attr('name', 'parent_id'); $newFld->attr('value', $origFld->attr('value')); // do any other instantiation work, like setting/copying title, label etc. $origFld->parent()->insertAfter($newFld, $origFld)->remove($origFld); // done

@David Karich & @kalimati Which PW version(s) do show this behave? AND: which ImageSizerEngine(s) have you enabled there? (GD | IMagick) We had a change in what image types are supported by IMagick and need to revert back some sorts of PNGs, especially 8bit PNGs are not correct supported by IMagick, and in very rare cases there also was wrong handling for some 8bit-PNGs in GD-Engine. Maybe you can provide the informations plus one or two of the (original uploaded) images in a ZIP to me?

$allowed_fields = [ 'title', 'seo_title' ]; $out = $pages->find('include=all, limit=10')->explode(function($p) use($allowed_fields) { $fields = $p->fields; foreach($fields as $f) { if(in_array($f->name, $allowed_fields)) { return [ 'id' => $p->id, 'title' => $p->title ]; } } }); echo json_encode($out);

What about PNG images with transparency? The transparent areas are appearing as black in the webp images. Any special settings for those?

I just wanted to mention. I found a new job as a front-end dev at https://backslash.ch. Since 2 months there already and enjoy it. We work with in-house CMS specially targeted to governments. So a lot less PW for me in the future, but I'll use it as my tool for private projects.

I guess the or operator | enforces a type conversion from float (return of Math.random) into integer. So left part of the or is intended to ranges from [0...2[ (not containing 2.0, since Math.random ranges [0..1[) and the result of the or is either 0 or 1. Not sure about the +1 and -1 though...