Category: Usability

UserPages should be off by default, and activated per relevant profile.


Syntax should become:
{CODE()}User:XYZ{CODE}
instead of
{CODE()}((UserPageXYZ)){CODE}

__Done in new installs of Tiki4 but there is no migration script__


When User pages are activated, they should be much more obvious for users. (ex.: in MyTiki)


Same thing for ((doc:User Trackers))

(This bug has been tested and verified on clean installs of TW 1.10b1 , 1.9.11 and on opensourcecsm.com)

When someone starts to create a new article (submit/edit/new) and chooses a different article type from the menu "Type", the field "Body" disappears (even if the heading_only property of the field is NOT set).

The problem seems only to exist on clean installs with empty databases which fill up the default values with null instead of 'n' for the different type settings.

In turn, the conditional in the function chgArtType() in the file /lib/tiki-js.js does not do a proper checking of the null values creating a situation where it interprets that the heading_only property for all article types is active (or so I gather). Thus it disables the Body field every time regardless of what the property of the article type says.

When clicking a link to answer (re) a comment (at least on blog), the comment section colaps.

Answear a comment on a blog, and all text magically disapair as the comment area colaps.

The new 12x branch option is missing when selecting instance type, to report a bug on show.

When previewing an item, you get:

Notice: Undefined index: calendarId in /home/amette/public_html/tikiwiki-BRANCH-1-9/tiki-calendar.php on line 395

On saving, this comes double (with another line number) and at the first try I got a lot more about "Undefined index: places, people etc"

This is the only wiki site on which I can see this problem... When I look in MyTiki->Modules I can see the login box between "Last changes" and "who's there" on the right column, but there is no box at all visible there. When I log out I can see it again (but I need to log out by editing the url of my browser to point on tiki-logout.php. Is anyone seeing the same behavior on this site or is it just me ? (Might be some personal configuration problems, but I can't track it down).

I changed my CSS to see if it solved anything, but the moreneat, mose and cinq styles behave all the same, I didn't try any others.

Just curious to see if anyone else experiences this odd anomally ...

{syntax type="tiki" editor="plain"}
I just did a test install of Tiki 29.0 beta. I'm not sure what the purpose of the "default password" is. This is shown on two screens near the end of the installation process ("Your default password is iw9z3"), but on the next screen is the form to input the actual new password, which makes no reference to the "default password" which is never used, never appearing on the actual password creation page. I was wondering "What was the point of that?"

If the purpose of the default password is to just be there in case the installation process is interrupted before the admin can set a new password (is this the rationale?), then that should probably be stated on the page where the default password is shown, something like "This is the default password for the admin account of this Tiki website, but in the following step please replace it with a password of your choice. This default password is provided in case the installation and configuration process is interrupted." That's what I can come up with based on my impression - I don't know what the actual purpose of the default password is.

Without an explanation, I think the new user will think the installation process is a bit quirky or broken, not a good first impression.

When reporting that a categ. mandatory field is missing, another mandatory category multiple checkboxes loose their previous selection.

You can try that here:
http://moviments.net/cursos/Inscripcions+2008

Fill all mandatory fields except the last mandatory one. Submit. User gets the message that the last field is missing, which is true, but then, the selections made in the first mandatory field (category multiple check boxes) are lost. So if user only clicks on last missing mandatory field, he gets a message again that the first is missing, but the last is missing again then, etc.





Same behavior when using the tracker directly (instead of tracker plugin)

I am running tw 3.6 LTS in an enterprise environment (PHP 5.3.2, Windows 2003, Apache 2.2.13). We saw this same issue in 3.2 before our LTS upgrade.

We have tried to enable Rating (Polls) by following the instructions at [http://twbasics.keycontent.org/tiki-index.php?page_ref_id=366] and [http://doc.tikiwiki.org/Polls] (Poll templates). I have enabled the Rating, Categories, Poll options in Admin.

After adding the rating option to a wiki page, I save and revisit. I can see the Rating button in the top right corner of the page. When I select it, the button expands as expected into a pane with the options and a vote button, however the page also redirects to tiki-index.php# (my main page).

Why does the Rating button redirect instead of remaining on the page and allowing the user to vote?

It behaves the same in IE6 and FF3.6

---

Can you please retest in currently supported Tiki versions? (e.g. Tiki12, ...). Thanks in advanced! {sign user="xavi" datetime="2014-02-07T09:46:47+00:00"}

Twice now, I have thought there was a Tiki bug because TableSorter decided to hide stuff.

Idea: have a little + where columns are hidden

When adding an URL that is already present in the Directory (not even just in the category), you get a message: "URL already added to the directory. Duplicate site?" - and aren't even allowed to duplicate the site..

# changed my email on tiki.org
# shows correctly here in user preferences on dev.t.o
# when going to Admin > Mail notifications, mail column displayed the old one still and the notifications were sent there

When using articles on a tiki 5 site, using a thenews.css-based theme style, we don't see the horizontal menu at the top bar.
On all the other tiki features, that menu is shown as expected.
You can reproduce that here:
http://intercanvis.net

versus


http://intercanvis.net/articles

When I use trackerfilter with the option sqlsearch in a wiki page to search a tracker it does not work as expected.

On PCs running Windows 7 and Windows 10 respectively. I can reproduce the problem in Tiki14.0 and 14.2 (both with MYSQL). In both versions there is no search box created on the wiki page with trackerfilter to enter the search string.

I have tested on the demo site and the versión 14.x demo site has the same problem.

Versión 12.x on the demo site does give a me a field to enter the search string, however, it appears to only search for the string in the first field and not in both fields.

To reproduce:
I created a Tracker with 2 fields ( "Name" a Text Field and "Description" a TextArea Field).

Then I créated a Wiki page with:
{trackerfilter filters="(1:2)/sqlsearch" displayList="y" noflipflop="y" trackerId="1" fields="1:2"}

In versión 14.x wiki page does not give área to enter search string.
In versión 12.x wiki page gives área to enter search string but search only appears to search first field regardless of field(s) requested. In my example there are two ítems. The word "Green" appears in ITEM1 field 2 and in ITEM2 field 1. If I search for Green only ITEM2 is listed (where Green appears in field1). If I search for "fruit" which appears in field 2 of both ítems there are no records found.
I understood that sqlsearch option should find the search string in any of the fields specified i.e. in my case "green" in field 1 AND/OR field2.

I have listed below:
tracker_1.csv to recreate the simple tracker used
itemId,status,created,lastModif,"Name -- 1","Description -- 2",
1,o,1453722833,1453722833,"Apple","A green or red fruit",
2,o,1453722869,1453722869,"Green","The color of some fruits",

I have uploaded the following images:
tiki14.png a screen shot showing the filter created which has no space to enter data in 14.x
tiki12.png a screen shot showing the filter created which has space to enter data in 12.x
tiki12_incorrect.png a screen shot showing how search does not opérate as I expected in 12.x only Ítem2 is listed and not Item1 despite the search string appearing in field 2 of first Ítem.

So I downloaded and successfully installed the latest version of the 14.x Beta. After that, I locked the installer and attempted to login to my website. While the authentication appears to be working, the site immediately goes to a blank white screen with the URL '/tiki-login.php' still at the end. I can't seem to find the problem that is causing this issue, so it appears to be some sort of bug.

If you have a link in a page to itself, or a semantic alias, the link is in the backlinks.

Is this of any use? Should we get rid of it?

{syntax type="tiki" editor="plain"}
When using an image from File Gallery like ''~np~{img fileId="1" width=300 align="center"}~/np~'' Img plugin renders the image properly, but using ''~np~{img fileId="1" width=30% align="center"}~/np~'' it breaks the layout, image is left-aligned and distorted.

Wiki "((doc:edit by section))": Nice feature added, thanks heaps to those who made that possible! :-)

BTW, I found that it doesn't allow concurrent edition of different wiki sections of the same wiki page.
Tried on doc.tw.o on June 8th 2008, using Mittwoch and also Tikinewt.css (After clearing tiki cache) , and it didn't work for me on any of both cases.

doc.tw.o page needs to be updated once fixed.
http://doc.tikiwiki.org/edit+by+section

See yourself by creating a structure and making a page with {toc} in the source code. That creates a Table of Contents of the structure. This table of contents isn't considered by the Wiki 3D browser. So you are forced to enter links manually to be able to browse the structure with the Java Applet.

2022-10-17: I (marclaporte) added PluginCode on examples below because it causes issues on index rebuild.

When using Wiki argument variables within a Wiki plugin, the combination of the curly braces and the quotation mark (e.g. {{itemId}__}"__)prematurely ends the plugin's options syntax.

Example:
{CODE()}
||__Plugin__|TrackerFilter
__Plugin Field__|url
__Field Value__|"Edit+Compound&itemId={{itemId}}"||
{CODE}

The following is an example of what I can see when editing the text of a wiki page:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}"} ~/pp~ ||
{CODE}

This is what should be shown:
{CODE()}
||~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"} ~/pp~||
{CODE}

If you keep on editing the plugin using the edit icon and saving without making any changes, it will keep adding on any options that proceed the argument variable, like thus:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}" silent="y"}}"} ~/pp~ ||
{CODE}

See screeshot

The functionality to allow comments in wiki pages on a 'per page' basis that was in Tiki 6 has been moved from Wiki admin to Comments admin and is therefore less visible

It should be replicated in Wiki admin as well to make it more visible


Fixed r48529

{syntax type="tiki" editor="plain"}
The plugin section of the wiki help is listing the plugins aplhabetically based on their english name. When it is translated to another language the sorting remains based on the english name, it is quite confusing and looks a bit chaotic in other languages in my opinion. Is there a specific reason why the code here is written this way? If not, can this be fixed for Tiki 4? I dont know how to do it but would appreciate it :)

The UI of the Wiki History needs some more love... See the screenshot:
{img fileId="1230" thumb="box"}

After ((rev:67935)):
{img fileId="1232" thumb="box"}

As of r68335:
# The language dropdown remains squeezed.
# When the Advanced/Simple button has focus, the text/background contrast is insufficient (in the theme on dev.tiki.org).
# --The "rows per page" text input field lacks Bootstrap classes it seems-- Should not be an issue as of r68348.

{syntax type="tiki" editor="plain"}
We installed Tiki with version 1.9 and we quickly installed the PluginInclude and starting making extensive use of it. This week, we upgraded to 2.2 and some of the includes stopped working.

After some trial and error, it appears to be the 3rd to 4th include on a page (all pages have the same permissions via categories) that fails. It works for admin, but not the average user.

I took a look at the plugin and found the line

// $text="<b>User $user has no permission to access $page</b><br />";

and uncommented it. The user received the message that they did not have permission.