Category: Patch

Hello,

When you want to create a form to embed a tracker you need to put the trackerId and the fields Id. I improved them in a more user friendly way in order to avoid to remember the ids.

__Before__:
{img fileId="1114" thumb="box"}

__After__:
{img fileId="1115" thumb="box"}

I have uploaded the files modified.

The modified files are:
*lib/wiki-plugins/wikiplugin_tracker.php
*lib/jquery_tiki/tiki-trackers.js
*lib/jquery_tiki/tiki-jquery.js
*lib/tiki-js.js

You will found the modified code tagged inside
// NOTE: Start Modification
......code....
//NOTE: End Modification

Please see: ((YSlow))

Increase ySlow score for all SUMO pages to A
https://bugzilla.mozilla.org/show_bug.cgi?id=444274

I do not know how to contribute code, but have developed the following "fix" that works to create TOCs when using the >Print Current Document feature in TW. This fixes the problem with the TOC growing to enormous length on a large page with each new section TOC being appended to the previous section's TOC. This fix has worked across many major versions.

File: [tikiwiki]/lib/parser/parserlib.php
Insertion point: in 12.0 line 2814; in 12.2 line 2967

Insert IMMEDIATELY BEFORE the following existing code:
{CODE()}
if (!empty($maketoc)) {
$maketoc = $maketoc_header.$maketoc.$maketoc_footer;
}
{CODE}

Inserted code:
{CODE(ln="1")}
//=====larryg -- beginning of custom code to make TOC and MAKETOC work properly in tandem
global $TOC_newstring, $TOC_oldstring ;

$TOC_newstring = $maketoc ; //===== get a copy of the newest TOC before we do anything to it
if ( strpos($maketoc, $TOC_oldstring) ) // larryg - if this MAKETOC contains previous chapter's TOC entries, remove that portion of the string
{
$maketoc = substr($maketoc, 0 , strpos($maketoc, $TOC_oldstring)).substr($maketoc, strpos($maketoc, $TOC_oldstring)+ strlen($TOC_oldstring)) ;
}

//prepare this chapter's TOC entry to be compared with the next chapter's string]
$head_string = '<li><a href=' ;
$tail_string = '<!--toc-->' ;
if ( strpos($TOC_newstring, $head_string ) && strpos($TOC_newstring, $tail_string) ) {
$TOC_newstring = substr($TOC_newstring, strpos($TOC_newstring, $head_string) ) ; // trim unwanted stuff from the beginning of the string
// $maketoc_header = 'PRESTRINGFOUND'.$maketoc_header ;
$TOC_newstring = substr($TOC_newstring, 0, (strpos($TOC_newstring, $tail_string) -5)) ; // trim the stuff from the tail of the string </ul></li></ul>
// $maketoc_footer = 'POSTRINGFOUND' ;
$TOC_oldstring = $TOC_newstring ;
}
//=====larryg -- end of custom code for TOC and MAKETOC
{CODE}
Please feel free to apply/use as you see appropriate,

-larryg

---
{BOX()}
See comments to this item.
In addition, a show.t.o instance has been created where the issue is reproduced:

http://larryg-10847-5405.show.tikiwiki.org/tiki-print_multi_pages.php?printstructures=%255B%25221%2522%255D&find=&print=Print

u: admin
p: 12345

As you can see, the table of contents in Chapter 2 ("3.2" in the numbering of the single html) shows the issue.
After applying your patch, I get the same issue still in this example.

You can test locally if you want by means of downloading a snapshot of the show instance.
{sign user="xavi" datetime="2014-08-08T09:05:34+00:00"}
{BOX}

This bug is tied to [http://example.com|http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1964&trackerId=5&show=view]

I have had various issues navigating my wiki seemingly because $base_url is not getting built correctly, or at all. The first of these issues happens at login where the user puts in a bad username or password. The redirect to the error page fails on Firefox and has a URL with doubled forward slashes after the domain because the $base_url is not getting passed. URLs get built as follows (where 'example.com' is my domain):

Firefox:
{img src=images/code.png}%%% {CODE()} http://example.com\/tiki-error.php?error=Invalid+username {CODE}

IE:
{img src=images/code.png}%%% {CODE()} http://example.com//tiki-error.php?error=Invalid+username {CODE}

This happens with relative URLs all over tikiwiki in my installation, which is a WAMP with virtualHost entries in the httpd.conf to resolve 2 distict domains on the same server.

{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

For multipage wikis the display of the "table of content" using __maketoc__ isn't ideal as this statement requires to be placed on every page otherwise it wouldn't be visible for other pages.
Usually this "table of content" is used for quick navigation purposes. Therefore an alternate to the __maketoc__ statement should be provided which should allow to specify the wikipage which shall be outline. Such a statement can then be used in a module nearby the original wikipage.

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.

I am pretty new at this, so I am not sure if I posted the bug and patch at the correct place and in the correct form. Please let me know if I should change something. Unfortunately I do not have time at the moment to learn how to commit patches via SVN and am also a bit unsure about my fix, so please take a look and include it in the next release if you think it is correct.

Scenario:
Tiki LTS 6.6, Tracker not publicly accessible (by anonymous users), RSS Feeds enabled, RSS for Trackers and for Individual tracker items enabled, RSS basic Authentication enabled.

Behaviour:
If I try to subscribe to the RSS feeds of my tracker (by adding http://tiki.***.***/tiki-tracker_rss.php?trackerId=9 to Outlook) I always get the error "Tiki RSS Feed Error Message: You do not have permission to view this section". Same happens if I log out of Tiki and copy the address in my browser.

When attempting to send messages to other tiki users whilst working in french locale, the messu-compose.tpl script hangs.

The problem is due to the different interpretation of commas and semicolons on french and english locales. The call to the quickhint (popup help) feature hardcodes the commas and semicolons, and this frustrates the french locale.

When using the UserList plugin, the links on the user names leading to their personal information pages, are shown and hidden depending on privileges of the logged in user. Unfortunately, the logic is reverse of what it should be.

Correct logic is: show links for all users that when either A.) You have admin privileges. B.) User listed is yourself. C.) User listed has chosen to make his profile information public.

Current logic is: show links when A.) You have admin privileges. B.) User listed is NOT yourself, AND user listed has chosen NOT to make his information public.

Spotted by a user who noted that the URL of a suggested Calendar at the bottom of a wiki page returned an 'invalid URL' error. I tracked the error down to the sefurl modifier in the template not handling calendar URLs properly. The tested correction to modifier.sefurl.php is:
{CODE(caption="add after line 95" wrap="0" colors="php")} case 'calendar':
$href = $sefurl ? "cal$source" : "tiki-calendar.php?calIds[]=$source";
break;{CODE}

A user registered himself, and chooses as login a name with uppercases (Stephane).

Two newsletter are created, with different subscriptions:
1) group subscription, including the aforementioned user
2) user self subscribe

When sending newsletter 1, the email is sent to the user.
When sending newsletter 2, the email address of the user is not found in the database and cannot be sent (despite finding the correct number of subscribers)

I traced it to two libraries:
first in ./lib/newsletter/nllib.php, in the function get_all_subscriber, we can see in the first part of the function how the email adresses are collected based on the subscribed groups. The select is mostly direct, and gets the correct information.
Later in the function (line 215 and following), individual users are added to the list of emails. Line 218, the "email" from the table tiki_newsletter_subscriptions (which is the login for registered users) is brought to lower case. (Note: I'm not sure, but it could be that the subscription module also puts the login in lower case in that table...)
Finally, line 232, the function get_user_email uses as parameter this lowercase login name to find out the actual email address.

This function is defined in the library ./lib/userlibs.php on line 5581.
This function compares the login passed as parameter to the login in the users_users table, but with a "binary" comparison, i.e. case sensitive! Removing the binary keyword lets the newsletter module find the correct user, and then its email.

Hello,

i found it annoying that you cannot redirect to an anchor or that if you use sefurl you you will still be redirected to a tiki-index.php site - so i wrote a small bugfix you can find in the attachment.

I don't know how secure it is as i am no security expert but it shouldn't open any wholes as far as i can see.

Not working yet

Hi,

as written to the dev list, I had the problem to restrict access to some newsletters but not to all. I found a solution, but I am not sure, if this breaks nothing else. Here is the problem:

I want to set up some newsletters: One with access from anybody (anonymous users can subscribe and view the archive) and some others with access only for special groups of users.

On global permission page I set 'tiki_p_list_newsletters' and 'tiki_p_subscribe_email' for anonymous users (this permissions are not available on the object permission page).

On the object permission page for the single newsletter (accessible through /tiki-admin_newsletters.php and the key icon of every newsletter) I activate 'tiki_p_subscribe_newsletters' and 'tiki_p_view_newsletter' for the group of users with permissions on this newsletter.

With this settings I would expect, that an anonymous user browsing page tiki-newsletters.php would see the list of newsletters, in this case showing only the public newsletter. But in this case there is an error (You are not logged in). As a privileged user (allowed to see all newsletters) the page is accessible but empty, not showing any newsletter.

{syntax type="tiki" editor="plain"}
When clicking the "unsubscribe" link from a newsletter email the customer is immediately taken to the site where they receive a "You are not logged in" error. If the customer were to first log into the site and then click the newsletter "unsubscribe" link in the email it works fine.

How to reproduce:
1. Allow Group Homepage
2. Set homepage for anonymous group: agr_home
3. Set homepage for registered group: rgr_home
4. make default page agr_home page
5. login -> you ll be redirected to rgr_gome -> thats ok
6. logout -> you ll be redirected to http://yoursitename.com/agr_home (note: not index.php?page=agr_home)

When you are using definition list plugin, if you want to use a colon in the definition, there is no way to do this that I know of because the colon is used to separate the term from the definition. If you have a second colon on the line, the second colon and everything after it is cut off (not displayed).

Tiki does not send out e-mail notification when tracker items are closed. They do get sent when set to pending.

Found that Tiki 9.x (9.0->9.4) has this issue.

LDAPv2 is obsolete, and the use of LDAPv3 is now standard practice. In fact, the [http://www.openldap.org/faq/data/cache/822.html|latest releases of OpenLDAP don't even support LDAPv2 properly anymore]. However, PHP's ldap_connect() and PEAR::Auth [http://www.openldap.org/lists/openldap-software/200204/msg00046.html|default to LDAPv2].

The patch to use LDAPv3 is attached. It shouldn't be difficult to make the LDAP protocol version a configurable preference.

There was an issue with the LDAP not syncing groups properly, and would thus cause a blank page to appear when logging into my site.

Essentially, the entire problem is attributed to a typo in the function name for the ldap_sync_groups function. The file ~/lib/userslib.php contains the function:

{CODE()} private function _ldap_sync_groups($user, $pass)
{...}{CODE}
The major problem is that this function name has a leading underscore (_) and causes an issue when it attempts to sync the groups with the LDAP.

Simply removing the underscore solves the whole problem. The function should be named as such:

{CODE()} private function ldap_sync_groups($user, $pass)
{...}{CODE}
This will make it so that when the file reaches the line:

{CODE()}$ret &= $this->ldap_sync_groups($user, $pass);{CODE}
It can successfully sync with the LDAP.

The string "isUsers" in line 1013, lib/userslib.php, must be enclosed in Backticks, else query will return postgres error when processed (because postgres will interpret the column name as "isuser" instead of "isUser")

Login page increments tiki_pageviews which skews viewing stats, IMHO, especially for sites which require passwords for content viewing, which may be additionally exacerbated if users maintain Tiki's login page as their browsers home page.