Category: Usability

It would be nice if there was the ability to have links to attachments easier than having to remember the file name from the attachments screen. It would be nice to get a list of all attachments on the WIKI edit screen and have the ability to click on the attachments to bring in the WIKI markup for the attachment link.

When I edit an older blog post (over 5 years old), the year of the Publish Date gets changed to the oldest year displayed in the year drop down. That happens to be 5 years ago since the Publish date only displays 5 years in the past.

One possible fix would be a checkbox to select whether you want to update the Publish Date at all.

Another fix would be to have the Publish year go back many years in the past. At least 20 as I have blog posts back to 2003!

\\Greg

{syntax type="tiki" editor="plain"}
As the calculated size of the line, depends of the size of the panel (resizable) is wrong (too of some ... <unable to translate, in printing in french the length unit "point">).
Then the line is always too long of a few for the panel (words or half of words cut before splitting the line).

This makes the blog edition unusable in normal conditions because to edit a text we have to make horizontal scroll continuously.

Analysis : the calculation of the length of line written in text editors is always complex. Generally today there is no problem, but the system which is behind editors is very complex to take in account all display configurations.

(nota : For my own I had developed some years ago a draw system - for engineering, Computer Assisted Drawings - system for windows displaying HPGL2 language drawings with fonts conversion from HPGL2 fonts system to True type, then I know well in details the whole problem)

~~#F0C:__With this problem, I can't let use the tikiwiki 5.3 by my bloggers.__~~

So I have written a warning take care "sorry very difficult to use"

{syntax type="tiki" editor="plain"}
In RC2 they made some changes to the edit-help (the now blue circle with a question mark).

When you open up the help and go to full screen mode, the text is un-readable while using the Darkroom theme.

When I edit or create a tracker item (e.g. on the bug tracker) in a popup, and accidentally click on the area of the screen outside of the popup, the popup closes and all my edits are lost. This is a usability problem and all edit popups should be modal imho, especially this one :)

If the width of an edit screen is temporarily increased - which is often very useful - then it underlaps a right hand column (if there is one)

This seems to happen in all edit screens, including this tracker edit screen where this 'wish/bug' is being entered.

I've tried to fix this with some custom css ie adding/increasing a z-index parameter but haven't managed to find a successful fix

fixed in 57795 - thanks Gary

Say I have a tab open to editing page X, and then I close tab X.
the editor does not register that I closed the edit session, so when another user comes along to edit the page, they get a notification that the page is currently being edited, even though its not.

Not sure if this persists, or eventually times out or something, but figured I'd dump the behavior. I'll update if I find out more.

{syntax type="tiki" editor="plain"}
In Opera (no need to mention version number; every Opera user uses the lastest version ;-) ), in the last day or so the edit textareas in branch 6 have been missing or misplaced, for wiki pages and trackers, that I've noticed so far. (Forum post forms are ok.) On the wiki edit page, the edit textarea is far down from the toolbar. Sometimes clicking on fullscreen edit and back again will bring it up to the toolbar. On the dev.t.o bug-submitting tracker form, the textareas for description and solution don't appear at all. I clicked on fullscreen editing and back, and a textarea appeared but it seems to be the solution textarea, not the one for the bug description. This affects the regular wiki editor; I didn't check yet about the wysiwyg editor.

Using strasa.css in demo.t.o/11.x (reproduced else where also)

Log in as admin
Edit a wiki page,
click at a tool in the toolbar (help icon clicked in the screenshot below)
popup box is shown under the text area, no button are shown, most controls are hidden, etc.

See screenshot

{img fileId="288" thumb="y" rel="box[g]"}

Using version 4.3

After insertion of an image using "Insert an Image" Right clicking on the image brings up the context menu and then clicking on "Image Properties" should bring up the original settings menu.

The original settings are not in the window. The window is in fact the window for inserting a new image. Using the window puts in another image.

The only way to change the attribute settings with "Vspace" and "Hspace" or the size of the picture is delete the current picture and put in a new one.

"Insert an Image" is part of the WYSIWYG system.

{syntax type="tiki" editor="plain"}
Define a tracker with a drop down field (called "Location" in this example). Set the list of values so that one or more values have an embedded space like this:{CODE()}
Kitchen,Living Room,Half Bath,Study{CODE}
Now create a tracker item and set the Location field to "Living Room". When you save the item, the Location will be set to "Living Room" when you view the item. But when you edit the item, the Location will be changed to "Study".
The only workaround is to not create drop down values with spaces in them.

Footnotes should be "My footnotes"

Comment should be "Edit Summary"

Since 1.9.6, when I post a new article ("Edit article"; I'm user with admin privileges on that site) I 'm returned to a page saying: "Article not found", and this is the url shown on the browser: http://www.moviments.net/tiki-read_article.php?articleId=

However, the article has been posted successfully .
Hoiwever, users get confused and re-submit the article several times, ... and end up with the idea that Tiki is "kind-of-broken"...

This is the message of the post, in case it matters:

Title:
Nous cursos GRATUÏTS: Wiki i Portals Web col·laboratius (TikiWiki CMS/Groupware)

Author name:
Xavi

Theme:
a theme called "Projecte_cursos", as with earlier tiki versions, working fine that them, associated img, etc.

Type:
Article

text floating around image

no categ selected

Header: (inside code box here on dev.tw.o; without on my site)
{CODE()}
Es torna a fer una nova tongada de cursos __GRATUÏTS__ sobre
* __Redacció col·laborativa__ de documents a través d'Internet emprant __Wikis__, i
* __Administració de portals web dinàmics i col·laboratius__, basats en __TikiWiki CMS/Groupware__, en nivell inicial, intermig i avançat.

Més informació sobre dies i hores a sota (o directament a http://moviments.net/cursos )
{CODE}

Body:
{CODE()}
------------------------------------------------------------------------------------
* Curs de __Wiki__: Redacció col·laborativa de documents per Internet (__nivell I__: iniciació) . DATES:
** 27, 29 de novembre, i 1, 4 i 5 de desembre. 10-13h,
++ ó
** 28, 29, 30 de novembre, i 1, 5 de desembre. 17-20h
------------------------------------------------------------------------------------
* Curs d'__Admin. Tiki CMS/Groupware__: portals web dinàmics i col·laboratius (__nivell I__, iniciació).
** 11, 13, 15, 19 i 21 de desembre. 10-13h
++ó
** 28, 29, 30 de novembre, 1 i 5 de desembre. 10-13h
------------------------------------------------------------------------------------
* Curs d'__Admin. Tiki CMS/Groupware__: portals web dinàmics i col·laboratius (__nivell II__, intermig).
** 11, 13, 15, 19 i 21 de desembre. 10-13h
++ ó
** 11, 13, 15, 19 i 21 de desembre. 17-20h
------------------------------------------------------------------------------------
* Curs d'__Admin. Tiki CMS/Groupware__: portals web dinàmics i col·laboratius (__nivell III__, avançat).
** 27, 29 de novembre, 1, 4 i 5 de desembre. 10-13h
++ ó
** 11, 13, 15, 19 i 21 de desembre. 17-20h
------------------------------------------------------------------------------------

Més informació (i pre-inscripcions, si t'interessa):
http://moviments.net/cursos

Exemple de nous "espais de treball" (nova funcionalitat del Tiki):
http://moviments.net/cursos/ws5

Fins aviat,

Xavier de Pedro
Projecte Cursos,
AlterComs SCCL
{CODE}

When a image or file is edited within a wiki page via Wysiwyg editor, the syntax is not extended into the file attributes.
For example, if you upload a file into a wiki page, and you use the wysiwyg to assign a "border" attribute, or a "popup, enlarges in a popup with zoom option" attribute, while it appears those attributes are being assigned, they are not, they do not populate the syntax for the file or image.

When user have multilingual site enabled and edits a page e.g. in English called Foo and adds an image there using the IMG plugin syntax, then creates translation of the page in another page called Foo2 in the other language and then tries to edit one of the associated pages via the IMG plugin helper icon, it saves nicely but - the page looses the language assigned back to the "Unknown" and that breaks the translation association and it is not possible to set it back because it yells an error that that translation already exists or something like that...

{syntax type="tiki" editor="plain"}
Hello,

If you activate the function "check orthography" in params of a tiki page when editing it, When you save you get systematically the following error :


__!System error.__

Le message d'erreur suivant a été renvoyé :

__Table 'spacprottwk153.babl_words_fr' doesn't exist__

The query was :
select `word` from `babl_words_fr` where `word`=? or `word`=?

Valeurs :

1. Table
2. table

The built query was likely :
select `word` from `babl_words_fr` where `word`='Table' or `word`='table'

Things to check:

1.

Is your database up and running?
2.

Is your database corrupt? Please see how to repair your database
3.

Are your database credentials accurate? (username, database name, etc in db/local.php)
4.

Did you complete the Tiki Installer?

Please see the documentation for more information.

__The database is conform to update from 4.1 and validated__

{syntax type="tiki" editor="plain"}
If you filter on a category field in trackers, you cannot edit any viewed tracker items. The system returns a SQL error because filterfield is set, and filtervalue is null. If you filter on other fields, you can save, with no errors.

I have traced the problem to the calling of trklib->list_items (this holds the query that fails). This function is used to call and order the other tracker items for easy pagination of the filtered tracker items after a save.

However, the real problem is that $_REQUST['filtervalue'] and $tryfiltervalue get lost in tiki-view_tracker_item.php when the save submit action is done on the form. Other URL query parameters appear to be stored as hidden fields on save action in tiki-view_tracker_item.

For whatever reason, non-array filtervalue fields (e.g. plain text fields) are remembered and thus the pagination and call to list_items works just fine.

However, when there is an array filtervalue (like there is with category fields), then filtervalue gets lost on the save action, and the save fails on a malformed query.

{syntax type="tiki" editor="plain"}
After upgrade to 27.5 (I have not observer this in 27.2), edits made to Wiki Plugins on any given Wiki Page cause PHP errors related to missing language definition.
# Assigned language of the Wiki Page is removed (causing a PHP error, and "No language assigned" message)
# Page Description is removed
The above can be reverted using History, but it's practically impossible to edit Plugins without causing data loss (description).
User is forced to manually re-assign language (which fixes PHP errors), and insert new Page Description.
Tested on fresh install of 27.5

PHP errors shown on affected page are related to translated-lang.tpl (missing language)
^<?php echo $_smarty_tpl->getSmarty()->getModifierCallback('escape')($_smarty_tpl->getValue('trads')[0]['langName']);?>
(<?php echo $_smarty_tpl->getSmarty()->getModifierCallback('escape')($_smarty_tpl->getValue('trads')[0]['lang']);?>^

Wysiwyg editor in tiki-editpage.php narrower in IE7 than in other browsers. It is not taking u p the full width of that middle column. This is the case in 3 column layout (did not try in other layouts). This is irritating as it causes toolbar buttons to wrap.

While trying to insert a file or image into a tiki page, the editor user interface will not load that image using "Browse Gallery" when that file is clicked on.
Please see show instance for 19.x and the same issue is present in tiki 20.x

{syntax type="tiki" editor="plain"}
I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

https://github.com/Drive4ik/simple-tab-groups/issues/794

We should consider this for Tiki.

Step #1: Make a list of all features and contexts that have this search as you type feature.

As of 21.x and 22.x the elFinder gallery url's have changed. This has created issues with existing menu items that were pointing to a file gallery. The url's used before would have a trailing /file1 for a gallery.
Now using elFinder their is an extra trailing url attached that looks like this:

/file1#elf_f1_MQ

A show instance will be created, at the show instance you can turn elFinder on and off, and view the gallery url's change.

If you are in a site with some "documentation" activity (a bunch of images already in the default folder), it's not easy for the end user to insert the image he/she has just uploaded to Tiki thorugh the toolbar icons/actions.

With the former file gallery interface to upload a file, you see the thumbnail or icon of the image/file just uploaded, so that it's very easy to find it and click on it to get the corresponding wiki syntax inserted in the text area, so that the file is used within the text.

With elFinder, this simple task becomes difficult, annoying, and time consuming (plus irritating at some times, if you can't seem to find the image you have just uploaded and you KNOW it's there somewhere).

Usual case (can be easily reproduced in doc.t.o):
# Log in doc.t.o
# Edit a documentation page
# Click at the toolbar icon to insert a new image from your local harddisk. elFinder interface is shown.
# Click at the icon to insert the file from your harddisk. Select your file, upload it.
# Once the file has finished uploading, you have no clue where the image is, and it's way more complicated to have your image inserted for you in your wiki page or text area.
** You have to start scrolling and scrolling there in the elFinder window to look for something... I know my image was called (real example from today) "tiki13_tracker_events_00.png".
** I typed "tiki13_tracker_events" in the search box, and nothing was shown (!).
** I typed "tiki13_tracker" in the search box, and nothing was shown (!).
** I typed "tiki13" in the search box, and dozens of images where shown (!!!).

At this time, my annoyance started to increase quite a lot, as you can image...

We need to make the lifer easier for the end user (and for the *.t.o Tiki contributor)

^ Expected behavior with elFinder:
* Once the file has finished uploading, we expected to have elfinder automagically search for that file name ("tiki13_tracker_events_00.png"), and display the end user JUST the icon/thumbnail of that file just uploaded, so that this human being can easily click on it to have it inserted.
^

Thanks for improving this lovely elFinder interface! :-) {sign user="xavi" datetime="2015-01-26T10:13:55+00:00"}

Email notification don't work except if "watch minor" is checked