Leaderboard

140 commits, 55 resolved issues, dozens of new features, eight contributors, and five new pull requests make yet another great new version of ProcessWire. This week I’m happy to announce another new main/master branch version of ProcessWire, version 3.0.210. Like most main release versions, there is a lot here. This post covers some of the most notable additions and improvements— https://processwire.com/blog/posts/pw-3.0.210/

PAGEGRID – A visual page builder for ProcessWire. Design fully responsive websites (or parts of them) without writing any code. Use ProcessWire's native templates (and fields) to create your own blocks. Rearrange and resize items in a visual way and use inline or modal editing to quickly edit the content of your website. Try PAGEGRID for free PAGEGRID is not free software. However, you can try PAGEGRID on your local machine or on a test server as long as you need to make sure it is the right tool for your next project. … and when you’re convinced, buy your license. Get it here Download from GitHub Download from Module Directory Requirements ProcessWire 3.0.210 or greater Installation Go to “Modules > Site > Add New“ in your admin Paste the Module Class Name "FieldtypePageGrid" into the field “Add Module From Directory“ Click “Get Module Info“ On the overview, click “Download And Install“ On the following screen, click “Install Now“ More install options Module install guide Site profile install guide Get up and running Quick start Create your own blocks or install the PageGridBlocks Module (installs premade templates and fields for PAGEGRID blocks). What's PAGEGRID? page-grid.com – Get to know PAGEGRID. Documentation – Read the official documentation. Issues – Report bugs and other problems. Forum – Whenever you get stuck, don't hesitate to reach out for questions and support. Why I build it ProcessWire is super flexible in itself and lets me build whatever I want. But building a custom website can be a lot of work. For some projects, I've ended up using a lot of templates and fields. To make my pages more flexible, I sometimes build my own little page builder based on the RepeaterMatrix or PageTable module. While these page builders were great for the specific site I was building them for, they were never flexible enough to be used for new projects, so I ended up customizing them frequently. The more complex they became, the harder it became to use them for my clients. After playing around with some WYSIWYG page builder tools, I realized that while they can save me a lot of time, they can also be very limiting or have expensive subscriptions and somehow tie you to their ecosystem. So I decided to build my own page builder based on the most flexible CMS I knew. Concept This fieldtype Renders block templates and adds drag and drop functionality in admin, as well as enable inline editing for text, and file fields. It also let's you manipulate CSS in a visual way to design fully responsive websites (or parts of them) without writing code. The fieldtype comes with an optional style panel to manipulate CSS properties directly on the page. You can customize the panel or disable it completely from the module settings (and just use a CSS file that you include in your template). The data to style the items is stored directly on the item using PW's meta data (no extra fields are created). Don't want to give your client all that power? Use ProcessWire’s powerful permission system to control what your clients can edit. You can then also grant access individually to the style panel, resize or drag functionality using ProcessWire's build in permission system. Features Blocks are just pages Blocks are defined by native PW templates and fields Manipulate CSS grid or flexbox based layouts in a visual way to design fully responsive websites (or parts of them) Encapsulated frontend code (PAGEGRID renders the template of your frontend inside an iframe in the backend) Design and editing features can be disabled for certain roles (using ProcessWire's build in permission system) Inline editing of text, textarea, TinyMCE (supports latest version), ckeditor and file fields Simply drag and resize to manipulate grid items directly inside the backend Manipulate grid columns and rows directly on the page (use any number of columns you want) All style manipulations are saved as JSON and used to generate dynamic styles that you render in your main template (no inline styles) Nested groups/grids (child pages of nested blocks are created under group parent) The style panel supports adding custom classes and assigning styles to them. These classes can be used globally on all pages (a css class is also a page) The style panel supports selecting html tags to style tags globally across the whole site Global blocks work with page reference field (changes on one page, changes all blocks on all pages) Manual and auto placement of grid items blocks and nested blocks can be cloned Redo/undo and copy/paste shortcuts Editing block items in modal sidebar immediately updates frontend (Ajax Save). Define custom icons for your blocks via native template settings (template -> advanced -> icon) Automatic page save (Changes are getting saved via ajax, no need to click the save button) NEW: Option to automatically load lazysizes lazyloader (V 0.1.0) Changelog V 0.1.0: Feature: Option to automatically load lazysizes lazyloader (Module Settings > Plugins). V 0.1.5: Fixed bug: Tabs not working when editing items via modal panel. V 0.1.6: Fixed bug: Setting height in VH unit was not working. V 0.1.7: Feature: Option to hide save button (and use automatic ajax save ) if there are no other fields than PAGEGRID on the content tab (Module Settings > Interface). V 0.2.0: Fixed bug: Custom block wrapper element <p> was not working with inline editor. V 0.2.0: Fixed bug: Inline editor would sometimes not save after clicking cancel and then edit item again. V 0.2.0: Feature: Now it's possible to add classes to elements inside richt text fields via style panel. V 0.2.0: Fixed bug: Inline editor was not working after first item was added to the page (needed reloading the page). V 0.2.1: Feature: Updated PageGridBlocks Module: Using TinyMCE as the default editor. V 0.2.1: Feature: Updated PageGridBlocks Module: Group/container wrapper element can now be changed to <div>, <section>, <article>, <header>, <footer>, <nav>. Thanks to everyone who helped me improve my coding skills and for the support of this great community! Special thanks to @diogo for the valuable feedback and @ryan for this great CMS and his support for the PageFrontEdit module!

These last few weeks I've been working on integrating a ProcessWire installation with the Fareharbor API for a client. Other than the authentication part (which is as simple as it gets), I've found this API to be one of the more time consuming ones to work with. It's not so much that the API is difficult to use, as much as it is just a time sink, taking a long time to reorganize the info it provides into something useful for our needs. And likewise taking a long time to prepare information to put back into it in the format it requires. My best guess is that it is an echo of an existing back-end API, projecting internals rather than tailoring a simpler public API to them. Perhaps it's an interface optimized for the some internal legacy system rather than the external consumers of it. Or perhaps it already is a lot simpler than what's behind it, and its interface has been carefully considered (even if it doesn't feel that way), who knows. To be fair, no API is perfect, and this particular API does provide a working and reliable interface to some pretty complex data, and an immense amount of power. It's good to work with lots of different APIs, from easy-to-painful, as it helps to clarify paths to take (and to avoid) when authoring new APIs. I ended up building an adaptor module in ProcessWire just to give this particular API a simpler interface that was more useful to the needs we had, and that is now saving us a lot of time. It reminded me of one reason why ProcessWire was built in the first place, to create a simple interface to things that are not-so-simple behind the scenes, and I think we've been pretty successful with that. We'll keep doing that as ProcessWire continues to mature, evolve and grow, as we always have. In terms of core updates, commits this week were similar to those from the last couple of weeks: a combination of issue fixes, a PR, feature requests and minor improvements. We are now 17 commits past 3.0.211, but I'm going to wait till next week before bumping the version to 3.0.212, as there's a little more I'd like to add first. Thanks for reading this update and I hope that you have a great weekend!

Where I am: Edit Page -> Settings -> Parent -> "+Change". Edit Field -> Page Reference field -> Input tab -> "Selectable pages (Select the parent of the pages that are selectable)" -> "+Change". ... and possibly other locations where the Page Tree is used. Quality of life improvement: When modifying Parent Pages (Edit Page) or Selectable pages (on a Page Reference field) and I press "+Change" to change the Parent Page, it would be nice if the current Parent Page came into focus without effort. Current solution: As an editor, I am required to find the Parent Page / "Page Reference parent page" manually which makes me think ("where did I put that page?"), takes a bit of time ("click, click, click"), and is hard on a larger site with a deep structure. The unmet goals are: I instantly see the context for the current Parent Page. I can effortlessly select another Parent Page. Constraints: Large website makes it hard to navigate and get a view of the Page Tree. I don't want to pick an incorrect Parent Page. It's sometimes difficult to see if I choose the right parent. The Parent Page must be in the current "Page Branch" ("/foo/bar/baz/" -> "/foo/quz/baz/"). I don't always need to see/browse the full Page Tree. Sometimes a lot of parent pages are unnessarily shown (larger websites with 4-5 levels of pages). Better: When I open the Edit Page / Edit Field page and click "+Change", I want the tree structure to expand (in a modal?) and bring the current Parent Page into focus. It's one of those small things that help create a smooth user experience. Additional thoughts: The displayed Page Tree only shows the current Page Branch; this might optionally be specified on the Template. Hide "unneeded" parent pages in a larger websites with 4-5 levels of pages (how?). Perhaps you have additional ideas that might improve working with Parent Pages when editing a page or a field?

I can click the button just fine on android Chrome, but can also confirm you are not going crazy I tested in my wife's phone which is an iphone and I can replicate the behaviour! It takes too taps to click the button!

There's tradeoffs between maintainability and controllable surface area vs. flexibility. The more options available the more permutations of options there are. More permutations of options make downstream concerns more tricky like caching, authentication, internal querying, …. Just need to look at the issues with deploying a graphql API at scale, where graphql sits rather close to the flexibilit end of the mentioned scale.

The only problem i see is, you have to do some workarounds that each user only see his own subdomain. Otherwise all users see all sites in the adminarea. A hook in ready.php could look like this: $this->addHookAfter('ProcessPageList::find', function ($event) { $event->return->each(function ($p) use ($event) { if (!$p->editable() && !$p->addable()) $event->return->remove($p); else if ($p->template == 'subdomain-home' && !$this->user->hasRole("superuser") && !$this->user->hasRole(strtolower(str_replace(' ', '-', $p->title)))) $event->return->remove($p); // title from homepage and userrole have the same name }); });

IIRC this just takes you to the normal page finder, where you can click the column headers to sort. You can also add and remove columns if the one you’re looking for isn’t there by default.

You have too hook the Lister: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /* @var ProcessPageLister $lister */ $lister = $event->object; // I'm not sure, but the parent of the "Search Lister" has the ID 0? if($lister->parent->id !== 0) return; // Set sort $lister->defaultSort = 'title'; bd("Changed Search Sort"); });

Yes I can confirm now hat everything works as expected.

Hello @Stefanowitsch There was a wrong query string inside the method, which is responsible to find all frontend templates. I have corrected it on Github. You do not need to download and install the whole module. Please replace the file JkPublishPages.module from the module with the new one at Github and let me know, if it works now. I have bumped up the module version too, because this was a significant malfunction. BTW: you can set the child settings to no again and only to mention: the homepage is excluded from the templates.

I'll send you a PM with some screenshots of my page structure and the settings.

My explanation, was for the parent pages, not for adding the publishing fields to the template. To clearify: This blog post template will not be visible at the checkboxes list for the templates in your case? I will take a closer look on my local installation and give you a feed back after lunch. I guess there will be a problem in querying templates.

You are right. This setting here in the page template settings seems to be responsible for including/excluding the template in the module settings. This was set to "NO" in my case: May pages using this template have children? Is this critical for the module to work? I want to include the "Published From" field to a blog post template. This template should not be allowed to have subpages underneath it.

You can use a hook for this ?

Hi all, I'm currently working on a PW app that is expected to get a lot of traffic for a few days. Peak will be around 5000 requests/second. The app is hosted on a virtuel server within the client's network and has some quite impressive specs: - 32 core CPUs - 80 GB RAM Now I am wodering if the server will be able to handle high loads. ATM we have around 100 open sessions per second and mysqld process is already spiking around 10% and php-fpm around 2-5%. We did load tests with 5000 virtual users through https://loadforge.com/ and the server is starting to produce hangs at only around 50 requests/second. On the code side there is nothing really special. No expensive queries that I am aware of. Caching is not really an option because frontend views mostly depend on frequently changing data and most views have form submissions. There is one dashboard view with long polling XHR requests for JSON data. This data can also not be cached because it changes frequently so I think permamnently updating cache on data changes would be equally expensive as just not caching it. Unfortunately we have no server monitoring tools at our disposal. But I would think that a server with these specs should be able to easily handle hundreds of requests/s. The IT responsivle for the server do not seem to have a lot of experience with LAMP stack web servers. So I'm concerned there might be some MySQL missconfigurations. Anyways, if any of you have experience with high load PW apps, please share your expertise ?

I have installed the module. On the module settings page in the "Add fields to template" checkbox-list some of my templates are missing (where I need to add the field). Does the module kind of "sort out" some templates depending on the settings here? Am I able to add the required fields "by hand" in the template settings instead?

Bumping this thread. It's an issue that has been brought up by clients, especially those with larger site structures. Selecting a page in the PageField set to "Tree View" is no problem. However, on edits its hard to identify if the correct page has been selected or which page has been selected altogether. A suggest improvement would be: Field Option: Tree Open/Closed This would improve UX of the field significantly.

those should be replacing with the corresponding ID3 tag - title, composer, artist, album and track. So if you're not using ID3, then you'd just use the file description field...

Sorry of course it's not ?field... on page edit, because you have ?id=... there, so you need to append that url parameter via &field[s]=...

I'm dying to know, am I the only one bothered by (or maybe the only one seeing??) this line under the tabs now? ?

You can also use the selector with the children() method: $page->children("children.count=0, sort=-date");

That doesn't look like the correct syntax for setting multiple sorts in a selector string. I think it should be "sort=template, sort=-created" https://processwire.com/docs/selectors/#sort To apply it to the admin search using a hook: $wire->addHookAfter('ProcessPageSearch::findReady', function(HookEvent $event) { $event->return .= ', sort=template, sort=-created'; });

You could also do this in your homepage template: echo $pages->get('/path/to/page/')->render();