Jump to content

Gutenberg For ProcessWire ?!

Recommended Posts

Gutenberg is.. okay. It's getting mixed reviews https://en-gb.wordpress.org/plugins/gutenberg/#reviews.

The trouble is, it allows the user to do too much. It's trying to sit in the middle ground of a page builder and an editor. I think giving the user everything even if they don't need it isn't inline with ProcessWire. Things like being able to make columns etc. 

I actually much prefer Statamic's implementation with it's Bard field - https://docs.statamic.com/fieldtypes/bard

  • Like 3
Link to comment
Share on other sites

16 minutes ago, Tom. said:

I think giving the user everything even if they don't need it

You are absolutely right, but there must a way to restrict that behavior; for example: disable adding images in a video area ..etc / It doesn't have to be that cluttered.

I don't know if the Drupal guys are OK with it, I will give it a try.

Link to comment
Share on other sites

11 hours ago, gmclelland said:

I saw somewhere on Twitter that someone mentioned they were doing something similar with Drupal and http://editor.ory.am/

That one looks really nice! First I thought I don't think ProcessWire is the right tool for such click-click-marketing sites, because its strength comes from the freedom of fields and querying them with the strong API, like $pages->find('template=xy,fieldx>50,fieldy<10'. But then I thought maybe it would be nice to have both combined. A site with custom templates & fields where we need more control over our data and an "ORY-template" (similar to the basic-page template) where the user can build its own totally flexible page. This could be great for landingpages.

So if anybody has the time to build it - go for it 🙂 

  • Like 2
Link to comment
Share on other sites

  • 1 month later...
On 8/7/2018 at 12:24 PM, Tom. said:

I think giving the user everything even if they don't need it isn't inline with ProcessWire. Things like being able to make columns etc.

From a core development perspective I'm going to agree with this – but while the core probably shouldn't include a pre-built, "full featured" page builder (at least for the time being, since no one really knows what the future holds), there's no reason why third parties should be discouraged to create such tools. I also know for a fact that there'd be a market for that 🙂

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

I'm still fairly new here having switched to using ProcessWire for pretty much every project (hence the frequent questions 😂 ) from Concrete5.

Concrete5 has had Gutenberg-esque block-based front-end editing for nearly 10 years longer than Wordpress. Although a finished site using C5 can look great for a site editor/frontend-only user with various drag-drop layout tools, we were finding c5 development had become very convoluted and was starting to make simple website projects unnecessarily complicated. C5's core weighs in at a hefty filesize too. This is why we started researching for alternatives and landed happily at ProcessWire.

I already find WP development unnecessarily convoluted, especially compared to the simplicity of ProcessWire. And with Gutenberg, I can only foresee the same sort of headaches ahead for the WP community that we were finding with C5 - namely conflicts between blocks and the core and frontend UI and your design style and functionality being dictated to by the CMS in order to work in the Gutenberg features.

Discovering ProcessWire has been a revelation for us - the clean API and design agnostic approach are making everything from simple website projects to complex web apps a breeze, with the added bonus of super simple frontend editing that not only wows client's used to site builder platforms but requires basically zero onboarding too.

I would urge anyone thinking of building out Gutenberg inspired modules for ProcessWire to consider the above comments to ensure that what makes ProcessWire special is retained.

  • Like 11
Link to comment
Share on other sites

  • 4 weeks later...

More on Gutenberg (it is a bird's-eye view article, and as such just a quick read) https://toolset.com/2018/11/toolsets-plans-for-wordpress-5-0-and-gutenberg/



The first version of WordPress and Gutenberg appears to be optimized for using Gutenberg to compose blog posts.
What we’d like to see in Gutenberg, which isn’t there yet, is mainly:

  • The ability to design templates, which will work similar to PHP templates, but with Gutenberg
  • The ability to launch Gutenberg editor for any content, not only the post body
  • The ability to insert dynamic values (fields and taxonomy) into block attributes


Link to comment
Share on other sites

Recently Bitrix (a popular commercial CMS here in Russia, known worldwide for its Bitrix24 CRM/PM/... solution) introduced similar functionality they called Site Constructor. This thing allows to build pages or parts of the pages from pre-defined blocks which can be static or dynamic. Site developer can style, modify or add their own blocks. They recommend this for landing pages for now, but are aiming to move all content management to those blocks. So there is some trend.

I actually do use (almost) the same approach in PW. Most of my pages have content-page template with content_blocks Repeater Matrix field holding most of the content in repeater items. What is missing in my solution is:

  • the easy ability to restrict the order, allowed types of those items (though possible with this module);
  • the ability to easily move/duplicate content blocks from project to project (still think Repeater Matrix should be PageTable Matrix);
  • the ability to easily preview the page built (like with this solution) in admin / edit it inline on the frontend.

I see this way of building content very flexible, but still somehow unfinished. We have all the parts in PW to build a full-blown page bulder that will not allow too much for ones that do not need it, but will make it easy to build something really complex and interesting without programming. But those parts are not yet combined in a polished solution. I would certainly like to have it in PW (as a PageTable-like PageBuilder FieldType/Inputfield combo, probably).

  • Like 6
Link to comment
Share on other sites

  • 2 weeks later...
  • 3 weeks later...

Hello Everyone!

I'm new here, just signed up.
I've discovered PW few days ago (what a shame...) and I'm angry for myself that I lost several years of my life...

I'm a homegrown webdeveloper since 2005, started from pure HTML, then e107, Textpattern and from 2008 I work(ed) only with WordPress.
I've made over a hundred of sites. Most of them are simple blogs but my main site is quite large (with over a 10k entries and over 100k of media).

It's outdated a little bit so I was planning to modify and refresh it lately but then... Gutenberg happened.
Gutenberg as an editor is unintuitive, buggy, produces massive problems and it's incompatibile with most of the things I'm using
(it seems to be the same story for hundreds of websites built on WP).
And though the whole WP community is frustrated and angry, it's been forced with WP 5.0 as the beginning of rebuilding WP as a platform into... hmm... next Wix?

I was trying to discuss - my comments were deleted and my account has been blocked (as many others).
After 8 years of developing WP...

Well... I've frozen the site for updates and started looking elswhere.
I have few advanced demands so tried Drupal, then played a little with Craft, Codeigniter and Laravel (I'm not a programmer per se).
And after few recommendations I've finally found You.

Guys... I'm so thrilled and emotional. I can't stop reading and following tutorials on localhost.
PW is THE TOOL I was searching my whole life!
I'm going to study everything very carefully and next year I'm going to rebuild slowly (there's no rush) my main site with PW.

Back to Gutenberg:
I understand where it aims to be and what it tries to accomplish BUT this is wrong on so many levels.
As far as I can see, a barebone PW installation is far more flexible and useful then WP with 30 plugins.
And obviously you know it perfectly.
So I'm begging you: no Gutenberg here... 😉

Cheers to Ryan and Everyone!
Greetings from Poland!

  • Like 10
  • Thanks 2
Link to comment
Share on other sites

Hi @phoros and welcome to the forum,

interesting read!

13 minutes ago, phoros said:

Gutenberg as an editor is unintuitive, buggy, produces massive problems and it's incompatibile with most of the things I'm using
(it seems to be the same story for hundreds of websites built on WP).
And though the whole WP community is frustrated and angry, it's been forced with WP 5.0 as the beginning of rebuilding WP as a platform into... hmm... next Wix?

I was trying to discuss - my comments were deleted and my account has been blocked (as many others).
After 8 years of developing WP...

Would be interested what your concerns have been. I love PW for many reasons, but I've also come across situations where I wished there was some kind of content-builder to give editors more flexibility than just different fields (where PW is awesome). There are several approaches for that already and I've built something like this several times already, but it still does not feel right, because you always have to start from scratch.

Seeing all those fance marketing screencasts about wordpress click-click magic I got a little frustrated from time to time, because building such functionality in pw needs a lot of time and effort - which means lots of costs and a disadvantage in terms of business.

So I'd be happy to hear some more details about the problems that gutenberg brings in. Thx

Link to comment
Share on other sites

Hi @bernhard!

Gutenberg in Wordpress is a dual misconception:

  • Wordpress is known as a blog platform. Yes, you can extend it massively and use it for many different projects but in the end it's mostly about operating with text. It's usually enriched with images and embeds but it's still an article, news, etc. So many authors for so many years just copied and pasted their texts, added few media and with 2-3 clicks published it. Now, doing this simple task with Gutenberg is insanely uneffective: instead one simple menu in editor there are several (hidden) menus everywhere (in every block). And EVERYTHING is a block now - a title, a paragraph, an image, a quote and so on (imagine the amount of additional code it generates!). You have to do absurdly much more things to get the same result and you have to spend much more time to do the simplest task.
  • So maybe Gutenberg is for designers rather? If it's true and if this was the idea (to simplify building content) - there are so many so much better WP site builders and themes (to do so) FOR YEARS! Anybody who wants a one-page site or portfolio just picks up a theme and few plugins and voila. The core blogging mechanism stays safe and ready when necessary.

I can understand that Matt, Automattic and the dev-deciders want to turn with WP elsewhere and change the character/purpose of the platform. Their choice (though the style they're doing that is embarrassing). But cutting out all those (millions?) of websites using WP for TEXT PUBLISHING and trying to convince the whole world that Gutenberg is better tool to write an article than TinyMCE or CKEditor is as funny as idiotic.

From practical point of view, Gutenberg is incompatible with so many plugins and themes (used stably for years!) that it broke hundreds (thousands?) of websites. Blank sites, errors, bugs everywhere AND in many cases people have no idea where is a problem and what to fix. At my site (mentioned above) I have 50 plugins. Half of them doesn't work or generates errors with Gutenberg. Just take a look at the reviews of Gutenberg (and their dates!) to catch the disaster happening there.

I know perfectly from my own experience how such a "click click drag-and-drop magic" approach can be tempting.
Probably even using PW at some point (it's still ahead of me!).
But it's the whole different way and phillosophy of creating (fast) content. There are all those Wix, Weebly, Spacesqare and Mobirise builders for that.
WordPress as it was thought in the beginning shoudn't go that way (that 30% of web share will fall quickly).

  • Like 5
Link to comment
Share on other sites

  • 2 months later...

Without going into too much detail regarding the previous discussion here, I've just heard of https://gutenbergcloud.org/ for the first time, and I've got to say that it seems promising. The basic idea is to provide a common service for installing all sorts of blocks – and only the blocks you actually need. (Currently the situation is roughly that some blocks are shipped as one-block plugins, while others ship as massive collections of blocks, neither of which are really optimal.)

Also took a quick dive into Gutenberg for Drupal (which Gutenberg Cloud promotes), and they've done a smashing job there 🙂


Code once, use everywhere: As Gutenberg blocks are CMS agnostic, we want to provide an ecosystem all systems can connect to.

I'm definitely interested in looking into setting up a Gutenberg Fieldtype, or perhaps a Process module – or something similar. Though once again my desk is kind of full, so who knows.


Although I did say that I wouldn't go into the earlier discussion, just a quick comment on that:

As a tool Gutenberg has it's flaws, and it's definitely not a tool that would/could/should somehow replace what ProcessWire does. I don't think that anyone has been suggesting that here either.

Gutenberg is a block builder, and admittedly one still in a relatively early state – but even at this stage it looks promising. There really aren't any serious contenders, particularly fully free and open source. Right now there's also a lot of momentum behind the project – not to mention financial backing from Automattic – which means that as a tool it will undoubtedly improve over time, and current issues will eventually get ironed out.

Whether going with Gutenberg is a good thing for WordPress or not is a debate I don't want to get into. Personally I don't know anyone seriously developing sites with WordPress and not using either one of the existing block / page builder solutions, or some sort of ACF based approach. WordPress alone is not the point – the plugins are.

Since block editors are probably the most popular way of building WordPress sites, in my opinion having one built into the core is a logical next step.

But that's just my opinion. And again, it has little to do with ProcessWire 🙂

  • Like 6
Link to comment
Share on other sites

7 hours ago, Ivan Gretsky said:

I think this one is pretty popular and powerful. Just to provide an alternative))

Thanks! Didn't know of GrapesJS, looks interesting 🙂

That being said, my first impressions are somewhat mixed: the default theme is pretty bad in terms of accessibility, UI felt kind of confusing (possibly because there are a million options there), and overall it could use a major facelift. On the other hand it seems fast, apparently there are quite a few features available as plugins, and it does seem to be actively maintained as well.

Overall I'm getting a strong "for power users" vibe from GrapesJS, and so far it doesn't seem like something that I'd be happy to introduce to non-technical clients who "just want to add some blocks".

In other words: in my (possibly subjective) opinion Gutenberg still seems more viable than GrapesJS.

  • Like 2
Link to comment
Share on other sites

Hey, @teppo!

Last night I spent a few hours reading through Gutenberg docs and marketing materials. I must say those are very well written and the whole concept is appealing to me. But it seems to be coupled with Wordpress and not so easy to bring into ProcessWire. I know, there is a Drupal integration and the "editor for the open web" marketing stuff. But it still seems to me it is primarily for Wordpress for now. I am talking not about those static html type blocks with defined styling, but rather those they call dynamic, which use data stored in the database.

I wish we could have an editor like Gutenberg (in tearms of UI) in PW where we could easily create static and dynamic (based on other pages) content for a content area. And we could easily add blocks ProcessWire way and maybe even be able to render them with ProcessWire or ProcessWire-like API. Kind of like a mix of Gutenberg and Repeater Matrix.

I can see that as an Inputfield that could generate json data describing content and store it in the textarea fieldtype. Same way as Gutenberg does store its data as html+comments. Same way as CKEditor 5 seems to work. To generate that json we would need some kind of a an SPA editor with visual block representation. And GrapeJS seems to provide that type of functionality, calling itself a Web Builder Framework. I can imagine we could build whatever UI we need with it and add only what we need (no paddings, but rather a data description - look here). Maybe it will turn out GrapeJS does not do just that, but that's what I'm talking about))

And then we could query this field from PW template like

foreach ($page->grapenberg_field as $block){

$block could be a new virtual page-from-json type and/or a Page.

Link to comment
Share on other sites

On 9/19/2018 at 11:14 AM, teppo said:

the core probably shouldn't include a pre-built, "full featured" page builder


On 12/14/2018 at 4:20 PM, phoros said:

So I'm begging you: no Gutenberg here.

Longtime WP user. Came here to escape the madness that is Gutenberg.
Please, for love of ProcessWire, do not include any such editor crap inside core.
People can do so via modules or even admin themes but keep PW clean, neat, tight, free and fresh from such nonsense.
Just learned about ProcessWire a couple days ago at a JS workshop/conference.
Reading the docs, doing first examples and totally in love with it all.
Keep it that way please.

Regarding Gutenberg.
Not only do you need to know React deeply, no also JS and a lot of it and deeply also, then you get to work with a "the WP way" version of React to build things. With Gutenberg WP has set the bar to entry into the WP world way above average, all the hobby coders that could easily make a WP site given a month of learning are now facing a very steep and intense learning curve.

This will surly show going forward. This is what got WP off the ground in the first place. Ease of use and also ease of getting a site done. This has changed. Kids these days want to see results, fast. Sure if you don't care about PageSpeed or WebPageTest, just need a page-builder, plaster external libs all over the source, go ahead, if that is your game, and if that is what you unknowing client pays for, the sure, yes, use WP and Gutenberg exactly for this kind of crap.

But if you really do care about all these things and want to make a good site that performs well where the client can have multiple custom blocks showing in the frontend, then you are going to have to invest a lot of time learning JS and React and "the WP way of React". Not something I see any entry level coder feeling up to. For example Just go ahead and make a responsive image block, and I don't mean just the img tag but something more like this.


Asked around many frequented channels, senior and seasoned devs could not come up with something that produces usable source code.
One guy had a solution, asked him if he could show the code "sorry, no, we have a team of devs working on that in our agency and cannot show it publicly".
Go figure. A whole team of devs at an agency for a responsive image block to work in WP.
Well done Matt and super smooth more there Mark, slipping React into WP that way.
A good colleague that has been using WP all his life and knows PHP inside out tells me "I am going to stay away from Gutenberg for as long as I can".

By your means, feel free and make a module, load the editor of your choice, give the client what you think they need or want, but do all this strictly kept away from the beautiful, clean and nice source that is ProcessWire.

Given the WP mess I am sure there will be more and more people going to use ProcessWire in the future.
I plan to speak publicly about ProcessWire at a conf as well as hold workshops, I am that much convinced about it.
I would not even go this way if I would have discovered any dependencies on external libs or any such page-builder crap that now WP has built in.

And now back to the docs and examples.
It is such a pleasure.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

I don't think that implementing another framework would be the way to go. I think we already have a great framework for editing our content: ProcessWire (the backend, meaning ProcessPageEdit). We have a great ecosystem with our fieldtypes and inputfields. It would take huge effort to rebuild all this on another framework (like grapejs).

My approach would be to keep all blocks as pages with all the benefits we get from it (setting templates, having access control, etc). Those blocks could easily be edited right away in the backend, as they are pages. Just append ?modal=1 and you have exactly what you need: A UI to edit your block. No extra work, no breaking updates etc.

Repeater and Repeater Matrix already show that this is possible. It would just need a new inputfield where we can drag&drop, copy, remove, create those blocks. @joshuag  and @elabx have already shown that this kind of magic can be done in the pw backend:  https://processwire.com/talk/topic/19557-designme-visually-layout-your-edit-screens-preview/ 

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

  • Like 1
Link to comment
Share on other sites

10 minutes ago, bernhard said:

I don't think that implementing another framework would be the way to go. @joshuag  and @elabx have already shown that this kind of magic can be done in the pw backend:  https://processwire.com/talk/topic/19557-designme-visually-layout-your-edit-screens-preview/

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.

  • Like 1
Link to comment
Share on other sites

On 3/12/2019 at 9:17 AM, happywire said:

Well done Matt and super smooth more there Mark, slipping React into WP that way.

When React dies, so does WordPress. They have tightly coupled WP to Reach, the learning curve to WP development has become a lot steeper than it was before. While JavaScript and browsers are evolving in a direction where therel will be less and less need for complex frameworks, see:



"That said, much of what frameworks do will probably become easier to do with smaller libraries and/or native code as time goes on. Take my application as an example. At the same time, if the large frameworks and libraries remain versatile they may morph, adapt, and stick around. If not, they may end up like jQuery — a tool of the past for the most part."

I would like to add that jQuery is not a thing of the past but still going strong 🙂

  • Like 1
Link to comment
Share on other sites

17 minutes ago, bernhard said:

Repeater and Repeater Matrix already show that this is possible.

I would concentrate on improving these and the Page Table field. For clients wanting to edit content easily, frontend editing is often enough. Actually, my clients would not be able (or willing) to use a pagebuilder anyway, they just want to click on ONE thing and edit text or images, any more than that and I am asked to do it instead.

  • Like 1
Link to comment
Share on other sites

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

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.

PageTable Extended showed a way true block editing could be done in PW. Frontend editing is another step that could revolutionize content editing, but I never read about any good implementation. RepeaterMatrix is cool and could be even better if it would be PageTableMatrix with a similar Inputfield)))

I think we can and should find a way to solve this need in true ProcessWire way. And we have to look at competition.

Gutenberg might be hard and messy for developers, but it is desirable for end users. Let's make good for both using our strong points.

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

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By flydev 👊🏻
      I would like to present you a new module which aim to facilitate the productivity of your editors/publishers when working on ProcessWire.
      The idea begun when my co-worker told me that when typing in ProcessWire CkEditor field he was feeling "loosing motivation" when writing big wall of text and/or inspiration. So he opened his web-browser and show me a site looking to Wordpress - feel free to put your preferred emoji here - then he opened Gutenberg... typed some text and moving some "blocks".
      I understood immediately why he got this feeling with CkEditor. If you or your client feel like this guy, then you will love this module !
      What is currently supported ?
      Auto-save Medias upload support HannaCode support Blocks Implemented
      Heading Image Paragraph Embed Quote Code Link Table (beta) Block Delimiter Raw HTML Note (custom block markup) Feature Request
      Frontend Edition   
      And there you go for the preview - sorry I am to lazy and bad at typing text so I had a copy/pasta moment :

      Module featured in the ProcessWire Weekly #317 - Thanks @teppo
    • By DV-JF
      Hey girls and guys,
      I'll want to open this thread in order to discuss a main problem I've run into with following setup:
      I'm maintaining a site where different URLs are directed to the same folder. In site/ready.php the $user->language is set based on the $config->httpHost
      <?php /* Set language based on the domain and user is not logged in */ /* Slovenian */ if( $config->httpHost == "www.domain.si" || $config->httpHost == "domain.si" || $config->httpHost == "domain.si.local") { if (!($user->isSuperuser())) $user->language = $languages->get('si'); } /* German */ elseif( $config->httpHost == "www.domain.at" || $config->httpHost == "domain.at" || $config->httpHost == "domain.at.local" || $config->httpHost == "domain.ch" || $config->httpHost == "www.domain.ch" || $config->httpHost == "domain.de" || $config->httpHost == "www.domain.de") { if (!($user->isSuperuser())) $user->language = $languages->get('default'); } /* Croatian */ elseif( $config->httpHost == "www.domain.hr" || $config->httpHost == "domain.hr" || $config->httpHost == "domain.hr.local") { if (!($user->isSuperuser())) $user->language = $languages->get('hr'); } /* English */ elseif( $config->httpHost == "www.domain.eu" || $config->httpHost == "domain.eu" || $config->httpHost == "domain.eu.local") { if (!($user->isSuperuser())) $user->language = $languages->get('en'); } /* Italian */ elseif( $config->httpHost == "www.domain.it" || $config->httpHost == "domain.it" || $config->httpHost == "domain.it.local") { if (!($user->isSuperuser())) $user->language = $languages->get('it'); } The homepage (id=1) has following settings:

      As you can see German (Deutsch) is set as default language. Everything is working nice and fine and I'm really happy with this kind of setup but now there are some new requirements, which causes me quite a headache :
      I've to add some pages only in one or two languages (they should not be present in German) I've to create some editor roles that are allowed to only edit (can be done with https://processwire.com/docs/user-access/permissions/#multi-language-page-edit-permissions) & add pages to their specific language. What I've found out so far:
      The default language can't be disabled and must always be present (though this would be in my eyes the easiest solution) Creating my own "language select field" - example here: won't work in this case because I've to rely on the native languages in order to setup the right permissions for editors. There seems to be some solutionsbut I think these won't match for me because I've to think about handling editors and permissions, too. After searching and searching, scratching my head and searching and searching again, the only possibility that comes to my mind is to add another language for German and assign this language to the specific URL's instead of the default language.
      The advantages with this solution for me:
      I could activate or deactivate any language on any page Editors which are allowed to add pages can get the permission page-edit-lang-default without affecting the German pages. The disadvantages:
      All multi-language-fields will have an empty tab for the default language - this may irritate editors a lot Seems to me like a lot of work to do because I've to copy the language field nearly for 1000 pages/repeaters (maybe I'll find an SQL query) My questions:
      How would you handle this task? Could my setup be optimized in a completely different way? If I go for my solution (adding another language for German) would it be possible to hide the language tab for default language in any way?  If some points aren't clear enough please don't hesitate to ask.
      Many greets...
    • By MilenKo
      Hello guys.
      I've decided to get brave and start my first delayed output profile for a remake of my knowledge sharing profile. It went all.good so far but I decided to make it multilingual as to fit the users needs.
      For starters, added a field named: image_single and limited the input to one image as this would be used for the logo. Added.the markup to allow the front end editing (method D or direct edit tag to the <img>. After double clicking on the image, I see the pop-up showing up for a second and then closes. As far as there are no errors in the logs, I am a bit stuck to find the reason. I've read earlier that some users had issues with multilingual fields but could not find anything to point me to the right direction. Any ideas or suggestions?
    • By pwuser1
      Hi people I think I have seen them all but maybe I missed some of the just wanted to know what do you recommend for an editor with JQuery autocompletion or support? 
    • By abdus
      There's native `Fieldset in Tab` for creating editor tabs, but sometimes it could make more sense to put a field that's not directly related to `Content` into `Settings` or `Children` tab (such as for body class or some toggles that I see being used often). You can use the hook below to move fields between the tabs.

      // site/ready.php wire()->addHookAfter('ProcessPageEdit::buildForm', function (HookEvent $e) { // make sure we're editing a page and not a user if ($e->process != 'ProcessPageEdit') return; // RESTRICT BY TEMPLATE // $page = $e->object->getPage(); // if ($page->template != 'home') return; // RESTRICT BY ROLE // $user = $e->user; // if (!$user->hasRole('editor')) return; $form = $e->return; $contentTab = $form->children->get('id=ProcessPageEditContent'); $settingsTab = $form->children->get('id=ProcessPageEditSettings'); // $childrenTab = $form->children->get('id=ProcessPageEditChildren'); // if page template is set noSettings = true, $settings will not exist if (!$settingsTab) return; // MOVE TITLE FIELD TO SETTINGS TAB $title = $contentTab->get('title'); if (!$title) return; $contentTab->remove('title'); $settingsTab->prepend($title); });  
  • Create New...