Category: Patch

{syntax type="tiki" editor="plain"}
If you have a tracker with fields e.g
X text
Y radio buttons, mandatory
Z date
and you would like to offer the user to update X only, or X and Z only, keeping the old value of Y, it won't work. The error message you get is that Y is mandatory.

{syntax type="tiki" editor="plain"}
Any dynamic list or other drop-down list will not get its default value, when modifying the item, or when it gets prefilled (or when autosave value is available).

{syntax type="tiki" editor="plain"}
TW5.0beta1
Tried a field($fieldid,user,$trackerid) expression, and it does not work if the $fieldid is of item link type.
Debug insight:
While field($fieldid,user,$trackerid) results in the unresolved itemid referencing to the item link domain, the
{CODE(colors="php")} $items = $trklib->list_items($trackerId, $tr_offset, $max, $tr_sort_mode, $passfields, $filterfield, $filtervalue, $tr_status, $tr_initial, $exactvalue, $filter, $allfields);
{CODE}
call does not work. Namely, $trklib->list_items(..) works with the resolved item links. Therefore, there is no match.

Hi guys!
This is my first contribution with the tikiwiki community.

Here follows my fixes to the trackers filters that occurs when someone selects a filter and try to select another filter. The input for the filter where alternating between visible or not, causing the bug.

Thanks!

In my installation, on some internal links that are represented in an absolute way, there is a backslash between the domain name and the first slash.

Eg when I try to login on http://mydomain.com/index.php, I get redirected to http://mydomain.com\/tiki-login.php, which the server cannot render.

Clean install of:
MS Windows Server 2003 SE SP2 on x86
Apache 2.2.10
MySQL 5.1.30
PHP 5.2.8
TikiWiki 2.2

Tiki resides directly in the DocumentRoot C:\tiki (as it is a dedicated server).

In tiki-setup.php, there is a line

{img src=images/code.png}%%% {CODE()} $tikiroot = dirname($_SERVER['PHP_SELF']); {CODE}

In the documentation of [http://www.php.net/dirname |((dirname))], they state that since PHP 4.3.0, dirname returns unexpected values. The example implies that on Windows dirname('/x') returns '\'.

Therefore, if you install Tiki in the DocumentRoot, _SERVER['PHP_SELF'] will be '/filename.php' and $tikiroot will be '\'.

poor translation to portuguese (standard)

With the 1.10b (and latest svn changes) it is meant for admins to be able to change the creator of the forums.

Unfortunately, all users with permission to create blogs, can now create blogs for any other user - even if they can not post to them.

It seems that the latest file templates/tiki-edit_blog.tpl and .php requires that a value for the creator is passed back from the field Creator. Thus, the field has to be present with a valid content.

When on a wiki page on my tiki, I have the options available to watch the specific page or to "Monitor the sub-structure". When clicking on the latter, I am redirected to a permission denied page and the watch for the sub-structure is not set.

Even admin is being denied the permission to set a sub-structure watch on a wiki page.

Setting a watch on a sub-structure inside the structure-admin menu works fine for any permitted, though.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Webhelp miss utf-8 specification for the tree menu.

{syntax type="tiki" editor="plain"}
I the user mail for registration confirmation the german translation for "you or someone registered this email address at" is a uncompleted sentence.

When you create an article and try to give formatting to it it puts weird symbols. For example, for bold, instead of putting a word bold it puts weird symbols around the word.

When you are trying to add a file to the article, so the reader can download it with a click, or when you want to add a link or if you want to add an image; all this buttons do not work.

Instead, at the moment that you are uploading the image or the file you will see some explanation of a code that you have to add to the body of your article so you can show an image or a link to a file in the Wiki.

This is not user friendly at all, __making the user experience very bad__.

Regards,

No XML RPC interface for Wiki

{syntax type="tiki" editor="plain"}
I applied the patch from bug report 2956. Only one of the zipfile content files is added.

{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

Sorry - these patches were committed quite a while ago - just forgot to close the item

-------------------------------------------------------------------

I have recently started to use the Calendar function in a new v2.2 site and I found a number of illogical/inconsistent functions that I changed by simply editing the .tpl files. I think some of these are sufficiently useful that I'm submitting them as patches - I'm not really set up to do the whole SVN/developer thing at present.

Here is a summary of the changes/adaptations

__tiki-calendar.tpl__ - original source {* $Id: tiki-calendar.tpl 13045 2008-05-29 07:07:56Z chibaguy $ *}
# logic changed so that Config/Options button is ONLY shown if the user is the admin
# logic changed so that Add Event button is only shown if $displayedcals|@count >0


__tiki-calendar_calmode.tpl__ - original source ?not shown?
# explicit ~np~%d/%m~/np~ used for day/month on each day 'cell' to show European style of date. This is just an interim patch to change the existing 'hard coded' version which shows ~np~%m/%d~/np~. It should be possible to change the logic to extract the right format from the General Admin time/date settings - am still looking at this
# logic changed for additional check to NOT show 'add event' in day cell icon if no calendar 'visible'


__tiki-calendar_nav.tpl__ - original source ?not shown?
# swap ~np~%B %e~/np~ to ~np~%e %B~/np~ in several lines in the "calnavigation" div - again to adopt a European style. Still looking to see how this can automatically extract the right info from the general Admin time/date settings

tikiwiki v 4.3 does not have possibility of reminding on events in calendar

The "Change language for this page" form fails when it's applied to an Article.

We have a registered user X with right tiki_p_modify_tracker_items.
X tries to update a field using the tracker wiki plugin, and fails.
"You do not have permission to modify an item"
Please review my correction proposal. I am rather new with both php and TW.

guys.. I fixed the probem.. doesn't appear that I can upload anything..


dthacker: thanks for the fix, but our dev's can't see what you changed. Could you please do a diff between your code and current CVS, and comment on the changes? Thanks!

The multilingual/translation support is integrated with the WYSIWYG feature in a way that if you are working in an English interface, the text direction in CKEditor remains LTR even when the page being edited is defined as being in Hebrew, which is RTL. I expect that this applies to any other RTL language.

Similarly, it seems to me (though I haven't tested it thoroughly) that a user working in a Hebrew interface would get RTL behaviour in CKEditor even when editing an English page.

I can only assume that use of the English-language interface for editing Arabic pages and Arabic-language interface for English pages is common, as such combinations are certainly common where Hebrew is involved. The forcing of direction according to interface language rather than page language is likely to be a significant annoyance in all such cases.

The ideal solution would be to make the editor direction dependent on the page language's direction, and only according to the user's language if there is no page language set (there is a CKEditor option which does that - see http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.contentsLangDirection)

Yeah, we're building a COBOL advocacy TikiWiki site. The CODE plugin removes leading indentation. FIXED format COBOL uses a 6 character sequence number, column 7 as a special indicator and actual code starting at column 8. The initial $code = trim($data); is inappropriate for COBOL, and perhaps for other snippets that need to be cut'n'pasted with indentation intact.

I'd almost just go ahead and commit the change, but I'm not experienced enough with the technical details of PHP, and worry that the solution I'm using locally is not an unacceptable performance hit or that using the > v4.1 charlist feature of the trimming functions breaks legacy Tiki installations. I doubt it, but I thought I'd start here and get expert opinions.

{img src=images/code.png}%%% {CODE(colors=>php, title='lib/wiki-plugins/wikiplugin_code.php')}
function wikiplugin_code($data, $params) {
if ( is_array($params) ) {
extract($params, EXTR_SKIP);
}
$code = trim($data);
$parse_wiki = ( isset($wiki) && $wiki == 1 );

// Detect if GeSHI (Generic Syntax Highlighter) is available
{CODE}

All that is required is changing trim($data); to rtrim(ltrim($data, "\n\r\0\x0B")); so that leading spaces and tabs (tabs, they should be removed ... just because ... but that's not playing nice with others) are left intact.

We're using GeSHi, but this trim occurs regardless.

Thanks for listening,
Brian

Bundled themes readiness, see ''New Css Entities'', Fix broken themes ((tw:RecipeRestoreCss))