Category: 8.x

{syntax type="tiki" editor="plain"}
__unified_incremental_update doesn't check for feature_search__

Unified Search with Lucene is awesome and is "the future of Tiki".

Now, on certain server configurations, it doesn't work well. An easy workaround is to simply revert to the legacy MySQL Full Text Search.

However, even when using MySQL Full Text Search, unified_incremental_update is defaulted to yes, and tried to update Lucene index, and generates an error message

Workaround is to deactivate unified_incremental_update, or even better, upgrade to 12.x and use Unified Index, with MySQL as storage.
---
Update: this issue has been reproduced in 12.x svn (and untested in 14.x so far, afaik) also with Mysql Full Text Search as unified search engine (on a multitiki install). See: [item5673] . {sign user="xavi" datetime="2015-05-19T09:10:57+00:00"}

{syntax type="tiki" editor="plain"}
We just updated our tikiwiki from 6.2 to 8.3 and came across a difficulty when viewing the rss-seed of tracker items. We cloned the database and have not changed anything about permissions, but it seems that only people from a certain group (and admin) can view the rss seed of the tracker while logged in, while others can't. This wasn't previously the case.

We kept the old wiki (6.2) and the tracker rss seed works. See for the example:
http://www.svi.nl/tikiold/tiki-tracker_rss.php?trackerId=5

The rss tracker in the new wiki doesn't. See:
http://www.svi.nl/tiki-tracker_rss.php?trackerId=5

Both have a different database, but they are identical. Also all the permissions concerning trackers are identical.

Is this a bug or has the functionality of the tracker changed? Tried to search in the tikiwiki and bug-reports but couldn't find anything.

EDIT: Apparently this wasn't working in 6.2 either but we created a workaround for it, which also seem to work for 8.3 (see below).

{syntax type="tiki" editor="plain"}
On dev.tiki.org

If I delete a tracker item, the notification email is entitled:

"Bugs & Wish list" item "" was modified at dev.tiki.org by "Marc Laporte"

1- So it's missing the decription of the wish

2- The content is
{CODE()}ItemID 2855 was deleted in the tracker Bugs & Wish list

Author: Marc Laporte
Date: 07:40 UTC{CODE}

So, it's missing the last info before it was deleted. What's the point of watching if I don't get a copy before it's deleted?

Problem:
FAQs do not appear in the 'list FAQs page' tiki-list_faqs.php
"No records found."


This bug is visible with fresh install 8.3
or content upgraded from 6.6 to 8.3.
(feature work ok in 6.6)

Adding a new FAQ work (the new entry is seen in database with select * from tiki_faqs;)
but it will not display in the FAQs list either.

Looking at the PHP code, it seems it is a permission problem.

in tikilib.php
function list_faqs()
code below: //FIXME Perm:filter ?

By removing the test on permission :
if ($objperm['tiki_p_view_faqs'] == 'y')
the FAQs do appear correctly.

It could be related with the 6.6->8.3 changes in user_lib.php function get_permissions() or the
way FAQs permissions are retrieved with tikilib.php
$objperm = $this->get_perm_object($res['faqId'], 'faq', '', false);.

They are quite a number of other //FIXME Perm:filter ? comments in the tikilib.php,
so it is possible that this bug affects other features (or is already reported!)

"htmlwrap() is a function which wraps HTML by breaking long words and preventing them from damaging your layout. This function will NOT insert <br /> tags every "width" characters as in the PHP wordwrap() function. HTML wraps automatically, so this function only ensures wrapping at $width characters is possible. Use in places where a page will accept user input in order to create HTML output like in forums or blog comments.

This function will not insert line breaks within HTML tags or HTML entities such as  . It treats all HTML entities as single characters, when taking them into account for string length. It will also attempt to find logical line-break insertion points (like after periods or slashes) before inserting breaks at $width characters."

http://www.greywyvern.com/code/php/htmlwrap

Both the wiki page attach file and filesplugin feature an action icon. When this icon is chosen a pop up box appears with several actions that can be taken on the file. When the delete or red X is chosen the page reloads but the file is still in the file gallery.

Steps in 6.3:
*create tracker, set Auto-create corresponding categories
*define tracker_item like name, add two items.
As result category is created (as tracker name) and items are added as subcategories:

*Informatics Projects(0/1)
** Item1(0/0)
** Item2(1/1)

Same steps in 8.3, result:

*Tracker 1
**Tracker Item
***Name Type Category
***# Projects tracker item Tracker Item
***# Projects tracker item Tracker Item

Result, instead of tracker name category 'Tracker 1' was created, than subcategory 'Tracker Item' and empty object inside, displayed as table with links to non existing "http://localhost/tiki/tiki-view_tracker_item.php?trackerId=1&itemId="

Thanks,
Jakub

{syntax type="tiki" editor="plain"}
With revision 31581 the LDAP group synchronisation has been limited to only happen 60 seconds after the login:

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/trunk/lib/userslib.php?r1=31565&r2=31581&pathrev=31581

So far as I can see this method is only called during the LDAP login procedure, so the if-statement in line 1415 will always be false, thus no synchronisation will happen.

I checked this problem with 7.1, 7.2 and 8.3 and never succeded to get the groups from an AD although the LDAP login worked. After disseminating the code and removing this if-statement the feature works again.

I wonder what the the use of this if-statement was? The commit message refers to webdav changes - how does it affect this?
Can this statement be removed so LDAP group synchronisation works or is there another way to fix this?

in debug mode (eg. when debugging ldap logins) many log entries are created at the same time so sorting by time is not sufficient to get the entries in their real order. Sorting by ID is better then.

Unfortunately sorting by ID leads to an unexpected result.

Looking at the code the problem can be fixed easily: The problem is that two tables are being joined (actionlog and actionlog_conf) and sorting by ID leads to sorting by actionlog_conf.id instead of actionlog.actionID.

Both needs to be fixed - in the SQL query the table for sorting must be added in the sort statement, in the template the columnname must be changed from Id to ActionId.

See patch.

{syntax type="tiki" editor="plain"}
LDAP group synchronisation is dependent on the "corresponding user attribute", a setting which is only needed if an external directory is used for group synchronisation.

The fix is simple - the combination of if-staments just need to be adjusted slightly - see patch.

When groups are synchronised with a big LDAP organisation many empty groups may end up in Tikiwiki.

This enhancement / patch adds an option to let the administrator of a tikiwiki instance decide whether during synchronisation of groups only the user assignments to existing groups will be done or if non-existent groups will be created in tikiwiki.

The default behaviour - as of now - is that when a LDAP user logs in all the groups he belongs to will be created in tikiwiki and he is being added as a member of these groups.

This enhancement adds the preference "ldap_create_groups_tiki" which is "y" by default - which corresponds to the current behaviour.

If "ldap_create_groups_tiki" is set to "n" and a LDAP user logs in the group synchronisation process will silently ignore groups that exist in LDAP but not in tikiwiki. Existing groups will be synced, though.

Uploading a file larger then around 30Mb results in an endless view of "Uploading file..." while the upload was actually finished. Found a previous ticket about this problem explaining that an invisible error is shown. It is assumed that this error has something to do with settings of upload_max_filesize or other settings in php.ini. See ticketID 4107.

However, this is clearly not the problem here. Especially since our old wiki (6.2) (which uses the same configuration and php) has no problems uploading files. So this sounds more like a bug in tikiwiki 8.3, then an wrong setting in the configuration files. I also checked all of our .htaccess files, which do not overrule the settings of php.ini.

Because the uploads do work in 6.2, but it doesn't in 8.3, I fear it is a bug in the new tikiwiki.

If there are more places that I could check that may cause the problem, please let me know. The upload feature on our wiki is quite important, so I would like to find a solution as soon as possible.

Thanks!

Edit: It seems that when I upload a small file, which gives no problems, and then replace this file with an other file of 50Mb, then there is no problem.

Edit2: It seems that the upload is also dependent on the memory_limit value, but this should not be the case. At least, it wasn't before. When the memory_limit is increased larger files can be uploaded. We had set our memory_limit to 64Mb, which allowed an upload of files around the 30 Mb (probably 32?), so there may be a factor two involved.

I am sent here

tiki-adminusers.php?user=abc&action=removegroup&group=xyz

{syntax type="tiki" editor="plain"}
Fatal error: Call to a member function toArray() on a non-object in /var/www/rtsdata/apps/WiP/tiki/tiki-8.3/lib/prefslib.php on line 243

New install, following "Tiki for Smarties" examples,
Install is successful. No problems.
Log in as admin. ... good.
change password ... good.
go to Admin page from menu ... good.
select "general" ... fatal error.

try ..."Getting started using Profiles" ... same error.

{syntax type="tiki" editor="plain"}
Hi,
I discovered that the wrap option of the code plugin doesn't work anymore. don't know from when exactly, but at least it was working with tiki 7.x
Exemple page: first code on [http://www.tontonitch.com/tiki/tiki-index.php?page=test],
Yannick

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

!!!This problems concerns quite all table and forms (in tables or not) with fixedwidth themes.
This is the reason while it appear in so many functions.

!!!As for most of tables in many functions, with "twist" (no other style tested) the tables of the middle (C2) either overlap C3 or are behind C3 and sometimes C2. They just have a little part outside the 990px large (in twist as the width is written into css it can't be changed by prefs).

__~~#F00:The corresponding functions are then completely unusable.
~~__

Here I write this for the example elementary function "add an element to a structure" givin in screenshots joined documents

Three scrennshots proposed are :
#What a user see
#The limit of the div as shown by firebug
#The whole div zone hidden

Search the full Russian word gives a result in the Russian word wiki-pages successfully.

When searching for part of the Russian word search finds nothing.

Search by part of the English word or full word - search is successful.


[http://imageshack.us/photo/my-images/29/18619205.png/|image 1]
[http://imageshack.us/photo/my-images/861/17424549.png/|image 2]
[http://imageshack.us/photo/my-images/809/25798887.png/|image 3]
[http://imageshack.us/photo/my-images/831/71733976.png/|image 4]
[http://imageshack.us/photo/my-images/69/43517748.png/|image 5]
[http://imageshack.us/photo/my-images/708/31417838.png/|image 6]
[http://imageshack.us/photo/my-images/21/59250827.png/|image 7]
[http://imageshack.us/photo/my-images/824/86604157.png/|image 8]

{syntax type="tiki" editor="plain"}
!!!After upgrade the admin can't login anymore

!!!The failure sequence :
#Create a new directory or repository for the new version
#Update with your files (particularly images or icons)
#Site enable (example a sub-domain) on Apache
#Copy the database on new name
#Install manually .htaccess (compare and insert your valid options )
#Update "local.php"
#run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
#~~#F00:__Try to login as admin : You will be rejected as wrong password __~~

!!Analysis - many possible reasons :
There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

#If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :
- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

#The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

#Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

#Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

#Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

It is sure that if you use only one site close everything and upgrade you will get the minimum of problems but you will get someone anywhere.


!!~~#099:This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.~~
It is not seen generally by developers, because it is not at all their common upgrade process nor test.

{syntax type="tiki" editor="plain"}
as the topic says

if you youse the redirect plugin in an article you cannot edit the article as it redirect the page even in edit mode

Tested in version 3.3 and 7:
Importing tracker items through CSV does not properly process the date field.

My exported CSV contains e.g. "24/12/2010 19:55"
The imported data only contains "24/12/2010" The time has been left out.

{CODE(caption="incorrect code 3.3" colors="php")}# Version 3.3
Line 1697
} elseif ($field['type'] == 'f' || $field['type'] == 'j') {
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = split('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = split('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
}{CODE}

Replaced by following code :
{CODE(caption="correct code 3.3" colors="php") } elseif ($field['type'] == 'f' || $field['type'] == 'j') {
$l = strlen($data[$i]);
switch ($l) {
case ($l == 10):
# Field does not contain the time
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
case ($l == 16):
# Field contains HH:MM
list($fd, $ft) = explode(' ', $data[$i]);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
}
break;
case ($l == 19):
# Field contains HH:MM:SS
list($fd, $ft) = explode(' ', $data[$i]);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
}
break;
}
}{CODE}

The same for the latest version 8.3

{CODE(caption="Incorrect code 8.3" wrap="0" colors="php")} case 'f':
case 'j':
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = preg_split('#/#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = preg_split('#/#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = preg_split('#-#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
}{CODE}


{CODE(caption="Correct code v8.3" wrap="0" colors="php")}# Line 1730
case 'f':
case 'j':
$l = strlen($data[$i]);
switch ($l) {
case ($l == 10):
# Field does not contain the time
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
case ($l == 16):
# Field contains HH:MM
list($fd, $ft) = explode(' ', $data[$i]);
list($hh, $mm) = explode(':', $ft);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
}
break;
case ($l == 19):
# Field contains HH:MM:SS
list($fd, $ft) = explode(' ', $data[$i]);
list($hh, $mm, $ss) = explode(':', $ft);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
}
break;
}
break;
{CODE}

{syntax type="tiki" editor="plain"}
Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

{syntax type="tiki" editor="plain"}
When I attempt to organize objects in categories and I either click on the orphans link or attempt to search for objects, the action fails and the error reported below occurs. Note that on our system tiki is configured to use legacy search (mySQL) since when I configured it to use Lucene the "Search index could not be updated. The site is misconfigured. Contact an administrator." error occurred.

Fatal error: Uncaught exception 'Zend_Search_Lucene_Exception' with message 'Index is under processing now' in D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php:280 Stack trace: #0 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php(529): Zend_Search_Lucene::getActualGeneration(Object(Zend_Search_Lucene_Storage_Directory_Filesystem)) #1 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php(211): Zend_Search_Lucene->__construct('temp/unified-in...', true) #2 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(40): Zend_Search_Lucene::create('temp/unified-in...') #3 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(123): Search_Index_Lucene->getLucene() #4 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(82): Search_Index_Lucene->internalFind(Object(Zend_Search_Lucene_Search_Query_Boolean), Object(Search_Query_Order)) #5 D:\Program Files (x86)\EasyPHP-5.3.9\www\t in D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php on line 297

Importing tracker items through CSV only sets the created and lastModif value properly if the dates from the CSV file are in the numerical php date format.

When you import a csv file where the created and lastModif dates are written as proper dates, the imported tracker items have a created and lastModif date/timestamp of the date & time of the import action.

example csv :

"itemId","status","created","lastModif","VRID -- 265"
"849","o","07/12/2009 13:24","07/12/2009 13:24","4"

Whenever I export a csv file, it contains the dates as shown above, so you can't just export data and import data on the fly without modifying all the values...

c.f. [https://dev.tiki.org/item3500|bug 3500]

{syntax type="tiki" editor="plain"}
In the version 8.3 there are some errors if one wants to export a spreadsheet

The first one appears if one click on the export button. An error () shows up.
I have tried to fix it by inserting the code
"$sheetlib = TikiLib::lib("sheet");" at the line 11 of the "tiki-export_sheet.php" file.

After this fix the export menu appears but exporting the spreadsheet as csv file does not work. (exporting as V 1.0 does not work either, exporting as TikisheetFile V.1 seams to work)
For the case of exporting as csv: After clicking on the "Export" button, the browser ask for saving the file. Depending on the option I choose for saving ("Save as" or "DownloadThemAll") different behavior are observed:
* Save as: A file of 0kB is downloaded (for info the .tws file as 141kb)
* DownloadThemAll an "Server error*" error is shown in the program.

{syntax type="tiki" editor="plain"}
Main bug.

A new user can't at all connect and get a blank screen.
This without crash.

If the user have an analyser he will find that tiki has sent this code

{CODE(caption="The page sent content")}<html><header</header><body></body></html>{CODE}