Option to have dynamic content on nodes

(Steffen Schmidt) #1


thanks for your great work, guys!

I would add a feature request to have dynamic content on a special node. For example I have a page node which only contains a title. Then I have a list of content plugins/extensions (name it whatever you like) like:

  • Text and image combo
  • Button
  • Image gallery
  • Video player
  • etc.

The content editor can choose which plugin he will add to the node so he is able to create individual pages as he like. I do not want to predefine how a page should look like.


(Aaron Russell) #2

Thanks for the suggestion Steffen.

Some of the core ideas in PushType came from an old Mongo-based CMS called Noodall (now abandoned) which had a concept of “Components”. It worked a bit like this:

  • A Component was a class - it could have it’s own custom fields and methods
  • On the node class you could define a number of “slots” in to which components are allowed to be placed
  • When editing a node, the content editor could then chose which components to put it to those slots

Typical components were things like video players, galleries/sliders, contact forms etc.

Is this the kind of thing you mean?

If so, then yes this is something that I’ve considered before. The feature never made it from Noodall in to PushType because the way Noodall implemented it was - to be honest - a bit of a mess. I wanted to avoid just copying what felt like a rough implementation and wait until I’d figured out a cleaner, simple, but powerful way of doing it.

I’d be keen to hear other ideas on this.

(Danny) #3

I do like this idea. Other useful components would be maps, Recaptcha/Captcha and placeholders for ads.

(Steffen Schmidt) #4

Hi Aaron,

it looks like that solution is only half the way I thought. If you look at the django-cms (python-based) there is the following solution which is more flexible then the one I understand from Noodall.

  • Components are own classes which contains of custom fields and methods (like in Noodall)
  • The node class is contains only the very simple fields which are necessary (like page title, slug, position in tree etc.)
  • When you create/edit a node you can add individuals components and with different quantity

Let me make an example for better understanding:

Think of the following simplified components

  • TextImage (WYSIWYG for text and image upload/select from media)
  • Person (first name, last name, profile image)
  • Video (video file, poster, title)
  • Audio (audio file, title)
  • Gallery (multiple image upload/select fields)
  • Maps (lat&long, title)
  • etc.

As a content editor you create three new pages which contains of the following components (added in random order in the admin panel):

Page 1:

  • Text-image
  • Gallery
  • Text-image
  • Maps
  • Person

Page 2:

  • Text-image
  • Video
  • Text-image
  • Maps
  • Text-image
  • Form


  • Text-image
  • Video
  • Video
  • Video
  • Text-image

But important: As a developer I do not want to predefine which components an editor should use and in which order. It should be totally flexible.

For later:

  1. Predefine that special components are only available in predefined nodes (like has_child_nodes for other nodes)
  2. Nested components could be a good thing like an accordion component which contains eg. a text-image and a map

(Danny) #5

That sounds an awful lot like other CMSs which focus on creating a site graphically rather than using code and HTML/CSS/JS. The focus of PushType and why many people prefer PT over other frameworks is the ability to code views and structure content using node classes.

Regarding your dynamic concept, you can achieve the same effect in PushType by creating nodes for Page 1, Page 2 and Page 3. I understand that you want the ability to do this dynamically as you are creating new Page nodes, but that would make the purpose of PushType muddy, making it more and more like the other frameworks.

Each individual page you propose above would have very different styling to accommodate for each component and its metadata (such as image captions, video titles).

I like the basic “Noddall” concept, anything beyond that reminds of back when I used a WordPress site and the Divi theme/framework and its drag and drop page builder to create pages.

I’d be interested to hear @aaron’s take on this.

(Aaron Russell) #6

Thanks @steffenschmidt for clarifying. I’m going to jump straight to the end of your comment as this is an interesting point to discuss:

I sit on the other side of this argument. I think the designers, developers and technical expertise in a project should be predefining and controlling how the website owners and editors use the system. I guess this is a slightly controversial view - it goes against the grain compared to many other CMS’ - but my preference is for the end users to have a very simple UI that allows them to do everything they need to do as easily as possible, and nothing more.

This doesn’t mean PushType can’t be a flexible and powerful CMS that is suitable for complex real world web projects. I agree that the CMS should be as flexible as it can. I just question where the flexibility should sit and who should be responsible for wielding that power. I think that the most flexible (and efficient) way of creating complex content models and relationships is through a programming interface, not a user interface.

There’s another important factor to this argument as well. One of the driving motivations behind PushType is to create a product that is easy for beginners to learn how to use Ruby to build websites. I want people to be experimenting and tinkering with the structure of their site by getting their hands dirty with code.

I mention these things because they’re kind of fundamental to PushType’s identity. Managing the underlying structure and behaviour of the site with code, and a very simple UI is what PushType is all about. That identity and vision helps shape all features and design decisions.


Apologies for getting a bit philosophical on you there. :stuck_out_tongue:

Most of the simplified components you describe above are already achievable with the existing built in field types (especially the StructureField). As @danobot mentions, with creative use of node classes you can probably give end users quite a degree of flexibility. Some kind of component (or whatever we call it) system will come eventually and will probably go some way towards what you’re suggesting, but I wouldn’t favour a major deviation from our current identity so I doubt we’ll go as far as a drag and drop “page builder” type solution.

(Steffen Schmidt) #7

Ok, understood. That’s a position/usp which is totally fine and a good way to go. For the needs of my upcoming project I have to look for another cms. Although I do not think that it is to complex for an editor when it’s a good ui to add multiple components. But anyway.

I will follow your good work to see where it will go cause I think you are on a good way for an extremely usable cms.


(Aaron Russell) #8

I was thinking a little more about your request and I think on reflection there’s actually no reason why something like what you suggest couldn’t happen in the future (in case I made it sound like it was in someway incompatible with the design ethos and vision).

The underlying data model in PushType is infinitely flexible - it’s just a json object - we can stuff whatever we want it to that object and use it how we like. So in theory there’s no reason why someone couldn’t create a PageBuilder field which works exactly how you describe. Imagine setting up a node class something like this:

class Page < PushType::Node

  field :content, :page_builder, structures: [ :hero_panel, :text_block, :author ]


And then how that would work in terms of the admin UI is one for the imagination…

So yes, no reason why that couldn’t happen. We already have the notion of “structures” so this fits fine with PushType’s own way of doing things.

However, this isn’t on the cards so doesn’t really help with your upcoming project :slight_smile: I think to get the UI right for such a field type would be the real challenge. What I’m hoping is that as this community grows people start experimenting with custom fields and developing and sharing their own fields. There’s a lot of potential for really interesting field types over time.

(Wil) #9

This would be something i’d love to see. I’d even be willing to give it a go myself, although i’d probably need some pointers along the way… Do you think this is best as a separate gem that would act as a plugin for push_type ?

SilverStripe is bringing this feature out soon, they have a nice design mockup: https://projects.invisionapp.com/share/K5E3I5IEB#/screens/258639352_Blocks1_-_Page

I’ve previously diy’d these in both SilverStripe and Wordpress using ACF & twig templates(WP) or just the gridfield and a set of templates (silverstripe) . - both quite clunky but users loved them.

(Aaron Russell) #10

If you wanted to have a stab at this I’d be more than happy to help you get up and running. Right now I’d say your best bet is to generate Rails Engine purely for the purposes of creating a new field type. That can be distributed as a gem initially, but it is the sort of thing that could be merged in to the core codebase at some point.

I think the front end javascript code will be the lions share of this work, so baring in mind our discussion in the other thread, it’s worth considering that you might have to redo all the front end stuff when the new admin UI comes along. It depends how keen you are - I’ve barely started with the admin UI, still loads of work to do.

(Steffen Schmidt) #11

Did you make any progress on that or need some logical support where I can help?