Using Edit+ and HTML frameworks

(Ryan Archer) #1

Hi all,

 

I wanted to put this one up for discussion to get anyone's thoughts on how to use Edit+/EES and a HTML framework such as Twitter Bootstrap harmoniously together.

The issue I am facing is that we built a website using the framework using a series of containers, rows and columns and we need to put on Edit+/EES so that non code savvy peeps can edit the content, but this has ended in shambles as within the content editable area within the Design file - we have got the Twitter Bootstrap framework HTML and then the content that needs to be edited within just the divs with column classes applied.

 

Edit+/EES just opens up the whole lot in the visual editor and when being edited there is a very high chance that the editor will break the Twitter Bootstrap framework code. I considered putting the framework code into the design file and just opening up what is within the column div - but the catch is that I can only choose one content area, so when using multiple columns in Bootsrap I get caught out (unless of course I go with a sidebar layout that allows editing in the section and leaves the 'aside' out of the editable area).

 

Bart suggested that I use custom JS/CSS to abstract the parts that I don't wish to be edited or manage them via metadata http://forums.squizsuite.net/index.php?showtopic=12765&hl=- Customising the JS/CSS will most likely do little for me and the other option provoked this facial expression from me  :blink:

 

If someone has built any websites with a framework and then had to allow Edit+/EES access to editors with little HTML experience (and want to use the WYSIWYG editor), I am interested in how you approached this.

(Nic Hubbard) #2

Put as much of the column and row bootstrap code in the template or Paint Layout. I have done this on many sites.

(Bart Banda) #3

Yea, your content area of the design/paint layout should probably just print all content into a single <col> div. If you need editors to edit HTML outside of this col, in something like an aside, you can let them do this via WYSIWYG metadata fields and print that area specifically in the right place using the paint layout or parse file. But might be able to give better advice if we see the whole structure of the HTML page and what you are trying to achieve.

(Ryan Archer) #4

Sounds like a lot of paint layouts and/or design customisations. The site I was looking to make more "edit friendly' was http://qanzac100.slq.qld.gov.au/

As you can see, the page structure has quite a lot of variations.

 

So I'd have metadata schemas set up on the pages with paint layouts to put in the aside content? Can images be handled by metadata?

(Bart Banda) #5

Ah I see, thanks for clarifying. Yea you can either do it with metadata wysiwygs and lay it out with paint layouts, or alternatively just have wysiwyg content containers with specific classes. Another option is to have those as nested objects and you treat each row as a separate editable asset that you just nest into various positions of the page. 

 

Yes, images can be handled by metadata, as in you can reference images using things like related metadata fields or embed them into metadata wysiwygs.

 

We are planning on making these sorts of page builds more edit-friendly in Edit+ in 5.3  https://squizmap.squiz.net/matrix/2746 

(Ryan Archer) #6

I have another solution that came about when discussing with my colleague. Due to our requirements, the header, sections and asides vary quite alot within this particular website so using design customisations and paint layouts and/or nesting probably just means it gets needlessly complicated - real fast (obviously you may not agree with this sentiment).

 

We just figure to use more bodycopies. and break up the Bootstrap framework code into 'chunks' and set all the bodycopies we don't want edited to Raw HTML type and leave the area we want users/editors to access as a WYSIWYG field.

 

We already have the footer setup in the design asset as it is constant and never changing.

 

Taking it to the next step, within Edit+/EES,  I hope to use CSS to hide the bodycopy edit fields for all of them save the WYSIWYG field that I want to allow editor access, effectively hiding/disabling them from ever being to edit the other bodycopies with Raw HTML in them.

(Ryan Archer) #7

With the advent of Content Container Templates. I think this now becomes a whole lot easier to achieve in Edit+…