Jonathan Lahijani

I like the idea of editing in a modal (full screen to where it almost feels like its own page), or perhaps a dedicated edit page outside of PW's page editor. I think having it inline as shown in the screenshot looks bad, not to mention the lack of page width. If going the modal route, the "esc" key should not close the modal, but maybe a close button that the user has to click. Also, I would imagine the icons are copyright YOOtheme, but this library is available for commercial use for free and a quick look seems to show they have similar icons: https://github.com/vaadin/vaadin-icons

WOW! This is incredible! I think this idea really has legs and you've proven it can be done in a ProcessWire way. I would like to contribute in any way I can... ideas, styling, testing, financial. I would 100% use this on multiple projects if it could be developed further. I hope you are able to see this project through as well as Padloper. Please let me know how I can help.

I bought a generic sounding ".run" domain name and have my client sites as subdomains of it. .run sounds very developer-y.

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?

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

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.

"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.

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.

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.

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.

The decimal fieldtype is available and works well (I use it for an ecommerce site with large numbers, no problems): However it would be nice if this was in the core: https://github.com/processwire/processwire-requests/issues/126 FieldTypeTable supports decimals by the way.

@ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.

Indeed. Alpine looks interesting and I'm considering rewriting the cart and checkout portion of my ecommerce site with it instead of Vue one day. I'm familiar with alpinetoolbox.com, and although the examples there look good, I prefer to have components that are more "official" and battle tested especially when using multiple components together. For example, if there were eventually a project that had ready to go components from a single source that covers most of UIkit's components, I'd strongly consider it. I believe there are some projects in the works for that, but nothing totally comprehensive yet.

Looks great. Random question: how does a piece of data like order notes get stored? Is it PW fields or custom Padloper tables?

For what it's worth, I have the following working without any issues: website on a fresh digital ocean ubuntu 20.04 droplet with lamp stack (installed using sudo tasksel install lamp-server) processwire 3.0.168 php 7.4.3 mysql 8.0.22 database on digital ocean database cluster -- set this up just now specs: 1 GB RAM / 1vCPU / 10 GB Disk / Primary only / SFO2 - MySQL 8 mysql 8.x (8.0.20 based on the logs) (connecting using the default 'doadmin' user account, which should be using caching_sha2_password, not mysql_native_password); no connection issues ... I'm clicking around going to various pages and it doesn't feel "fast". Not slow, but not fast. I then upgraded to the 4gb/2cpu database cluster and it's still pretty slow. I just switched back to the local mysql server and it's way faster. Keep in mind both my droplet and my db cluster were in the same region (SFO2). Looks like I won't be using Digital Ocean's database cluster at least until it's faster or I figure out how to make it faster (if it's possible). Not sure why it's so much slower. Related: https://bensmann.no/running-wordpress-with-digital-oceans-managed-mysql-databases/