Category: Patch

When you submit a fix, either by attaching a file or by posting a diff of the code
Show subcategories objects

Name Type
[ aulawiki 1.6 cannot install in tikiwiki 2.2 ]
An error occured in a database query!

File tiki-mods.php
Url tiki-mods.php?
INSERT INTO tiki_menus VALUES (100,'Workspace menu','Sample workspace menu','d');
Column count doesn't match value count at row 1
Built query was probably:
INSERT INTO tiki_menus VALUES (100,'Workspace menu','Sample workspace menu','d');

tracker item
{toc} with max_depth, file access by name, show_image with random picture of a gallery
I've added the following features to my tikiwiki 1-9-5:
1. added max_depth to {toc}
with {toc max_depth=3} I can limit the depth of the toc created. This is convenient if I only want to show the next level of subsections.

2. get a file by name via tiki-download_file
with galleryId=<id>&name=<?> I can retreive a file by name. If there are files with the same name the most recent is taken. This is convenient as I can reference the files by there name, e.g. schedule, an I can easily update it with out changing pages. Dynamic content would also work but I prefere the name as it is more obvious than 'content id=42'

3. get a random picutre from a gallery via show_image
with galleryId=<id> a random picture of the identified gallery is given.
tracker item
"tiki-edit_structure.php" Add Pages To Current Node list truncates at 50 records. Fix included.
The list of tiki pages presented for selection and addition to a structure is truncated at 50 records for no apparent reason and there's no way to add records >50 without running a filter.

I just parroted what I saw in tiki-admin_categories.php for its similar page list and it works.

The diff is below - hope I did that correctly.

*.backup is the original file from the official tiki releast. *.php is the version I modified.
tracker item
PAM authentication broken
An attempt to log in using PAM (php-auth-pam) gives the following error message:

Notice: Undefined variable: error in /var/www/tikiwiki/tikiwiki-1.9.7/lib/userslib.php on line 554

Warning: Error variable must be passed by reference in /var/www/tikiwiki/tikiwiki-1.9.7/lib/userslib.php on line 554

Warning: Cannot modify header information - headers already sent by (output started at /var/www/tikiwiki/tikiwiki-1.9.7/lib/userslib.php:554) in /var/www/tikiwiki/tikiwiki-1.9.7/tiki-login.php on line 292

I'm using:
- php5-auth-pam-0.4-9.2 (Debian package)
- tikiwiki-1.9.7 (source)
tracker item
Calendar item start/end hour selection is broken in Tikiwiki 2.0 using PHP 4.3.2 or previous - Patch
On TikiWiki 2.0, when adding or editing events in a <span class= "highlight_word_0">calendar</span>, if you're using PHP 4.3.2 or previous, you will only be allowed to choose 0, 1 or 2 as the <span class= "highlight_word_1">start</span>/<span class= "highlight_word_2">end</span> hour, even if the <span class= "highlight_word_0">calendar</span> is configured to offer 0-23 or something along those lines.

This is because of the following line in the file $TW_HOME/lib/smarty_tiki/function.html_select_time.php:

{img src=images/code.png}%%% {CODE()}
$hours = $use_24_hours ? range($hour_min, $hour_max) : range(1, 12);

The range function, as explained [http://php.net/manual-lookup.php?function=range|here (see ChangeLog)], in PHP versions previous to 4.3.2 inclusive, treats numeric strings as strings and not integers which <span class= "highlight_word_2">end</span>s up meaning that "23" is seen as "2", hence producing the problem.
tracker item
3.0beta1 patch: automatically extract Admin time/date settings for month/day display
__Now applied in 4.0 so this item is closed__

Current calendar displays always display month/day no matter what the
Admin time/date setting is for display_field_order.

This suggested patch follows on from [tiki-view_tracker_item.php?trackerId=5&itemId=2314|item 2314] and modifies tiki-calendar_calmode.tpl and tiki-calendar_weekmode.tpl in 3.0beta1 so that the display is either month/day or day/month dependent on the Admin setting.

The patch also includes the logic changes for an additional check to NOT show the 'add event' icon in the day cell if no calendar 'visible'

Files attached for anyone that wants them as a patch - and for consideration for inclusion in the next 3.0 cycle?
tracker item
3.0beta1: Calendar iCal patch for recode issue
__Fixed in 4.0__

My hoster does not install the Recode extension as part of their standard PHP (5.2.6 being used) so when testing the Calendar export function I was getting Fatal errors with "undefined function recode()"

I have therefore changed line 105 in tiki-calendar_export_ical.php to use iconv instead.

I don't really know how common this issue will be ie is iconv always available and recode rarely?? but I've attached the changed code, which I have tested to some degree, for anyone with the same problem and perhaps the developers could decide which is the 'safest' approach.
tracker item
Fix for Bug Ticket ID 2184
I have confirmed this bug (2184) in Tiki 6.3 using Chrome and IE7/8.

I am not a javascript guru so this may not be the most eloquent solution, but it works.

To fix, replace the icntoggle function (line 693) in tiki-js.js with the following:
tracker item
DB update SQL statement
When upgrade from version 2.2 to 3.9, I received one database error.

The error is related to this statement:

INSERT INTO `tiki_menu_options` (`optionId`, `menuId`, `type`, `name`, `url`, `position`, `section`, `perm`, `groupname`, `userlevel`) VALUES (197,42,'o','Mind Map','tiki-mindmap.php',255,'feature_wiki_mindmap','tiki_p_view','',0)

The SQL statement failed to complete because the optionId 197 already exist.
tracker item
Missing translation call in smarty_tiki/modifier.tiki_short_datetime.php
Showing a comment to a blog entry that has been posted the same day, only the time when the comment was posted is displayed. We use the German translation of TikiWiki, but the English "at" in "at 12:34" is display, not the German "um".
After having a look into the code, it seems the translation function is not called in lib/smarty_tiki/tiki_short_datetime.php
tracker item
updates to lang/hu/language.php
Bugs & Wish list
tracker item
Active Directory domain users are not recognized by TikiWiki
Domain Users are not recognized by TikiWiki when using IIS and Webserver auth against AD.

substr function in tiki-setup_base.php mistakenly removing first char of the login name during substracting domain part. For example "DOMAIN\username" is truncated "sername".

I've fixed the issue with the patch below.
tracker item
Add memcached support, with admin panel
Support.mozilla.com solution


tracker item
admin validation - new user account - can't login
new user can register but after admin validate his account user can't login because have no password in database

version: tikiwiki 1.9.9 - sirius
conf: allowRegister=y ; validateRegistration=y ; validateUsers=n
tracker item
Allow Copy / Duplicate Calendar event
Our users have requested the facility to "copy" a calendar event.

This would be via the means of a "Copy" button when previewing an event, on clicking the button you would then see the event details and be able to change any of them before clicking "Save".

Where upon a new event will be created with these details.
tracker item
Allow pagination inside articles wiki-plugin
It is not possible to use pagination inside the wiki plugin articles. The attached Patch enables this by adding a paginate (y|n) to the parameters.
tracker item
Allow redirect plugin to use fragment identifiers (section/anchor ids) (patch included)
The redirect plugin currently lacks the ability to include fragment identifiers, e.g. -+~np~{REDIRECT(page=Foo#some_id)/}~/np~+- does not work; the resulting URL is -+~np~tiki-index.php?page=Foo#some_id&redirectpage=this_page~/np~+- instead of -+~np~tiki-index.php?page=Foo&redirectpage=this_page#some_id.~/np~+-
tracker item
another patch on aulawiki.1.6.2 for tikiwiki.2.2 + a new workspaces
These are more patches on aulawiki.1.6.2 posted by xavi

* Versions 1.6.2x are intended just to make aulawiki work on tikiwiki
2.2, the way it worked before.
* Versions 1.6.3x -1.6.4 were transition step.
* Versions 1.6.5x -1.7.x has put back capability to add groups to the
workspace (not only users), and see all child's groups, starting from
the topmost a user can admin, when adding perms to single workspace
This was be done by adding some new functions to workspaceslib.php:

- get_includable_child_workspaces_groups : will get all groups in WS and child workspaces, starting from the uppermost on which one has admin objectperm down, purged by veryfing a list of includable groups to avoid loop inclusion.
- user_can_admin_workspace_or_upper(), an alias of
get_topmost_workspace_Iadmin(): will get up in the workspace path and
return an upmost parent workspace one can admin, thus gives him admin
capability on the ws and children, or false.
And in lib/workspaces/userslib.php, function group_can_include_group() will check if the group we are trying to include can be included.

with these functions a RolePerm with tiki_p_admin_workspace has
view of all child workspaces and their groups down from the
topmost one he can admin, no matter in which of these he is actually
(current workspace), and be able to add groups and assign perms to
groups within all these ones (only) without need of of having
tiki_p_admin_workspaces also on any child ws.

To the intermediate objectperm tiki_p_create_workspace_resour has been given as a gift the possibility to add single users, not groups, to the workspace predefined groups. On the other hand he can grant objectperms to his resources choosing among any group that belongs to his 'workspace-level'(brothers workspaces) + his parent's (dad, see what I am doing!)

This behaviour is easily changeable in the code, as the ability to do things is stated at the top, where (object)permissions on the workspace are tested once and translated into variables used throughout the code.

In practice:
*'tiki_p_admin_workspaces' as an objectperm on a WS (got
from the RolePerms template for that type of Workspace) is de-facto a
local Workspace administrator. He can do everything (create new sub workspaces, add groups, change perms) except define new
workspace types and roles, and he sees only groups starting from the
topmost workspace he can admin to the bottom.
*tiki_p_create_workspace_resour, as objectperm on a WS (got from the
RolePerms template for that type of Workspace), can manage objectperms
of his ws resources (excluded the ws object itself) choosing among
a tree of groups that starts at his parent's level (dad, see what I am doing), includes 'brother workspaces' (on the same level, child of the same parent), down to bottom. He is a ''resource manager''. For adding users/groups to the ws, he can only add single users by typing the name, no groups. But if his ws has an admin group, he could add himself there. So __tipically workspaces either have a ws_admin role OR a ws_resource manager role__. On the other hand, a top, empty (no resources) workspace, with only an ws_admin role, would grant administration to all childs.
* For global tiki_p_admin_workspace nothing changes, although he is now prevented from including groups that include the includer, something that would put the entire site down.

For a user that has the approriate objectperms from the roles template
to the workspace (tiki_p_admin_workspace or, with less possibilities,
tiki_p_create_ws_resour, for the workspace object), everything can be
done starting from the resources module that has extra links to create child ws, add users/groups, and assign perms to resources.

The resouces module will show/hide Buttons and icons next to each
resource accordingly to what can be done by the actual type of user.

Most of the modifications happened in :

- tiki-workspaces_objectpermissions.ptp + templates
- modules/mod-workspaces_users_groups.php + templates
- lib/workspaceslib.php (new functions only)
- lib/users.php (new functions only)

With respect to the connection workspaces-categories, nothing should be changed. All categories related code is still there and used as before.

New permission scheme 1.7.0:
perm allows as allows as
name group perm objectperm
view_ws - -view the ws

create_resour - -create resour onws

admin_ws do all on any ws -add group/user to ws

perm allows as allows as
name group perm objectperm
view_ws - -view the ws

create_resour - (1) -create resour on ws
(de facto admin resour)
-change perms on ws
resources (excluded
the ws itself)
choosing from the
father ws groups and

-add single users(not groups)
to ws predefined groups

admin_ws -do all on any ws(2) -create child workspaces for
any ws from the topmost ws
he has admin rights

-change perms on ws object
itself & resources &
child-ws objects and
resources choosing from
the topmost ws groups
he has admin rights

-add any groups to any ws
choosing from the
topmost ws groups
he has admin rights

-create child workspaces to
any ws from the topmost ws
he has admin rights

(1) this slot is free! Can't we use it to allow the creation of an
'organic workspace' of some predefined type with himself as
tiki_p_create_resour objectperm on it?

(2) as he can add the 'admins' group, and add users to it, he is
defacto a tiki_p_admin.
maybe he should only be able to add 'workspaces groups'? This would
make him different from a tiki_p_admin_groups and tiki_p_admin.
see comments and examples of different possiblties in

(3) see comments and examples of different possiblties in
there's quite a lot I think, especially in the interface, making it
nicer and more intuitive.
-Add confirmation steps for various deletion actions
-Deletion of workspace does not delete its objects (should it?)
-test it really hard
-understand first, and maybe integrate, the working of 'Private Zones'
and 'user Workspace types' (isuserWS and userws filed in table).
Version 1.7.x has been committed to svn trunk.
You can now download the up-to-date version (not in mods format though) from:
The mod in the repository does not provide a working example of these new features, it has the usual Teacher/Student Roles. One has to define roles with 'tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour' to see this in action
tracker item
Article type not maintained on editing
When editing an article the type is reset to the first in the list. This is due to an useless? foreach loop inside tiki-edit_article.php . See the patch attached for a solution.
tracker item
Articles Plugin: Allow display of titles only (for side modules)
The following patch provides a version of the ARTICLES wiki plugin, that displays article titles only. To use, people simply specify titleonly=>1 in the options for the ARTICLES command. This is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website -- just look under ''News'' on the right-hand side of the page.
tracker item
Automatically fill in Page Name field when creating new links fck
Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.
tracker item
Automatically fill in Page Name field when creating new links fck
Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.
tracker item
Better layout of the wiki top (.tocnav, .wikitopline, .categbar)
tracker item
BiDi.css bug in RTL language
tracker item
Big avatar in forums, elsewhere
"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
tracker item


The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Articles & Submissions
BigBlueButton audio/video/chat/screensharing
Browser Compatibility
Communication Center
Contacts Address book
Contact us
Content template
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Draw -superseded by Diagram
Dynamic Content
Dynamic Variable
External Authentication
Featured links
Feeds (RSS)
File Gallery
Friendship Network (Community)
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Lost edit protection
Meta Tag
Missing features
Visual Mapping
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Performance Speed / Load / Compression / Cache
Revision Approval
Search engine optimization (SEO)
Semantic links
Shopping Cart
Site Identity
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Staging and Approval
Syntax Highlighter (Codemirror)
Tell a Friend
Terms and Conditions
Token Access
Toolbar (Quicktags)
User Administration
User Files
User Menu
Webmail and Groupmail
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives

Useful Tools