html editing in pages using all html tags

[pwired]

Hi,

In the admin back end, is it possible to edit body text in pages with all html tag possibilities ?

If I open the dropdown list in the rich text editor, under Body there is only:

Paragraph-Heading2-Heading3-Heading4-Block Quote-Preformatted.

If I click on the html button in the rich text editor a html source editor opens up but when I want to insert div tags or span tags or center tag or whatever html tag, they all disappear when I click on the update button at the bottom of the html source editor. How can I get full html editing with all html tags on in the rich text editor ?

[iNoize]

Hello,

I think you have misunderstood something. Why you want to place DIV's in there ? 

The TinyMCE is just a WYSIWYG editor and helps you to format the  i say carefully the "TEXT" in the content..

You can customize it to make more but that is not intended to create your html structure.

 

 

Your HTML structure you create in the template PHP files

It's best to reads at times the two tutorials through here.

 

this  one

http://wiki.processwire.com/index.php/Small_Project_Walkthrough

and this immediately afterwards. Is a little more detail but shows you the construction of PW

http://wiki.processwire.com/index.php/Basic_Website_Tutorial

here is a better advice  

http://processwire.com/talk/topic/2850-processwire-for-designers/?p=28027

[pwired]

Your HTML structure you create in the template PHP files

I should not have mentioned the div tag as an example in this context, was just part of trying the html editor.

I don't want to make text formatting part of a template but part of the TinyMCE editor. I only want to format background and foreground color for some text in the body, and centering some words.

I found out in Setup => Fields => Edit Field:body => TinyMCE Advanced Configuration Options => valid_elements

you can add style and center to the following : @[id|class|style|br] and or span[style|color],center,

This allows these html tags to be used and at least now I can use back and foreground color and center some words in the rich text editor using the html button.

Anyone knows a better solution or how to configure TinyMCE in a way to enable formatting only part of a text

a background or foreground color and choosing arial as font or replace it with a plane html editor like in the modx days ? Anyone figured out a working style dropdown added to the button rows ?

[diogo]

I seem to recall that someone mentioned a plugin for that lets you prepare a set of classes in a select that people can assign to parts of text, but I'm on mobile and can't look for it

I seem to recall that someone mentioned a plugin that lets you prepare a set of classes in a select that people can assign to parts of text, but I'm on mobile and can't look for it

[pwired]

Hey thanks diogo, but look what I found after nightly digging the net and processwire:

Go to => Setup => Fields => Edit Field: body => Input => TinyMCE Advanced Configuration Options

Replace what is there in theme_advanced_buttons1

with this:

formatselect,|,fontselect,fontsizeselect,|,bold,italic,underline,strikethrough,justifyleft,justifycenter,justifyright,justifyfull,|,bullist,numlist,|,link,unlink,|,image,|,code,|,fullscreen,|,forecolor,backcolor,|,charmap

Then you can format text in the body with the more usual wanted. (background - foreground color, font, fontsize, special characters, justifycenter, etc. etc.)

[pwired]

Next problem:

When I click on B to format text in Bold, text turns into a grey tone instead of staying black ! (using firefox)

Maybe some css collision somewhere in processwire

Anyway, if I check the html code in the html editor I see that B uses the <strong> and </strong> tags. (outdated anyway)

If I delete the <strong> and </strong> tags and replace them with font-weight:bold; as part of the inline style,

all is well, text is Bold and stays black instead of grey toned.

Anyone knows where to dig TinyMCE to make it use font-weight: bold; when clicking on B ?

[Macrura]

most editors I've ever seen use <strong> for bold and <em> for italics. it's perfectly fine and not outdated at all, in fact these are semantic

http://html5doctor.com/i-b-em-strong-element/

edit: oh and stay away from inline styles if you can.

[pwired]

edit: oh and stay away from inline styles if you can.

Hi Macrura,

What editor do you use in processwire to edit text that is in the body ?

How would you realize in the editor you use for example 10 lines of text where these 10 lines each have black foreground text color, where you also need to set the fontsize and fonttype, and these 10 lines are together inside an orange rectangle background color ?

I use TinyMCE as my editor in processwire and I added div to the valid_elements in TinyMCE advanced configuration, so I could do this in the html source editor in TinyMCE:

<div style="background-color: orange;">

My 10 lines of text with black foreground color.

</div>

This puts my 10  lines of text inside an orange rectangle background, but this also results in my text black foreground color turning mysteriously from black into a grey color and have to resolve this

by using inline style <p style="text-align: center; font: 35pt/6pt Arial, Garamond, Georgia, serif; font-weight: bold; color: #000000;">My text that now stays black</p>

I tried to install the CKEditor and have the same problem, I am sure there must be something wrong.

It seems I can't give my text in body a black foreground color inside an orange box with TinyMCE in a simple way.

[Martijn Geerts]

Be aware of the div element has no special meaning at all. it's just a structural element to group elements that belong to each other.

If those first 10 lines ( I think it's better to have a paragraph ) needs styling, it has a function within the context, say 'intro'. 

Then it's a good thing to have a separate textarea field for that as you know where to place it in the article. There are other meaning full blocks. Say you want to quote, you can use blockquoute etc.  

You can however manipulate the text output with js, textformatter or some custom PHP replace functions. But manipulating the raw text in a wysiwyg editor is a bad idea. If the customers wife really hates orange and tells blue or yellow, you've have to change all pages.

$(function(){

   $(".body p:first").addClass('standout'); // asuming that it's all wrapped in .body

});

.standout {

    do your styles here.

}

[Macrura]

@pwired

you could use hanna codes to create the divs so that there is less potential for editors to screw things up that they can't see.

[[div class=special-class]]

text

[[_div]]

then setup hanna code to take that class variable and make it output in the div element; put all of the styling in your CSS;

if you do need to do this on the fly in the editor, then add div buttons, background color buttons, font selectors etc to your TinyMCE;  I remember in the bad old days of Joomla that the editor had so many buttons that it would sometimes take me a while to find the one i was looking for

[pwired]

With all respect for hanna code and tinymce but I find it a complete lost of time to look for hours and hours on the net to find first the right code blocks and then their formats that you have to enter in:

theme_advanced_buttons1 and valid_elements and Additional TinyMCE Settings,

just to make some simple things work in tinymce. But it doesn't stop there, you still have to hack things in tinymce like using escape codes <p>…</p>  http://processwire.com/talk/topic/4436-tinymce-plugin-addcontent/

Soma's solution to work with html templates still gives me hope:

http://processwire.com/talk/topic/1655-add-bramus-cssextras-plugin-to-tinymce-inputfield/#entry17210

Heck, sometimes I just want to use my own favorite IDE and copy and paste the code directly into the html source editor of tinymce. But you have to think about your clients too, they still need something like tinymce.

Anyway, in the end, too much hassle here too, don't like plugging in scripts and extra tags.

http://www.w3avenue.com/2010/01/04/list-of-free-web-based-html-editors-for-your-cms-project/

I stick with tinymce and the solutions found in this forum.

[ryan]

Part of the goal with rich text editors (and LMLs even more) is to place limitations upon the input in order to maintain quality and consistency. ProcessWire's TinyMCE and CKEditor come configured to focus purely on portable and semantic markup. Once you start introducing non-semantic things in the markup like inline styles, colors, arbitrary font sizes, etc., then your content is no longer semantic or portable. It becomes essentially anchored to your current site design (if you are even that lucky with the client). You'd likely have to go back and make edits to all those fields the next time the site is redesigned. An even bigger problem is that when you give clients the tools to do these kinds of things, they start to get creative and think of it as an art project. But they blame you 1-2 years later when their site no longer looks professional. CMS control of style in text output ensures degradation of consistency and quality of output over time. For these reasons, you usually want to keep your content management tools (and especially rich text editors) focused purely on semantics of content, and as far from style as possible. This is one reason why I think front-end inline editors are a bad practice, as they keep the focus off the semantics of the content and on the subjective aspects of how it fits the area. Let all the style aspects be handled the site designers, in your front-end CSS stylesheets that accompany the site's design.

If you still want to inject style, Hanna code is not a bad way to go because it does at least introduce some separation of concerns. It still leaves the content semantic, even if the underlying Hanna code isn't. 

If the site is for your own use and you are okay with the compromises, then both TinyMCE and CKEditor can be configured to let you do nearly anything you want. I'm not an expert on how to configure them that way, but if you look at the demos at either site, they have "all options enabled" configurations you can see and these configuration options can be duplicated in PW. 

Lastly, a plain textarea field (no rich text editor) on it's own also works well for just regular HTML input. This is what I use when I do need something that lets me copy and paste HTML directly, though it's something I'd only do on a site where I'm the only admin/editor (at least for that particular field). 

[pwired]

Thanks for stepping in on this Ryan.

All the hours I spent looking for Tinymce's code blocks and formats, we'll I can still use that knowledge to change the toolbar of Tinymce. That is handy to know because experienced clients ask for an extended Tinymce toolbar.

Once you start introducing non-semantic things in the markup like inline styles, colors, arbitrary font sizes, etc., then your content is no longer semantic or portable. An even bigger problem is that when you give clients the tools to do these kinds of things, they start to get creative and think of it as an art project. But they blame you 1-2 years later when their site no longer looks professional.

Yes those things are very true and we should not learn them in time the hard way with our clients, but keep our focus on it from the beginning when designing the website. Sometimes we lose focus and "fix" something quick and dirty with the help of the html source editor of tinymce. Bad habit. I think using a css framework also helps to keep design clean and portable like I am playing now with simplegrid but that's another story.

Coming back to the subject, where clients want to edit their own text in their website.

What about clients editing things in their text like :

1. font type 2. font size 3. font color 4. text line background color 5. text block color.

Those edits I think should be done by the client himself in Tinymce, right ? Or should that also be part of the webdesign ? Should clients call and pay you for editing one of those 5 edits ?

If that is so then all that is left for a client is pure text and nothing else. Isn't that just too limited for a client ?

Would it really hurt portability and semantic there ?

Which reminds me that there is also a discussion going on about markdown and textile

http://processwire.com/talk/topic/2303-markdown-textile/#entry49298

Is it really true that markdown and textile are better for a client instead of tinymce ??

Lastly, a plain textarea field (no rich text editor) on it's own also works well for just regular HTML input. This is what I use when I do need something that lets me copy and paste HTML directly, though it's something I'd only do on a site where I'm the only admin/editor (at least for that particular field).

I remember from the old modx evo days you could go inside the modx evo configuration file of tinymce and change it into a plain text / html editor but I don't know where to configure that in processwire.

[pwired]

***

[ryan]

What about clients editing things in their text like :

1. font type 2. font size 3. font color 4. text line background color 5. text block color.

Those edits I think should be done by the client himself in Tinymce, right ? Or should that also be part of the webdesign ? Should clients call and pay you for editing one of those 5 edits ?

These are styles, not semantic elements. Most of the time, these are exactly the things you don't want your client editing. Determining these things is part of the design process and its the designers job to come up with a typographic system that maps styles to these semantic elements. 

If that is so then all that is left for a client is pure text and nothing else. Isn't that just too limited for a client ?

It's not a limitation, but rather a great thing for the client and their content presentation. Here are the things the client should determine:

• paragraphs
• headlines and what level of headline (h2, h3, h4, etc.)
• bulleted lists
• numbered list
• emphasized text (strong, em)
• contextual links
• contextual images, if necessary
• block quotes, if necessary
• possibly others if called for by the content (definition lists, tables, subscript/superscript, etc.)

Note these are all things that say "what" the content is, and not "how it looks". The client should know that when they input content, it will look good and consistent with the overall design system. The designer has already determined the sizes, colors, line heights, etc. for all of these things, and they are defined in the stylesheets. If the site goes through some redesign at some point in the future, all that existing content will be restyled without any edits to the content itself. 

Is it really true that markdown and textile are better for a client instead of tinymce ??

If you can convince them of the benefits and to use it, then yes. It's hard to beat the long term quality and portability of content kept in markdown or textile. However, I think a well configured TinyMCE/CKEditor (configured to focus on content, not style) is preferable to most clients I've dealt with.  

I remember from the old modx evo days you could go inside the modx evo configuration file of tinymce and change it into a plain text / html editor but I don't know where to configure that in processwire.

You can change it to a plain textarea by going to Setup > Fields > body > details > Inputfiled type > select "textarea". 

I'm a little embarrassed to link to this because my website is so old and broken right now, but I think the content is relevant here:

http://www.ryancramer.com/journal/entries/cms-design-longevity/

(keep in mind this is from 5+ years ago, and my site is a bit broken at the moment). 

[pwired]

Thanks Ryan, making these issues more clear to think about for better webdesign.

[Joe]

(...) This is one reason why I think front-end inline editors are a bad practice, as they keep the focus off the semantics of the content (...)

Ryan, as I´m currently struggling to integrate front-end inline editing into my site design, what you are saying is valuable input for me. I agree that it is a good idea to limit clients to creating semantic markup.

For a certain kind of user, namely small web site owners with limited computer skills, it is very appealing to edit things right on the page. And let´s face it, it just does feel more intuitive than having to go to the back-end. So basically look and feel is the reason I want my pages to be editable that way. I would not give clients more editing options in the front end than they have in the back-end.

It is of course the task of the site developer to insure that content can only be added in such a way as to be mobile-compatible for example.

So if used in this way, I don´t think it can be said that front-end inline editors are a bad practice, any more than RTEs in the back-end.

EDIT: I just saw the point you made here:

I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg

...yes, those really seem matters to worry about.

In the headline example: I would make the headline a separate field. If it is just a text field they cannot input line breaks. With other problems I suppose it is either possible to eliminate the option of inputting non-compatible content or filter it out if done and finding an adequate way of letting the client know it´s happening.

As I said above I do think that these issues are all similar as when editing from the back-end. Things come down to making the CMS interface more intuitive for the client, but more work for the developer I guess...;-)

Edited January 9, 2014 by Joe