Jump to content

PW 3.0.170 – Core updates


Recommended Posts

1 hour ago, bernhard said:

Robin, I disagree here. I've modified the admin quite a bit to fit to my needs.

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?

  • Like 1
Link to comment
Share on other sites

If anyone else is interested, I started researching different ways to try to solve this problem(not just with Processwire.)  You can view the Google doc here.  Feel free to copy/edit or whatever.

I wonder if we can simplify things?  Do we really want a layout editor in the Processwire backend where you can adjust the grid widths and so on, or do we just need some UI modifications to the tools we already have?

Here's an example where I think the backend page editor is too complex.

from:https://getkirby.com/ and https://modmore.com/contentblocks/

image.thumb.png.5a26e6dd04b49ce04a027b390eaabdad.png   image.thumb.png.aa9cb6e9a7d1541ee18f4c69f9481507.png

  • The page editor could slow down and be clunky from trying to render all the DOM elements?
  • Too complex to work on mobile
  • Content editing gets smushed into small columns
  • Dragging and dropping across layout regions requires a lot of dexterity for the end users - think accessibility.
  • requires taking up the whole page for editing

A page/layout editor will have to somehow visually represent your frontend layout in the backend.  That seems problematic to me.

Instead of having a complex page/layout editor where the user has to drag and drop columns, how about we simplify the interface so that it works on mobile as well?  While the YooTheme demo looks cool, I don't think it would work good on mobile?  I think the YooTheme UI is still too complex.

How about we just allow the user to choose from prebuilt sections or components?  Those prebuilt sections/components could then be edited in the Processwire sidebar panel like the Processwire ProDrafts sidebar editing.

It would be cool if the RepeaterMatrix, Page Reference, Page Table, Repeater fields got rid of all the cluttered "Add New" type links and instead had one "Add new" button/link that would give the option to choose a template visually in a Processwire Sidebar Panel. 


Maybe also add another option to RepeaterMatrix, Page Reference, Page Table, Repeater fields to edit pages in the Processwire Sidebar Panel instead of the inline expand/dropdown editing?  Just like the Processwire ProDrafts module does with Live Preview?


This is how Godaddy.com's website builder works.  You can try it for free.  When you click the plus icon to add a new section, it shows this selector in the sidebar.


This is also how https://froont.com/ sidebar works.  A user selects a prebuilt section or component/widget.


Also http://cards2.webflow.io/ and https://froala.com/design-blocks  and https://www.brizy.io/brizy-design-kit-2/ you can see how a page is built from these widgets/components that stack on top of each other.

Imagine if I were to create a Processwire "Landing Page" template. It would probably only have 3 fields:

  • Page Header - Single Select - to override the default site header
  • Page Sections - Allow Multi Select - to add layout rows 
  • Page Footer - Single Select - to override the default site footer

That would give a lot flexibility of the page design without allowing a user to screw up the design.

When looking at the processwire page editor, it could show the three fields each containing a preview graphic of the element that was selected.  Maybe @bernhard 's module would allow the visual selection of the templates somehow or maybe @ryan could add a representative/template preview image option to all the templates?  

The Sections field would allow multiple selections.  Those selections would display in a single column like the Page Table field that allows you to move the preview graphic of the element that was selected up or down in the list.  Maybe Page Table Extended could be used to show that preview graphic from the TemplatePreviewImages module?  I haven't tried.  If you click the preview graphic, it will open that element in the Processwire Sidebar Panel for editing.

Here is a rough mockup of what it could look like:


That way the page editing is nice and simple, no need to worry about messing with the indentation of nested elements like in this example:


Indentation is too easy for editors to mess up IMHO.

Now what happens if you click on the "Three Column" item above?  It would open for editing in Processwire Sidebar Panel on the right.  Now that "Three Column" page has other Page Reference fields to components/widgets:

  • Column 1 - contains a RTE Editor widget using a limited/restricted CKeditor or a markdown editor?
  • Column 2 - contains an Art Directed Responsive Image widget
  • Column 3 - contains a Accordion widget with other types of referenced widgets like a Editorjs.io widget or a file downloads listing widget

So that is where I'm not clear on.  Do we need some mechanism to allow us to "Drill down" to edit other referenced pages in the sidebar?  How do we go deeper?  Could there be some kind of breadcrumbs or back button like on an iphone?  The SilverStripe CMS has drill down editing as seen in this video at the https://youtu.be/IKGUd2dq8XI?t=1022 although it doesn't use sidebar editing.  Technically, I'm not sure how they achieve that?

Anyways, I don't have the solution, but I thought I would share those concepts as rough as they are. ?

I also like Bernhard's concept of defining these widget/components in code so they can be shared across sites.  Creating all these fields and templates by clicking in the admin would not be fun.  No disrespect to Processwire.  (I love Processwire and it's admin theme btw)

I love hearing all the discussion on this.  It's one huge problem that definitely needs solving.  I need to able to give non technical users the ability to create customized landing pages without them knowing html.  They like to be able to switch out a whole section just to see what it would look like.  That's why I would prefer to give them the ability to select prebuilt responsive components instead of allowing them the ability to create grids with rows with margins and paddings and so much other htmly stuff.


  • Like 9
Link to comment
Share on other sites

Good writeup, thx @gmclelland ? 

10 hours ago, gmclelland said:

So that is where I'm not clear on.  Do we need some mechanism to allow us to "Drill down" to edit other referenced pages in the sidebar?  How do we go deeper?

Exactly what I thought, when I read your concept. I think the best solution would be to have the page editor work only on the frontend. Then editors have the final layout instantly visible on the right half of the screen and when they click on a block, they can edit that block in a sidebar on the left. If the block had a nested block, they could simply click on that block, which would open a new sidebar at the same position on the screen (left side), overlapping the old sidebar, then closing it. So the editor would be in the nested block and if he/she wanted to go back to the parent block, he/she could click either on "parent" (maybe having breadcrumbs, as you mentioned) or choose the block to edit from the right side of the screen (live preview). Well, that's exactly the concept @kongondo has shown in his video ? 

  • Like 1
Link to comment
Share on other sites

Great job jploch and kongondo!  Ya'll can really put together modules quickly.  Looks like that could also be used as "Freeform layout builder" component/section that can be added to a normal page table like I show above?

jploch, I wasn't clear on how the user gets to see the grid editor in your example video?  Do they click on a button to enter into the grid editor or does it take over the normal page editor somehow?  I also like the mobile preview buttons at the top?  Maybe ProDrafts preview mode can add those?  I think CraftCms just added that feature as well?


6 hours ago, bernhard said:

I think the best solution would be to have the page editor work only on the frontend. Then editors have the final layout instantly visible on the right half of the screen and when they click on a block, they can edit that block in a sidebar on the left.

I expected it would work like the ProDrafts preview mode's sidebar?  I just don't want the preview area modifying the site's markup.  Like adding plus icons everywhere or drag and drop.  That is what the Godaddy.com editor does.  I'm not a fan of that.  Sometimes those *features* can cause CSS conflicts and cause the preview to mess up.
See below for example of the buttons that appear on hover:


I like how the ProDrafts preview mode doesn't add those *features* to the preview area.

On another note...people here were also talking about Editorjs.io and storing content in json in the database.

I ran across a spec for that from https://www.sanity.io/ it's called Portable Text https://github.com/portabletext/portabletext and they talk about it more here.

I guess you can run into problems when creating headless sites that store rich text as HTML in the database?  They use JSON instead to remove all the styling and so on.

I'm not sure how widely it is used, but I thought I would mention it in case anyone hasn't heard about it.  I'm also not sure if it is compatible with Editorjs.io?

  • Like 2
Link to comment
Share on other sites

19 hours ago, gmclelland said:

ploch, I wasn't clear on how the user gets to see the grid editor in your example video?  Do they click on a button to enter into the grid editor or does it take over the normal page editor somehow?

It's just the regular page editor. You can also combine my fieldtype with other fields on the same page. In my example I was using AdminThemeCanvas, maybe that was a little confusing, it will look more like the regular page edit screen with the default theme.

Link to comment
Share on other sites

Here is an example of sidebar editing from https://www.storyblok.com/:



Sorry, I'm not sure how to embed youtube videos on this forum?

https://www.contentful.com/ also something similar called a "Slide-In Editor"


Here is another image that shows how a page is composed in contentful.com.  It looks similar to Processwire's PageTableExtended module, but notice how you can also link existing entries/pages.  We can't do that with PageTable or PageTableExtended.


PageTableExtended comes close to a lot of the other systems I have seen, but it lacks a few features that would make it a good solution.  It needs to be combined with https://processwire.com/modules/page-table-extra-actions/ and I also don't think the ProDrafts module fully supports PageTableExtended?  It gives a warning that say's "This field doesn't support Drafts. Changes will always save to the live version."



  • Like 3
Link to comment
Share on other sites

  • 7 months later...

I know I'm super late to this party, but since I've been away for quite some time - but absolutely love ProcessWire - and Ryan mentioned that this roadmap could extend beyond 2021, I thought this was the most appropriate place to comment. Thanks to @teppo's PW Weekly I've been able to, mostly, recount (in summarized form) multiple years of development (with plenty of tangential links, often reading the full blog posts by Ryan) both of PW and in 3rd party development efforts, so I don't feel too terribly left behind.


Zoom out and look at the bigger picture, and look towards the future—what's game changing and "next level" for the years ahead that we might not already know about? It doesn't have to be unique to PW either

Something a little different not yet discussed:

Zooming out and looking at the bigger picture, within regards to the CMS/CMF landscape, I think an area that PW lacks is in marketing of itself, and I don't mean this as a knock on ProcessWire - the product speaks for itself and word of mouth is awesome, and marketing efforts can oftentimes detract from active development time. Marketing isn't exactly a "core feature" of the codebase, but it is something that I think can be code-adjacent. ProcessWire is capable of so, so much, but from just looking at it, or installing it from source, it's hard to see that from the eyes of a first-time user. ProcessWire doesn't use templates like WordPress, but templates are a big business with WordPress. Although some WordPress templates come bundled with custom plugins which starts skirting the line of what ProcessWire does (site profiles), there's a plethora of ready-to-go, custom designed websites with a only the simple task, after installing, of adding content. ProcessWire is more developer focused (which I personally love), but that doesn't mean we can't, or shouldn't, also cater to an audience that may want to see what designs or functionality can be made (almost) immediately available after install. As a simplistic first step here: currently Site Profiles are listed under Modules as its own category, but that's not too intuitive for findability - if this were to have its own landing page and higher level navigation, with feel good images based on the profile (for those that provide them), I think it might help to attract more potential users.

On the topic of Site Profiles, since ProcessWire is capable of so much (that many of us aren't even entirely aware of), having some custom built, premium Site Profiles built as premium starter kits (kind of like what my buddy Jack McDade is doing with Statamic) it might be another boon, and additional income source. He's also considering selling branded merchandise, which I think we'd tried before and it didn't take off, but it's easy to do (via something like CafePress) and every little bit helps I suppose?

On these notes, should there be - or has there been thought to - an official marketplace via the ProcessWire website for things like these (with a percentage going back to PW)?

Pro Module Thoughts:

1. Search:

I remember a mention of the front-end search functionality of the current version of the PW website potentially being packaged up into a Pro Module. What's the status on that? I think that - if it could be packaged into a pro module - it would be a fairly popular one. I realize that language issues would be a hurdle and there were strides made towards that endeavor such as with WireWordTools but don't know if the feasibility was broken down once multi-language was considered or if it's still able to be worked on and released.

2. Recurring Dates / RRule


adrian: If you want an idea for another profield, a properly working version of a recurring dates field would be awesome.

Robin S.: A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date.

I too would have a use for this. Realistically, most businesses could if they want to attempt to accurately list their open hours when they celebrate holidays, as holidays have recurrence, and can have annoying recurrence (like the American Thanksgiving) which is the 4th Thursday of November. API-based things might have a need/want to integrate LazyCron into a non-standard recurrence. My personal usage would be for events - honestly I'm surprised the school websites Ryan's worked on haven't had a need for this. Reporting to Google for JSON-LD on its recurrence may also be helpful to have an API-level access to it as well (I'm not familiar enough to know for sure though).

The largest difficulties in handling recurring events is exception management. There are usually two ways to generate recurrence - tie them to a single entry and assign a recurrence rule and extrapolate from that dynamically on call, or use the recurrence rule to generate the actual entries, individually (and usually have them tied to an original). How would exceptions be handled if a single date, or time, needed an adjustment? If one or more were cancelled? If one or more were to be added? If editing the primary edits them all, does it overwrite all others even if individual changes were made? Whether convention or configuration, these are just some potential issues with recurrence. ?

Image Reference Field and/or Central Image Manager:

It's certainly not necessary to a website being used, created, or maintained - but it would certainly be helpful if it was part of the core, whether optionally (in page settings) or statically (as a field/input setting). Teppo did a great job illustrating why:


I've found that this becomes more important when a site has more content and more content editors: sometimes it's about not having to maintain a separate media library (in a traditional media library, somewhat like the one found from WP, they would just upload the materials once and then reuse them everywhere with ease), and other times it's about knowing where each material has been used / being able to update it in a central place if it needs to change.

I'm essentially a technician (title is Web Administrator, but 85% of my job's time is help desk / support), professionally I'm a programmer/web developer, but the business I've worked for has 100+ people who are extremely varied in their technical expertise. 40 or so of them will be expected to have access to the administrative back-end for the primary website I'm (finally) redoing in one way or another, as they will be the content authors/maintainers (I work for a public library, so these are city-level librarians). They would not take the time to find a reference to an image already in the system when they could more easily just upload another completely brand new copy of the same image (let's say it's a 200MB file) multiple times, and resize it to a 240px width. I know that I could create a page that contained a "shared" image repository, or use one of the various modules, but the fact is that it can be very useful for various reasons.

Layout Tool / Editor:


Ryan: I wonder if anyone else can weigh in on directions here? I know a lot of people like the editor.js direction, but Bernhard has also posted what seems like a good direction. They are very different directions, but seem to accomplish similar things. Ideally I'd like the community to narrow in on what's best for their needs and for ProcessWire.

bernhard: Please. No!

monollonom: Mixed with the inline CKEditor, it almost looks like your screenshot, except that it's still clear we're still dealing with "components" that the user can move around.

gmclelland: It would be cool if the RepeaterMatrix, Page Reference, Page Table, Repeater fields got rid of all the cluttered "Add New" type links and instead had one "Add new" button/link that would give the option to choose a template visually in a Processwire Sidebar Panel.

From my own personal experience, I would agree with bernhard here. I think, based on the 5th time I've read through this topic, that it's been decided that Editor.js, specifically, is not a good fit, but continuing on... I'd done some testing of my own, like bernhard, and found limitations and issues with it. I'd also tried showing it to some basic-skilled coworkers with minimal (but enough) instruction and they struggled, hard. Showing them a CKeditor field (without instruction), however, they were able to do what they wanted and although were confused with certain things, weren't struggling. That said, from what I've seen of Bard and Editor.js, a similar approach can be managed using styling and JS adjustments with the RepeaterMatrix fieldtype, even if it's apparently overkill where storage needs come in. I do like that individual fields are still independently searchable within RepeaterMatrix though, which I think wouldn't be the case with an Editor.js fieldtype solution.

How is RepeaterMatrix similar to Editor.js with style and JS changes?

Robin S. and monollonom essentially had similar ideas - that the layout is different for Editorjs/Bard type fields, they're more compact and seemingly integrated. From the observation of the front-end GUI interface of Editor.js and Bard, it's doing something fairly similar to what RepeaterMatrix currently does - you create a new item (or start of a block of items) from a predetermined set of options. It's just that the interface of the other two has a different "wow" factor. Click a hoverable + button, choose from the available options, and then go about adding the related content. So if a fieldtype was created that's similar to RepeaterMatrix but stored data in a more efficient way, and was intended to be a more concise and (for lack of a better word) all-enclosed field, I would think using similar markup to RepeaterMatrix with a much more visually minified styling could help here.

I'd love to understand more about how the $page-meta() can be used to integrate non-field stored data like bernhard was asking about, because that could be a way for developers to setup layout-like interfaces within custom-made template builders.

Actual Page Builder - an Alternative: Fieldtype

There are a few open source visual page builders for email templates (ex: GrapeJS). These are well-tested and I'm thinking that for the purposes of single page instances or landing pages, something like that could be used and created into a fieldtype of its own. Remove all of the markup from it afterSave to get only the text content, and place that content in a separate data field in the DB to make it searchable and it's now capable of being a standard page/template in PW. It would be up to the developer to place appropriate limits on it, but beyond that... Just a thought.

I ♥ ProcessWire.

(I also love all of the work that's been done since this topic was created, too!)

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...