Category: Usability

In 1.10, there is a "minor" button when you save a wiki page.

When using the wiki for translation, checking minor tells the system that the corresponding translation are __still valid__.

I believe __minor__ also prevents sending notification emails to those watching the page. (why bug them for a corrected typo?)

After saving the edit to a wiki page you get the usual Success Alert at the top of the page. I think in previous versions this used to disappear after 3~5 seconds. Instead you have to close it manually. I think this item should be timed to disappear after a few seconds.
{file type="gallery" fileId="2137" showicon="y"}

When you try the Slideshow wikiplugin to customize the appearance of the wiki page Slideshow (background image, font color, etc.), it just flashes for a second and then it is being overwritten by the Slideshow default "theme" (vendor/jquery/jquery-s5/images/bg.png) rendering the plugin kind of useless.

Reproduced here: http://luci-199-5148.show.tikiwiki.org/

Just click the Slideshow button on the bottom of the page or go directly to the slideshow:
http://luci-199-5148.show.tikiwiki.org/tiki-slideshow.php?page=HomePage#

{syntax type="tiki" editor="plain"}
Hi,
I found an issue using "wikiplugin_files" plugin.
If You try to use it (on Wiki pages or in other available places like parsable ptracker descriptions etc) Wiki page show files in the particular gallery but You can only download file. You cannot update newer version or see a history of that file althou theres an option to do it.
Ive try it both on TW 2 and TW 3(beta).
Ive tried to turn off/on all java UI thingy but w/o success.

Best regards,
Piotr

In WikiPluginTracker the confirmation message should have an option to send to any URL. That way, insted of having a confirmation message when the user click on send, he is send to another wiki page, etc where you can put the confirmation message you want. Because confirmation message may be more than one sentence, it may be very useful; and it open to the possibility to have another WikiPluginTracker on the second page... So you can have a tracker on multiple page.

__french__
Dans WikiPluginTracker, exemple la fonction qui permet d'afficher un texte comme message de confirmation devrait avoir une option de renvoyer vers une URL. De cette façon, l'utilisateur a plus de latitude sur la forme du message de confirmation. Surtout, il peut étaler un formulaire sur plusieurs pages wiki !

ex.:
TRACKER(trackerId=>4,fields=>13:14:15:16:17:18:19:20,url=>http://www.google.com)}{TRACKER

When you double clic in a text box in a wikiplugintracker, your send to /tiki-editpage.php?page=... This fonction sould be disable in wikiplugintracker.

En remplaçant la fonction qui permet d'afficher un texte lorsque l'utilisateur enregistre le formulaire par un lien vers une page wiki, on aurait plus de lattitude sur la forme du message de remerciement et... en plus, on pourrait répartir les formulaires sur plusieurs pages.

ex.: au lieu d'avoir les wikiplugin comme ceci (avec le texte "Merci de votre contribution" indiqué dans le wiki plugin)
TRACKER(trackerId=>4,fields=>1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20,action=>youpi!)}Merci pour votre contribution !{TRACKER

on aurait ceci :

TRACKER(trackerId=>4,fields=>1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20,action=>youpi!)}NomDeLaPageWikiDeDestination{TRACKER

De cette façon, on peut indiquer le texte dans la page wiki de destination et, alternativement, répartir le formulaire sur plusieurs pages wiki !

Typing a WikiWord does not result in a wiki link. You must enclose the word in (()), even if the feature is turned on.

On a multilingual Tiki 22 with "Prevent special characters in page names" enabled and "Wiki link format" set to relaxed. (multilingual is important factor here, it is because you have many languages with accent or non-latin characters)

This is working ((Tiki and Virtualmin interop))
This is not working ((Tiki, Virtualmin intérop and more and m’ore and זה או זה))
''On dev "Wiki link format" is set to complete" so it is correctly displayed'' ?

{img fileId="1470" thumb="box"}
{img fileId="1471" thumb="box"}

Having a comma or a quote in the title of a page will break future usage of the page name as link. (wiki link)
The user has no warning about this and it gives a very bad user experience.

# Warning on edit/rebname
When renaming or naming (edit) a page the editor should be warned: "you are about to save this name for the page and it contains xxxx those character(s) may forbid..."
# Warning on using wiki link syntax
It should be forbidden (or at least a warning) for an editor to create a wiki link in a page that contain such characters to prevent breakeage and bad user experience.

Once you have selected a language for a page (Editing => Properties or on page creation) other than "unknown" you can’t select back "unknown".

Sometimes it is better to keep a wiki page language as unknown and use the TR tags (plugins) to have a page adapting to different language. Therefor it is important to keep the option to have language=unknown pages.

!!How to reproduce
#Go to the instance
#Login as admin
#Edit the homePage
#Set the properties=>languages to "unknown" save
#Check again it is back to English

#Go to the instance
#Login as admin
#Create a new page
#Keep the properties=>languages to "unknown" save
#Check again language = Unknow.
#Change language to en and save
#Try to change it back to "unknown" and save, it is not possible anymore

I would like to be able to filter searches by Category ''names''. This would improve usability across a Tiki site.

I'm aware that when search filtering by Category, there is a popup on the search page that allows a user to select a Category (or Categories) which will then appear in the Category filter box in a way the search filters can understand. This is handy, but it would be handier to be able to directly type a Category name (or part of a Category name) into the filter box.

The Category selection box also does not help when composing {LIST()} blocks from PluginList with {filter} blocks. At the moment, {filter} blocks must be composed with prior knowledge of the Category ID number. One must use {filter categories="12 AND 38"} instead of, for example, {filter category-names="Czech Novels of the 1900s AND Polish Novels of the 1900s"}. This makes it harder for people to approach writing wiki pages when they want to include lists of objects in Categories.

I imagine a version of this feature would be easy to write for someone familiar with the codebase, because methods for searching by Category ID have already been built and there is already a function get_category_id($name) in lib/categories/categlib.php.

If I want to update an image that's used in a wiki page, or for some other reason find an image in the file galleries when I only know its ID, as in "display290", it would be great to be able to find it by simply searching for the ID number or display code. This doesn't seem to be possible now.

When a fixed-top navbar is used, the page needs top padding of the same height as the navbar to prevent the navbar from obscuring the page content. Also, when an in-page TOC is used, and a link is clicked to go down the page to the relevant heading, the heading will be positioned at the browser window top, and under the navbar, unless there is an offset (such as margin/padding on the target heading).

Currently there is default pagetop padding for layouts using fixed-top navbars, but there isn't a fix yet in the Tiki stylesheets for the TOC problem (the Tiki project sites have a custom CSS rule as a fix). However, the height of the padding may not be right for all sites because the navbar height can vary depending on navbar content, font size, and so on.

Being able to specify the navbar height would ensure having the right px value for the site. (If there is a JavaScript solution instead that could be automatic and solve the problem, that would also be an acceptable solution, as far as I know.)

If you do not load a specific bug tracker (e.g. by a bookmark), but insted start on the search page for bugs and feature requests, the whish list, under

https://dev.tiki.org/Wishlist

you simply get a 503 ("Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.")...

Thanks
hman

I recently wiped my 1.9.7 install of Galaxia and replaced it from today's BRANCH-1.9 distribution. I am noticing that when I create a new process in the Admin Processes screen, it will auto-create the __start__ and __end__ activities in the ''galaxia_activities'' table. This is fine and dandy.

When I go to the Admin Process Activities screen to manipulate and add more activities, the start and end activities do not show up in the Process Activities list. It does report at the top of the screen that there are errors (such as start being interactive but no role assigned, and must use a particular method), but they appear invisible.

I also added a unique activity via this screen that does show up in the database as well, but it isn't showing up on the activity list from the Admin screen.

Interestingly though, I can go to the Monitor Activities screen, and there they are.

This is a significant roadblock to usability. I'll see if I can find what's causing it, but I'm having trouble deciphering a lot of it. Each script farms out to three or four others, which I'm not used to, so by the time I find the statement I'm looking for, I'm 5 scripts deep, and have to go back to get context. Difficult to troubleshoot.

Working with workspaces + permissions comes from the need to protect content from unauthorized access. While this already works great with wiki pages, such confidential content are also files & images uploaded to galleries. However, those aren't created via workspace templates. one has to create and manually assign permissions to them additionally.
Either have them created automatically or have an option to do so if it's not common case to have separate galleries along with separate categories/ permissions.

Recycling the previously mistakingly added item...

Using workspaces, creating a workspace from template and making a structure out of the homepage, workspace is renamed.
After renaming the homepage according to the category/ workspace, you also must adjust the "Namespace" property of the homepage, otherwise pages created off that homepage via the "add page" button (from using structures) will be misnamed with the old name.

When renaming workspaces (& their category), it would be convenient to have that homepage property automatically adjusted to reflect the change.

For creating workspaces via templates, editing the default permissions of the template doesn't list all possible permissions which can be set globally or when editing a created workspace afterwards.
For some cases each workspace has to be edited afterwards to catch those permissions.

with latest cvs updates in our site (1.9.7 -> 1.9.8cvs), and at least when logged in, the module workspace calendar (from ((doc:Mod AulaWiki))) is showing those lines between module "workspace members" and "workspace calendar":

{CODE(wrap=>1)}
Warning: Missing argument 2 for date_format() in /home/httpd/tiki19/lib/tikilib.php on line 6307

Warning: Missing argument 2 for date_format() in /home/httpd/tiki19/lib/tikilib.php on line 6307

Warning: Missing argument 2 for date_format() in /home/httpd/tiki19/lib/tikilib.php on line 6307
{CODE}

Example:
[http://www.moviments.net/cursos/ws100]

And the date in workspace calendar is from 1970, when it used to be the present date.

My users would like a button to turn search highlighting off. Implementation could be as simple as submitting the current URL with the highlighting part stripped off. They would prefer an Ajax implementation but they'll settle for a full page refresh.

1/ Wrong calculation

There is some issue with the the filtering on status (open, pending, close) and the item count.

The average is calculated on the TOTAL of the item in the tracker and not on the total of the item displayed and thats wrong.

Fixed : https://sourceforge.net/p/tikiwiki/code/61412/

2/ Item list fields are not displayed properly.

See instance.

When watching a wiki page, emails send on change contain iso-8859-1 charset in their header, while the body is utf-8 encoded.
The result is that special characters like umlauts are not being displayed properly (without manually setting the character encoding in the mail client).

Detailed error:
In lib/notification/notificationemail.php for function sendWikiEmailNotification(..) exists for sending those notifications. This function then calls tiki_send_admin_mail(..) in lib/mail/maillib.php which then starts a new instance of Zend_Mail. At this point, the Zend_Mail constructor would need to be given the charset or it uses iso-8859-1 as default.
Since the whole procedure of sending the notification seems to be ignoring the charset settings of the general tiki settings, the constructor would need to be given "utf-8".

I guess the error, though, is that character encoding is not set at all during the process. This might have to do with the fact, that wiki notifications are sent another way then i.e. structure notifications. Someone with a clue needs to look into this, though.

On creating a group, group is created but a false error warning is displayed wrongly.

Check adding a group on the instance.

On Safari the error is different:
{CODE()}AJAX: error 0 (rejected) for URL: tiki-ajax_services.php?controller=group&action=new_group&modal=1{CODE}

{syntax type="tiki" editor="plain"}
I the user mail for registration confirmation the german translation for "you or someone registered this email address at" is a uncompleted sentence.

{syntax type="tiki" editor="plain"}
if you enter the <-character in a text (e.g. for an arrow like -->) the following lines have no linebreaks anymore