Gutenberg For ProcessWire ?!

[teppo]

22 minutes ago, Ivan Gretsky said:

Nobody's talking about bringing content builder stuff to the core.

This. Please read this before you post. Not a single person here has, to my best understanding, suggested that there should be a page builder in the core. This very topic is in the Modules/Plugins development area of the forum. This topic is not about the ProcessWire core.

Thank you ?

[happywire]

3 hours ago, Ivan Gretsky said:

Nobody's talking about bringing content builder stuff to the core. I guess only Ryan could))

Excellent.

3 hours ago, Ivan Gretsky said:

js page api was on the roadmap. Might be a good fit here once it's done.

Do you mean a native/ProcessWire core way to output JSON data from the databse through the use of a then native REST api that is called with vanilla JS?
That is, as far as I can see from being about 48h into ProcessWire, the only thing I could not find.
But again I found modules that do this, so perhaps leave it in modules?

it would somehow be very cool though to have core team approved modules that work with the Basic site profile so devs new to this can build from there and learn.
Is there a core dev team or is Ryan the one and only being able to commit to ProcessWire?

I agree though in a certain way. There are devs that work per client requirements and then there are web designers that just want a page-builder to be able to sell websites/themes that then clients might buy without having to hire a dev while also wanting to use ProcessWire. I guess for the later such a page-builder would come in very handy.

I am raised with the "build it yourself" frame of mind, sure not re-inventing the wheel, though the satisfaction of knowing what source will be produced is very important to me, especially knowing where the source code comes from, meaning what in the end is responsible for each line of code that the browser gets to render.

But.. given a module would be made that enables devs to output clean code without having to load external libs into the frontend while also being an advantage to devs in the sense that snippets/blocks of code/content sections could be easily dropped and dragged in the backend, well I would at least give it a shot, given it is clean and does not interfere with ProcessWire, meaning if you remove such a module the database and source code produce the same result in the frontend.

3 hours ago, Ivan Gretsky said:

But the request for content building is high. Content is king. And RepeaterMatrix + Hanna codes are not as user friendly as Gutenberg seem to be. SPA editing is way more pleasant than opening and saving things one after another and adding images only after 1st save.

Quality content is kind. There is tons of well designed websites with plain bad content. I don't see Gutenberg being user friendly or a real thing to look at as a reference for what could be useful for ProcessWire in terms of SPA editing. My experience with Gutenberg was that is made me feel that the entire dashboard has become very brittle on a psychological level, meaning, you click, it shows up, but if it really is saved and will work is a different matter. Often the preview would not render anything, blank page. At least for me, opening and saving things one after another makes me feel much more in control, knowing what why when and where code will be in the frontend. But this is just personal preference. I guess I like things clean, working and working well.

Bottom line, I do not find the idea bad per se, I just think something like this requires a lot of thought and careful use case consideration before any code is written, i.e. who would benefit most from such a SPA editing module and what would be the implications for ProcessWire.

I say let's first get that JS api going if I understood you correctly that that is/was on the roadmap.

[happywire]

3 hours ago, teppo said:

This. Please read this before you post. Not a single person here has, to my best understanding, suggested that there should be a page builder in the core. This very topic is in the Modules/Plugins development area of the forum. This topic is not about the ProcessWire core.

Thank you ?

Thank you for pointing this out. Very new to all this. Will be more cautious and take the time to, as much as I can, read most of the thread before posting. No bad intentions here. I guess I am still under shock for what happened with WP and Gutenberg, saw the title and felt it would be good to voice my concern before things get going. Thank you indeed.

[teppo]

2 hours ago, happywire said:

No bad intentions here.

No worries – no hard feelings here either! It's just that folks sometimes miss the point that having a module that does x for ProcessWire doesn't mean that ProcessWire itself, as in the core package, needs to do that. In this thread alone we've had some posts where this point has been lost.

What third parties (such as me) build on top of ProcessWire does not have a direct impact on the core.

I get that this is a topic that can bring some emotions to the surface, so trust me: I for one would not like to see ProcessWire go the "page builder route". At the same time I see a lot of value in having a block editor style Fieldtype – or something similar – as a module that one can plug in if and when that sort of feature makes sense ?

[elabx]

9 hours ago, bernhard said:

which library are you using for this drag&drop magic and also for the side panel?

It's jQuery UI! And the sidepanel is just an animated div, nothing fancy really. 

[joshuag]

9 hours ago, happywire said:

Totally agree. Keep ProcessWire clean and do what you like to do in the backend.
Having a default editor that all new devs/clients must use would ruin ProcessWire for good.
More a fan of "build it yourself, nice and clean" than "click and drag it yourself" .. and be left with a mess of badly performing source code full of external libs etc.

We are using the included in PW jQueryUI drag, drop, sorter. 

[jploch]

This is an interesting topic!

Iam a designer that learned to code and PW really helped me improving my coding skill.
I don't want the client to control the layout/design to much. 
In my experience this results in clients messing up the design of the website.
So the functionality to change the design should be configurable to a certain role.
But I would like a way to change the layout of my blocks in the backend without touching my template code.
Ideally in a WYSIWYG way. So I would like to only have one template for all my pages with blocks that I define.

A workflow that would make sense to me, and would save me a lot of time (for larger websites with a lot of different layouts per page):
1. The client would add blocks to a page, which layout in a default way (that I define). If the default way is not good enough, proceed to step 2-4
2. The client saves the page without publishing
3. I would edit the design right in the PW backend and show it to the client.
4. The client approves the design and the page gets published

I implemented a solution using blocks with PageTableExtended and it worked quite good, but had some things that could be improved, like ajax editing the content, without the need of opening a modal to edit the content. I will make a post on my use case soon.

Looking around in the forum I also found this post by Theo (he uses a WYSIWYG wich is far superior to mine from a usability standpoint):

Demo:
http://theowp.bplaced.net/upload/pics.html
http://theowp.bplaced.net/upload/prev3.html

[Jonathan Lahijani]

On 5/21/2019 at 5:54 AM, jploch said:

I implemented a solution using blocks with PageTableExtended and it worked quite good, but had some things that could be improved, like ajax editing the content, without the need of opening a modal to edit the content. I will make a post on my use case soon.

RepeaterMatrix is going to be the best choice for any type of page builder in ProcessWire (at least at this time).  The recent updates to the module improve its flexibility further, such as being able to change the matrix-type of an item that's already been added to a page (this is similar to Gutenberg functionality of being able to change block-types... nice).

After using RepeaterMatrix and its equivalents in other CMSes over the years (such as WordPress ACF Flexible Content field), my suggestion is you're better off NOT providing fully customizable layout functionality within your builder (that is, avoid the capability of allowing users to add things like containers, rows, columns).  I've personally found that even other CMSes that do this well and are built around that concept are just too clunky.  It's the nature of the beast.

The better approach in my opinion is to provide a good set (5-10) of matrix-types/blocks that can instead achieve this.  Once again, the recent feature addition whereby matrix types can be changed is going to help here since switching a matrix-type retains its content as long as the matrix-type you are switching to uses the same fields.

[fliwire]

this is like gutenberg

https://codex.so/editor

[gornycreative]

On 5/30/2019 at 4:44 PM, fliwire said:

this is like gutenberg

https://codex.so/editor

This! Someone on another thread was working on an integration of this in a PW module... I've been trying to find it again for a few weeks, I came across the thread by accident before and forgot to bookmark it... I'm not a huge fan of page builders but I like the aesthetic and functionality of this.

[fliwire]

 

[Jonathan Lahijani]

I've been following WP's Block Editor development on-and-off since it was announced.  I was hoping for the best and something very well thought out given they could make core changes to WordPress to facilitate a great experience, but it seems, at least from my point of view, chaotic and disjointed.  I am not surprised however since page builders are tough to do, especially if certain things are not "forced" (like a universal CSS framework).

This comment touches upon several issues from a developer's point of view:
https://wptavern.com/getting-to-know-the-upcoming-wordpress-5-8-template-editor#comment-382930

[szabesz]

19 hours ago, Jonathan Lahijani said:

This comment touches upon several issues from a developer's point of view:
https://wptavern.com/getting-to-know-the-upcoming-wordpress-5-8-template-editor#comment-382930

The weakest point of WordPress has always been not relying on well established design patterns but on custom, ad-hoc solutions they made up as they went.

Also, there is a great belief in not starting from scratch but trying to refactor the whole system somehow to get rid fo the technical debt, even thought it rarely succeeds, if ever. Maybe it might work for small projects but not for substantial ones. The devs of WordPress certainly failed in that. Another team trying to make a gradual but complete refactoring to make this idea come true is the devs of PrestaShop. They advertise it as the only sensible way to go, as this way – according to their reasoning  – merchants can keep their investments in paid modules and other customizations applied to their shop(s), yet, when the next major PrestaShop version upgrade comes along, merchants are expected to start from scratch, somehow importing their old (and "incompatible") shop data into a freshly installed PrestaShop! They also state that module developers can better support their modules because they can keep them compatible with several mayor versions of PrestaShop without writing and maintaining their modules for each major versions separately. However, the the thing is that they do it by writing extremely long if-else statements all over the place to take account into all the differences between the systems (and there are many!), so you can imagine how fragile that style of coding is. Does that really help the module developers? I don't think so.

ProcessWire used to have a v1 version and Ryan decided to start from scratch, and there must have been a good reason behind it. When something fails to deliver what it was supposed to deliver, then – in the long run – the only way to move forward is it to go back to square one.

Two more "success stories" regarding starting form the "beginning": 

• Ashley Hewson's interview : https://youtu.be/ABM60-0fbuM?t=344
• Construct: https://www.construct.net/en/about

Even Adobe has failed in this regard, as their applications are just somewhat similar to each other and they are still not yet rewritten, they just keep growing in size, never really bringing real UX enchantments along they way by turning into one, actually integrated suite like the Affinity apps.

I have already switched from InDesign and Illustrator to Publisher and Designer. Affinity Photo has yet to deliver smart objects and pixel wrapping so that I can leave Photoshop as well, but I hope they are already working on these features. Fingers crossed ?

Sorry for partially being off-topic.

 

Edited June 23, 2021 by szabesz
typos and clarifications

[Chris Ernovsky]

4 hours ago, szabesz said:

The weakest point of WordPress has always bee not relying on well established design patterns but on custom, ad-hoc solutions they made up as they went.

Soooo true!
In consequence, devs have to follow that and do the same. We have so many WordPress sites which have grown in years and and now they are stupidly patched with our homegrown snippets, patches, hooks, etc. And lots of them have been frozen against updates because of incompatibilities or/and Gutenberg. The only option is to build such a site from the beginning. In some cases we did.

13 hours ago, Jonathan Lahijani said:

I've been following WP's Block Editor development on-and-off since it was announced.  I was hoping for the best and something very well thought out given they could make core changes to WordPress to facilitate a great experience, but it seems, at least from my point of view, chaotic and disjointed.

The same. I get the idea. I just don't buy the WP way from the very beginning. After 3 years of Gutenberg it doesn't get any better. And this is an opinion of our clients/administrators. I've never liked it so I'm not objective here.