Log of Tiki5 testing carried out by eromneg (geoff)

Tiki5 is being tested at www.opendev.enmoreservices.com where this site is regularly synch'd with the 5.x branch. Please note that this test site uses the wysiwyg editor as the default with the "Wiki paragraph formatting" set to y and the "but still create linebreaks within para" set to n. These settings have been found to be the 'best' compromise but does have the consequence that <br/> tags have to be used when the normal editor is used

This page creates a log of the testing that has been carried out and any issues found. The version that was tested for the logged item is shown in brackets eg (26035)

Anyone who would like access to the test site should contact me.

Overall impression is that this release is now looking robust - but there are still some issues with the wysiwyg editor, particularly with FF

WYSIWYG editor

Some issues: still being observed in (v27024)

Still seeing a few issues with the wysiwyg editor in 5 beta2 - now using v27024

Please note: all is working fine in tiki v3.5 using FF3.6.3 Chrome, IE8.0.6001.18702 and Opera 10.53

However for FF none of the basic functions work:

  1. inserting an internal link: link text not carried thru to the pop-up and the link is inserted at the top of screen
  2. inserting an external link: just doesn't work at all
  3. inserting an image: places the image at the top of screen no matter where the cursor is

For all the other browsers the basic link and image insertion works but in all cases for an external link if _blank is used as a target tag this is tripped out when the page is saved. This seems to be OK in trunk however so a backport may fix this.

Strasa theme

The wysiwyg editor is not currently usable with the strasa theme with the fixed_width option since the edit screen has the background from fixed_width.css (line 85) ie url("fixed_width/body-bg.png") repeat-x scroll 0 0 #214D68 !important
ML: looks fixed since fixed_width was removed as a theme option.

I've now fixed this in trunk. Not yet retested 5beta2 - but will backport if appropriate - probably for 5.1

As reported on devel list 6th April -

an item link tracker field has options to display and select multiple fields from the target tracker ie:


  • [trackerId] is the tracker ID of the fields you want to display;
  • [fieldId] is the field in [trackerId] from which you can select a value among all the field values of the items of [trackerId];
  • [linkToItem] if set to 0 will simply display the value, but if set to 1 will provide a link directly to the item in the other tracker;
  • [displayedFieldsList] is a list of fields in [trackerId] to display instead of [fieldId], multiple fields can be separated with a |;
  • [status] filter on status (o, p, c, op, oc, pc or opc);
  • multiple options must appear in the order specified, separated by commas.

So for example 2,2,0,2|3 would use trackerId#2 as the target for the drop down selection and should concatenate fields 2 & 3 to both display and select values.

This works fine in 3.x, but now what happens in 5alpha and trunk is that only the options for field 2 are displayed instead of all the 2|3 options and I can't quite work out what logic has been applied for setting the selected value.

Blinking and unresponsive script errors (v27024)

This seems OK now - at v27024
  • getting lots of "blinking" when some pages/functions are selected: looks like an intermediate blank page is being displayed between process cycle - a good example is when the List Articles menu is used and there are quite a few Articles
  • also getting unresponsive script errors (+ blinking) after a minute or so with some functions e.g. when opening the category permissions. Error message is:

"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://www.opendev.enmoreservices.com/tikiwiki/lib/jquery/jquery.js:4733 "

which is odd since php.ini has "max_execution_time = 600"

CATORPHANS Plugin (v26237)

This plugin still only works with Wiki objects - I have updated the documentation to reflect this for now

Articles Preview (v27024)

If you set a Topic but that Topic does not have an image and you do not use an image of your own then the system tries to show the non-existent Topic image when the Article is Previewed.

It is OK once the Article is saved (I think it used to try and show it in the saved Article but I guess the .tpl has been updated)

This is irritating in the IE browser which displays an empty image icon.
ML: +1 and should be easy to fix