I know WordPress has never adhered to semver, but that really bothered me.
1 Like
If you’re looking at flat-file CMSs, Grav is an absolute joy to work with.
I’ve been looking at Gatsby for future projects. It uses GraphQL to pull in data, so your “source” content can come from pretty much anywhere. It wouldn’t be too hard to use or build a backend that would fire a webhool on “publish” and trigger a rebuild of a Gatsby site automatically.
2 Likes
I’ve had a look at Gutenberg and I didn’t like the approach in the architecture myself (although the editor app is very nice). The article that ACF and the OP linked to is very good.
I’ve been using ACF (PRO) for a few years. It’s the #1 plugin I install before anything else. I integrate things like the options page and custom fields to affect pieces of information that a client can input into the backend to customise and display information on the frontend.
ACF has supported “flexible content” for a while, and I’ve experimented with it in the past only a small amount. However just recently I did a lot of research into plugins like Divi Builder, Visual Composer and Gutenberg and was really disappointed with them all.
The commercial plugins (Divi Builder and Visual Composer) performed poorly regarding their questionable practices regarding usage of unreadable shortcodes in the post_content field and poor CSS implementation (custom themes have to write lots of CSS with !important and nested #id selectors to overwrite the plugins’ CSS) and Gutenberg doesn’t have a great approach by embedding HTML comments and code in the post_content*.
I’ve been recently experimenting with creating an extensible approach to defining page layouts using ACF’s flexible content field with pre-defined re-usable layout blocks, e.g. text, image, carousel, etc. You can see the current progress of my experimentation, along with an idea of where I want to take it: https://github.com/lvl99/acf-page-builder
The whole point of my experiment is to create a drop-in page builder layout system that works off ACF’s ecosystem of custom fields and inputs. At the moment it relies on ACF’s backend UI to input and customise the layout, but the idea is to abstract some kind of REST API that a frontend client editor app could be built around. I’m hoping that it means that multiple frontend editor apps could be made, depending on features and people’s personal preferences.
I’m really interested in getting other people’s input regarding this small project, as I think it could be a great alternative to something like Gutenberg, changing nothing with how post_content is entered.
(*) Personally I see post_content as a basic textual representation of the post content – think like the plain text/MarkDown version. If a page requires a custom layout, then that custom layout information should be stored in the post’s meta data, and when the_content is rendered that it would serve the post’s content rendered via the page builder. This means there would still be an accessible plain-text version of the page when rendering RSS feeds and/or AJAX/API stuff, or any type of non-presentational situation would occur.
I’ve been experimenting with Grav too.
It’s really nice, but quite young and there are still some rough edges.
There is no way (at present) that it could replace WP for anything other than simple brochure or blog type sites.
Having said that, I am hooked on the simplicity of working with flat files in the filesystem so will be watching closely. Give it another year and it could be a serious contender.
In the meantime, I can’t help but think that Greg Schoppe’s proposed roadmap would be the perfect answer to Gutenberg.
A fork of WP that includes all the Roots posse on the core team would be the best of all possible worlds.
4 Likes
Cross posting:
Matt announced they are gutting React on Guttenberg which looks to be due to the licensing issues:
So he isn’t completely ignoring the community and they are planning on a rewrite of Gutenberg. You got to give him credit for that. So that leaves some hope for a better implementation.
I’m moving away slowly from WordPress and will make room for “JAMstack” https://jamstack.org sites.
It’s solves the biggest rpoblem of wordpress, that for every problem you add a plugin, and for that plugins problems you add another one. If the app doesn’t work or the server CPU is 100% we upscale the server/db instead of fixing the app. Thousands of queries/second for loading same thing for everyone? It makes you think of the environment also.
Anyway, JAMstack in short are static sites (but not those we know from the 90s) with a layer of JS (client apps) for dynamic things or (micro)services.
If anyone is interested, look into Gatsby, Hugo (https://www.staticgen.com for more options), Netlify CMS, prismic.io or contenful (https://headlesscms.org for more headless CMS options - yes static sites use a cms as data input), Snipcart or Shopify buy button for ecommerce.
Server? You get better scalability cheaply, you host it directly on a CDN/ S3 and scale the speed globally with CloudFront. Imagine what servers would cost for such a coverage and maintaining them? Netlify.com is an amazing service/hosting for JAMstack and they have FREE tier for personal and commercial sites.
Security? You can’t hack a basic html,css site 
Updates? It will never break, it can’t really. No need for them.
Backups? Either a headless cms or markdown files that live in a git repo (netlify cms does that really well)
I know it may not be for every project, but there are many solutions already in place.
Roots Combo is still amazing and Trellis is great but it’s overkill for a lot of things today. Just look at how complex the roles are and all the tasks? It’s beautifully made but sometimes we need to take a step back and think if we really need all this? Keeping it simple with basic things and doing them really really good will bring much more value to anyone.
2 Likes
I’ve seen a huge shift from my clients in the last three or so years from “oh, WordPress? Isn’t that bad and cheap?” to “oh thank god you use WordPress! Everyone on our team already knows how to edit that!”
A lot of my clients need to make content changes to their own sites, so a familiar tool is supremely important to us.
4 Likes
Bingo.
Until any other CMS has a plugin library as deep or an editing interface as simple as WP it’s a no-brainer. I’d love to use some fancy static site generator but can’t imagine pitching to a client that we’d need to custom-develop any additional functionality they request, or they have to look at a file system to add/edit content.
1 Like
It’s interesting, because the agency I work with has sort of found the opposite - majority of clients suppose they want to be able to edit their website, but they end up contacting (and paying) agency to make any updates. We use a few key plugins, like ACF and Gravity Forms, but any small functionality beyond what WP core offers and outside of well known and (relatively) stable plugins, we generally build what the client needs. Saying WP has a depth of plugins is true but when so much of it is so poorly coded, it’s hard to use “depth” as a pro, IMO.
I suppose using Bedrock and not allowing plugin installation on production also helps sway that, as it should be. Please don’t experiment with WP plugins on your live site.
To be honest, I’m also looking at what’s available in the static site realm as well. I think for the majority of clients we work with, a static HTML site would be just fine for them. They might have a contact form, and we’d need to figure out something for that, but that’s pretty minor.
Also, it’s important to mention that a “static site” doesn’t necessarily mean it doesn’t change. Prismic for instance has packages that you can use both JS or PHP (and most other major web dev languages) to query the content from them. That means you can have a static site of HTML/CSS/JS and still have it dynamically query Prismic. Still wouldn’t be as fast as a 100% static built HTML site, but still most likely faster than running WP every request and have it build your templates.
You never really know with client’s what their expectations will be when building them a site anyways, even when you cover all that before signing a contract. Some won’t ever touch the site and some will wonder why they can’t completely reconfigure every tiny piece of a site because they used Divi once.
Guess my point is, everyone knows their clients and what may or not be possible, but you also might not have a 100% clear idea of what’s out there, either. And with that being said, I think I’ve steered the topic far enough off topic from Gutenberg that we should return to that topic.
6 Likes
My biggest worry is what will become of Roots if everyone starts moving off onto different platforms?
I was lucky in that I stumbled across Roots when it was just a starter theme and I was new to WordPress. For me, Roots is what makes WordPress ideal for building modern, SEO friendly client sites.
If Gutenberg causes the Roots posse to lose interest in WordPress then that will be the beginning of the end as far as I’m concerned.
I’m more at-ease now that React is out, but prior to the React announcement I was intending to move away from WordPress all together. When contemplating this move it was Roots, project, team and community that I pictured missing the most.
I can’t speak to your concerns but wanted to mention that.
3 Likes
Don’t worry, I sort of doubt this will happen. WordPress isn’t even really part of my daily work anymore, it’s more extra work I do, but I stick around. And Scott hasn’t actually done a WP project in YEARS… if ever… I’d have to ask him again. But he basically started Bedrock and Trellis. So whatever comes of Gutenberg shouldn’t affect Roots much at all.
2 Likes
Yes, the React climbdown makes me feel better too, mostly because it shows that those in charge of the project are taking the community’s concerns seriously, and also respecting the letter of the GPL.
I still have my worries though. I think Greg Schoppe’s alternative roadmap for Gutenberg raised some excellent points, and I’m not happy about the changes to metaboxes, but hey ho.
Well that’s awesome to hear. I feel like I owe all of you guys.
I’ll just keep on buying the t-shirts 
.
5 Likes
I found this linked on Reddit (don’t judge me… okay judge me)
Ultimately I would hope to not have to rewrite this stuff over and over for each block, but this at least gets me started thinking.
1 Like
Maybe this is also the reason for the opposition that Gutenberg faces - as being too WYSIWYG / live, albeit in the admin area.
Yeah exactly, that’s the thing.
The admin area is a punch in the face compared to modern UI and slow like hell, plus there’s a complete lack of live editors or an official builder.
So basically they mixed the whole thing together without a sense instead of:
- adjust the UI of the dashboard and clean it up
- create a standardized builder within the editor
- create a live editor or at least enhance the actual customer, which was close to Shopify
To split it in 3 different concerns is the basic of a project development.
They are creating a monolith with frameworks which work in components.
That’s a whole no sense.
Saying WP has a depth of plugins is true but when so much of it is so poorly coded, it’s hard to use “depth” as a pro, IMO.
Poorly coded plugins for few money is a match.
It’s good to have a wider spectrum of options for people and companies interested in quick and cheap results, beside as developers that’s a torture.
However compared with the real world, you would not always buy the most expensive tool, house and so on. This concept cannot apply in any kind of market and Wordpress is exactly a cheap way to build a website, without know anything of code, design, SEO, etc.
1 Like
I see Matt’s post as a reminder that the Roots community needs to lead by example and contribute the solutions we have here directly to the WordPress codebase.
I’m personally documenting and critiquing Trellis / Bedrock / Sage to the fullest extent I can, to then train about 8 other developers, to then weekly contirbute to the WordPress core so we can move it forward.
I would love to work with this community to get everyone (or as close as is possible) to contribute directly to core but with a unified agenda.
Imagine if we all stood up together, and said “Hey Core team… we are a community of 100 developers who want you to accept our pull request for ONE feature.” and then record that win.
Rinse. Repeat. Over time we earn respect and trust from the leadership as a COMMUNITY. So then we’re permitted to say “Hey Core team… we have TEN pull requests we want you to accept.”
At that point we have momentum and we can have a great influence over it’s future.
While Matt certainly has pull and influence, I think it’s more of an empowering influence then one that actual dictates the communities future - IMO. It is a democracy after all! 
6 Likes
Just a update React will be MIT licenced. I guess Matt’s post was heard and things are shaking up again
2 Likes