PW 3.0.170 – Core updates

[kongondo]

9 hours ago, Jonathan Lahijani said:

Please share your thoughts.

Btw, @Jonathan Lahijani, making content editable versus non-editable as per your comment in the video is 'quite easy' to do with reactive frameworks. You can even make this configurable if you wanted.

[Ivan Gretsky]

Just in case we really go that route with dynamic admin pages there is a way NOT to use a reactive JS still achieving similar results, staying in the realm of a server-generated html and avoiding complex build workflows. There is a mature Unpoly library and a new Hotwire stuff from Basecamp themselves. Using those might be an alternative, which would not require such massive changes, as switching to Vue or React (do not think Alpine is enough here))

Hotwire would be a great couple to ProcessWire due to it's name only))

[kongondo]

28 minutes ago, Ivan Gretsky said:

staying in the realm of a server-generated html

This is very much doable using Vue JS. It is a progressive framework. You can use it with your existing HTML ,sprinkling in as much or as little of Vue reactiveness as you need.

[Ivan Gretsky]

10 hours ago, Jonathan Lahijani said:

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits.  I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan )

(note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem)

Please share your thoughts.

Wow! That is the best explanation possible!

My thought on making the whole layout thing happen on top of RepeaterMatrix field, is using the second approach with levels, but allowing the matrix types to define allowed children. So you can only put a grid under a section, a col under a grid and a component under a col. All that should be definable in the field config.

Other important thing to consider are:

• being able to easily move content types between fields/projects;
• being able to define which components are available on which template (in case we do not want top duplicate the fields; it kind of works with Matrix overrides, but is not so easy to customize);
• being able to copy the whole sections from page to page (kind of like this).

We should not abandon the idea of not basing on Repeater Matrix though, if it removes its restrictions.

[Ivan Gretsky]

1 minute ago, kongondo said:

This is very much doable using Vue JS. It is a progressive framework. You can use it with your existing HTML ,sprinkling in as much or as little of Vue reactiveness as you need.

Not so sure) IMHO, anything beyond the basics would require an SPA with webpack build. Vue (or Alpine as it's stripped down alternative) would not solve the problems we got if not used at full scale. But something like Hotwire can.

[kongondo]

3 minutes ago, Ivan Gretsky said:

IMHO, anything beyond the basics would require an SPA with webpack build. Vue (or Alpine as it's stripped down alternative) would not solve the problems we got if not used at full scale

I see your point. However, it doesn't need to be an SPA. Webpack is a pain to configure, although there are various approachable alternatives out there. 

[ryan]

Quote

Perhaps you're further down the adoption curve? One can always hope

ProcessWire is definitely a sustainable open source project and here for the long term. Though if the standard of adoption measurement is WP, then we are nowhere near that and never will be. I certainly wouldn’t want that either. But our installation base is already much larger than I would have ever believed possible. This is in part because ProcessWire has grown, but also because the demand for what ProcessWire provides has grown, as has the entire online landscape. 

Quote

A few years ago it was easier to convince clients to try other platforms, today it's common for WP to be not just a strong recommendation but actually a strict requirement.

When a client hires us, they hire us because they aren’t web developers themselves, and they want an expert. If the client has already decided on the best tools for the job, which is not their expertise, then they aren’t looking for an expert. I hope that most of us can be selective enough not to take on such clients. 

There are also cases where you as the expert may decide that WP is indeed a good fit for their need. So long as the client understands what they are getting into, and they trust your expertise, why not use WP? Maybe some think that PW should always replace WP, but they are different animals with their own strengths, and neither is a replacement for the other. 

To be honest, I am glad that WP is where it is and has the usage that it does. In some ways PW is successful because of WP and the path it has opened for PHP, MySQL, content management and open source. WP has helped to open the gates so that even a relatively small project like PW can have a significant self sustaining user and installation base. 

Quote

However it would be nice if this [FieldtypeDecimal] was in the core

I see no harm in expanding FieldtypeFloat to support a decimal column type, so I’m going to go ahead and do that. Is there any issue in the existing FieldtypeDecimal that also needs to be solved when I put in this update?

Quote

I wonder though if perhaps it's time to set up a "base" theme that handles all the basic functionality / layout of the admin and have Uikit extend that. 

This is the AdminThemeFramework class, which AdminThemeUikit extends. While it hasn’t really played out that way yet, AdminThemeUikit itself was built to be a more generic base, though for Uikit-based theme) The AdminThemeUikit module (and its supporting files) are also a good template for marrying a CSS framework with an admin theme. I don’t see much potential for an abstraction layer between AdminThemeFramework and AdminThemeUikit. If I wanted to build an admin theme that used a different CSS framework, then I would copy all the files from AdminThemeUikit, replace the Uikit library with another, and update the files as needed for the other framework. 

Quote

Regardless, I do think it's time it became the default theme way one or another.

AdminThemeUikit is already the default for new installations. For existing installations where someone has already selected AdminThemeDefault or AdminThemeReno as their theme, then we don’t change their selection. Although I think AdminThemeUikit has effectively replaced AdminThemeDefault, and I don’t plan on doing any more with AdminThemeDefault, other than probably dropping it at some point. I would like to keep AdminThemeReno though maybe refactor or rebuild it so that it is also using our base AdminThemeFramework.

Quote

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits.  I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. 

That you Jonathan, this is a really fantastic overview/presentation of the builder concepts. Also, amazing work with what you’ve built! 

My impression is that yes we could certainly take RepeaterMatrix quite a bit farther in supporting a lot of this (moving children with parents, limiting child types, etc.), per the things that have been outlined here and in your video. And maybe I should add those things, just to open the door at least, and let people decide how they want to use them.  

But it’s uncertain if RepeaterMatrix is the best foundation for this builder concept (as you’ve pointed out). To take it further, I think it’s also uncertain if pages are even the best foundation for each element or section in a builder. In a page builder, there doesn’t seem to be much technical need for all the data to be stored in separate fields and pages, because it all seems to be aimed at achieving some front-end layout rather than a flexible and accessible inventory of data. All of the sections, elements, etc. in the builder seem to be aimed at segmenting content for a particular layout on a single page. This separation is about front-end layout, and not much else (is this even content management?). I think the back-end storage of it should also reflect that. Basing it on a Fieldtype does seem to make sense, but RepeaterMatrix is really overkill on the storage side, while not enough on the editor side. Given this, it seems like a site builder might benefit from being a new Fieldtype rather than one based on Repeaters. Though I can already see there are drawbacks and benefits either way. 

One question for those interested in a site builder: who is the audience for it? Whether we should be looking towards something really simple, or something more complex, likely depends on the answer.

It looks to me like the audience is primarily web developers, or at least people that know some web development, because you’d need some pretty savvy clients to use tools like this. Though “The Bard” looked like something I could potentially walk a client through. But it’s obviously not nearly as powerful as something like the YOOtheme builder. That one looks like Dreamweaver for Uikit. Is there demand for that? It’s technically quite cool,  but is it wise or portable to couple content with layout like this? It’s clearly a compromise, but maybe it depends on the use case. CKEditor is also a compromise, but it’s usually portable and semantic enough for the content to survive site redesigns. 

Quote

If we end up using Vue JS (or even React), then perhaps we need to pay a visit to our old friend jQuery (and its siblings - UI) to plan for their retirement?

I like and am open to adopting Vue where needed, but not at the expense of jQuery. I don’t lose interest in a particular tool just because it’s been around a long time. I know everyone likes what’s new and always changing, but for me, some of the best tools are the ones that have been around a long time. jQuery remains one of my favorite tools and an important part of ProcessWire's admin. Now if we have to change the way we use jQuery, such as using jQuery() instead of $(), in order to integrate a library like Vue, then I would be fine with that. 

Quote

I agree that something like the YOOtheme Pro Builder would be the way to go. 

As fun as it looks, building a tool at that level probably isn’t realistic (for me anyway). If we were to have a tool like that, we’d want to adopt an existing open source tool, much in the same way we do CKEditor. That would be ideal. If that’s even an option?

Quote

There is a mature Unpoly library and a new Hotwire stuff from Basecamp themselves.

I spent some time checking out the Unpoly library and thought it looked pretty great! Hotwire’s video lost me though, some guy talking on top of a video on fast forward, zipping through command lines and such, insanity, can't tell what the hell is going on.

[adrian]

7 minutes ago, ryan said:

Hotwire’s video lost me though, some guy talking on top of a video on fast forward, zipping through command lines and such, insanity, can't tell what the hell is going on.

Glad I am not the only - I was intrigued by what I read, but that video was confusing as hell. Either way, I have never been a fan of what the Basecamp guys do, so I would definitely be hesitant for that reason alone - maybe an unfair approach to judging Hotwire because I am sure they've learned a lot since they build Basecamp.

9 minutes ago, ryan said:

I see no harm in expanding FieldtypeFloat to support a decimal column type

This sounds a bit confusing to me. I feel like we either need a separate decimal fieldtype, or maybe a FieldtypeNumber that has options for all the numeric types that MySQL supports. Of course we also have a separate FieldtypeInteger, so maybe it will start to get confusing if they are all combined into one Numeric type now, although I think it might be the ideal option, although I haven't thought through all the possible issues with this yet.

[Jonathan Lahijani]

6 minutes ago, ryan said:

One question for those interested in a site builder: who is the audience for it? Whether we should be looking towards something really simple, or something more complex, likely depends on the answer.

I often develop ProcessWire websites for large companies and organizations, where there are 20+ employees.  In these scenarios, my point of contact is almost always someone with a marketing or managerial role.  Here are the actual positions I just pulled from the email signatures of my go-to contacts of several of my clients... notice the similarities:

• SVP Marketing
• Marketing & Business Development
• Marketing Associate
• Director of Marketing
• Director of Marketing (again)
• Assistant Marketing Manager
• Marketing & Communications Coordinator
• Production Artist
• Office Manager

These marketers are the ones who manage the day-to-day content needs of the site.  They are not coders, but are generally technically savvy.  They like ProcessWire, or at least the way I set it up.  They oftentimes need to throw a page together that's not strictly defined by a template.  They need some flexibility to express themselves.  While this can be done with Matrix in its current state (say you made 20 different sections that they can choose from), it requires a lot of planning beforehand and can't handle edge-cases without developer involvement.

[kongondo]

Same here with Hotwire. I watched 4 different videos and I still couldn't get it.

Site / Content / Page / Theme Builder

Are these four really synonymous? I am not an expert, not at all. However, we seem to be using these terms interchangeably, meaning perhaps we are not on the same page? Could someone please explain the differences? @Jonathan Lahijani?

[Jonathan Lahijani]

Hotwire is an alternative approach to building an SPA without having to do the whole API-first approach, whereby a frontend in React would consume some JSON API.  Instead you just build a site the classic, server rendered way, sprinkle in Hotwire, and it makes it work like an SPA.  Behind the scenes, it's working with actual HTML instead of JSON, which is the key difference.  It was born out of Hey.com, the new email service from the creators of Basecamp.

I strongly recommend listening to this podcast episode with DHH.  He and Adam Wathan (creator of Tailwind) get deep into it:
https://fullstackradio.com/151

As they say in the episode, it fits my mental model.

I don't think ProcessWire from the admin side of things needs to be an SPA.  However Hotwire could be used on the frontend if a developer decided.

[Jonathan Lahijani]

44 minutes ago, ryan said:

It looks to me like the audience is primarily web developers, or at least people that know some web development, because you’d need some pretty savvy clients to use tools like this. Though “The Bard” looked like something I could potentially walk a client through. But it’s obviously not nearly as powerful as something like the YOOtheme builder. That one looks like Dreamweaver for Uikit. Is there demand for that? It’s technically quite cool,  but is it wise or portable to couple content with layout like this? It’s clearly a compromise, but maybe it depends on the use case. CKEditor is also a compromise, but it’s usually portable and semantic enough for the content to survive site redesigns. 

"Is there demand for that?" -- I would say this is a resounding yes.  There are dozens of page builders out there, and many tied to WordPress:
https://blog.hubspot.com/service/wordpress-page-builder

Block Editor (Gutenberg) is more of an advanced version of TinyMCE/CKEditor, but it's quickly becoming more of a "page builder" in the next year or two.

[Jonathan Lahijani]

43 minutes ago, kongondo said:

Site / Content / Page / Theme Builder

Are these four really synonymous? I am not an expert, not at all. However, we seem to be using these terms interchangeably, meaning perhaps we are not on the same page? Could someone please explain the differences? @Jonathan Lahijani?

They are not synonyms and their loose definitions are sure to cause confusion.  Here are my definitions:

• Site Builder (aka Full Site Editing / FSE): a no-code type tool that allows you to create a website, including global portions like header and footer.  Good for basic websites and non-technical people.  See brizy.cloud as an example.
• Layout Tool: something that allows you to create a section/container/grid/cell structure for a specific page in a visual, no-code way.
• Components: simple things like Headline, Text, Image to complex things like Table, Definition List, Video, Slideshow, Slider (ie, things that are basically repeating content).
• YOOtheme Pro: a mega-theme that turns a WordPress website into a Site Builder.
• YOOtheme Pro's Page Builder: it's the part of YOOtheme Pro that you encounter to build a page in WordPress, as shown in the video.  It's a combination of what I'm calling Layout Tool + Components.

[kongondo]

Thanks for the defs @Jonathan Lahijani

6 minutes ago, Jonathan Lahijani said:

YOOtheme Pro's Page Builder: it's the part of YOOtheme Pro that you encounter to build a page in WordPress, as shown in the video.  It's a combination of what I'm calling Layout Tool + Components.

I'll see if I can set myself a challenge to build a basic clone of this this weekend ?.

[ryan]

Quote

This sounds a bit confusing to me. I feel like we either need a separate decimal fieldtype, or maybe a FieldtypeNumber that has options for all the numeric types that MySQL supports. 

It makes sense in FieldtypeFloat because they both represent numbers with decimal points, they would share most of the same configuration options, and they would use the same Inputfield. A separate FieldtypeDecimal module is also good, but since that’s already a module that exists that people are using, I don’t want to cause trouble for anyone by getting into that namespace. I also like to avoid adding new modules to the core unless absolutely necessary. A FieldtypeNumber would be too broad and too much overlap with existing modules. Keep in mind we’re talking about the module class name here, not the module title, which could be something like “Float or Decimal”, rather than either/or.

Quote

I often develop ProcessWire websites for large companies and organizations, where there are 20+ employees.  In these scenarios, my point of contact is almost always someone with a marketing or managerial role.  Here are the actual positions I just pulled from the email signatures of my go-to contacts of several of my clients... notice the similarities:

Thank you, that clarifies a lot. I can see how this would be just right for a marketing person at a company. It's been a long time since I've worked with a marketing person, so I hadn't thought of it.

Quote

“Is there demand for that?" -- I would say this is a resounding yes.  There are dozens of page builders out there, and many tied to WordPress:

What I meant was, is there demand for a YOOtheme type builder in ProcessWire? Like, would anyone’s clients use that, or would it be another tool for us developers? It sounds like the answer is probably yes to both. But WordPress is conceptually very different from ProcessWire, where this mixing layout and markup and content might be fine. Whereas I think people look for ProcessWire to be a little more best practices oriented, in which case it might make more sense for the builder to be more semantic than layout oriented. Defining columns, grids and things of that sort seems more about layout than content? I’m sold on a builder, but trying to get more clear on where our boundaries should be.

[Jonathan Lahijani]

1 minute ago, ryan said:

Whereas I think people look for ProcessWire to be a little more best practices oriented, in which case it might make more sense for the builder to be more semantic than layout oriented. Defining columns, grids and things of that sort seems more about layout than content? I’m sold on a builder, but trying to get more clear on where our boundaries should be.

Can you elaborate on what you mean by more semantic oriented?

[ryan]

Quote

Can you elaborate on what you mean by more semantic oriented?

Using text elements as an example, semantic would refer to the meanings, like headline, paragraph, list, blockquote, etc. Things that wouldn’t change and would be portable even if the whole site got redesigned. Whereas layout or style of the text would refer to where it goes and how it looks, columns, grids, fonts, etc. Things that usually accompany a site's design. It seems like some of these builders (like YOOtheme) might be blurring this line and mixing it up to some extent (?), and so I’m trying to better understand that, and if or where it makes sense for us to draw that line. 
 

[Ivan Gretsky]

The great thing about Repeater Matrix way, is that a dev can create his own Builder (be it layout, content or full page builder). A content type can represent a section with all predefined components, just a section, or a column in a grid. And it is the dev who decides how it is rendered for the frontend. It would be great if we wouldn't drop that customization part.

Some of the content types I build contain not just the simple markup like buttons, text and headers, but link to other ProcessWire content. Like a Page Reference field to define selected products to output. Or a selector field for that purpose. It is not shown in @Jonathan Lahijani's video, so adding this point. Some "components" of mine are just a content type without any fields attached to customize - like a "calculator" content type. The whole page here, for example, between the header and a footer is a single Pepeater Matrix field.

As for me, the WHATEVER-builder field should be in fact а framework for constructing:

• a content builder (just the content that goes into <main> tag, like the bard field or this editor.js based field)
• or a whole page builder (like the YOOtheme builder example).

Leaving the dev to construct all the possible types, their possible children/parents, the way they are displayed in admin and rendered on the frontend. Plus the way to easily reuse stuff within a site or on a different project. Sounds like an impossible task, but a lot of us here already done that mixing Repeater Matrix (or a couple of those) and Mystique (for adjusting little things like headline tag or margin/padding, that does not deserve their own regular fields). The thing that's missing is the js polish on top of that and handling of edge cases. And I am not too much pro leaving the repeater pages as storage (it really hurts the reusability part). I am for the presence of the ability of customization that it gives to Repeater Matrix as it is now.

[adrian]

1 minute ago, Ivan Gretsky said:

The great thing about Repeater Matrix way, is that a dev can create his own Builder (be it layout, content or full page builder). A content type can represent a section with all predefined components, just a section, or a column in a grid. And it is the dev who decides how it is rendered for the frontend. It would be great if we wouldn't drop that customization part.

This is also really important to me - I don't always want the editors to have too much flexibility. 

[szabesz]

26 minutes ago, ryan said:

Using text elements as an example, semantic would refer to the meanings, like headline, paragraph, list, blockquote, etc. Things that wouldn’t change and would be portable even if the whole site got redesigned.

I think most of us are thinking along this line in addition to more complex "custom components" as what we love ProcessWire for (among other things...) is that we devs can decide on the final output, and not the system is the one to dictate that in any way.

However, ProcessWire could help us by providing a "builder" which renders semantic HTML which is in turn somehow also customizable by the developer. In other words: we need a layout tool so that our own "custom" components can be managed like LEGO blocks, either by us or by our clients.

Allowing clients to customize styling could be "just" an additional feature but I would not venture too far in this area, as most of the time it is not a good I idea to let clients style anything (there are surely exceptions to this, of course, but still...).

[teppo]

3 hours ago, ryan said:

One question for those interested in a site builder: who is the audience for it? Whether we should be looking towards something really simple, or something more complex, likely depends on the answer.

2 hours ago, Jonathan Lahijani said:

Block Editor (Gutenberg) is more of an advanced version of TinyMCE/CKEditor, but it's quickly becoming more of a "page builder" in the next year or two.

This is an important question indeed.

In its current state Gutenberg is a page or content builder: it provides the tools for laying out content for singular pages from existing out-of-the-box or developer-built components (aka blocks). It's literally a drop-in replacement for TinyMCE, now known as the "classic editor" in the WordPress ecosystem, with a GUI that is better suited for that kind of flexibility. The most one can do with Gutenberg in terms of "full site editing" is add columns of blocks, and even in that case there are limitations.

(It does also provide tools for defining purely visual aspects of the blocks, such as colors, fonts, and whatnot, but most developers I've talked with outright disable or at the very least severely limit these features.)

This is what, in my experience at least, many clients want these days: to be able to build rich and interesting content, whereas RTE is mostly good for relatively simple text content. Even laying out images among text with an RTE requires specialised know-how and can be a tedious task... and while a combination RTE and shortcodes may be able to achieve all the same things as a page builder, it's just not quite as intuitive.

A site builder — which, as Jonathan already pointed out, is also where Gutenberg is eventually headed — is a different beast altogether. Personally I wouldn't feel comfortable giving clients access to this sort of tool, and in my experience that's not even the intent behind most of them. They are primarily tools for designers/developers: folks who are comfortable designing sites and making CSS/JS tweaks here and there, but don't necessarily feel comfortable diving into "actual development", backend work, or building sites/themes from scratch.

Long story short: in my opinion ProcessWire has a great set of tools for developers, but what we lack is a great tool for building rich content. A GutenWire™.

Just my five cents ?

51 minutes ago, Ivan Gretsky said:

Leaving the dev to construct all the possible types, their possible children/parents, the way they are displayed in admin and rendered on the frontend. Plus the way to easily reuse stuff within a site or on a different project. [...] The thing that's missing is the js polish on top of that and handling of edge cases. And I am not too much pro leaving the repeater pages as storage (it really hurts the reusability part). I am for the presence of the ability of customization that it gives to Repeater Matrix as it is now.

This! ☝️

 

[Ivan Gretsky]

2 hours ago, Jonathan Lahijani said:

I don't think ProcessWire from the admin side of things needs to be an SPA.  However Hotwire could be used on the frontend if a developer decided.

I am thinking about it in the context of the page/content builder we're talking about here. Something like Hotwire (or Unpoly, or Vue if we go there) would simplify making it work slicker, without the reloads of the Repeater Matrix and with dynamic previews like in the YOOtheme example. So not the whole admin is the SPA, but just the edit page.

[Jonathan Lahijani]

 

8 minutes ago, szabesz said:

I think most of us are thinking along this line in addition to more complex "custom components" as what we love ProcessWire for (among other things...) is that we devs can decide on the final output, and not the system is the one to dictate that in any way.

However, ProcessWire could help us by providing a "builder" which renders semantic HTML which is in turn somehow also customizable by the developer. In other words: we need a layout tool so that our own "custom" components can be managed like LEGO blocks, either by us or our clients.

Allowing clients to customize styling could be "just" an additional feature but I would not venture too far in this area, as most of the time it is not a good I idea to let clients style anything (there are surely exceptions to this, of course, but still...).

What @szabesz said is what I'm thinking as well.

There is an ick-factor among developers and page building tools because it crosses the line of keeping content separate from the structural display of that content, but it's incredibly useful for landing page type pages and the marketing people who often manage them.

@ryan What approach did you take in building the ProcessWire.com Home page?  Entirely hardcoded?  Matrix for each main section (overkill since that hero is only used once)?  If I wanted to add more text beneath the two buttons in the hero, how would I do it?

[adrian]

@ryan - another thing I'd like to see is the search functionality from this module: https://processwire.com/talk/topic/14354-fieldtypedatetimeadvanced-subfield-selectors-for-datetime/ incorporated into the core datetime field. 

[3fingers]

Quote

However, ProcessWire could help us by providing a "builder" which renders semantic HTML which is in turn somehow also customizable by the developer. In other words: we need a layout tool so that our own "custom" components can be managed like LEGO blocks, either by us or by our clients.

Allowing clients to customize styling could be "just" an additional feature but I would not venture too far in this area, as most of the time it is not a good I idea to let clients style anything (there are surely exceptions to this, of course, but still...).

That's it.

I just don't want to let my clients have the freedom to play with styles, at least not within boundaries I can manage by code. It would be such a pain if I have (as accountable/developer of the project) to fix the mess made by a client inside the editor. Moreover, from my experience, if I give a client some sort of freedom (especially inside the creative side of things) then he will ask me more and more (Can I do this? Can you add this for me?). The editor become their toy, and the front-end the crappiest as ever.

On the flip side of the coin I would really love if we, as developers, could have the ability to let editors manage our pre-made components in a more compelling/modern visual way.