Category: Release60

{syntax type="tiki" editor="plain"}
The email sent to the admin with the form that was filled by an anonymous user, it shows the email address of the user but only the part that is before de "@" sign.



Using
Tiki 6.2

and I formerly encountered this error in
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

The email sent to the admin with the form that was filled by an anonymous user, it shows the email address of the user but only the part that is before de "@" sign.



Using
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

{syntax type="tiki" editor="plain"}
1) Column colapsing is not remerbered whenever I change from one page to another.

2) And also have had some problems with their navigators saying "cookies must be on" when they are on, no matter wich browser is being used. This happends as they attemp to login. After many tries the user can login.


Using:
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

{syntax type="tiki" editor="plain"}
System error.

The following error message was returned:

Unknown column 'reltype' in 'field list'

The query was:
SELECT `fromPage`, `toPage`, `reltype` FROM `tiki_links` WHERE `toPage` LIKE ? AND `reltype` IS NOT NULL

Values:

1. Editor Test

The built query was likely:
SELECT `fromPage`, `toPage`, `reltype` FROM `tiki_links` WHERE `toPage` LIKE 'Editor Test' AND `reltype` IS NOT NULL


--------------Link-------------------

tiki-editpage.php?page=Editor+Test&quickedit=Create+Page

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

Tiki 6.1

This will make upgrades easier as people won't have to worry about overwriting their enhancements,

Multilingual categories need translations and doing by FTP is not fun.

Related:
[tiki-view_tracker_item.php?itemId=485] -> This is suboptimal


Support.mozilla.com has need for this as well.
https://bugzilla.mozilla.org/show_bug.cgi?id=488728

In 3.0, language/*/custom.php can be managed by the web interface.

Next step is to have this in a wiki page

When writing a particular wiki page, and being set this page to be watched to a group (let say Registered users).

Then if the page has plugingroup to hide particular peaces of special text that is not intended to be known by certain users. Then every time this page changes, a notification email is sent to all Registered users (this is ok), but in the content of this email all the source code is revealed to EVERY user on the Registered group, regardless if they have the right to see Source of wikis.

Don´t know how this could survive the testing and dogfood of this community. May be there is another way to let the Registered group to be acknowledged of a change in a wiki, without compromising content. Please enlight me on how to do this much of the work done on our live tiki portal uses plugingroup to restrict snippets of text to certain groups and other snippets has to shown, in the same wiki.

There should be an option to configure a watch to be sent in a way that only alerts the user that a particular page has changed without showing all source, in respect to a particular right to see or no to see the source.

I have checked on the proper user rights and object perms to avoid them to receive this notifications in the proper way, but tiki doesn´t seem to take it.


Using Tiki 6.2

Hi,

Because of partial translations of pages, I use French or English GUI translated and sometimes Spanish, Italian or German.
Because I Have defined complementary of elements of GUI dictionary, it is not so evident to take care the whole time with which language you are working and more the associated date format.

It is the reason, while, after, some errors in input dates in a wrong format that I do believe that the current format to input a date should be always repeated into display tpl or input title (displayed).

This is a long and progressive but useful job in my opinion.

Each time I can do it, I do.

{syntax type="tiki" editor="plain"}
dev.tw.o: users apparently can delete their tracker items but they are not deleted and no message

To reproduce:
* Log in as normal user to dev.tw.o (without admin perms) (ot test with user "xavi" if you prefer).
* report a bug/wish
* edit it in order to see the edit form
* click on the red cross to delete it
* after that, you are shown the list of tracker items, as if your tracker item was already deleted. No message indicating any problem is shown. However, the tracker item is not deleted.
+ Example: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2879

---
reported in comments as still around in tiki5 and tiki6

{syntax type="tiki" editor="plain"}
As Admin, when I create new Topic Post in a Forum, and add Tags and post... if I edit the former post tags, adding more tags, they are not saved. The former tags remain.


General Settings:

Tiki 6.0 fresh install.

Problem solved in 6.2

I have a drop-down-with-other field with value 0 (zero) as default in a tracker form (so options for that field are "0,0"), but when I see the tracker dropdown to insert items, the drop down gets populated with some string about the sandbox...

still occurring in latest baraches/6x (r30164)

{syntax type="tiki" editor="plain"}
As the calculated size of the line, depends of the size of the panel (resizable) is wrong (too of some ... <unable to translate, in printing in french the length unit "point">).
Then the line is always too long of a few for the panel (words or half of words cut before splitting the line).

This makes the blog edition unusable in normal conditions because to edit a text we have to make horizontal scroll continuously.

Analysis : the calculation of the length of line written in text editors is always complex. Generally today there is no problem, but the system which is behind editors is very complex to take in account all display configurations.

(nota : For my own I had developed some years ago a draw system - for engineering, Computer Assisted Drawings - system for windows displaying HPGL2 language drawings with fonts conversion from HPGL2 fonts system to True type, then I know well in details the whole problem)

~~#F0C:__With this problem, I can't let use the tikiwiki 5.3 by my bloggers.__~~

So I have written a warning take care "sorry very difficult to use"

{syntax type="tiki" editor="plain"}
In Opera (no need to mention version number; every Opera user uses the lastest version ;-) ), in the last day or so the edit textareas in branch 6 have been missing or misplaced, for wiki pages and trackers, that I've noticed so far. (Forum post forms are ok.) On the wiki edit page, the edit textarea is far down from the toolbar. Sometimes clicking on fullscreen edit and back again will bring it up to the toolbar. On the dev.t.o bug-submitting tracker form, the textareas for description and solution don't appear at all. I clicked on fullscreen editing and back, and a textarea appeared but it seems to be the solution textarea, not the one for the bug description. This affects the regular wiki editor; I didn't check yet about the wysiwyg editor.

{syntax type="tiki" editor="plain"}
error when uploading files with accented names in batch directory in File Gallery

If you use Directory Batch upload of files, if files have particular language characters like "á" then it shows an error on the report for those files.

It works well with other file names that do not use this type of characters.

Settings are:

Uploading to directory ON

{syntax type="tiki" editor="plain"}
Cannot use wysiwyg editor in blog if we want also to use excerpt feature.

If any temporary or fixed solution can be found...

Many many thanks

When using a user tracker to collect additional information per user during registration process, it would be great if you could specify to include that information in the user popup/mouseover.

{syntax type="tiki" editor="plain"}
PopUp window for viewing image does not show up when browsing to a 2nd page.

Instead it shows the picture file going out the File Gallery.

Using Firefox, Chrome

Spreadsheets can be created directly through wiki SHEET plugin directly within wiki pages. this allows managing big tables visually, as well as having the data ready for producing graphs, etc. (see documentation for tikisheets at doc.tw.o, if needed)

However, when you create a sheet through a call to the SHEET plugin from the wiki page itself, there are 3 issues which need to be fixed:
# you need to know the id you want to assign it to,
# after that, tiki-sheets.php doesn't list it (even if the sheet is really created, and you can import data to it, and show it at the wiki pages, etc.).
# the sheet is not shown with the right css

Even if we have wysiwyg option available, I still think that is worth improving tiki sheets usability to be used directly from wiki pages, once those 3 previous issues are fixed.
---
Updated on Feb. 2, 2011, using trunk (7svn)
# Steps to reproduce the first issue
## Edit a wiki page
## Use the plugin helper to create a new sheet in that page. And since it's a new sheet, it doesn't have a sheetId yet, so that you leave all fields empty in the plugin helper for the pluginsheet
++ this will add this type of code in your wiki page:
++ {CODE()}{sheet}{CODE}
## Save the wiki page
++ you will see an empty sheet shown in place at that wiki page, with the button at the bottom to allow the user to "edit it" (so far, so good)
## Once you click in the edit sheet button, you end up in some url like this one:
++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=&parse=edit
++ which produces a WSOD (blank page).
*** In my case, I guess that this url should have been:
+++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit
+++ since I had only one sheet previously created, with sheetId 1, so that the next one should be 2. However, this new url is still producing WSOD for me. (tiki caches cleared, just in case, repeated this step, and same WSOD)

The expected behavior is that the user is the user would be editing a blank new sheet with the url:
http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit

and when the user saves that sheet, the new sheetId 2 exists, and the user is either sent back to the wiki page where he clicked at the button "edit sheet" (preferable option) or either sent to the corresponding tiki view sheet 2.

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

{syntax type="tiki" editor="plain"}
{CODE(caption="tiki-login.php line ~308")}if ($prefs['limitedGoGroupHome'] == 'n' || $url == $prefs['site_tikiIndex'] || $url_path == $prefs['site_tikiIndex'] || basename($url_path) == $prefs['site_tikiIndex'] || ($anonymous_homepage != '' && ($url == $anonymous_homepage || $url_path == $anonymous_homepage || basename($url_path) == $anonymous_homepage)) || ($tikiIndex_full != '' && basename($url_path) == $tikiIndex_full)) {{CODE}

for $prefs['limitedGoGroupHome'] == 'y'
the sefurl will not match

The group theme functionality no longer works in 5.x and 6.0.

To test:
*Set "each group can have its own theme" in Admin>Look&Feel>theme
*Admin>Groups, edit a group and try to set the default theme for a group.
*nothing happens.

*theme control - still working.
*user preferences - theme - still working.

I got a strange problem when writing a text in square brackets (in trunk):

~np~[[These brackets] should stay~/np~

should result in the output
~np~[These brackets] should stay~/np~
but they produce
~np~<a class="wiki" href="These brackets" rel="">These brackets</a> should stay~/np~
It works as expected in 5.0

Installed a clean TW6.1 for a new multilingual project.
Choosed to limit languages to either german or english.
whenever the language is set to german (english works fine btw.) and i want to go to an admin subpage (like tiki-admin_modules.php, tiki-admin.php works fine) i only get (i guess) the $mid part of the templates - white background with unformatted text and no js or css

{syntax type="tiki" editor="plain"}
If you create a page or subpage for a structure with the bar above the displayed page you will asked for a language. after you select the language and enter the text into that page and submit it the page gets created but not put into the structure

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