Category: Patch

{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))

{syntax type="tiki" editor="plain"}
Tracker plugin:
Imagine we would like to offer modification of a dynamic list field without offering modification of its reference field. In this case, the dynamic list should fall-back to a simple list with no selectValue calls in the js.

Please see:
https://wiki.mozilla.org/Support/l10nPriorityPRD


This should be not just for localizers but editors in general.

[12:55] lphuberdeau: where can I see the l10n dashboard in action?
[12:55] djst: https://support.mozilla.com/sv-SE/kb/Localization+Dashboard?bl=n
[12:56] djst: lphuberdeau, this page explains the syntax for the plugin https://wiki.mozilla.org/Support/l10nPriorityPRD/Plugin_Usage

{syntax type="tiki" editor="plain"}
When editing a Wiki page, or even creating a fresh Wiki page, The editor is loading, with text Loading ... but it never ends, and the striped bar continues to run.

The environment is 26.2 and comes from a migration from 23.
I have looked into the tiki logs, but nothing, and no mention in the apache error log.

Browser console says:
Loading failed for the <script> with source “https://site-name.com/Wiki/Tiki26/vendor_bundled/vendor/ckeditor/ckeditor/plugins/MediaPlayer/plugin.js?t=N5UC”. tiki-editpage.php:1:1
Is there any place where the MediaPlayer plugin is available?

Best regards, hubert j.

{syntax type="tiki" editor="plain"}
I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

Email notification don't work except if "watch minor" is checked

If you write a wiki article for example and want to insert a image or picture you already uploaded you use the button for picture.
Then you select file galleries as the data source and want to select a file directly within the file gallery.
That's not the real problem. But as soon as you use elFinder for file gallery view you still can select a image but it will always insert a whole code tag within the "image id" field (eg. {img fileid="34" ...}) and not only the fileid itself.

The fix is really easy, you just need to edit the file [yourtikihome]/templates/tiki-list_file_gallery.tpl at line 294 and replace this line with the following:
{CODE(caption="templates/tiki-list_file_gallery.tpl")}window.opener.insertAt('{{$filegals_manager}}', data.fileId);{CODE}

Maybe you should fix this in a following version, as it's really annoying to fix the form every time.

-------

the patch doesn't seem to work. still having the issue of the full plugin code gets injected.

This is probably a Jonny bug now since it touches ElFinder

As installed, there is no easy way to globally style the overLIB popups. Preferably, there should be css classes defined so that themes can style the popups to match.

This patch (attached) can be used to replace the same file in folder lib/smarty_tiki

A blank line out of a paragraph should not start a new paragraph (as in 4.2). If feature_wiki_paragraph_formatting_add_br is on, an empty line is created on top of the new paragraph.
It comes from lib/tikilib.php line 6838ff
} elseif (!$in_paragraph && !$contains_block) {
// If not in paragraph, first non-blank line; start a paragraph; if not start of div created by plugins
$data .= "<p>";
...

in the comment it is stated that the paragraph should only begin at first NON-BLANK line

The following appeared at top of browser window, when opening most versions of tiki
Warning: in_array() expects parameter 2 to be array, bool given in binderlib.php on line 51

I changed: if (in_array($categId, $descendants)) {

to: if (in_array($categId, array($descendants))) {

Now the warning is gone.
IS this OK?

{syntax type="tiki" editor="plain"}
Using the [http://doc.tiki.org/PluginFtp&structure=Documentation|FTP Plugin], when you try to download a big file you'll encounter an error like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 59506688 bytes) in /home/myUser/public_html/lib/wiki-plugins/wikiplugin_ftp.php on line 65

In this case, I had tried to download a 56 MB file with a PHP memory_limit set to 128 MB on my hosting.

Having a wiki plugin that is not readable by apache in the plugin directory causes an infinite loop when the user attempts to edit a page, because edit page tries to load a list of plugins and descriptions in the help.

tiki-editpage.php calls wikilib.list_plugins(), calls get_plugin_description(), which doesn't check open status after fopen().

{syntax type="tiki" editor="plain"}
This has been seen on Tikiwiki 2.0 & 2.2: Trying to install the "googlecalendar" wikiplugin from "Admin mods" fails. A page appears stating "wiki-plugins/googlecalendar/wiki-plugins/wikiplugin_googlecalendar.php to impossible to copy".

This appears to be caused by a typo in the Packages/wikiplugins-googlecalendar.info.txt file on the line that states where to copy the plugin file to. There is no space between the source and destination paths and the "lib" directory the plugin should be copied to is missing.

With version 2.2 (not checked previous versions) using the "Show/Hide Menus" option to collapse a left or right hand column with IE7 gives page errors and does not execute. Error message says:

Line 409
Char 4
Error: Could not get the display property. Invalid argument.
Code:0
URL: http://dev.tikiwiki.org/tiki-index.php

Function works fine in FF3 and (surprisingly) IE6 but gives exactly the same problem across a number of different tiki sites with IE7, including dev.tikiwiki.org.

The error message (it is assumed) refers to the function flip(foo,style) in lib/tiki-js.js

FIXED

Text mime parts of mail messages are initialized with an improper Content-Transfer-Encoding MIME header of 7bit instead of 8bit