PW 3.0.170 – Core updates

[szabesz]

3 hours ago, ryan said:

Is there any issue in the existing FieldtypeDecimal that also needs to be solved when I put in this update?

@arjen forked it because, quote: "We needed an option to determine whether 0 or empty should be regarded as equivalent. I copied the method + config from FieldTypeFloat. In my testing it seems to work fine."

Others wanted to convert Float fields to Decimal but I guess your "combo" solution would solve that out of the box.

Last but not least there was interest in "number spinner" which would be nice to have for all number fields, provided that the "values of increments" are configurable.

BTW, I forgot about all this,but @apeisa joined in the discussion at some point, quote: "As a @sforsman's coworker I'll let him know about this. We do use namespaced version of this module ourselves."

So maybe you and Apeisa could also discuss what their current extra needs are, if any.

[ryan]

Quote

The great thing about Repeater Matrix way, is that a dev can create his own Builder (be it layout, content or full page builder). 

The other great thing about it is that it's a very realistic thing we can do. Though Jonathan's video pointed out a lot of drawbacks. Maybe we can solve some of them with upgrades to RepeaterMatrix like Jonathan proposed, and maybe others are acceptable drawbacks given our context is very different from tools like WordPress. Plus, it seems like Jonathan is already using this approach successfully with clients. 

Quote

As for me, the WHATEVER-builder field should be in fact а framework fo constructing: a content builder (just the content that goes into <main> tag, like the bard field or this editor.js based field)

I took a closer look at https://editorjs.io/ and I like it for a lot of the same reasons I liked what The Bard example was showing. The plugin-based approach for blocks it uses looks great and this seems like something we could probably integrate pretty easily/quickly since it's based off an existing tool that handles the difficult-to-code parts. Being able to solve this need with an existing tool like this is the ideal route IMO. 

Quote

or a whole page builder (like the YOOtheme builder example).

While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management.

Quote

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.

Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. 

Quote

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. 

I'm already a fan of Unpoly after spending a lot of time looking at it, particularly with how lightweight it is relative to what it does. 

Quote

@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?

There isn't anything hard coded in it. The top area is a CKE and images field, and images use tags to place in groups. The next part is list of features/highlights, each with headline, icon, description, and link; these are a FieldtypeTable field. Another FieldtypeTable field manages quotes (quote, cite, source, active), which are pulled randomly in different parts of the page, as well as on other pages in the site (which pull from the same field). Everything else on the page is pulled in dynamically from other parts of the site. For instance, the blog part always shows the newest blog posts, the showcase part always shows the newest site additions, the Pro modules part pulls from the /store/, etc. So there isn't really much code on the actual homepage template, since it's actually the other parts of the site rendering each of those. 

Quote

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

I agree, I will add this. 

Quote

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.

Yes, that has been my experience as well and so this was one of the things ProcessWire has always tried to solve from the beginning. Keep the client focused on semantic content and not on style, layout or presentation. It's also why I've never been a fan of front-end editing. As soon as the person editing content takes their focus off of meaning and shifts to presentation, that's where things go south and content is no longer portable. I see a fundamental job of a CMS being to manage portable content. 

With all that said, it does seem like there is an exception to the above (per what Jonathan mentioned earlier). That is, the perhaps temporary 1-page marketing things, where questions of portability don't really matter and the short term marketing needs do. 

Quote

@arjen forked it because, quote: "We needed an option to determine whether 0 or empty should be regarded as equivalent. I copied the method + config from FieldTypeFloat. In my testing it seems to work fine."

This is already built into FieldtypeFloat, so another good reason for it to add DECIMAL column support. 

Quote

Others wanted to convert Float fields to Decimal but I guess your "combo" solution would solve that out of the box.

Well in this case, we would add the support to the core, so one wouldn't need to use Combo for that purpose. 

Quote

Last but not least there was interest in "number spinner" which would be nice to have for all number fields, provided that the "values of increments" are configurable.

A number spinner is built into the HTML5 number type, which is already an option for the float field. What's lacking is the ability to modify the step value from the default. I can add that, no problem.

@Robin S I've been experimenting with your Uikit admin CSS additions and a few of them (some of the "fix" ones) seem like they should be added to the core. Some of the other more subjective ones, you've got me thinking we should have a "customization presets" dropdown in the Uikit admin that lets you select predefined customization sets like yours. I think having separate configuration settings for all the different things you've changed is probably too much configuration, but presets seems like a good way to answer common preferences people might have?

[teppo]

1 hour ago, ryan said:

Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take.

1 hour ago, ryan said:

Yes, that has been my experience as well and so this was one of the things ProcessWire has always tried to solve from the beginning. Keep the client focused on semantic content and not on style, layout or presentation. It's also why I've never been a fan of front-end editing. As soon as the person editing content takes their focus off of meaning and shifts to presentation, that's where things go south and content is no longer portable. I see a fundamental job of a CMS being to manage portable content. 

A lot to agree with here ??

One thing I particularly liked about editor.js is how it keeps content separate from design: behind the scenes everything is abstracted so that a quote block is really just an object with a few text properties, etc. You could render that quote block in a hundred different ways for the front-end. Portable indeed ?

In fact the more I think of it, the less sense it makes to think of block editors as something that would replace pages and fields. I'm all about having content split into separate fields where it makes sense. But as a replacement for RTEs, that's something I can definitely get behind: an RTE is a decent tool for creating text-only content, while for anything beyond that I find them rather awkward.

For "body content" (which may these days typically be a varying mixture of text, images, tables, forms, highlights, and so on) flexible content fields are (imho) a much better choice.

[apeisa]

Yes, thumbs up from here also to focus on bard/editorjs level of "content blocks" instead of full layout editor.

[jacmaes]

Another huge thumbs up from me to focus on flexible content blocks. I find that I need this more and more often not just for the typical landing pages, but for content-rich, art-directed articles, and repeater matrix only partly fits that need. 

[kongondo]

@flydev ??,

Sorry to tag you like this.

I am not sure if you are following the discussion here regarding content blocks? Just wondering how far you are from releasing your Editor.js-based Fieldtype?

 

Given that you've probably spent months developing the module, I'd be interested to hear what your thoughts are.

[Kiwi Chris]

On 1/8/2021 at 6:21 AM, adrian said:

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.

I agree. The way I see it, if there's a low level SQL type that supports given functionality, there should be a fieldtype that corresponds to it, however the ProcessWire specific fieldtypes are there for when additional functionality is required that can't be supported directly through SQL.

Speaking of that, it may be a bit of a limited use case, but I've wondered a few times about adding geometry fieldtypes and adding geometry selectors. There's already the FieldtypeMapMarker, but this is using just standard float fields in mySQL, while mySQL and MariaDB have support for geometry datatypes and spacial indexes, and there are times it would be nice to be able to do a query and return all the places within a given distance. I already hacked the FieldtypeMapMarker a bit to allow adding KML overlays exported from Google Earth, or mobile tracker apps, but there's certainly a lot more that could be done to give geospatial data first class treatment if enough people use it.

[dotnetic]

Wow. So many great input here, but instead of making one large post, I split this up to multiple ones, so I can talk about more features and wishes specifically.

On 1/8/2021 at 3:36 PM, ryan said:

I took a closer look at https://editorjs.io/ and I like it for a lot of the same reasons I liked what The Bard example was showing. The plugin-based approach for blocks it uses looks great and this seems like something we could probably integrate pretty easily/quickly since it's based off an existing tool that handles the difficult-to-code parts. Being able to solve this need with an existing tool like this is the ideal route IMO. 

Quote

or a whole page builder (like the YOOtheme builder example).

While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management.

Quote

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.

Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. 

I had the idea to implement editor.js some years ago (but did not done it yet), and think it would be a great addition to ProcessWire, because building blocks are something requested by one large client of me. He now has the ability to add content blocks with Repeater Matrix, but I think its cumbersome and not very intuitive, and has its drawbacks. That is the same for every page builder and content block solution, that I have seen here on the forums except FieldtypeEditorJs. Everything in my opinion and please don't feel offended.

Editor.js and the Bard fieldtype from Statamic (which is extended in V3 of Statamic, Bard is based on ProseMirror) are very good, because they save content not in HTML (but you can, If you want to) , but as structured data, which then can be rendered via partials however you like (that's how I do it in Statamic). As an explanation you can read my post 

 

The FieldtypeEditorJs : Preview of a productivity fiedltype for editors. - Module/Plugin Development - ProcessWire Support Forums is a first good looking implementation of this fieldtype, but is not released yet. Maybe you can talk to @flydev ?? about integrating it into the core. I think there would be enough people to sponsor this feature.

I do not think, that we need another website page builder which is responsible for the whole layout. Block based contents would be enough in my opinion. But that's just my two cents and I know, that opinions might differ on this.

[Ivan Gretsky]

First of all I want to say, that I am really enjoying the discussion about the flexible content builder or the WHATEVER-builder (as I accidentally named it earlier) we are having here. And now I am purposely not calling it more specifically Site / Content / Page / Layout / Theme Builder. I think that @kongondo made a really wise question asking to define the distinction between those. And to determine, what exactly do we want to build.

Are we really talking about the different things?

It seems to me that now we are contrasting the YOOtheme Builder from @Jonathan Lahijani‘s epic video labeling it as a layout editor or a site builder, to bard / editor.js calling them content block editor or something like that. And choosing between the two.

But, as I understand, @Jonathan Lahijani never proposed a layout editor / site builder way in a sense that it should store the final html code and let the content editor to directly manipulate it. He intentionally made it clear, that he chose to show us YOOtheme builder because it “separates the builder-part from the actual content” doing it in a “ProcessWire way”. And he also stated, that he is not for tightly coupling to the CSS framework (Uikit in YOOtheme). But he would want the ability to define the layout IN SOME WAY, like being able to create a 2/3/4 column grid and place the components (I think that they are the same as content blocks from bard / editor.js) inside those columns. And to be able to move those components to desired slot in the layout. I would really want that part too)

I think that the earlier mentioned “ProcessWire way” is actually the separation of content and presentation. When we use Repeater Matrix, we store the content and some meta information not directly in the html code, but in the Repeater Matrix Page’s fields. Actually, editor.js (do not know about the bard field, but probably that one too) is also storing the content separately from the presentation. Not in the separate database tables, but in one json object. So it is kind of doing it the “ProcessWire” way too))) One difference, is that in the case of editor.js we have to manually deal with json when generating actual markup, when Repeater Matrix provides us the comfortable PW API for that (making this way a little bit more ProcessWire). The other difference is that when using Repeater Matrix we have to manually create all the actual fields and assign them to content types, making this way more laborious. The coin has two sides.

So, as I can tell, we all want the same kind of editor. The one that does not store the actual markup, but the one that stores data, that later we can render to actual html (or any other format really).

What about the layout part?

As I said earlier, I would really want to have the ability to define layout with the flexible content builder we are talking about. @Jonathan Lahijani showed 3 ways of doing it in current Repeater Matrix-based content builder, and all of them are kind of a pain. But I do not want our editor to actually store something like col-sm-6, but rather some generic layout information. Like having a grid block, that can only have col block as a child, which in it’s turn can store the actual components.

In Repeater Matrix now we do not have a distinction between layout element and a component. We only have the ability to put one element inside the other (the ugly nested Repeater Matrix way or the repeater depth way which also has its flaws). But it is the developer who is responsible to make all the decisions generating markup. So the developer could choose to implement the layout part or not to do so, which is really a powerful stuff I enjoy and would like to keep. That’s why I was talking about the “WHATEVER-builder” or a “framework for constructing a content builder” before.

To do so, our new flexible content builder should allow us to:

• define the allowed parents/children for the elements;
• allow to show the child elements side by side (to imitate layout);
• intelligently control the drag and drop, taking into account the allowed parents/children for the elements.

As far as I know, editor.js does not allow the nesting of the elements.

Creating custom elements from admin

The other great thing about the Repeater Matrix-based content builders is that we can easily create new custom content types (elements, components…) right in the comfort of the admin. It is not really a quick thing, as we need to deal with creating the fields and assigning them, but it is rather familiar. And those custom components can use all the other ProcessWire data with Page Reference fields, Selector fields etc, which is cool.

If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement.

Visual representation of the content

Repeater Matrix-based flexible content builders in the mentioned video look nothing like the actual content. The left part of YOOtheme builder does neither, but it at least represent the layout in some way. Editor.js / bard do not do that too. From the other replies in this thread I see, that it is not that important and even not desirable.

Repeater Matrix interface is kind of ugly, when representing content. But:

• at least is is familiar and in line with all the other backend;
• it could be improved to be more like YOOtheme builder:
  • add icons for adding content types,
  • remove or refactor the repeater elements “chrome”,
  • allow showing repeater elements side by side for the layout thing;
• and it uses the standard admin form ui, which means it is easier for @ryan to deal with.

As you see, I am for the native ProcessWire UI here)

And one more thing. In the video we see the actual markup rendered to the right of the YOOtheme content editor. We can do that also, creatively reloading THE WHOLE PAGE on changes with Hotwire / Unpoly / Vue. Making the flexible content builder feel dynamic and not requiring those saves-and-reloads. And making the connections between the options in the builder part and the final markup obvious to the editor.

The data storage

Repeater Matrix-based flexible content builders store the data in pages and fields. This makes it laborious to create new content types (create a new field, or find an existing one to reuse it, assign it, override it…) This also makes it hard to duplicate, copy/paste content in the site or between the projects. But it also allows us to use the familiar API when generating markup.

Editor.js’ data object is compact and probably easier to be reused. But it lacks connection to other PW data. And the UI is totally different.

Could we combine the benefits of the two? What if we invent the json-based storage for the data gathered with regular ProcessWire inputfields? Something like Mystique field combined with JsonNativeField (so the content is even searchable).

And what if we allow to create the Interface for the new flexible content builders components with “fake” fields, which have their inputfields only, and are not connected to the database? Kind of like fields for the Form Builder or the UI for the @adrian’s Admin Actions’ actions.

Think about that. We could design elements with any fields we need not messing up the regular fields namespace. Those fields’ definitions would be stored in our flexible content builder’s options, as well as all the content types (elements) and the actual field data in json. The UI would be the same inputfields we already have. When working with this field from the API, the field could be   accessible as a PageArray object where each Page is a corresponding element.

Bringing it all together

I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW. It can be comparable if not better than all the other competition. It can be well integrated and totally configurable through the admin. It can be portable between templates and projects. And it can be visual and responsive.

What do you think?

[szabesz]

Thanks for the great write-up, Ivan!

2 hours ago, Ivan Gretsky said:

It can be portable between templates and projects.

Good point! We totally forgot about our long standing portability shortcomings. The current "manual" import/export feature of fields and templates is a basic one, I rarely use it for this reason.

Maybe Ryan should start this builder project by designing and implementing our sought-after migrating subsystem, which would also be the bases of portable builder components (components which can be managed by version control). See: https://processwire.com/talk/topic/21212-rockmigrations-easy-migrations-from-devstaging-to-live-server/?do=findComment&comment=183572

[netcarver]

@ryan Not sure if small requests count here in this storm of idea goodness.

Please could you make ProcessLogger::formatLogText() hookable?

[dotnetic]

One of the things that bothers me about ProcessWire is the integration of the community into the development process.
It is not clear which features or ideas will be implemented and if and how you can influence this decision at all.
For example, it would be conceivable that within a period (for example a quarter) you look at which Github issues have the most thumbsup and then fix or implement them.
If there are too many features, or they have the same number of thumbsups, you could also make a poll in the forum, what the community would like to have implemented faster.

The pull requests sometimes are not integrated for years.
Even if a control or a rewrite would be necessary for this, it would be good to have a feedback if the PR is "under consideration" or "won't merge" or "working on it" or a comment.
Because the way it is now, it seems like the PRs are just decaying unseen and there is no point in working on this open source project.

Ryan wrote: My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through.
It would be nice if this was also listed in the Contribution Guidelines https://github.com/processwire/processwire-issues/blob/master/CONTRIBUTING.md

These guidelines are also the place to say how new ideas or fixes are handled and under what conditions they are integrated.

If Ryan discloses his criteria that he has as a requirement for features, enough developers might follow those guidelines when creating a PR.

After all, it would be great if there were a few selected contributors and they could then merge PRs, or at least do a pre-review, so that Ryan has an easier time integrating them later.

[dotnetic]

The Page Lister (a centerpiece of PW) is also in need of major improvement IMHO.
The icons are not always in the same place due to page titles of different lengths, which is very annoying and distracts a good workflow.
A tabular representation or other optimized view, would be better suited here.
Here, again, everyone may have a different preference, so an option of which display type to use would be a good idea.
This has been mentioned here before.
I would be willing to work on a proposal for an optimized layout.

Moving entries in the page lister, doesn't work very well and it's cumbersome.
I found a great Tree JavaScript a while ago that implements drag and drop much better http://www.treejs.cn/v3/demo.php#_307 and was actually going to work on integrating it to PW, but unfortunately didn't have enough time. The looks of that script can be completely customized.
Then I didn't know if it was worth it, since I know that many PR's just never get integrated and I also lacked the time.
I had made first attempts, but noticed that the PageLister is very extensive and nested.

[flydev]

You are all right and everyone have good arguments. A page builder should be built IMO.

As a recent example, I needed to build a cool invoice, like the one you receive in your inbox sent by big companies names. Their email look so fun/cool/responsive that YOU WANT TO DO THE DAMN CLICK on their call-to-action button.

Then I found a cool software called "Nicepage", where you move blocks, edit styles and content, and tada, a cool page done in a minutes, with clean code, really - after a copy-pasta moment, I had my invoice in my template sent by PadLoper. 

I think it's @Jonathan Lahijani that was saying something in this, users which build marketing pages, landing pages and other things like that, it's just incredibly useful.

Another example, I don't build website everyday anymore, but backends (based on ProcessWire) with public/restricted API and desktop/mobile apps connected. I can imagine how easy it could be to extract/manipulate data from an external apps (What's happened with EditorJS).

Plus, and even if it's not the primary goal, given the tool we already have in our hand, it will make a bump on new users/devs which will use ProcessWire. The right ones ? not sure, maybe the forum will be spammed by "unexperienced user" which will try to build a website with the builder but doesn't understand in first instance how to apprehend ProcessWire.

But it should be developped keeping in mind what all the devs say in their different horizon.

I mean, a system of permission should be built-in, every blocks or type of blocks should have a permission, restricting some functionalities that could be used in an editor, or the page builder it-self. Eg. all blocks are available to superuser, but other users will have only access to the defined blocks for their role combined to the restrictions of the page being edited.

"I don't want to give so much freedom to my client because he will ruin the front-end"

Absolutely, but is your job to lock everything. Building pre-defined blocks (speaking styles, not content (even if you should limit content)). 

- Give them possibility to write their article, and to add a block with three columns for 3 featured products of their webshop. So cool.
- Give them possibility to write their article, and to add a banner/call-to-action newsletter. Here you limit the number of words/paragraph, whatever, then again, So cool.

And IMO, it doesn't change anything at this time of writing: with or without a page builder, clients are often asking more and more.
Where I see a benefit to give the user the ability to add / remove blocks from a page builder is the ease and feel when editing content - productivity in addition.

It depend also on how large is the project, the client's technical background, if there is a team or not, a frontend dev on the team or not. 
Given this factor, you have to "educate" your client in consequence. 
This imple to explain to the client, how/why it can and howtonot/whynot it can. To each one his field of work and I think this particular argument should not stop any idea because it is valable for whatever special you make for a client purpose.

You will have on the next weeks a preview of EditorJS which maybe will give you more idea/insight on how to work/render/restrict theses data blocks.

[kongondo]

@flydev ??,

Spot on, everything you've said! I've been thinking along similar lines! I wish I could give you more likes! ?.

3 hours ago, flydev ?? said:

I think it's @Jonathan Lahijani that was saying something in this, users which build marketing pages, landing pages and other things like that, it's just incredibly useful.

I agree and I don't think it should be limited to this group. Lowering the entry barrier to any software, especially in the modern age is incredibly useful. Look at all the rage about coding for kids, etc. Python is great in this regard. So are tools like Flutter. 

For a while I was of the notion that things like page builders are somehow anti-pattern with respect to ProcessWire. Lately, I have had to discard that opinion. Don't get me wrong, I am not saying that the core should provide this capability. No, such things can be built by the community. For me, when we say that ProcessWire is simple, powerful, enjoyable, scalable, familiar, friendly, etc...., that encapsulates the absolute freedom the tool provides me. I can do almost anything with it. It doesn't take away from the tool. It is a testament to how versatile the tool is. Behind the scenes, it is still ProcessWire. The output, what I can do with it, well, that is the magic that is ProcessWire. And for this, I have to give Ryan credit. I doubt there are many CMSs out there that will allow you to extend it as much as ProcessWire does, yet remain stable and secure.

3 hours ago, flydev ?? said:

Plus, and even if it's not the primary goal, given the tool we already have in our hand, it will make a bump on new users/devs which will use ProcessWire. The right ones ? not sure, maybe the forum will be spammed by "unexperienced user" which will try to build a website with the builder but doesn't understand in first instance how to apprehend ProcessWire.

I don't see this as a problem at all, but rather an opportunity. I am not talking about the more the merrier. Rather, making a powerful, enjoyable tool accessible to people with different skill sets and different approaches to building things. That is a good thing, maybe even a great thing. In the end, we all want the same thing. To build secure, reliable, fast, stable websites/portals for our clients. If you can achieve that via pure coding, more power to you. On the other hand if you can achieve that (at least partly) via drag and drop, nice one mate! More power to you too. In addition, a builder doesn't mean the builder will just output code arbitrarily. On the contrary, the dev still has full control over the output, access controls, etc.

3 hours ago, flydev ?? said:

Absolutely, but is your job to lock everything. Building pre-defined blocks (speaking styles, not content (even if you should limit content)). 

This is crucial! In the same manner we lock 'fields' , 'templates', 'modules', etc., we can and should lock the builder down, both at the visual and processing data level.

3 hours ago, flydev ?? said:

To each one his field of work and I think this particular argument should not stop any idea because it is valable for whatever special you make for a client purpose.

Exactly! 

3 hours ago, flydev ?? said:

I mean, a system of permission should be built-in, every blocks or type of blocks should have a permission, restricting some functionalities that could be used in an editor, or the page builder it-self. Eg. all blocks are available to superuser, but other users will have only access to the defined blocks for their role combined to the restrictions of the page being edited.

That's how I've designed the builder I worked on this weekend ?.

3 hours ago, flydev ?? said:

You will have on the next weeks a preview of EditorJS

Looking forward to this!  Hopefully, in the next few days you will also have a preview of the page and content builder I developed over my weekend hackathon ?.

[ryan]

Quote

One thing I particularly liked about editor.js is how it keeps content separate from design: behind the scenes everything is abstracted so that a quote block is really just an object with a few text properties, etc. You could render that quote block in a hundred different ways for the front-end. Portable indeed

Yes, this is also what I was liking about it. I think the only thing that gave me pause is the development side of it. The plugins don't look as simple to develop as I thought they would be. At least, the learning curve there looks a bit high, and the amount of code to develop something simple seems more than I would have expected. But the same is true of developing CKEditor plugins, and none of those are deal breakers. This seems to be the nature of JS based plugin systems. I do feel like I need to find all the editor.js type options, as I'm guessing there are similar projects we should explore before picking one to build from; even if editor.js seems the most likely at the moment. 

Quote

Speaking of that, it may be a bit of a limited use case, but I've wondered a few times about adding geometry fieldtypes and adding geometry selectors. There's already the FieldtypeMapMarker, but this is using just standard float fields in mySQL, while mySQL and MariaDB have support for geometry datatypes and spacial indexes, and there are times it would be nice to be able to do a query and return all the places within a given distance. I already hacked the FieldtypeMapMarker a bit to allow adding KML overlays exported from Google Earth, or mobile tracker apps, but there's certainly a lot more that could be done to give geospatial data first class treatment if enough people use it.

Sounds awesome. I'd encourage you to release it as a module if you can. 

Quote

Editor.js and the Bard fieldtype from Statamic (which is extended in V3 of Statamic, Bard is based on ProseMirror) are very good, because they save content not in HTML (but you can, If you want to) , but as structured data, which then can be rendered via partials however you like (that's how I do it in Statamic). As an explanation you can read my post 

The reason I'm looking at two strategies is because I agree that the editor.js approach is great, and probably a good fit for many (or most). But there's also users like Jonathan Lahijani, where the editor.js/bard approach is not nearly powerful enough. The repeater approach does have the power, even if it's not as immediately intuitive. That's why my plan is to further develop RepeaterMatrix to better support those that want to use it as a builder, while also pursing a simpler strategy along the lines of editor.js. Does this mean that either approach is going to answer every need and interest for everybody? That's unlikely, but hopefully it'll be a good start and get the momentum going. 

Quote

One difference, is that in the case of editor.js we have to manually deal with json when generating actual markup, when Repeater Matrix provides us the comfortable PW API for that (making this way a little bit more ProcessWire). 

If we were to use editor.js, then I wouldn't expect one's template code to consume JSON. We'd map the JSON to an object (or array) so that it could be used just as easily as page fields. 

Quote

So, as I can tell, we all want the same kind of editor. The one that does not store the actual markup, but the one that stores data, that later we can render to actual html (or any other format really).

Right, same kind in terms of what it stores. In terms of implementation, I think we are talking about 1 core direction, but 2 different directions overall. Neither direction at the expense of the other. A reasonable one that the core provides (editor.js approach or similar). And then upgrades to RepeaterMatrix for those that want to use it as a more powerful builder. So the 2nd option would simply be ProFields RepeaterMatrix, and it wouldn't even be a builder per se, but it would be ready to be used as a builder a lot more than it is now. 

Quote

 ...or the repeater depth way which also has its flaws

Not flaws per se, but features that would make it better support use as a builder. That's what I'm looking to add.

Quote

But I do not want our editor to actually store something like col-sm-6, but rather some generic layout information. 

For a repeater matrix based builder, this would be at the discretion of the developer as to how and what they wanted to store. So in your case you might want to store something more abstract, whereas someone else might want something directly tied to their output framework. For the simpler/editor.js type builder, I don't think it would get into this type of layout thing at all. 

Quote

If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement.

This is all true, I don't think you would be able to on the editor.js side. The elements are defined by editor.js plugins, static code. Just like CKEditor plugins. Though we'd probably bundle a lot of plugins and build some of our own. Ultimately the editor.js route will never be as powerful as the repeater route in this regard. But it will be very easy to setup and very accessible.

Quote

Could we combine the benefits of the two? What if we invent the json-based storage for the data gathered with regular ProcessWire inputfields? 

This is something Jonathan and I discussed on our call last week. The storage behind Repeater/Matrix is overkill for the needs of a builder, so what would be ideal is if repeaters had an option to merge some of the storage needs. It's something I'm going to be looking into, though I'm not yet sure what's possible.

Quote

And what if we allow to create the Interface for the new flexible content builders components with “fake” fields, which have their inputfields only, and are not connected to the database?

This is basically what the new Combo field does. Though they are connected to the database, but a repeatable Combo field wouldn't require pages for storage the way Repeaters do. Nevertheless, for a builder, it seems that the underlying pages do bring a lot of benefits, even if they are overkill for the need. 

Quote

I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW.

This is already true. But I still think the two-tier route offers the most benefits. On one side something simple like editor.js, and on the other side, something ready for more complex needs based off an existing Fieldtype like RepeaterMatrix. Also, Bernhard's solution in the other thread looked pretty great too; he said it was similar to repeaters in some fashion, also using pages from what I understand. 

Quote

Please could you make ProcessLogger::formatLogText() hookable?

Will do.

Quote

 It is not clear which features or ideas will be implemented and if and how you can influence this decision at all.

That's true. Use ProcessWire (or any other tool) for what it has right now. You are right there are no guarantees about which features or ideas will be implemented, even for me. There have been cases where someone needed something and decided to sponsor it for the community, by hiring me or someone else in the community to build it. Outside of that, I have to find a crossover between feature requests and the needs of the projects that I work on with my clients, or with Pro modules. I can't afford to build features just for the sake of building them; I still have to find a way to fund them and then support them afterwards. The way I do that is by developing stuff that finds a balance between client needs and project needs. That way I don't have to bear all the development costs myself. The Pro modules also help to fund the core, though they also are significant projects in their own right, so I try to put much of Pro module budgets back into Pro modules themselves too. Though I put the question out there because I thought this year I could get into a couple of things that go beyond the usual development path. 

Quote

The pull requests sometimes are not integrated for years.

I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible.  

Quote

It would be nice if this was also listed in the Contribution Guidelines

The guidelines are here (https://github.com/processwire/processwire/blob/master/CONTRIBUTING.md) and while they do touch on this, they could go further. I will work on that. Thanks.
 

[LostKobrakai]

17 hours ago, ryan said:

I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible.  

Your points about this are all completely fair. It's up to you to integrate or reject the changes a PR does.

Currently the latter however does not happen in a manner visible to the creator of the PR or anyone else looking at the PR. So they just stack up looking like they were never looked at. If you consider something not possible to be added (or even not possible in the near future) everyone is better off if the PR would be closed with a short note of the reasoning. PRs do not age well and it's better to close them than letting them sit until no longer mergeable. The closed PRs (and issues) are still searchable, so if people to their due diligence they'll see that things were rejected before, find related discussion if attached, …. If you're not happy with the code for a given change you can also help people come to a version you're happy with maintaining without needing to go code it yourself. This does even work for issues. One of the most encouraging responses to issues I know from other OSS projects is "Sounds good. PR welcome.". I rarely see that as a response to bigger feature requests, but on smaller incremental things making parts of the project better it's a good way to move the burden of actually fixing something off of the maintainer themself.

17 hours ago, ryan said:

Sometimes something can be added very easily and without a lot of investment to review and understand it all

If a PR is not of that kind it's totally fair to close it with something like "This is to big a change and needs upfront discussion before consideration.". You don't need to take the time of reviewing PRs in depth, when you already know you'll not merge from just the title/description/amount of changes/….

So in conclusion: Without a response from your side a open PR is dead weight in the context of the community helping you improve processwire. Someone did some work and now it's stuck. Even if the response is negative it'll give anyone involved context either to adjust and be fine with things not being added or next steps to get things integrated either by starting a needed discussion, changing the code or implementation or whatever else needs to be done before it could be merged. Given the fact PRs don't age well I also feel response should be reasonably timely – even if the merge actually happens at a later time. Take a year and the PR creator might have moved on or worked around it, the underlying code changed in the meantime so the PR is no longer easily mergeable, but the issue fixed by the PR might still be present. I know this well given I have two open PRs for processwire from 2017 – one small fix, one not as small feature. I hardly use processwire anymore by now.

[OllieMackJames]

Just adding my voice from a user perspective.

I am not a coder but a very happy user of processwire.

For some of my sites I use the repeater matrix apporach which was done for me by someone from the forum, great work.

End of last year I decided to buy access for one year to thrivethemes.com a builder for wp, simply because my business model needs landing pages, email squeeze pages, courses, etc. etc.

I get sick already with the trouble of learning how to do stuff in thrivethemes environment.

Everything I built so far is far slower than what I have in pw, but for pw I need developers everytime I need something new.

The guy behind thirvethemes now has 70 people working, so there is a market for this type of stuff.

I much prefer what I have in the repeatermatrix pw way of doing things, and would therefore be SOOOOOOO happy if this gets taken further and I beleive if a few of you coding ninjas would build the pw version of thrivethemes, there is a market waiting to be tapped into.

Just my 2 cents!

Love the discussion and the talent gathered here.

[ryan]

@LostKobrakai In addition to what I've mentioned above, I openly admit I'm not great at PRs, if that's what you are looking for an admission of. I try and make up for it in other areas. Nobody is perfect and one area I have work to do is getting better with PRs. I stated earlier that this is a priority for 2021. I will revisit the PRs that you mentioned. 

Maybe some think it looks bad to have open PRs, but to me it looks like enthusiasm, ideas and potential. I consider it an honor anytime someone would want to contribute in this way. I actually think the majority of PRs have a lot of merit and like what I see. I almost never would say "no" and close a PR in the way you are suggesting, because I almost never would feel that way. Instead, I look for the same crossover of priorities and timing that I do when it comes to adding new features. I like having a solid repo of PRs because it's stuff that is available for when the time is right and stuff I can refer back to and know someone else is also interested. All open PRs are a "yes" in my mind and just a matter of timing. Though going forward my hope is to find more time to cover open PRs even before the timing is right, since the community has indicated this would be helpful in appearances.

PRs only don't age well if taken as literal code, which is not the way I work with PRs. It doesn't matter to me if the literal code has not aged well or not because it's the ideas that matter much more. Whether PRs or not, and whether my own code or not, I go through code additions line by line multiple times, often writing and re-writing, both for QA and to fully understand the logic... so I do not care about age of any particular code. I just care about the idea, getting it right and being able to support it for the long term. 

[bernhard]

Wow - totally missed the discussion here!!! That's why the page-builder-part in my post in the newer news-thread was somewhat offtopic... I'll reference it here and throw it into the discussion ? 

 

Let me comment wildly on some statements first - I'll try to summarize that in the end...

On 1/8/2021 at 3:36 PM, ryan said:

Quote

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.

Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. 

Please. No!

I've done some research before starting with RockMatrix and editorjs was an option that I looked at. I decided against that approach. I can't really explain, but I had the feeling that this is some 3rd party concept and not the way ProcessWire would do content management. I had the feeling, that if we used something like editorjs we'd need to develop a totally new concept for all the content blocks. But WHY should we do that? WHY would that be better then using existing ProcessWire concepts? We have everything we need (speaking about Fieldtypes and Inputfields) and throwing that away would not be clever imho!

Take a look at my matrix setup:

First block is a headline - a regular PW "title" (text) field. I'm just removing the inputfield's header (we can already do such things easily via hooks!)

Second block is a ckeditor field - similar, we remove the header and allow just a subset of usual ckeditor buttons. For example the image button is removed, because images are inserted via their own custom blocktype (gallery). That approach has several huge benefits that by far outweigh the drawbacks:

• Blocks are PW pages, this means you can do all kinds of PW magic with them. Think of hooks, think of custom page classes, think of doing listings using RockFinder (for example I'm using RockMatrix to hold invoice items having a description, an amount and a price and I can simply query all those items with a simple find call like "template=invoiceitem, year=2020") etc.;
• What about Multi-Language?! How would one build an editorjs field that properly reflects the internal PW multilang system??
• What about file uploads? We know that files need pages and corresponding folders...
• We use existing, proven tools (fieldtypes/inputfields)

On 1/8/2021 at 5:14 PM, teppo said:

In fact the more I think of it, the less sense it makes to think of block editors as something that would replace pages and fields. I'm all about having content split into separate fields where it makes sense. But as a replacement for RTEs, that's something I can definitely get behind: an RTE is a decent tool for creating text-only content, while for anything beyond that I find them rather awkward.

For "body content" (which may these days typically be a varying mixture of text, images, tables, forms, highlights, and so on) flexible content fields are (imho) a much better choice.

Exactly. That's what I've built my matrix field for and that's what I need in every project.

@Autofahrn has also put a lot of work into that topic!

 

On 1/9/2021 at 7:24 PM, Ivan Gretsky said:

To do so, our new flexible content builder should allow us to:

• define the allowed parents/children for the elements;
• allow to show the child elements side by side (to imitate layout);
• intelligently control the drag and drop, taking into account the allowed parents/children for the elements.

As far as I know, editor.js does not allow the nesting of the elements.

That sounds great. My matrix field does not allow nesting and showing items side-by-side or dragging dem from one block to another. But so far this has not been a problem at all! Quite the contrary. My clients love the ease of use. Even Non-Tec people can build great looking sites within no time. See these examples:

• https://www.kaumberg.gv.at/naturparadies-kaumberg/wanderwege/bergsiedlungsrunde/
• https://www.kaumberg.gv.at/gemeindeamt-buergerservice/aerzte-therapeuten/gemeindeaerztin-dr-alexandra-hutsteiner/
• https://www.kaumberg.gv.at/gemeindeamt-buergerservice/gemeinde-mitarbeiterinnen/
• And using the same content blocks for a totally different topic:
  https://www.kaumberg.gv.at/gastlichkeit-tourismus-betriebe/betriebe-in-kaumberg/

This is SO flexible. If they needed any new content type (eg Youtube Video) I'd just add another matrix block and they could add videos everywhere on their website.

On 1/9/2021 at 7:24 PM, Ivan Gretsky said:

Creating custom elements from admin

The other great thing about the Repeater Matrix-based content builders is that we can easily create new custom content types (elements, components…) right in the comfort of the admin. It is not really a quick thing, as we need to deal with creating the fields and assigning them, but it is rather familiar. And those custom components can use all the other ProcessWire data with Page Reference fields, Selector fields etc, which is cool.

If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement.

I'm avoiding the PW admin more and more. I'm doing most of my work in RockMigrations nowadays, because it turns out that this often is quicker and less tedious than clicking around through the admin, replicating the changes on dev/live, rolling back changes manually etc etc.; Using migration scripts on the other hand I have my code in GIT, can just copy over parts as needed (git pull/git push), or simply use MultiCursor in my IDE to change the "columnWidth" setting of multiple fields at once (does anybody want to count the clicks necessary for changing 3 fields' columnWidth setting in the PW backend? ? ).

I don't want to say that the PW backend is bad. Not at all. I've even wondered what @LostKobrakai is talking all the time when he showcased his migrations module back then, but I want to say that the PW backend might be really nice to have for simple use cases and beginners, but it is definitely a burden when dealing with advanced setups (think of automation, CI/CD, maybe multiple people working on one project at the same time, etc, etc).

But I'm not voting for editorjs route here either! When I looked at editorjs and how plugins are built, that was a whole new world. I don't know much about all those modern javascript related dev tools and I don't really want to learn them, to be honest. Maybe that's the problem and I'm not being fair. But creating a new matrix block in my case is simply creating one single PHP file that extends \RockMatrix\Block, that's it... And I'd love to see such a setup in the core or a professionally supported one as pro module ? 

 

On 1/9/2021 at 7:24 PM, Ivan Gretsky said:

And one more thing. In the video we see the actual markup rendered to the right of the YOOtheme content editor. We can do that also, creatively reloading THE WHOLE PAGE on changes with Hotwire / Unpoly / Vue. Making the flexible content builder feel dynamic and not requiring those saves-and-reloads. And making the connections between the options in the builder part and the final markup obvious to the editor.

Sounds great ? 

On 1/9/2021 at 7:24 PM, Ivan Gretsky said:

This also makes it hard to duplicate, copy/paste content in the site or between the projects. But it also allows us to use the familiar API when generating markup.

This gets totally easy when using RockMigrations!! That's another reason why a solid migration system should definitely be part of the core! Everything would benefit a lot from such a core feature - module development, devs developing sites and reusing parts, etc...

On 1/9/2021 at 7:24 PM, Ivan Gretsky said:

Bringing it all together

I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW. It can be comparable if not better than all the other competition. It can be well integrated and totally configurable through the admin. It can be portable between templates and projects. And it can be visual and responsive.

What do you think?

That would be a dream. Though I say again that I much more prefer defining things in code. Building user interfaces can be soo hard, while adding a hook can be so simple, efficient and clear. For example defining allowed blocks in RockMatrix is done like that:

$wire->addHookAfter('RockMatrix::getAllowedBlocks', function($event) {
  $field = $event->arguments(0);
  $page = $event->arguments(1);
  if($field->name !== 'rmtest') return;
  $event->return->add([
    '\RMDemo\Headline',
    '\RMDemo\Markup',
  ]);
});

Imagine you had to build this as GUI... Sounds not too complicated, because you could use an ASMSelect field that lists all blocks and makes them selectable and sortable.

But what if you'd want to show some blocks only to some special user role and hide them for others?! A simple if-statement in the hook. Nearly impossible to build as GUI...

21 hours ago, ryan said:

Yes, this is also what I was liking about it. I think the only thing that gave me pause is the development side of it. The plugins don't look as simple to develop as I thought they would be. At least, the learning curve there looks a bit high, and the amount of code to develop something simple seems more than I would have expected. But the same is true of developing CKEditor plugins, and none of those are deal breakers. This seems to be the nature of JS based plugin systems. I do feel like I need to find all the editor.js type options, as I'm guessing there are similar projects we should explore before picking one to build from; even if editor.js seems the most likely at the moment. 

*emotional* Please, don't ?

21 hours ago, ryan said:

Also, Bernhard's solution in the other thread looked pretty great too; he said it was similar to repeaters in some fashion, also using pages from what I understand. 

I've created a video that hopefully helps you all to get an impression:

21 hours ago, ryan said:

I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible.  

I think it would be helpful to clarify WHERE this discussion should happen upfront. In the forum? Via e-mail? Opening an issue (I think that's not the right place)...? But yeah... thinking about it I can imagine that monitoring all those channels is not easy and must take a lot of time...

[ryan]

I don't have any strong opinions here, just a few observations. I like the editor.js strategy, but I also like Bernhard's strategy. For example, I like the "something new and interesting" aspect of editor.js, and I like the "something clear and familiar" aspect of Bernhard's. His screenshot is immediately clear how it all works. I don't speak the language of the headers, content and buttons, but it's all still obvious how it works and what it does. That says a lot. To my eye it's more clear than editor.js at first glance, though I've used a lot of ProcessWire and very little editor.js, so I would trust others' judgement more. One major difference is clearly that Bernhard's approach uses pages in the same way that RepeaterMatrix does (I think?) whereas editor.js uses a block of JSON. There are benefits and drawbacks to each approach in terms of storage and overhead, but from a familiar API side, the pages approach is a good and known factor, even if it is likely a bit overkill for this type of storage (as it can be with many repeater cases). This already appears to be built in ProcessWire and already in use (?), that's quite a head start too. 

[bernhard]

4 hours ago, ryan said:

I don't have any strong opinions here, just a few observations. I like the editor.js strategy, but I also like Bernhard's strategy. For example, I like the "something new and interesting" aspect of editor.js, and I like the "something clear and familiar" aspect of Bernhard's.

great ? 

4 hours ago, ryan said:

His screenshot is immediately clear how it all works. I don't speak the language of the headers, content and buttons, but it's all still obvious how it works and what it does. That says a lot. To my eye it's more clear than editor.js at first glance, though I've used a lot of ProcessWire and very little editor.js, so I would trust others' judgement more.

Also reasonable and clever ?  I'm sure the interface can be improved a lot more. Just did not have the time for that and had to get things done and work with what I have...

4 hours ago, ryan said:

One major difference is clearly that Bernhard's approach uses pages in the same way that RepeaterMatrix does (I think?) whereas editor.js uses a block of JSON. There are benefits and drawbacks to each approach in terms of storage and overhead, but from a familiar API side, the pages approach is a good and known factor, even if it is likely a bit overkill for this type of storage (as it can be with many repeater cases).

Yeah, that's true. With one difference that I can define WHERE the created pages live. Usually they live under the page /rockmatrixblocks, but that can be totally up to the user. Not sure if I'm using that "feature" anywhere or really need that. But thought this might be good to have one day... For example one could create a site of team members of a football club using RockMatrix and all the players would still be a regular PW page that can be visited on the frontend, but can be sorted and quickly edited via RockMatrix GUI. One can think of it as an extended page reference field (like ASMSelect).

Regarding the overhead: I have thought of that, and I don't know how my setup would perform on large scale. But my feeling was that PW is built for handling millions of pages, so why should it not also be capable of handling millions of matrix blocks?

[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. I don't think I'm the audience for this builder (my projects don't use this approach), but I really want ProcessWire to meet this need and compete in this space. I trust the community advice on this more than my preferences so would like to hear from you. I've spent some time looking at editor.js, and here's a benefits/drawbacks list that I came up with: 

Editor.js benefits

• Easy for users figure out, but does require experimenting with it to find where the tools are.
• Tools only visible contextually so everything is very clean, no real baggage until you  need it. 
• From a marketing/appearance standpoint, maybe good for PW (?). 
• Storage is simple JSON, which is easy to work with as a PHP array on the front-end. That's assuming you need the content separated like this in the first place, which presumably the developer audience for a builder would be. 
• Since it's a modular/plugin system, it has potential to offer more down the road than it does now in terms of capabilities. 
• To me it also seems like kind of a cross between a full builder and something like CKEditor, so it might appeal to some as an alternative to CKEditor for certain cases. 
• It already seems to have wide adoption and be an active open source project with a good track record. 

Editor.js drawbacks

• Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block.
• Interface that while nice in many respects, is completely different and inconsistent from anything else in PW. 
• You are forced into using HTML elements (like <p>...</p>) as blocks, rather than being able to have something like a "rich text" block. It seems to me like a "rich text" (CKEditor) block is more useful than assuming every block-level HTML element to be a builder block.
• There are surprisingly few plugins, and few (or none?) seem to go much beyond what you can already do in CKEditor. Maybe the potential for creating our own new plugins is greater than CKE, but it's all JS and we mostly work in PHP. 
• Unclear if there are any tangible benefits to the user relative to CKEditor. I'm also guessing most clients would prefer CKEditor since it's more like working in MS Word. Maybe it doesn't matter since this is a different animal and you might not swap one with the other anyway.
• If we are to do anything beyond the basics with it, it looks like it would be a lot of work. The plugin system looks beautifully simple at its base, but the actual implemented plugins look surprisingly verbose/complex for what they do. 
• We couldn't use our existing Inputfield modules for new blocks (like an Image block) and so would be starting from scratch on a lot. 

I've also spent some time with Bernhard's editor (he sent me a demo) so will also come up with a benefits/drawbacks list for that. Interested in any other approaches you think we should look at also.

Regardless of direction, my plan is to bring live preview and auto-save into the core, as I think all builder directions would benefit from that. 

Also, I want to mention the RepeaterMatrix stuff discussed earlier is something we'll be doing either way, I consider that just part of regular updates to the module, and so that's a separate project. 

[szabesz]

30 minutes ago, ryan said:

Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block.

Drag and drop is only easy as long as the target is in the visible viewport. As soon as one needs to scroll while dragging, it becomes a really challenging thing to do, even in native applications running in modern operating systems, not to mention JavaScript based GUI apps. Providing both means of reordering should be the "solution", if possible.

30 minutes ago, ryan said:

clients would prefer CKEditor since it's more like working in MS Word

At first sight, my clients think they can deal with it as it does look familiar indeed. However, it has rather quirky behaviors when adding/removing list items, adding/removing line-breaks, and last but not least the horrid feature of injecting styles when pasting (which can be partially dealt with but never properly). So in the end my clients are always confused by the quirky way of using CKEditor.

30 minutes ago, ryan said:

If we are to do anything beyond the basics with it, it looks like it would be a lot of work.

And we should go beyond the basics, so currently personally I prefer Berhard's approach, simply beause it looks like that it is a more realistic project in the long run.

Edited January 14, 2021 by szabesz
lots and lots of typos fixed...

[rafaoski]

It would be great to have something like tinaCms for editing pages ...