HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

WYSIWYG messing up formatting

Login / Search

 [ Join | More ]
 Add topic 
#102032 (In Topic #20005)



I created a test Wiki page this afternoon in order to try to track down problems I've started having with another one. My wiki.css is set up to produce Mediawiki lookalike pages, and creates them just as intended in WYSIWYG mode, provided that I create them at Administrator level - i.e. such that the HTML isn't all converted to Comcode. My previously page started messing up when I edited it as a sub-admin - the output of Comcode codeboxes within the page displayed in its parsed rather than human readable form, and despite trying to apply semihtml and semihtml + comcode HTML tags, I haven't managed to restore the original output.

Since it's par-for-the-course that Wiki pages are end-user editable, I created the new test page at sub-admin level, entirely in WYSIWYG mode with only a Table of Contents as a Comcode feature. The page was created using editor-resident formatted headings and Normal paragraph blocks.The initially saved page was mostly OK, apart from two issues - the TOC's listed items displaying at different font-sizes (h2 li smaller than h3), and three or four lines of whitespace interposed between each block of paragraph text and the heading following it.

To investigate, I re-opened the page in the editor in WYSIWYG mode, to find that all the blocks I'd created had been removed (i.e. all "p" tags stripped), and in place of them whitespace inserted as displayed in the page's output. Without editing the page I saved it again, now to find  my headings  partly overlapping the first line of paragraph text beneath them. (The headings, btw, are styled with a visible border-bottom that has become almost completely obscured.) This screenshot shows the page's current state:

My concern at this stage of developing my site is with understanding how to prevent these unintended effects, as opposed to how to rectify them. What measures need to be taken before initially saving new Wiki pages, such that end-users can safely edit them?

I'm also deeply curious to understand why it's seemingly necessary for the editor to strip "p" tags/blocks from markup code. Paragraph text is surely the most basic and essential element of web pages, and the element that most needs to be easily modified by their author in order to address accessibility issues (you'll notice, for example, that my page's paragraph text is undersized) without hand-coding every single instance of it. And there's no way I could find the time for that and stay online interactively with site visitors! 

Thanks for reading!
Back to the top

If you have turned on Comcode conversion, or have not granted HTML permission to members, then exact HTML will not be preserved.

Comcode is a simple text based language, a long way away from being a superset of HTML.

Become a fan of Composr on Facebook or add me as a friend. Add me on on Twitter. Support me on Patreon
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about Composr whenever you see the opportunity or support me on Patreon.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying Composr on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top


Thanks Chris!
I just checked up on my "Convert XHTML to Comcode" option and it's disabled, as it always has been. In the last couple of days - in the light of your words concerning Search highlighting -I've also granted the "more liberal HTML filter" privilege to sub Admin usergroups that will have use of the CEDI system, so I presume that henceforth there won't be any disparity between the way the editor handles their input and admins' input. If so, another problem solved!

I do fully grasp your remark about what Comcode is and isn't! And coming to grips with it hasn't yet posed any difficulty for me - thanks for the plentiful tutorial info you've made available. It's the editor, rather, and its actions on input (including Comcode objects) that I'm really groping around over at this point. Optimistically I'll soon enough learn what results to expect and what's needed to control its standard behaviour as desired, but for that I need to do a fair amount of trial-and-error test-driving - just like everybody else, of course.

Best regards,


Back to the top
There are too many online users to list.
Control functions:

Quick reply   Contract

Your name:
Your message: