Loading...
 
Skip to main content

WYSIWYG Acting Strange

Status
Closed
Subject
WYSIWYG Acting Strange
Version
12.x
Category
  • Error
Feature
WYSIWYG (What You See is What You Get)
Resolution status
New
Submitted by
jcarter
Lastmod by
jcarter
Rating
(0)
Description

--I was originally having a smaller wysiwyg bug on my tiki 12 instance, but I'm not sure what is going on with it anymore after testing with a fresh instance.

On the current instance created for this ticket, the formatting bars (Format, styles, font, size, etc) are not showing up for WYSIWYG, and going to the toolbar admin and changing things doesn't change the toolbars for the WYSIWYG, but changing things for "Wiki only" added them to the WYSIWYG too.

It seems to be acting really weird, and "link" and "unlink" show up when you go to the editor toolbar admin, but don't show up in the editor (feature is enabled).

user: admin
password: 12345

update: looks like maybe WYSIWYG only shows the "visual wiki" toolbar, but I'm not too familiar with how that works. Hopefully this is user error, but I've customized editor toolbars in tiki wiki before, and this seems to be working strangely.--

Here is a more concise explanation of what is going on. Ignore Above


Turns out it was in fact mostly user error + confusingness, though there is a bug.

bug:
Setting the toolbar selection mode to "WYSIWYG Only", and then adding an icon to the toolbar adds the icon for all editors instead of just WYSIWYG. This is present in tiki 11 also, but I can't seem to destroy the instance and test other versions (tried from multiple browsers).

Possible bug:
"Link" icon tiki WYSIWYG does not set link element class to "wiki" by default, resulting in possible css/styling inconsistencies. Links created with square bracket tiki syntax always have class="wiki external". I think that links from both should be generated with same class so css can apply to both without having to set css for all anchors just to cover links generated by "Link" (but I'm not a CSS guru, so I don't really know css best practices. Seems inconsistent though).

Discussion/What I thought was a bug:

I had previously talked about the lack of formatting bars (Format, styles, font, size, etc) in wysiwyg being a bug, but this is not really bug. In tiki 12, the "Use Wiki syntax in WYSIWYG" perference's description says "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools", which would make it so that only the visual wiki toolbar shows up when you are in the wysiwyg editor, and you don't get any WYSIWYG toolbar icons (as I understand it).

When you enable WYSIWYG, the "Use Wiki syntax in WYSIWYG" preference is enabled along with it by default, meaning that by default WYSIWYG does not actually have any WYSIWYG toolbar functionality, and is really tiki toolbar icons with a wysiwyg text interface.

The reason I thought this was a bug was because I did not understand the implications of "Use Wiki syntax in WYSIWYG", and in tiki 11.0, with "Use Wiki syntax in WYSIWYG" enabled, the toolbars were still usable. The description still stated "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools" however, suggesting that perhaps in tiki 11.0, the fact that the formatting bars still worked was itself a bug. However, if that can happen through a bug maybe that is something that should happen intentionally? Seems like a big loss that if you enable "Use Wiki syntax in WYSIWYG" you lose the entire WYSWIWYG toolbar, and you don't get a hybrid toolbar. Anyway, just throwing that out there/explaining confusion.

Importance
9
Easy to solve?
6
Priority
54
Demonstrate Bug on Tiki 19+
Demonstrate Bug (older Tiki versions)
Ticket ID
4834
Created
Thursday 31 October, 2013 20:37:40 UTC
by jcarter
LastModif
Wednesday 08 January, 2014 16:40:02 UTC


Show PHP error messages