Leaderboard

Absolutely love this Ryan! I know this is a very simple example, but take a look at the difference in the execution time and memory usage ?

This week we have a couple of useful new $pages API methods. They are methods I've been meaning to add for awhile but hadn't found the right time. The need coincided with client work this week, so it seemed like a good time to go ahead and add them. I'm doing a lot of import-related work and needed some simple methods that let me work with more page data than I could usually fit in memory, and these methods make that possible. These won't be useful to everyone all the time, but they will be useful in specific cases. The first is $pages->findRaw() which works just like the $pages->find() method except that it returns the raw data from the matching pages, and lets you specify which specific fields you want to get from them. For more details see the findRaw() documentation page. There's also getRaw() method which is identical to findRaw() except that it returns the raw data for just 1 page, and like get(), it has no default exclusions. The next method is $pages->getFresh(). This works just like $pages->get() except that it gets a fresh copy of the page from the database, bypassing all caches, and likewise never itself getting cached. ProcessWire is pretty aggressive about not having to reload the same page more than once, so this method effectively enables you to bypass that for cases where it might be needed. Again, probably not something you need every day, but really useful for when you do. More details on the getFresh() documentation page. I'm going to likely cover these new $pages API methods in more detail in a future blog post, along with some better examples, so stay tuned for that. I noticed there's some pretty great conversion and examples happening in the posts on page builders here, but have been so busy this week I haven't had a chance to dive in, but I'm really looking forward to doing so. Thanks and I hope you all have a great weekend!

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

@kongondo, Great proof of concept! I would like to make a case for going the open source route with this and making this a group effort. Reason being that this is a massive undertaking. I recently decided to get a one year subscription to https://thrivethemes.com/ and to be honest I hate working with it, it is buggy, sometimes things save, other times they do not. But I do like the conversion focused page builder aspects of it. AND, what I also like is how this one guy who started it, now has a base of tens of thousands of customers. And the company now has close or more than 70 people working there. Why do I say all of this? Because years ago already I bought padloper, never used it because it is nowhere close to what I needed or need. Then on september 3rd 2018 I saw kongondo taking over, kudos to you I thought and still think. But over time I became worried more and more, because dates kept on moving away further, then on november 29 2020, I saw the post stating that padloper 2 alpha might be released Q1 to a closed base of alpha testers. Q1 2021 is now more than 2 years later than 2018 for a functionality that is key to broader adoption of something as great as PW. IMHO PW needs a good shopping solution yesteryear already. Just like I believe a good PW page builder is needed yesteryear also. There is a huge market out there, now going for products that have IMHO a far inferior engine underneath and are buggy to work with. Then if I see the smarts of the people now sharing stuff on this forum I have hopes that this can be turned into something made by people combining forces and getting a MVP out there asap, and then build on that to get fast iterations of minimum viable productversions. On one of my sites: https://www.backpaingoodbye.com/ @netcarver built all different blocks with repeater matrix, and it is a joy to work with already, and IMO the page builder could go the route of pre-made blocks that serve a specific conversion focused purpose on pages. If thrivethemes can build a base of customers around a page builder for wp, don't you guys think we could do better with a superior engine underneath? And don't you think it is too much for one person to take on? I am not a coder, but I could think of a business model where together we build the best page builder for websites for people that want their sites to generate results. The examples are out there, often buggy, yet making their makers lots of money, mind you I am NOT focused on the money side, but PW is such a dream to work with compared to the other stuff, so why not turn that dream into reality together, AND support our businesses as well. Proof of concept of business model? - subscription based conversion optimised page builder driven by the best engine under the hood - timebased and royaltybased payments to building participants, both coders, marketeers and ??? - a transparent website with access to all participants to see income streams and honest value add based division thereof - allow participants to create derivatives for their own projects @kongondo, I hope you do NOT see or take this as criticism... ....firstly it is not meant like that, on the contrary, you deserve a righteous applause for your taking on padloper on your own. I look forward to it going live. ...secondly, this processwire tribe is not a tribe where we criticize each other, but help each other reach unseen heights, at least that is how it feels to me. So once again, if any of my wording sounds like it is criticism, please excuse me for being Dutch Thanks and kudos to all you processwire lovers and ninjas from a Dutchman who loves this thing called Processwire!

The forum topics are monitored at all times and most posts have timely responses. Is there a specific topic that you are having a problem with? If you have issues related to specific VIP Support Forum issues, I would PM @ryan or any other developer directly, if you feel that you are not getting a timely response

Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs. You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself). All my responses below are with respect to this Page Builder. Wrong again. Jessica White's data actually lives in the database. Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits. That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc). Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.

Hello community! I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites. Fluency is available in the ProcessWire Modules Directory, via Composer, and on Github Some background: I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and the high quality services now available. Inspired by what is possible with ProcessWire, I built Fluency, a third-party translation service integration for ProcessWire. With Fluency you can: Translate any plain textarea or text input Translate any TinyMCE or CKEditor (inline, or regular) Translate page names/URLs Translate in-template translation function wrapped strings Translate modules, both core and add-ons Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWire to those offered by the third party translation service you choose. Currently Fluency works with DeepL and Google Cloud Translation. Module Features Translate any multilanguage field while editing any page. Translate fields in Repeater, Repeater Matrix, Table, Fieldset Page, Image descriptions, etc. Translate any file that added in the ProcessWire language pages. It's possible to translate the entire ProcessWire core in ~20 minutes Provide intuitive translation features that your clients and end-users can actually use. Fluency is designed for real-world use by individuals of all skill levels with little to no training. Its ease-of-use helps encourage users to adopt a multilanguage workflow. Start for free, use for free. Translation services supported by Fluency offer generous free tiers that can support regular usage levels. Fluency is, and will always be, free and open source. Use more than one Translation Engine. You may configure Fluency to use either DeepL, Google Cloud Translation, or both by switching between them as desired. AI powered translations that rival humans. DeepL provides the highest levels of accuracy in translation of any service available. Fluency has been used in many production sites around the world and in commercial applications where accuracy matters. Deliver impressive battle-tested translation features your clients can count on. Disable translation for individual fields. Disable translation for multilanguage fields where values aren't candidates for translation such as phone numbers or email addresses Configure translation caching. Caching can be enabled globally so that the same content translated more than once anywhere in ProcessWire doesn't count against your API usage and provides lightning fast responses. Set globally ignored words and text. Configure Fluency to add exclusionary indicators during translation so that specific words or phrases remain untranslated. This works either for specific strings alone, or present in other content while remaining grammatically correct in translation. Choose how translation is handled for fields. Configure Fluency to have buttons for either "Translate from {default language}" on each tab, or "Translate To All Languages" to populate every language for a field from any language to any language you have configured. No language limits. Configure as few or as many languages as you need. 2, 5, 10, 20 language website? Absolutely possible. If the translation service you choose offers a language, you can use it in ProcessWire. When new languages are introduced by third parties, they're ready to use in Fluency. Visually see what fields and language tabs have modified content. Fluency adds an visual indication to each field language tab to indicate which has different content than when opening the edit page. This helps ensure that content updated in one language should be updated in other languages to prevent content divergence between languages. Render language meta tags and ISO codes. Output alt language meta tags, add the current language's ISO code to your <html lang=""> attribute to your templates that are automatically generated from accurate data from the third party translation service. Build a standards-compliant multi-language SEO ready page in seconds with no additional configuration. Render language select elements. - Fluency can generate an unordered list of language links to switch between languages when viewing your pages. You can also embed a <select> element with JS baked in to switch between languages when viewing your pages. Render it without JS to use your own. Manage feature access for users. Fluency provides a permission that can be assigned to user roles for managing who can translate content. Track your translation account usage. View your current API usage, API account limit, and remaining allotment to keep an eye on and manage usage. (Currently only offered by DeepL) Use the global translation tool. Fluency provides translation on each field according to the languages you configure in ProcessWire. Use the global translation tool to translate any content to any language. Use Fluency from your templates and code. All translation features, usage statistics, cache control, and language data are accessible globally from the $fluency object. Perform any operation and get data for any language programmatically wherever you need it. Build custom AJAX powered admin translation features for yourself. Fluency provides a full RESTful API within the ProcessWire admin to allow developers to add new features for ProcessWire applications powered by the same API that Fluency uses. Robust plain-language documentation that helps you get up to speed fast. Fluency is extremely easy to use but also includes extensive documentation for all features both within the admin and for the Fluency programming API via the README.md document. The module code itself is also fully annotated for use with the ProDevTools API explorer. Is and will always be data safe. Adding, upgrading, or removing Fluency does not modify or remove your content. ProcessWire handles your data, Fluency sticks to translating. Full module localization. Translate Fluency itself to any language. All buttons, messages, and UI elements for Fluency will be presented in any language you choose for the ProcessWire admin. Built for expansion. Fluency provides translation services as modular "Translation Engines" with a full framework codebase to make adding new translation services easier and more reliable. Contributions for new translation services are welcome. Fluency is designed and built to provide everything you need to handle incredibly accurate translations and robust tools that make creating and managing multi-language sites a breeze. Built through research on translation plugins from around the web, it's the easiest and most friendly translation implementation for both end users and developers on any CMS/CMF anywhere. Fluency complements the built-in first class language features of ProcessWire. Fluency continues to be improved with great suggestions from the community and real-world use in production applications. Big thanks to everyone who has helped make Fluency better. Contributions, suggestions, and bug reports welcome! Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is a long-standing issue in the larger web development community and creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Github page and file a bugfix ticket. Requirements: ProcessWire 3.0+ UIKit Admin Theme That's Fluency in a nutshell. The Module Is Free This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). DeepL Developer Accounts In addition to paid Pro Developer accounts, DeepL now offers no-cost free accounts. All ProcessWire developers and users can use Fluency at no cost. Learn more about free and paid accounts by visiting the DeepL website. Sign up for a Developer account, get an API key, and start using Fluency. Download You can install Fluency by adding the module to your ProcessWire project using any of the following methods. Method 1: Within ProcessWire using 'Add Module From Directory' and the class name Fluency Method 2: Via Composer with composer require firewire/fluency Method 3: Download from the Github repository and unzip the contents into /site/modules/ Feedback File issues and feature requests here (your feedback and testing is greatly appreciated): https://github.com/SkyLundy/Fluency/issues Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます！ 谢谢你

PAGEGRID 1 released!

This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend!

The Bard field in Statamic has been been discussed and mentioned several times in the forums, dating all the way back to 2018, as something worth emulating in ProcessWire. Here is a short demo of a proof of concept of an unimaginatively (temporarily?) named (and very colourful) module doing just that. Demo App running outside ProcessWire. Screenshot Screenshot of the app in InputfieldBrad, running in a modal, quirks and all. Way Forward I don't know but no current plans for any sort of release, paid or otherwise. I like where @flydev ?? is headed with FieldtypeEditorJs so let's support that ?.

Please send a Private Message (PM) within this forum software to @ryan and he should be able to clear up any issue that you may have.

It's only much more efficient as long as it only finds IDs and that's just using findIDs... as soon as I add a column of data the new findRaw is much quicker! Actually finding 1000 pages with just the ID column taking almost 2 seconds seems quite long... But I don't have time to investigate further at the moment.

Haha sorry, I got so used to ALT+ENTER and always reset the console that I totally forgot about that "feature" ? Thx for the reminder!

Not really, I ran them both separately without clearing the results of the previous run. I also used the ability of the Console panel to only run the selected code so I didn't need to comment out one and then the other. Make sense?

For simple queries we now have findRaw() in the core! Seems like joining columns could be improved in terms of performance... @adrian other than in your example I had to fire separate d() calls to get separate execution times and mem consumptions?! Am I missing anything?

Hi Ryan, thx for the update! Is there any reason why the label field is required? I find that really annoying - I'm leaving that blank most of the time while developing, because I see the name of the field instantly and change/fill the label only if the setup turns out to be working properly. Otherwise removing fields, renaming fields etc. is more work than necessary, because one always has to fill/rename one additional field that does not add any benefit. Would be great to revert this back to optional. I like the new interface, though. But it would be better IMHO to show name | type | label (optional) PS: I saw that the page name fills automatically based on the label - that might be nice for all english speakers, but most of the others I guess will usually have different labels and field names, because the label is in their language while the field name is english...

This iconset might be of interest for you as well : https://tablericons.com/

Hey folks! Iam exited to show you a preview of a pagebuilder fieldtype I'm working on for quite some time now. Let me know what you think

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

Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. Thanks. Will have a look. By the way, I have been keeping an eye on this one: https://heroicons.com/ ...by the folks at TailwindCSS

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

Hi @teppo. This is a holding response since I am short of time at the moment. You've raised an important issue surrounding funding of modules/remunerating developers, etc that I have been meaning to discuss in the beer garden with the whole community. As it is a broad issue, I would like to answer this question within that broader context. As for this module in particular, I haven't decided yet but leaning toward commercial. That's not cast in stone though given the broader issues I'd like to discuss. I had a feeling this would cause some confusion. I will come back with a detailed answer. For now, just note that schema is used in the sense of defining something, in this case, a column in a DB table containing JSON with the schema/description of that element with respect to layout, tags, etc. Hope I haven't confused you further. Excellent! Thanks.

Hey @kongondo! I know this project is at a very early stage, but it does seem promising. I also like your ideas about the data structure, though I'm not entirely sure I fully get it yet (might require a more hands-on example of the data vs. schema vs. database structure part). At this time I really only have one question: do you currently see this as a potential commercial module, or something that you would consider open sourcing? I get that it's very early, and I want to stress that there's absolutely nothing wrong if you think it'd be better suited for commercial release. That being said, I see this kind of tool as a pretty massive undertaking, and thus something that could benefit from larger community involvement. I for one would definitely be interested in contributing in some way, assuming that would be an option. Anyway: a very interesting project — keep up the great work! ? Just wanted to point out that I don't really see this as an issue. If we take WordPress as an example, they've always had UI's that (for similar reasons) step out of the regular Admin: Customizer from the core, for an example, as well as various plugins (Ninja Forms has a very distinctive full page form editing GUI), and in my opinion that works just fine.

Thanks for the very insightful video @Jonathan Lahijani Flexible Content / Page Builders When it comes to this, if you look at what's out there, in many cases, you'll invariably end up in either of two places with respect to the technology behind the builders; Vue JS or React. A few examples: Statamic - Vue JS Gutenburg - React YOOtheme Pro's Builder - Vue JS Storyblok - Vue JS There is ?. It is called Vue JS (I prefer it over React). OK, there is no ready made tool solution but from my experience developing Padloper 2, I can say it is quite doable. If we are to build any sort of page/site builder, I'd highly suggest to look at either Vue or React - especially Vue. It will save you a lot of hassle. The biggest challenge I found with these frameworks if using the CLI versions (recommended) is that the 'app' has to be developed outside ProcessWire as they run on different ports. This means the app has to be 'built' in order to test it inside ProcessWire. This is a tedious process. I have never been able to develop a Vue app inside ProcessWire and still get the benefit of Hot Reloading. 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? ?. It wouldn't make sense to have both. Even if we didn't end up with Vue, modern JavaScript has some great APIs that can replace the dependency on jQuery. I know this is a huge undertaking. I know both the modern and the old have their pros and cons. I also know that jQuery is not evil. I know the decision to use it or not can be subjective. I just prefer working with reactive frameworks (and vanilla JS). What do you guys think? @ryan, would modern JavaScript tools fit into this vision?

RockFinder3 has a performant and versatile SQL groupby feature: https://github.com/baumrock/RockFinder3/tree/40da7c5f087d87bc33d883add5b78cf7c546bacd#predefined-methods

Hi Has anyone tried to install (and/or) update languages without using admin UI? I would love to automate that process.