Category: Usability

{syntax type="tiki" editor="plain"}
Because if you are good in English, it's not immediately obvious what is translated vs needs to be translated.

Any unstranslated string should be seen in a fraction of a second

This is a feature request for trunk
Edit: {sign user="Bsfez" datetime="2017-03-09T10:08:17+00:00"}
To activate the interactive translation : Admin -> i18n -> enable Multilingual, enable Use database for translation.

In the admin menu: Edit Language -> Toggle interactive translation ON.
Go to a page, at the top of the display you’ll have a switch to turn to start translation.

When you are on a modal (like when you "Save and Comment" a trackeritem in this tracker) you still can use the "Help" button of the toolbar.
It usually open a modal with help for Wiki Syntax and Plugins but in that case, you are already IN a modal and using it will close all modal and all your previous work is lost.

It is not possible to open a modal from a modal in Tiki (I most case if not all) therefor the action shouldn't be possible and so it shouldn't be allowed and lead to lost of data.

When "jQuery Select2 Select Boxes" _placeholder and _firstlabel are lost.
This is pretty bad when you create display in a modern way without wasting space for a label outside the field to be filled.
It displays instead "Select an Option".

-+{select _field="tracker_field_something" _trackerId="10" _firstlabel="pick somethingt" class="form-control"}+-

{img fileId="1783" thumb="box"}
{img fileId="1784" thumb="box"}

As you can see on the video the href action is available on the entire row where the tikihelp button is placed.

It should be limited to the button area.

It may be not limited to the switch user module but elsewhere.

{mediaplayer src="display2120"}

I posted this on the Features/Usability forum pn tw.o, but it seems to be coming down to a bug or a setting.

We've been wrestling with Internal Server Error 500 for several months. We are transferring the content of a static HTML site to a TW site.

At first, we thought it had to do with the length of documents or reserved words or special characters. All of that may still be true, but what I find after exploring the Web a little is that it has to do with script failure. Apache thinks something is screwy in the content being fed to it.

Most recently, I tried to get the TW sql module to work. I set up the DSN per the instructions on doc.tw.o , assigned permissions to a group,then created a test page. I inserted one line,

OPEN CURLY BRACE SQL CLOSE CURLY BRACE (db=>memberlist) SE (NO SPACE)LECT count(*) FROM members OPEN CURLY BRACE SQL CLOSE CURLY BRACE,

then hit Preview and got Error 500 immediately. (Obviously, I've substituted words for characters like the curly brace and space. I did that so I wouldn't get Error 500 when I up load this message. And, yes, I know "up load" is one word, but if I use one word, it is likely to fail.)

We have previously gotten the Error 500 message when words like 'up load' and 'se lect' (as noted above) were in the text of the page. When those words are removed or altered, the page up loads.

It tends to happen more often when pages are long (that may be psychological. You remember the BIG failures.) which, of course, just means the odds are greater that a reserved word is used, if that's the case.

When I tried to up load the above example to tw.o, it failed three times until I had all the curly braces and suspect words broken up. I know others are having this same issue. Here's chibaguy from tw.o on his experience up loading in response to my message. (I've edited for brevity)
---------------------
chibaguy on Fri 16 Nov, 2007 08:08 CET

I tried once to reply to your post and got the 500 error when I had "se lect" in the text (with no space), and then the submit went smoothly when the space was added. A few minutes later I submitted that test post, with "se lect" intact and it also went fine. Meanwhile I found 469 instances of the word at this site, including in wiki pages and forum posts, so obviously a lot of the time having "reserved words" in posts doesn't stop the submit.
...
I've also gotten the 500 error here trying to submit a post, once in a while, but waited a little while and then could submit exactly the same post with no error.
...
I rarely get the error at other Tiki sites I use pretty intensively, but am not sure if my pattern of use just avoids the pitfalls.

-- Gary
------------------------

ricks99 on tw.o leapt on the cut and paste scenario, offering that it might be a text encoding conflict. I've had it fail, as above, with directly entered content as well as pasted content. I'm on a Mac and our host is using *nix.

Note that I'm not saying some text encoding issue isn't a part of it. In fact, I kind of suspect there is more than one culprit.

When I get one of these errors, I start reducing the up load by halves, previwing a portion at a time, until I get failure. Once I get failure, I always get failure.

We've up loaded (copy/paste) pages of documents in which one line would cause the failure. Removing the one line makes it OK. Taking the suspect portion and the remaining text and putting it into a comment page works, too.

My suspicion is that there may be a combination of "suspect" words that crosses a threshold and drops the error message on us. Maybe there's a setup issue?

I'd really like to use the SQL plugin. It would solve several problems for us. Thanks,

Bill

------

This is the third in a series of "HOW DOES IT WORK" articles describing the various systems of the TD Vixens. The first two described the engine cooling and coach heating systems. This article will describe the engine fuel system.

By Tom Picking
ENGINE FUEL & ELECTRICAL

When I first got my Vixen it was hard to start. The problem got worse until I was afraid to go anywhere. I spent several weeks studying the system and talking to other owners about what might be wrong. I tried many "fixes" hoping they would solve the problem but nothing helped. I learned a lot about the system over those weeks with the help of several people and only after fully understanding "HOW IT WORKS" was I able to find and correct the problem. VIN 0050 is stock with 110,000 miles and starts easily even after being idle for weeks. Yours should, too!

The BMW engine's Bosch fuel injection pump, in my opinion, is a work of art! It is completely mechanical using no electricity (except for the fuel shut off valve) or electronics. It is a very complex system and adjustment or repair of the fuel injection pump should be left to professionals. But if we understand howthe total system works, we should be able to determine if the problem is in the pump or some other component of the system that we can fix ourselves.

In order for a diesel engine to start and run it needs three things: Air, fuel, and heat. It is also very important to make sure that no air can mix with the fuel until the fuel gets into the combustion chamber.
AIR AND HEAT

When the starter cranks the engine, air is sucked in and compressed by the pistons. When air is compressed, it gets very hot, hot enough to ignite fuel if it is present. On very cold days the engine and the air being drawn in are much colder making it difficult for the air to reach the temperature required for ignition. This is where glow plugs come in. They are actually small electrical heaters inside each combustion chamber. They look something like a spark "plug" and when turned on they get so hot they actually "glow". The glow plugs only come on during the initial start up sequence and the amount of time you should wait before trying to start the engine is determined by the engine electronics based on the temperature of the engine. Maximum ON time is about 15 seconds. The "WAIT TO START" light on the dash indicates the glow plugs are being commanded on and the engine should not be cranked till they have had a chance to do their job. If the glow plugs are not working, the engine will still start (except on very cold days) but only with increased cranking times.
AIR AND FUEL

Air in the fuel before it is injected into the engine is a bad thing. The injector pump must be able to develop very high pressure in order to force the fuel into the combustion chamber and if air is mixed with the fuel, this high pressure cannot be achieved.

The injector pump is actually two pumps in one. The first is a low pressure priming pump that floods the primarypump chamber. Any air in this chamber is forced out of a drain line at the top of the chamber along with excess fuel flow from the priming pump. This drainline is common with the drain lines connected to the injectors in each cylinder. If any of these lines leak while the engine is off air will enter the system and fuel will drain backward through the fuel line and empty the primary chamber of the injector pump. The result is hard starting (delayed while the priming pump is filling the primary chamber) but otherwise a normal-running engine.

If there is a leak in the fuel line or the fuel filter between the injector pump and the fuel tank, air will be drawn in by the suction of the injector pump and, depending on the amount of air, the engine may start but will not run correctly under load or high speed. As reported by Charles Rausch (TD 0106) in December's issue of Fox Prints, this same symptom can be experienced if there is a severe restriction in the fuel line such as a clogged fuel filter or a clogged fuel tank filler cap air breather vent.

You can inspect the fuel entering the pump by checking the clear (after 12 years mine is yellow) plastic line connecting the fuel filter and the pump. If you see bubbles in this line while the engine is running or cranking there is a fuel line problem. If you see a large bubble in the line after the engine has been off for several minutes, this is an indication of a drain line problem and that fuel is draining backwards through the fuel line to the tank. If you tap the line, with an indication of air in it, you can watch which side the air bubbles up. That will cut the investigation in half.

Between the tank and the injector pump is a fuel filter. The stock filter has a special manual priming pump built into the head of the filter. Turning the selector head of the filter pump to "RUN" bypasses the internal check valve and makes it easier for the engine injector pump to draw fuel. Turning the head of the filter pump to "PUMP" allows manual operation. The engine will run just fine with the filter pump selected to either position if all the rest of the system is in good condition. Diesel fuel is notorious for dirt and water. The fuel filter is your protection against dirty fuel.

After I learned all of the above, my Vixen still would not start! The problem was that it was not getting fuel because of an electrical problem!

The ignition switch mounted on the steering column (a standard GM part) has several electrical contacts that perform various functions depending on the position of the key in the ignition. One of the functions is to energize the fuel shutoff solenoid valve that allows the flow of fuel to the injector pump. One of the first things I did was to check the voltage to the solenoid valve with the key in the ON position, it was OK. What I didn't realize until several weeks later is that a different set of contacts energize this valve when the key is in the START position. These contacts were defective and when the key was in START and the engine was cranking, the solenoid valve was off and no fuel was available!!!!! This condition can be measured with a voltmeter which eliminates the guess work. A new ignition switch solved the problem.

{syntax type="tiki" editor="plain"}
I have several tikiwikis (v 3.0 beta 4) on the same domain. Both behind the same .htaccess protected directory. The goal was to setup a working instance of InterTiki between these two Tiki's.

By way of example
* Apache .htaccess limit: http://www.mydomain.com/p/
* Master e.g. http://www.mydomain.com/p/master
* Client e.g. http://www.mydomain.com/p/client

__BACKGROUND__
A few setup issues have been noted (these details have now been added to the InterTiki documentation). Most notably is correctly specifying the location of "/remote.php" for the above case. For our above example to following is req'd:
* host: http://www.mydomain.com
* path: /p/master/remote.php

On the master, I have successfully made contact using either the IP shown in the Apache logs, or by simply using "127.0.0.1" in this case.

Likewise (also added to InterTiki docs) there was some oddity related to order of events with how the server info was being plugged into MySQL tiki_preferences interlist table. I have not properly tracked this down so will not go into it further at this time.

Also of note (for another bug or support request) is that I am unable to get InterTiki on the master to log out anything.

__BUG/FEATURE REQUEST__
''Note: InterTiki operates as designed and is simply unable to get behind an Apache Basic Auth wall. However, hard-coding in setCredentials line for the XML_RPC_Client should work in this case but does not.''

After getting setup dialed in like above, the client received the following message:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 401 Authorization Required)''

Some digging into /lib/userlib.php finds the calls for setting up the XML_RPC_Client at lines (around) 228, 2812, 2831, 2860 and 2905. Looking into the XML_RPC_Client class in /lib/pear/xml/rpc.php shows that there exists a setCredentials($username, $password) method. The setCredentials method exists to allow for RPC calls to get through Basic Apache Authentication.

__Possible Bug__
I went ahead and modified the clients (and eventually the master's) /lib/userlib.php in the above locations with a simple addition of:
$client->setCredentials("myApacheUsername", "myPassword");

This time, when logging in from the client, the response was:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 302 Moved Temporarily)''

And with that I am stuck. It seems like (as a workaround hack for the time being) the ability is there in the XML_RPC_Client methods to get through an Apache Basic Auth, but the return code is weird at best.

__Possible Actions__
#Ignore -- Explicity note that InterTiki masters/clients must not exist behind Basic Auth walls.
#Investigate why a hacked userlib.php returns a 302 code and determine if this is as designed or a bug.
#Possibly add a basic username/password entry field in the client administration page for driving the setCredentials method.

This may or may not be considered an error, but is not-as-expected behavior.

!!Problem
When setting up InterTiki, one would assume that 127.0.0.1 would work as an IP filter for localhost. However, it was pretty clear that this was not working in 3.0 (beta 3, beta 4, rc1)

!!Regression
* Turned on the XMLRPC debugger in /lib/userlib.php around line 2817 ''$client->setDebug(1);'' to look at the response back from the server and do a bunch of printouts.

Traced InterTiki problems to the IP security check to the following (line 55) in /remote.php.
{CODE()}
if (!isset($prefs['known_hosts'][$key]) or $prefs['known_hosts'][$key]['ip'] != $tikilib->get_ip_address()) {
{CODE}

By changing the line to the following, the IP check problems went away:
{CODE()}
if (!isset($prefs['known_hosts'][$key])) {
{CODE}

InterTiki stopped working on this site properly. Users and the groups are not being replicated anymore. When someone registers on tiki.org, the user does not appear here. For example on tiki.org there is registered validated user samymwamba, but if you check here the user is not found on https://dev.tiki.org/tiki-adminusers.php

http://dev.tiki.org/tiki-tracker_view_history.php?itemId=4678

{syntax type="tiki" editor="plain"}
Try: http://dev.tiki.org/Together/

{img fileId="524"}

{syntax type="tiki" editor="plain"}
Tiki automatically includes the "id" attribute for headings. For example:

{CODE()}
!my heading
{CODE}

Becomes:
{CODE()}
<h1 id="my_heading">my heading</h1>

By default, the value of __id__ is the text of the heading. However, as per the XHTML specification, __id__ ''must'' begin with a letter -- not a digit.

Therefore, if I have:

{CODE()}
!2009 Highlights
{CODE}

Tiki generates:
{CODE()}
<h1 id="2009_Highlights>my heading</h1>
{CODE}

Which is invalid.

See http://validator.w3.org for details.

{syntax type="tiki" editor="plain"}
It seems to be an error only by the first settings (creation) of a wiki page, maybe depending on the staging and approval system:

* Every time a new wiki page is created initially in the staging version the creators name is correctly shown under "created by" and "creator" (in the listing of the wiki pages and below the page in the collaborative-listing of creator and contributors).

* Then after approval

** the page description disappears (I mentioned this in another posting before) and

** the creator of the page is changed, I mean: __instead of the user's name (who created the page)__ now __there is shown the IP of the approver__.

* So

** below the page and in the page listing the IP (of the approver) is shown as creator,

** and in the history the "user" of the page and the "comment" are changed.

Please see the screenshots I attached, for better explanation of this. The page in the three screenshot was created by admin and approved by admin. But it's the same, if created by an user:

__Always the name of the creator of a wiki page is not correctly shown in each area (wiki page listing, below the page and in the history).__

* By edit of an existing page, this doesn't occure! - You see in the screenshot, that in the second and third version of the page there are correctly shown the "user" with his name and "comment" with an comment, that the page was approved by named approver.

Hi all, I have been using tikiwiki since it was about v14 and have seen it use more and more compute resource. I recently pulled a production site from AWS as the compute bills where starting to get out of hand. I think I would have a hard time convincing small sme's to fork out hundreds of euro each month for in-house tikiwiki hosting. Any thoughts are welcome. I have tried disabling various features but it still takes up cpu time. This isn't a complaint, I love tikiwiki , but if tikiwiki increase in size it will become a software suite for large corporations ONLY. Cheers, Kevin.

Have a look at this older post on dto:

https://dev.tiki.org/item7913-Migrating-18-8-to-21-4-fails-utterly-breaks-layout?highlight=update+cycle

It is currently being rendered to the screenshot (cf attachment), completely illegible. Without starting a new discussion on Tiki breaking existing layouts: What went wrong? dto was to my recollection not built on acient versions, but fairly up-to-date ones. My browser today is a current MS Edge on W10.

If something like the screenshot can still happen, how can an admin protect his/her website against that? How can it be remedied? Large sites like dto cannot be checked page by page for layout breaks...

Thanks
hman

So I've been doing some testing on 15.x and I noticed that there is an issue with the calendars. When you click on 'Add Event' for some calendar, it opens the window that lets you change event times and whatnot, but it loads with a backdrop that prevents the user from being able to click anything. It seems to me that the backdrop is simply appearing in front of the other windows... perhaps it is an issue with the way it is assigned a z-index.

The element in question is 'modal-backdrop fade in'. It creates a gray backdrop that covers the entire screen, including the window that appears to add an event to a calendar.

You can have a groupSelector field in a tracker displayed to a user that has no right to view groups. The result is a selector with a single option (None) instead of telling to the user that he don’t have right to see groups.

Check the instance.

An alternative would be to hide the groupSelector if you can’t interact with it.

{syntax type="tiki" editor="plain"}
Currently, users cannot join groups even when the `userChoice` option (“User can assign himself or herself to the group”) is enabled, unless they also have additional group-related permissions.

This change allows self-assignment when `userChoice` is enabled, without requiring extra permissions.

The `userChoice` option is intended to allow users to join groups themselves, not to grant permission to add other users. Requiring `group_add_member` contradicts this purpose.

The `group_add_member` permission remains enforced when adding other users.

This aligns the behavior with the expected purpose of `userChoice` groups.

On A tiki23 I have a user tracker.
Then I have a second tracker with an itemLink for where I can select one or several users.

In a customSearch I can't find any of them.
Here an instance http://bsfez-11581-7848.show2.tikiwiki.org/tiki-index.php?page=HomePage#User_list_in_customSearch

On previous version of a Tiki (17 and 18) and as per documentation at https://doc.tiki.org/Favicon it is possible to set a favicon using the favicon feature.

This is not working with Tiki20.

Using a favicon checker it shows the usual Tiki instead of the new favicon and show: ~pp~ http://blabla.com/themes/greenvalley/favicons/favicon.ico is declared but not accessible~/pp~

The browser path for favicon is now: "/themes/base_files/favicons"

To have unique favicon for Tiki20 by erasing the content and place your own favicon files.

It is not possible using the HTML plugin or the wiki syntax to have bootstrap modals as explained at : https://getbootstrap.com/docs/4.0/components/modal/

The page turn black/faded and the modal is displayed below the modal-backdrop (without the modal id).

Note: I have the feeling it was possible in the past (19, 20, 21). May be it is a recent change that has been merged into Tiki 21.

On the tracker 5 when you edit an item you can't type the first letter of an option in the "Resolution status" dropdown to jump to the option.

You use a search field, but the more "natural" type first letters option should work too.

{img fileId="1636" thumb="box"}

At : tiki-admin.php?page=login
It is possible to enable "Use pretty trackers for registration form" without indicating a template in "Registration pretty tracker template". That lead to a broken registration page.

There should be a control mechanism to block/warn the user to apply without indicating a template.

As reported here:
https://bugzilla.mozilla.org/show_bug.cgi?id=398767

{THUMB(image=>img/wiki_up/2008-01-17_low-tech-image_picker_TikiWiki.jpg,url=#)}{THUMB}
{THUMB(id=13,url="show_image.php?id=13")}{THUMB}
{THUMB(id=16,url="show_image.php?id=15")}{THUMB}


Some ideas of nice links to have:

Thumbnail with link:
{img src=images/code.png}%%% {CODE()}
{THUMB(id=13,url="show_image.php?id=13")}{THUMB}
{CODE}


[tiki-upload_image.php|You can test some experimental stuff here] (upload a pic and see the suggested wiki markup to copy in a ((test)) page.)


Nelson Ko and Marc Laporte were planning to work on tiki at ((tw:TikiFestToronto)) but something else came up so it's still on todo list :-)

{syntax type="tiki" editor="plain"}
"If a user upload a big avatar (more than 45x45 px) tiki 2.1 not 'avatarize' and show the big image in the forums. This problem may be very uncomfortable when you read a forum topic."

I can confirm that this still occurs on tiki.org and whatever Tiki version it is running presently, specifically with GIF images. -- ssanders

Hello,

I just install the version 7.2, and here is the php info: http://grip.umich.edu/tikiwiki/tiki-phpinfo.php. When I switched to the WYSIWYG editor (I tested all WYSIWYG editors), I could create content and sometimes could save it, but when I edited it the editor could not load the existing content.