Category: Toolbars, Quicktags and Smileys

In 2.0 a new email {img src=pics/icons/email.png } syntax was added in quickatgs

{img src=images/code.png}%%% {CODE()} [mailto:text|text] {CODE}

But this prevents the spam protection code from working

Contributors

Contributors

There's a bug with the image icon in the toolbar on IE9 only.
{img id=121}

When we click on it nothing append. The box for the setting doesn’t show up.

The bug seems to have been fixed in tiki 7.x and 8.x but I like to know how cause I need to fixed in tiki 6.3 for a client.

Thanks

The WYSIWYG editor should have a button to create HTML comments that will only be visible in edit mode, and not in read mode.

As with all HTML, the comment tags should not be visible in WYSIWYG mode. The commented text should be a different color; perhaps grayed out.

This feature would enable editing discussion to happen right within the page being edited. Editors could more easily reference the text under discussion, since it would be right next to the comments. Discussing pages separately in the forum would no longer be needed, or would be optional.

Apparently the loadComponent function is not present. I tested ajzxlib->processRequests by changing it to printJavaScript instead of getJavaScript - this had the effect of putting the function loadComponent into the javascript, but it still failed.

Textarea in Trackers checks for quicktags from the "tracker"-category - those are not yet in the db.

Currently quicktags must be defined individually for each different feature. It would be nice if you could define one set of quicktags for multiple features. If you define a good set of quicktags for one feature, say the Wiki, the only way to propagate that set to other features would be to do a manual copy and paste (very time consuming) or modify the database table/s directly (Not easy for the novice user).

Quicktags cannot easily be ordered i.e. the order in which they are displayed to the user. Currently the only way to do it is to prefix each quicktag name with a number to ensure they are sorted in the order in which you want to display them

Make 1.9.11 and 1.10 consistant
Remove less used quicktags and add some in the spirit of ((EditUIRevamp))

This bug is seen by our IE 8 clients. 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.

Our users are editing in the CKEditor WYSIWYG and try the Code plugin from the toolbar. The Code window opens as expected and the users enter their code in the correct field. On pressing Insert (or Replace) the code plugin is added in the editor but there is no contents in the plugin. If I open the normal editor it displays as%%%~np~{code caption="MyCode.java"}~/np~%%% which is completely the wrong syntax.

If I try using the Code option in FF then it opens a new window and I can add the code just fine. I view from the normal editor and it reads%%%~np~{CODE( caption="MyCode.java")}public class MyCode {
//testing a point
}{CODE}~/np~%%% which is correct.

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

Thanks,
Tim

It should be at the very least possible to add content templates where the cursor is, like ((quicktags)).

I would like Tiki to display each item's freetags when display the search results. This would help end-users determine the relevancy of each item.

This bug is seen by our IE 8 clients. 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.

When our users are editing in the CKEditor WYSIWYG and try the File option in the toolbar there is a Javascript error for lib/jquery_tiki/tiki-jquery.js at line 808 char 4. What is happening after the error is thrown is that no new window is opened (as expected) but the File selection fields are now under the WYSIWYG Editor. This wouldnt be an issue, but there is no OK button to select the file so our users can not like to a file in the File Gallery.

If I try using the File option in FF then it opens a new window and I can select the file just fine.

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

Thanks,
Tim

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

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.

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.

Features Classification

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.

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

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~

So after I delete a quicktag, I am sent back to page 1, even if I was working on page 6

OLD DESCRIPTION: When editing a tracker textarea with quicktags enabled, the quicktags field shows quicktags for map-editing.

PROBLEM REPHRASED: All Quicktags are shown, when editing tracker items. You can see that e.g. the IMG-quicktag is there twice.

I tried adding the img quicktag with feature "tracker" to tiki_quicktags, but then it was shown trice (triple? - no!), well, three times! ;)

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.

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!

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]