Category: 6.x

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

if you are trying to edit a page in a multilingual wiki where you have currently a language other than english selected (i only have german allowed in my tiki) you only see something like this (complete html output):
{CODE(wrap="1",ishtml="0")}<div class="floatright">
<a class="previewBtn" title="Vorschau Ihrer Änderungen." href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/magnifier.png" alt="Vorschau Ihrer Änderungen." width="16" height="16" style="border: none" class="icon" /></a></div>
<h1><a class="pagetitle" href="/test/tiki-editpage.php?page=test_de">bearbeiten: test_de</a>
</h1>

<!-- templates/tiki-preview.tpl start -->
<div class="wikipreview" style="display:none;" id="autosave_preview"><div>
<div style="float:right;">
<select name="diff_style" id="preview_diff_style">
<option value="" selected="selected">Vorschau</option>

<option value="htmldiff" >HTML diff</option>
<option value="sidediff" >Side-By-Side Vergleich</option>
</select>
<a title="Popup preview" onclick="ajax_preview( 'editwiki', autoSaveId );$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/arrow_left.png" alt="Popup preview" width="16" height="16" style="border: none" class="icon" /></a> <a title="Close preview" onclick="$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/close.png" alt="Close preview" width="16" height="16" style="border: none" class="icon" /></a> </div>
<h2>Vorschau : test_de</h2>
<div align="center" class="attention" style="font-weight:bold">Hinweis: Dies ist nur eine Vorschau und wurde noch nicht gespeichert!</div>
<div class="wikitext">

</div>
</div><span id="autosave_preview_grippy" class="ui-resizable-handle ui-resizable-s"> </span>
</div>
<hr style="clear:both; height:0px;"/>
<!-- templates/tiki-preview.tpl end -->

<form enctype="multipart/form-data" method="post" action="tiki-editpage.php?page=test_de" id='editpageform' name='editpageform'>

<input type="hidden" name="no_bl" value="y" />



<table class="formcolor" width="100%">
<tr>
<td colspan="2">

<input type="hidden" name="page" value="test_de" />




<div id='edit-zone'>
<div class='textarea-toolbar' id='editwiki_toolbar'>{CODE}

{syntax type="tiki" editor="plain"}
I tried some other languages, but it seems only to apear with the german translation.

The wiki css breaks if u change to german. most pages work well, but the wiki gets killed

If a user is watching/monitoring for when "any wiki page is changed"...
*"Monitor this page" should be disabled, and
*Old watches should be deleted.

{syntax type="tiki" editor="plain"}
If you click on an Edit Section button, the Switch Editor button is not available when you are editing.

In IE7, after double clicking an image to get the image plugin editor and making changes, a new image is created at the top of the page instead of editing the image plugin.

In IE8, the same attempt appears to make no changes to the plugin, but no new image appears either.

This works in Firefox.

adding pref will "fix" this. However, for IE, there is an additioal CKEditor bug that still needs to be fixed: [http://dev.ckeditor.com/ticket/4208]

{syntax type="tiki" editor="plain"}
The mechanism to alter a tiki sites logo uses a cumbersome server relative path mechanism. Not intuitive especially seeing as there is a file upload facility.

{syntax type="tiki" editor="plain"}
Hi,
I'm testing tiki 6.0. I found that there is a problem to edit submited articles with image uploaded in section "own image". After saving an article appears page:
406 Not Acceptable
.../tiki-edit_article.php with info:
"Not Acceptable

An appropriate representation of the requested resource /enigme/tiki-edit_article.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."

It happens during second editing. The error does not appear if there is no image uploaded or if the image is uploaded by WYSIWYG. In result of this, it's impossible to reedit some articles.

The second problem is adding new article with option submit article. When I user tries to apply a template the site doesn't refresh.

Best regards,
Tomek

{syntax type="tiki" editor="plain"}
Emails containing inline images fail to present when selected from the email inbox list. This is a problem for both jpg and png images. It does not seem to be relevant as to where the image appears in the email. I have tried with the image in the middle of the text as if the image has been sent as part of the content and at the very end as if a signature block with exactly the same result.

I rated this as a 7 as it makes the webmail feature unusable to the users of the [http://sistersafar.com|site] in question. This in turn makes the site itself, being designed to keep distant family members in touch with each other and friends, pretty much ineffective for the target audience. It does not however technically render anything but one site feature unusable so a rating higher than 7 does not feel justified.

--Steve

{syntax type="tiki" editor="plain"}
After upgrading from 3 to 6, resizing of images fail. I tracked it down to Imagick's scaleImage function resulting in broken image, hence all that is shown is the GIF icon. This is the case when using the {img tag with size set.

http://en.wikipedia.org/wiki/Gravatar
http://en.gravatar.com/site/implement/images/smarty/


https://www.libravatar.org/

An imported Mediawiki page that has

{CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}* a bullet
** sub bullet{CODE}

gets translated to

{CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}* a bullet
{DL()}
sub bullet
{DL}{CODE}

which results in the sub bullet and text not displaying on the page at all, except being represented by a small icon.

Yet if the importer had just left it as

{CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}** sub bullet{CODE}

it would have worked.

__Update:__ Sometimes it does get the nested bullets. But there are other places where Mediawiki stuff ends up in the DL tags where it shouldn't - with the effect that it disappears from the visible page.

{syntax type="tiki" editor="plain"}
I have created a new site, and asked some people to try and register on it, and tell me anything that confused them.

And it seems there is something about the registration sequence of Tiki that can be confusing to end users.

In Tiki, the sequence (as I have configured it) looks like this:

A) User registers
B) Admin receives a notification
C) Admin approves
D) User receives a notification asking for him to confirm his email. He clicks on a link to validate that he controls that email.

Because I am the sole admin and am not at my computer all the time (I do sleep 8h a day ;-)), there can be sometimes a couple of hours between A) and D). This means that for many hours, the user no “persistent” confirmation that his registration request has been noted. To be sure, when you register, Tiki prints a message on the screen that says you will receive an email notification and that this can take several hours. But it doesn’t send you an email until the Admin has approved the account. So, for say, 12 hours, you are wondering what’s going on, and you don’t have anything anymore that tells you it’s being processed (because the Tiki message is now gone from your browser). It’s easy for people to start wondering “Did this REALLY work? Did I REALLY see that message from the server saying that I would receive an email message?”. This is what happend to my test user.

In most systems I have worked with, the sequence is more like this:

1) User registers
2) User immediately receives a notification asking him to confirm his email. User clicks on a link to validate that he controls that email.
3) Admin receives a notification that someone with a valid email has requested a registration
4) Admin approves
5) User receives a note that his account has been approved

With this sequence, even if the admin takes a long time to approve the request, during that time, the user has a PERSISTENT acknowledgement in his email inbox.

Another advantage of the later sequence is that we don’t bug the Admin until we know that the email address is valid. With the current approach, if a spammer tries to register with an email that doesn’t exist, the Admin will be asked to approve the account anyway, and we will end up with an account that exists, but was never validated.

Do people agree with this analysis? And if so, do we know how easy or hard it would be to change the order so that step D) happens right after A) instead.

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

Recurrent problem since 4.0. already reported, seems to had been solved, so may be it's a regression. To test.

The sort command (by clicking into header) leads to a crash.

Before we got an SQL error, now the current selection is cleaned.

__Important details :__
* not tested (again) for each column in "table header"
* not tested for various selections of tracker items
* Sure : after a selection of items (content of selection not empty normally without importance : category feature and feature requests for all), a click on date column header which runs a sort command leads to an empty page for a new search.

I am quite sure that an error still occurs into the sort SQL command, but the error is kept and a locate to new search is made.

__What I am going to do :__
* Test for the not tested various conditions (already done six month ago)
* Test on my development version 6.x with xdebug (show the requests, firebug and eclipse)
* Check the SQL request(s)
__
Then write here the report __

Wiki 6 is incorrectly parsing text in wikilinks, in 4 and 5 this ~np~((Easy and Play|Easy & Play)) ~/np~ produced a wikilink like: Easy & Play

In 6 it produces : Easy & amp; Play

It is not possible to circumvent this by using an np command or by using ~038~ as per the documentation, that produces #038 rather than &

Why is the text that follows | in a wikilink not parsed as any other text ?

This is hard to explain. To reproduce, create below a page like this:

Link1
Link2

Link3
Link4

Paragraph formatting is on, so each line is on it's own paragraph. Take care NOT to press enter at the end of Link4 for now. There is no blank space before Link1 which is on the first line

Note the blank line between Link2 and Link3.

Now do the following test:
1) Select Link1 taking care to select only the text and not the start of line or end of line around it, click on Insert Wiki Link. You get Link1, all good

2) Select Link1 aggressively, dragging the mouse cursor to the left of the Link1 before the start of line, or alternatively to the right of the end of line. You will get Link1Link2Link3 picked up.

3) Now add an enter at the end of Link4 (the end of the text)

4) Now repeat step 2 above, you will find that instead if Link1Link2Link3 you will now pick up Link1Link2Link3Link4

5) Now another problem: If you highlight Link3 "accidentally" capturing the br above it (the blank line), and then click Insert Wiki Link, you get nothing.

6) Now select from beyond the end of line of Link4 back but only "nk4". You will get a garbage.

The above tests were done in Firefox.

In Safari, 5) is reproducable, but the rest can't really be reproduced except note that if you select Link2 accidentally capturing the blank line below, you get Link2Link3 or Link2Link3Link4 depending on whether there is a blank line at the end of the text.

In IE (IE8 and in IE7 compatibility mode), you don't get any text whatever you do. IN IE8 compatibility mode you get a "scroll bars appearing in the popup" which is a separate problem I suppose.

Insert Wiki Link popup has scroll bars in IE7 messing up view

{syntax type="tiki" editor="plain"}
Three queries fail during the installation of version 6.1 when using Mysql 5.5.9 because the deprecated syntax __timestamp(14)__ has been removed and should now be __timestamp__.

The queries that fail are the table creation queries for tiki_banning, tiki_friendship_requests, and tiki_users_score.

This is essentially a duplicate of Ticket ID 2213 except to clearly note the solution and that it affects TikiWiki 6.1 and Mysql version 5.5.9.

If you install a brand new Tiki6 site, and your database was created with latin1 charset (by sys admin, phpmyadmin, by whatever means), Tiki doesn't warn you at installation time that the db is using latin1.

Only when you upgrade the Tiki6 site, tiki detects that db and tables are not utf-8, and allows converting them to utf-8.

This can be reproduced easily with the TikiLiveCD 0.6, which came (from a customized Slax GNU/Linuxd distro) with an empty db called "test" with latin1 charset, that is to be used for Tiki installation.
http://tiki.org/TikiLiveCD

Since r20087, database errors during the installer have an empty error handler, because failures in queries from upgrade scripts are already properly reported.

This unfortunately also has the bad effect of quieting all other errors in queries outside upgrade scripts.

In tables
tiki_comments, tiki_history, tiki_pages, tiki_tags tiki_user_voting
the column IP is too short (varchar 15) for IPv6 logging

In tables
tiki_actionlog, tiki_download, tiki_logs the column IP is very big (too big ?) varing from 39 to 200 char . In tiki_download the IP cloumn is in UPPERCASE (may be problem with some Mysql installation)

In tables
tiki_banning
the IP is split in three columns . so we can't bann an IPv6

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.

Machine translation ( http://doc.tiki.org/Machine+Translation ) seems to be broken in Tiki 6 LTS, at least.
No content is translated from the page.

The same site (before upgrading months ago to tiki6) had that feature working.

Is this feature working for anyone on any stable (non deprecated) tiki version?
--
Update:
I've just checked on localhost with 8.x (r38429), and the feature still exists in admin panels. When enabled, and attempted to request to have a wiki page google-translated, a blank page is shown :-/

{syntax type="tiki" editor="plain"}
I defined a structure Helpdesk FAQ and a categorie Helpdesk.
Now I give a group Helpdeskadmin the permission tiki_p_edit (and a lot of others).

If a helpdeskadmin trys to add a page with the button on the top of the wikipage with over the toc, the message "You do not have permission to edit this page." appears.

The problem seems to be the following permission test in tiki-editpage.php:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

If I give the permission tiki_p_edit to the group, the helpdeskadmin comes to the wysiwyg-edit-page, also he gets a message like the page must have a categorie. I didn't analyzed that yet.

{syntax type="tiki" editor="plain"}
Does the "Users Information Tracker Fields Asked at Registration Time" work for someone in 6.1? it used to work in 5.x. not pretty.

This feature was not particularly important if the trackers with registration="y" would work nicely. Read more here.
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-08,Sat&sel=52#l48]