Category: Toolbars, Quicktags and Smileys

On ((Add to WishList)), quicktags are missing.

When adding a new quicktag (for inserting YouTube videos) I wasn't able to add it to more than one feature. I.e., after adding it to the forums and then attempting to add it to articles and wikipages, rather than create a new instance, the forums instance would disappear and the new instance would take its place.

When -+vuejs_toolbar_dialogs+- is enabled, the toolbar dialogs produced from a toolbar in a modal (e.g. when editing a tracker item) don't allow any inputs to accept the keyboard focus.

In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.

Wiki syntax parsing for tables is broken

Following two things are supposed to work. These are just copied from the offered quicktags.

||r1c1|r1c2
r2c1|r2c2||

||r1c1|r1c2||r2c1|r2c2||

First one works, but the second ones ends the table at the || and then just prints the text " r2c1|r2c2|| ".

Ok, just saw that Trakcer-Items are Wiki-parsed, too. Good thing! As you can see the effect live! :)

Hmm, everything gets saved, when editing a Tracker except for the feature.... I really have to start working with them.... and search for bugs... sorry for three mails about this, if you are subscribed!

The WYSIWYG doesn't load the bars with size and font into the post (''and several other tools in the toolbar'') .
Please see this short video recording which explains and shows the issue:
[https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view|https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view]

Kind regards
PowerQuest

{syntax type="tiki" editor="plain"}
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

With a simple wiki page that uses the standard wiki editor the drop down menus for font colours and background colours are blank.

Occurs in 12.x at r49095

The editor settings when this occurs are:
Full WYSIWYG editor
BUT Wiki syntax is NOT used
Content is parsed like a wiki page

A show instance has been created which shows this bug/regression

fixed commit id=49334 - thanks jonny

The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.

We miss at least one icon to easily add files to the file gallery and get them inserted in the text area easily with the minimum number of clicks.

In default installs, for usability for new users.

AND we need to respect tiki sites that had those tools ({img src="https://dev.tiki.org/img/icons/file-manager-add.png"}, for instance, which does something like [https://dev.tiki.org/tiki-upload_file.php?galleryId=3&view=browse&filegals_manager=area_51bb470595cd3&insertion_syntax=file]) added in the toolbar. In a site that I upgraded from 10.x to 11.x I had that tool removed, and this other one {img src="https://dev.tiki.org/img/icons/file-manager.png"} (PluginFile) also removed sitewide.

Icons available for assignment to QuickTags are not displayed in the Tiki editor, nor is the path to them. This is a major usability bug for Tiki admins and end users who have no access to the server's file system, particularly because Tiki does not permit assignment of QuickTags without an icon.

I would like to see an option to assign QuickTags without an icon (text title only) plus an interface to display and select icons. (Personal preference: text title only; I am not an icon lover.) Icons already in use should either not be displayed for selection or the fact of already being in use should be clearly indicated.

After upgrade from 4.2 to 5.0 in the administration panel of Toolbars I can not drag-n-drop icons on the toolbar. Changes browsers, computers, don't work.

When I click Insert Object Link, it hangs forever, and PHP lists errors in searchlib-unified.php

Same problem in category admin if you have unified_add_to_categ_search enabled the add objects hangs too {sign user="jonnybradley" datetime="2016-02-01T10:13:11+00:00"}

To insert a special character within tiki-editpage.php in 1.9DR4 you have to use templates/tiki-special_chars.php which cannot be accessed because of .htaccess settings.
a better solution because that little bloody window is a pain anyway (and inserts the characters always in the end of the editing window:

I have done a fix, by including the following lines (see solution) after the table row with the smileys and cutting the link to tiki-special_chars from below the quicktags:

To use the plugin helper, you need to click the (?), and then, click plugin help.

There should be a direct link on the toolbar.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

This feature isn't internationalized.

The usage of quicktags is hardcoded in the PHP, like

$quicktags = $quicktagslib->list_quicktags(0,-1,'taglabel_desc','','trackers');

for the trackers. The french translation e.g. reads

Catégorie : wiki, formulaires, etc.

So a french user would enter "formulaires", but never see his Quicktags in the Trackers feature.

In /lib/toolbars/toolbarslib.php several calls for icon FILES get translated. Why would the file names or paths of icon files be translated?

This is just a (very) minor issue, but unnecessarily inflates language.php in all target languages. Example:

{CODE(Colors="Tiki")}
switch ($tagName) {
case 'bold':
$label = tra('Bold');
$icon = tra('img/icons/text_bold.png');
$iconname = 'bold';
$wysiwyg = 'Bold';
$syntax = '__text__';
break;
{CODE}
With this, a translator could exchange toolbar icons (or their paths) in his/her translation. But what would be the use case for that? 22 icon file names are pumped through tra() in total... Maybe there is some deeper logic, but I don't get it ;-)

{syntax type="tiki" editor="plain"}
Wow, toolbars are seriously messed up ((File a big|here))... what isn't broken in 30.x?

Anyway, on doc.tiki.org and all my v29+ tikis the plugin help has disappeared from the help popup. Here however it has appeared as a separate {icon name=plugin} icon, so presumably whoever broke this hasn't done an upgrade script (that works)

Also no preview on this text area? Wow...

Links added in a certain Tiki instance to that same Tiki instance should be wiki links when the target is a wiki page. If not, they should be relative links as much as possible, rather than absolute links. Using relative links eases domain name changes, and facilitates the management of several environments (for example, synchronizing a production environment with a development environment, like nextdev.tiki.org vs dev.tiki.org).

There may be cases where an absolute link is best, but these should be rare. When a user adds an external link to self with an absolute URL - for example "http://tiki.org/Foo" - which starts with one of the Tiki site root's base URL-s - for example "http://tiki.org/" - Tiki should detect the situation and convert to a relative link - for example "/Foo" - unless the user really wants an absolute URL.

One vector through which URL-s are commonly inserted is the External Link tool in the toolbars of parsed text fields. This tool should be modified to detect attempted insertions of absolute links to self and offer the user conversion to relative.

I imagine there should be an administrative preference to control behavior - either automatically convert to a relative link, or prompt users. Should there be more options?
I believe the default should be to prompt users.

As noted above, quicklinks toolbar does not appear.
follows is convo with mlpvolt regarding issue and attempts to fix:

is this a new install (clean DB?)
> >>
> >> this sounds like a configuration issue - have you defined some
> >> categories (in the admin menu?)
> >> feel free to email me a screenshot.
> >>
> >> Mlpvolt

It is a new install...clean db..
> > I followed the instructions exactly as given for a windows desktop install.
> > Brand new Easy PHP, etc....
> > Yes, I have defined some categories....(8 hours of playing around)
> > Tried themes, changed title bars, etc..

Is there any loss of functionality?
> > can you categorize the page?
> > and this only appears when you edit, right?
> >
> > MLP

Everything else seems to work quite well.
> I can edit the page with code, but no quicklinks..so it's not as easy as it might be.
> and yes, only appears with the edit function.
> I have no idea what's going on and my efforts this morning have just produced more of the same.
> Love tikiwiki and would really like to get this resolved so we can get it up for our group.

OK try deactivating categories in admin>features and see what happens.
> Also try switching themes in admin general. (i don't recognize that theme)
> > MLP

That got rid of the error message and I can live with categories turned off.
Still no quicklinks on the edit page though..
Feels like progress...LOL oh...and I've tried just about every theme and it makes absolutely no difference.
Sid

{syntax type="tiki" editor="plain"}
The tiki normal editor has a problem when a page uses multiple carat elements. It creates unwanted boxes. i.e ~np~10^¹¹~/np~ used twice would create a malformed simplebox breaking the natural math operators into unreadable divisions.

The {img src=images/code.png}%%% {CODE()} ~np~ … ~/np~ {CODE} is not a workaround as this creates an unwanted space after the carat and before the next character. It is also awkward. It also does not allow the natural use of an otherwise perfectly suited math symbol.

~pp~
Tables in form of:

||test|test
test|test||

are not parsed correctly since version 1.9.1. Now ist works only the old syntax:

||test|test||test|test||

~/pp~