Content Creation Is About More Than an Editor

Reid Peifer
Reid Peifer

This is a guest post written by Reid Peifer, Partner and Art Director at Modern Tribe. In this post, Peifer shares his experience, opinions, and things to consider as the content creation experience in WordPress is revamped.


Let’s imagine a world where the tools that we have don’t limit us, but instead enable us to create unique, contextual, and thoughtful content. We don’t fight with them, we don’t quibble over line breaks and margins.

We don’t argue about whether or not two images should line up. We’re not limited to bold, italic, underline, and bullet points to express our ideas. We’re not limited to taxonomies for our organization and obtuse relational algorithms to determine complementary content.

This is the reality that we should have. Content management should be more than TinyMCE and meta boxes. While WordPress has continued to grow into a mature platform, the focus on what should be its core mission has taken a second seat.

We (the WordPress community at large) have gotten so excited about making WordPress awesome, we lost sight of our charge – to enable WordPress to make awesome things. To democratize publishing. To get the stories out of people’s heads and hearts and out to the world.

We forgot about content. Without content, WordPress and all its bits and bobs amount to much ado about nothing. While it’s true that WordPress has grown to an almost unimaginable scale, the content it creates today isn’t going to support the needs of tomorrow’s web.

I couldn’t make it to WordCamp US, but I’ll admit that I sat slack-jawed with joy listening to the video calling for a focus on the editor in 2017.

The initial discussions happening on make.wordpress.org and within slack are incredibly encouraging. The community has taken this charge and is moving forward with a passion that reflects the importance of the task at hand.

While I absolutely applaud their effort, and think the conversation thus far has been valuable – it immediately went to the editor itself. What makes a good editor? The discussion is focused on the UI, what format the data should be stored in, should shortcodes be used etc. All good questions, but if we answer them first – we limit the scope of our inquiry.

The first question should be ‘what makes good content’? What is ‘content’? Does content only live on the post or the page? What are its essential elements? How do those elements interact and relate to each other? What’s the life cycle of content? Where and how does it surface throughout the site? Does content behave differently in different scenarios or positions?

If we start with these questions, their answers become our objectives for the UI. The question ‘what makes a good editor’ has a clear answer – one that makes achieving these goals delightful and effortless.

The Need for a More Robust Content Creation Tool Is Not New

Years ago, when ‘magazine layout’ was the new hot thing, we had the privilege of working with some large publications. In our design discovery, we learned how they thought about the presentation of their content, how layouts would change based on the content they were presenting that day.

The rigid templates of the web that we were used to building couldn’t possibly meet the strategy that they had employed for ages in print. The sports, business, and lifestyle sections all needed to be able to leverage different layouts and presentation depending on their immediate needs.

They needed to change day after day. We were going to toss out what we knew about building sites in WordPress. We were going to have to ditch the template hierarchy and start from scratch. The taxonomy term page in the admin wasn’t going to cut it.

Meanwhile, ‘art directed’ or ‘editorial posts’ became a thing. Folks like Jason Santa Maria and Trent Walton were pumping out beautiful, bespoke articles rich in editorial design. I’ve never been more excited about the web’s potential than when I saw those first Jason Santa Maria articles – I’m a sucker for good content design.

At some point shortly thereafter the NY Times published Snowfall, and everyone we talked to needed ‘long form’ (even if they had no idea why or what that could mean). I ran my own experiments trying to recreate that functionality in WordPress – at the time that meant full markup and a reams of custom CSS all cooked into the WYSIWYG. Beautiful output, crappy experience.

These are two really common (and old) examples of how the content needs more than the tool can offer.

We toiled away at these challenges over the years and have solved them for our particular use cases. Every project pushes our own solutions forward. Here’s some of what we learned.

(So we’re all talking in the same terms, below when I reference Content Creation I mean the act of creating a new piece of content. When I reference content management, I mean both the content model, and the organization and presentation of content throughout the site.)

We Should Learn From Modular Development & Atomic Design

We should be applying modular development and atomic design principles to both content creation and content management.

Atomic Design Principle by Brad Frost
Atomic Design Principle as Explained by Brad Frost

We’ve adopted a modular and systematic thinking to our coding practices, breaking once monolithic templates into smaller reusable parts. We’ve applied design systems thinking and atomic approaches to our UI/UX and visual design work.

Small pieces come together to create components, which come together to create pages which come together to create full experiences. It’s the LEGO blocks school of design and build. This is a refrain that many of us know well.

Extending That Philosophy to Content Creation and Management

While we’ve embraced this idea of systemic thinking in how we design and the infrastructure of what we build – we haven’t gotten to thinking about how to approach content creation and content management (content strategy) in a similarly modular fashion.

This is primarily because our tools won’t let us apply modular thinking to content creation and management. CMSs, including WordPress, are generally limited to predefined structures and organizational models.

The role of templating in the overall CMS architecture limits the flexibility of our content creators. Today, content strategy occurs before, and then is at the mercy of development. In a better world, our content strategy could use design and development to grow, adapt, and change over time gracefully. Our publishing tools could become the method by which our ongoing content strategy evolves.

Modular Content Creation

Let’s think about the idea of content on the web. Much of what we see on the web today is a logical baby step forward from print. Titles and headlines, paragraphs of copy, images, pull quotes. Those pieces are a 1:1 analog. Because it’s a digital medium, and we’re oh so clever, we’ve included videos, image galleries, those dang carousels, and whatnots as well.

For most of you, those elements are plopped onto a webpage using a WYSIWYG editor. You fight with TinyMCE for supremacy. Perhaps your theme or plugin has dedicated meta boxes for special elements. There may be a slide show or gallery at the top of the page.

When we look at most executions of content on the web, they are in fact less interesting, less engaging, and less beautiful than what our print counterparts have been doing for ages (and I mean literal ages).

We have all of the advantages but fail at creating anything more interesting than a preformatted spew of content. Our insistence that content and presentation need to be separate is an overstep – they are related at their very core. Was there an earth shattering news story yesterday? Too bad, you get the same 400px featured image slot that every other story gets.

I refuse to believe this is the best we can do.

TinyMCE is not the pinnacle of content creation tools.

The platform that can figure out how to make content creation engaging and powerful is the platform that is going to continue to grow. While Calypso is an interesting engineering feat and is a helpful model for future development, it did little to push forward what it actually means to create content within the WordPress framework.

Trying to fight this out in a single WYSIWYG sucks

Our content creation tools should allow us to approach content creation the same way that we think about design. What are the atomic elements of my content strategy? How can I remix, reassemble, and work with those elements to create interesting content?

It must be systemic. All of the elements and components must work as part of an overall structure and strategy to form a coherent whole. Just like our design work, and our development work. Our strategy, design, and development process is focused on identifying and creating patterns.

Throughout the content strategy and design portion of the project, we’re focused on identifying what those patterns are at their very core; how do we break them down into their smallest parts? Then, through design and development, we start putting those pieces together in a way that supports internal objectives and end-user objectives.

  • Elements – the simplest unit. Strings of text, single images, videos, a form input field or button
  • Components or blocks – groupings of elements that form a cohesive unit
  • Modules – groupings of complementary components to for a larger whole
  • Pages (or posts, or CPTS or whatever) – groupings of modules to form a complete piece of content

To push WordPress’ content creation tools forward, we must look at what those elements, components, and modules could be, how they relate to each other. Are they created on the fly, are they opinionated or flexible. Then how do we create them. How do they relate to themes and data sanctity. And on and on.

Modular Content Management (modular content strategy)

While there are enough visual references to start to imagine what a modular content creation tool looks like, modular content management is a bit tougher to visualize so hang with me.

Within modern CMSs we’ve got a couple of tools at our disposal. Tags and categories, coupled with parent / child relationships, are the primary organization structures cooked into WordPress. Of course those can be extended to include any number of taxonomical structures imaginable.

Tools like Post to Posts (P2P) provide and create an interesting peer-to-peer layer allowing you to create 1:1, 1:many, or many:many relationships.

That’s pretty much it. The mechanics of relationships are defined and subject to code. I can assign content into those defined buckets. I have fixed templates that display those buckets in predetermined ways. If I want to vary from that, if I want to create relationships and remix content as a content manager or a content creator, I’m outta luck.

Think about the category term screen within WordPress. What sort of content management tools do you have at your disposal there? What can you do? What can you manage? Not much at all. Look back over the history of WordPress releases – when has that screen changed?

We are not living up to our potential if we stop at a taxonomical organization as the be-all-end-all of content management.

The Loop is one of the central concepts of WordPress content management. While it is incredibly powerful and key to understanding how to think about your content, it’s the beginning, not the end, of content management. We cannot stop at the ‘list’ as the pinnacle of our content strategy.

Needs Change Over Time

We do a lot of work for universities and schools. Each and every one has a category landing page dedicated to current students. Throughout the year, they want to gather and surface all kinds of different elements, pieces of content, and tools for those students.

In WordPress terms, we’ve got pages, blog posts, events, tools, resources, key dates, applications and files, on top of video galleries and who knows what other CPTs your content strategy has formed.

The needs of those students change through the year – welcome materials in the fall, midterm information in the winter, job support and internship programs in the spring. If our university friends were tied to templates where those needs were articulated in code, they’d need to go back under the hood to update their content strategy and approach it at least quarterly.

Relationships Should Be Richer Than Taxonomy Terms

Real content management would enable content creators to package and present the things they’ve made in thoughtful and unique ways–where the relationships and connections have value beyond each individual piece. Together they become a cohesive whole. That’s a content strategy that’s worth a damn. If you can’t do that, your content strategy is really just a thoughtful list of categories and tags.

Our content management tools should enable and empower you to gather your content and present it how you need to. You shouldn’t be limited solely by lists and algorithms. We want our clients to be able to create unique cross-sections of content where they need, not where they happen to have pre-baked templates that allow them do so.

An example to help visualize: Sticking with our college student, imagine the registrar publishes a deadline for financial aid application. The residential life department has updated forms for getting a spot in the dorms.

The student life department publishes a list of events for new students to meet each other. Each piece of content lives in its own silo in disparate places on the university website. Now imagine you’re in the communications department, and you’ve been charged with ensuring that new students get the information they need.

Do you A: manually type excerpts to those pieces of content in a sidebar widget, hardcode some links trying to apply a specific class that makes the links look like buttons but you can’t remember if it’s .btn_round or .btnround or .round_btn_blue_large, and pray it stays in the same place OR B: create a ‘Key Info for New Students’ module by referencing each piece of content dynamically and dragging it at the top of the homepage displacing the out of date commencement gallery that you forgot to take down last spring?

Old school is option A. New School option B (and it’s not the cool old school, it’s the lame frustrating old school).

The Way Forward Is Modular

If you’re new the concept of atomic design, read this piece by Brad Frost first. If you want to see how we solved some of these problems specifically – there’s a couple of WordPress.TV talks where I harp on this stuff here and here.

We’ve got to strive for more than just an updated WYSIWYG editor. We’ve got to aspire to a bigger and broader understanding of what content is and could be. When we’ve got that vision, we’ll be able to build tools to help realize it.

29 Comments


  1. An exciting post! I was searching for “content blocks” yesterday and now this post covers everything around the idea.

    I think WordPress did a good job on improving the editing content with the editor (from simple text to drag & drop images and preview galleries and embed media). But it’s too far from the true content creation tool.

    Talking about content creation, it’s interesting that the page builder plugins are doing this better than WordPress editor (except they use shortcodes). They provide some kind of content blocks (with configuration) and some basic elements (like rows, columns). Besides, the frontend editing makes them a good tool for this purpose.

    It’s worth noting that there are a lot of intesting ideas in the discussion at make.wordpress.org!

    Report


    1. It’s true that the folks pumping out page builders have done a lot to push this concept forward. We gotta remember though that they have a teeny tiny little user profile to worry about. The folks working on this problem for WordPress at large have a much more daunting task.

      You can see that come into play in how most page builders choose to address the objective.

      If your tool is presenting with you margin and padding inputs in the content creation UI – you’ve already lost. That’s a visual code editor (which serves the user profile that they’re solving for).

      For anyone that built websites in the 90s, going back to a dreamweaver-lite content creation experience is not something I’m too excited to do.

      Report


    2. Page builders are a terrible concept. Content itself should be modular but page builders almost universally just handle presentation and in doing so break the important separation between content and presentation.

      I use my website as a cms to organise and record content and a dashboard to distribute it to a multitude of channels (email, feeds, social media, amp, google, etc. What my content looks like on my website to a human is in many cases irrelevant.

      Report


  2. In the end wordpress is not a CMS. It is some hybrid of a CMS and web page builder, but much closer to the page builders than CMS.

    There is no need to look far to see this. On the post edit page you first have the slug which the page is going to use and only after that the content.

    You can see it also in the automatic way archive pages are generated, zero editorial control over them.

    Unfortunately seems like in 4.8 core will attempt to compete with pure page builders like WIX instead of attempting to get into the big CMS league. From following the discussion, it seems like the focus is on the layout in the front end for the single post, instead of building the blocks and tools to create more interesting aggregations of content.

    IMHO the first step should have been to finish the unfinished business of post formats. I can’t understand how anyone seriously believe that he can design any sort of aggregation of content types when the simpler task of handling just one content type per page is still an unresolved issue.

    Report


  3. Wonderful post, Reid.

    I couldn’t agree more that when the “exciting” developments in WordPress hit the pavement, the narrative trends to the more (geeky) technical aspects of making it exciting again. How people experience content creation and how they expect to manage it (easily) is secondary to how we’ll build it. When in some cases, it should be the opposite, start with the user and work our way backwards through their desired use case.

    The other challenge will be how much of WP can and *should* adopt your new experiences? -When should it be left to 3rd party vendors to develop, like yourself?

    Page builders (of all sorts) are how most people want to experience (and will) experience WordPress. The real disruption will start when core rolls out their builder-like solution to the masses. I think we’ll find page builders staking their claim of users, by tailoring their solution as a new “flavor” of WordPress. i.e. Come experience WP the Beaver Builder way, experience it the Divi way, etc.

    Fragmentation? Yes. I’ll save my “what is WordPress anyway?” for a beer at our next conference :)

    I don’t know about you, but I’m giving up my battle with page builders, creating a new experience for WordPress isn’t something I’m interested in, nor do I have the resources to tackle that head on.

    Content blocks for WordPress? That’s where I’m moving Conductor into for the future. Hyper-focused control on the output of the data you have stored in WP, and attempting to make it easy and compatible, with the builders of the world. We’re even on Github now :)

    https://github.com/sdsweb/conductor

    Report


    1. Love that you’re on github, but isn’t conductor just a very expensive query and view builder? Seems a bit overpriced compared to say Toolset, if all you want to use is views with an easier GUI

      Report


    2. I 100% agree with your thoughts here Matt. As a content creator first and foremost, my own journey reflects the frustration that comes from the dynamic you’ve described.

      In the past, I’d have this grand vision for something I wanted to create and I’d buckle down to work on it within WordPress. Then, before I know it, I’m bogged down in what should be basic formatting. After a short while I’m completely out of creation mode and into tinkering mode, amateur developer mode, and frustration mode.

      Enter page builders. A massive user experience improvement for people who want to create content. And by many accounts a huge pain (or, at the very least, a huge source of annoyance) to others in the community. But that’s a different conversation; one whose complaints (I believe) are being addressed as best and as fast as they can be by the major third parties developing page builders.

      (Full Disclosure: I work for Elegant Themes, creators of Divi, as their content manager.)

      I’m really excited to see what comes out of this next phase of WordPress core development. If they do indeed choose to take a modular approach to content, which I agree with Reid is the way to go, then they will have to address the same issues and concerns lodged against all current page builders while also creating a user experience that can compete. A tall order indeed! But one I’m confident we as a community can achieve.

      Report


  4. Love this post! It is long past time for this to be considered. Thank you for bringing it to the forefront. I’m sure you’ve discussed it in the past, but it’s the first reference I’ve seen go into this much depth in the WP world. Please, WP, consider focusing more on making the content-creation process easy, AND flexible.

    Report


  5. The article is right on regarding the need to step beyond hierarchical taxonomies in organizing content. However it falls short to mention and explore the W3C standards for the Semantic Web, namely XML, RDF, OWL, Linked Data.
    WordPress should strive to integrate both the Web of Documents and the Web of Data paradigms.

    Report


  6. Thanks, Reid. “What is ‘content’?” is a key question to consider as WordPress revamps the editor and customizer, stepping back from the technical issues of TinyMCE, shortcodes, etc., (remember Post Formats?)… The WordPress WYSIWYG experience has been disjointed between the dashboard editor, the customizer, and front-end editing. Now, we are considering a new vision for that experience, but it’s not so clear where it will go and how it might be accomplished.

    In Drupal the answer to your question is obvious: Node. And what’s a node? That depends upon the Content Type. Nodes are as atomic as one can get, though it’s rather abstract semantically, compared to how Brad Frost designates HTML elements as the atoms of web content. With Drupal the followup question is how do we construct content at the next levels for useable blocks? There are many answers, and the pathways become complex design and development projects.

    For WordPress, blocks seem to be the current answer for something less than a post/page, but there’s no consensus yet on what constitutes a block. Blocks are often constructed as a shortcode with page builders, but without clear semantics for that as it’s buried in the actual longcode behind them. The current core-editor discussion explores different directions: whether blocks might be text or paragraphs, plain or formatted, or even if they are HTML-based. Matias Ventura commented in one discussion, “There are tradeoffs depending on where we draw the line regarding what is the minimal unit that we consider to be a block.”

    For a lot of end users content is both the source material they start with—words, images, audio, video, products—and the output on the web that visitors experience. It’s simply their content, while WordPress and the web are just communication mediums that moves content out there. No wonder commercial site builders like Squarespace are popular, as they don’t get in the way, even if they box in the end experience.

    AX ≠ UX. That’s something Rick Yagodich explains in his book Author Experience. Web design has focused on complex and beautiful UX, but the content construction process is secondary, and as Karen McGrane summed it up, “CMS is the enterprise software that UX forgot.” (Content Strategy for Mobile, A Book Apart, 2012)

    You’re right that “to push WordPress’ content creation tools forward” we need to focus on defining the elements, their relationships, and how they work with a new editor along with themes, plugins, and other tools. And as we continue to democratize web publishing, let’s keep the barriers to entry low for authors, editors, content managers, and all the other content creator use cases.

    Report


    1. @david, @reid – Good stuff.

      > let’s keep the barriers to entry low for authors, editors, content managers, and all the other content creator use cases.

      I know it’s complex to keep things simple, and, I actually think the WP core team does an _amazing_ job keeping things simple…for us coders!

      Can’t have it all, I guess, and good to see the content creator getting a moment in the sun (hopefully it persists).

      Excited to see what the next year brings for WP!

      Report


      1. Toby, not so much simple as streamlined by integrating the editor, customizer, and frontend into an improved UX somehow without dumbing things down. WordPress can offer both simplicity and power, and yes content creators want it all.

        Report


  7. A nice hit, thank you for sharing this these ideas.

    When comparing WordPress with Drupal, you will see WP is outperforming Drupal in its easy content creation in posts & pages. I mean a very powerful editor integrated with media library, and a lot of hidden capabilities of its editor (internal linking, spell & grammar checking, embed support, mark down support, etc.). You will really miss them when using Drupal 7 and even Drupal 8. In Drupal you should install and configure a lot of modules (plugins) to prepare an editor friendly environment, so they are planning to enhance their Author Experience (e.g. media initiative).

    BUT …

    When it comes to more complex use cases (e.g. universities, … , web applications = big clients), you will front a lot of shortcomings of WP core and should install and configure a lot of plugins, write a lot of PHP code, or find a developer to solve your problem. I thinks here is the pain point of content management in WP. Drupal is doing this very good, using modules like:
    * CCK (to define fields and custom post types (CPT) in dashboard, no PHP coding. in core since Drupal 7 = Jan. 2011)
    * Views (to define presentation of post types + other lists based on CPTs, relationship between CPTs, arguments, …, to feed content area, blocks (widgets), RSS, etc. It’s a real beast. in core since Drupal 8)
    * Panels / Display Suite (allows you to take full control over how your content is displayed using a drag and drop interface. Arrange your nodes, views, comments, user data etc.)
    * Rules (to define conditionally executed actions based on occurring event = configure workflows = Beast No. 2)

    For a detailed review, see this post (Why Drupal Developers Make x10 More than WordPress Developers, Nov. 2013)

    So I think page builders are hardly part of the solution.

    I think Toolset components (the same guys behind WPML) present good alternatives of Drupal to WP. Although there is no alternative for Drupal Rules yet, and Toolset views is not as mature as Drupal views, but they are addressing the real pain points of WP.

    Report


    1. I agree with what you said. I think this post is pointing WP to Drupal direction.

      Report


  8. the Pressbooks community ( a wordpress plugin for books publishing) we are working on that, allowing a more open system of publishing.
    You can join our discussions

    Report


  9. Interesting post, Reid! I’m incredibly excited about all things happening for the editor in WP core. I agree with a lot of what you wrote about in this post.
    Anywho I am really looking forward to how blocks approach is going to help us improve the WP content writing workflow!

    Report


  10. Hello there, the content are brilliant. I have read in a breath. If you don’t mind, I want to translate some of parts of this post for my Turkish followers on my blog. Thank you…

    Report


  11. Very interesting article and discussion. I use both WP and Drupal for different types of projects.

    I’ve recently discovered the Paragraphs module for Drupal. I have to say that it is a very good step forward in creating structured content:
    https://www.drupal.org/project/paragraphs.

    Instead of putting all their content in one WYSIWYG editor, users can choose on-the-fly between pre-defined Paragraph Types independent from one another.

    Paragraphs can have any number of fields and can be anything you want from a simple text block or image to a complex slideshow or multi columned layout.

    The developer simply sets up the likely paragraph types required by the project. The content creator then chooses the paragraph and enters the content. No worries about formatting, style and layout. These have already been setup by the developer.

    The nearest WP equivalent that I’ve found is ACF’s flexible content field:
    https://www.advancedcustomfields.com/resources/flexible-content/

    Apart from page builders (which I’m learning to dislike) is there anything else similar?

    Report


  12. Maybe the problem is what we believe is a post, maybe a post must be dinamical and what now is a post, must be a component. In that way the formats have trully meaning.

    Report


  13. I’m a book and magazine editor, and when WordPress or any other CMS does (or goes beyond) what the likes of QuarkXpress does for me, on my computer for layout, then I’ll buy in.

    I want to be able to move and manipulate each and every element on the page, text flow from page to page, and drag and drop to my hearts content to create not only rich visual content, but simple, clean, crisp texts.

    Report


  14. Excellent post!

    Coming at this from a more pragmatic perspective (= average user perspective), I still have a hard time grasping what it is that really needs to change (and how it should change), but change it must. Visualizing a modular (and more granular) approach and how that might look in the end is not all that easy.

    All I can say is that over the years, I have found myself increasingly weary of having to divide/sub-divide/categorize my content before it is even written. The strict model behind WP’s post and page creation is one that forces me (in my small world) to, for example, decide if I want to lose an important post in the stream of blog posts or, which is what I have done here or there, turn a post into a page and dock it to the main menu, highlighting it in a sense and pulling it from the stream. That isn’t really necessary as the search function can easily let me find that post, but, in the end, whatever I try always ends up in a print-design approach that has a table of contents and pages/posts that table links to. Not very satisfying.

    I would really love to see a different approach and am looking forward to this type of discussion (hopefully) growing the next couple of months.

    Report


  15. I’m with Alexandra Wolfe. I worked in print publishing for 30 years and still miss the layout flexibility I had with PageMaker. I’ve been on WP for 9 years, doing the best I can, but still I hope …

    Report


    1. But the difference between PageMaker and Indesign was night and day.

      Report


  16. Great post. Found myself nodding along as I read the whole thing. I did the same when I saw your WordCamp presentation.

    It’s been a mad rush to get to the start line these past few weeks. A lot of groundwork had to be laid out. I have a feeling tomorrow the pieces will all be in place.

    Your concerns are duly noted, though I suspect we’re all largely on the same page. We are starting with the block as the smallest unit of content. The block has to scale from phones to desktops. The block has to be pluggable, even added itself by a plugins. Whether the block is a child of TinyMCE, or TinyMCE is a child of the block, that hasn’t been decided yet, because that’s just technology, and what matters is the user experience. We are making a bet on blocks as a way to build rich posts in an effortless way, while seamlessly surfacing the breadth of features WordPress already supports. If we can all together make this building block experience great, imagine what amazing experiences you can create by inserting these componentized little units of design — imagine a dynamic block as a replacement for custom fields!

    In fact, only copyright keeps us from calling these blocks LEGO pieces.

    Reid, it would be so great if you would contribute to this project, in any capacity really. Whether simply in an advisory role, or all the way up to contributing patches and code. Please consider this! We’ll for sure bring up this post in the chat, this Wednesday in #core-editor at 1900 CET! See you there?

    Report


  17. I do so much desire modular content blocks in place of (or as alternative to) the main editor. When I write longform blog posts they are often interspersed with non-text elements, and managing the markup manually for these is tedious. I think modular content blocks would be a big stepping stone for WordPress in continuing the CMS evolution .

    Report


  18. Very interesting article. This is a very reason I shy away from page builders, because I want to impose organized and reusable content…actually have WordPress function as a true CMS. Your article has me thinking about creating modules that reuse that content in more creative ways.

    Report


  19. Hey Reid, great post, this is something we started to think about over a year ago and at that point we didn’t even see Matt’s original comments about ‘content blocks’, we just upped and made somehing!
    We’re in the final stages of getting our take on this whole ‘commodity/content’ blocks thing out for beta very soon and as I read all the comments here I’m reasonably convinced we’ve made a good start…
    If anyone’s interested in having a look and perhaps beta testing/reviewing, please sign up here:
    https://redforge.io and I’ll contact you with more details.
    Thanks
    David

    Report

Comments are closed.