Category: Release60

With CSS Menus enabled (PHP Layers disabled), text and images on the background page show through the menu. See attachment image.

I can reproduce this on tw.o, as well as www.cbbca.ca (coelesce theme) but only using IE7 (I have reports it's broken in IE7 as well).

I looked for a z-index setting that was wrong, but couldn't find any. It may be a background transparency problem.

{syntax type="tiki" editor="plain"}
The template tiki-print_blog_post.tpl uses the classes posthead for div and span which are not defined...

This is not ended it is good for an alpha version. Not a publish release.

The title or the blog post is then displayed are small...

The title of the blog is not at all displayed
The site name is not at all displayed
The subcomment of the blog at all displayed

__Even Copyright is activated nothing is defined.__

__This print function can't be used.

If you can't print the text of post of a blog which under Copyright the blogs themselves are not usable.__

__The admin of such a site is then not in good conditions when this function is used.__

tiki-register.php has a few flows:
- the string "Passwords match" is not translated even if added to translations
- the string "Passwords don't match" is not translated even if added to translations
- the input fields (username, email, code, etc) are not aligned to the left, this is not nice

tiki-login.php:
- the string "Log in as..." is not translated even if added to translations

Try here: http://dev.tiki.org/tiki-view_tracker.php?status=o&trackerId=5&sort_mode=created_desc
Maybe it happens only when AJAX is on.

{syntax type="tiki" editor="plain"}
The comparison method in the TrackerFilter plugin is not comparing.

No matter which operator you choose

>, <, >=, <=

( for greater than, less than, greater than or equal, less than or equal)

it returns all the records.

This is if performed on a text or a numeric field so far.

Tested on three tikis.

Sample of code (produced by the the wiki's plugin help)

{CODE(caption="trackerFilter code used")}{TRACKERFILTER(filters="54/<=",action="find em",trackerId="13",fields="53:54")}
here ya go
{TRACKERFILTER}{CODE}


!!Update
I have reproduced this on a completely separate system, http://www.softaculous.com/

Brand new Tiki 6.1
Only Trackers turned on (over a default installation)
One tracker with one field

Using the filter value 1/>

It returns all records.

Admins and other groups can see all tracker items if status="opc" is set, while an anonymous user can only see the open items.
TW5.0Beta1

Example:
~np~{trackerlist trackerId="1" fields="23:11" sort="y" showtitle="n" showlinks="y" showdesc="n" showinitials="n" showstatus="y" showcreated="y" showlastmodif="y" showfieldname="y" showitemrank="n" status="opc" sort_mode="lastModif_desc" max="10" showpagination="n" filterfield="43" filtervalue="C" ignoreRequestItemId="y" silent="n"}~/np~

The open and closed issues are fine.

- Imagine you have a record with ten fields, but you only have a 'n' in the last column. It is not easy to select this column.
- Since each field contains a separate field, it suggests that each brings you to some different page.
- If one link of a record is active, the record is not selected.

{syntax type="tiki" editor="plain"}
Syntax error is present in the file "lib/trackers/trackerlib.php" row 870:
{CODE(caption="syntax error")}...
if (in_array($keys[0], array('<', '>', '<=', '>='))) {
...{CODE}
[http://ru2.php.net/manual/en/function.in-array.php|Manual for function in_array()]:
{CODE(caption="manual")}bool in_array ( mixed $needle , array $haystack [, bool $strict ] ){CODE}
May be need correct row 870 for code:
{CODE(caption="syntax error")}...
if (in_array(array('<', '>', '<=', '>='),$keys[0])) {
...{CODE}

{syntax type="tiki" editor="plain"}
1) Child links are "usually" (not always) configured to point to a bad Url.

Instead of taking you to :

http://mi.solcentral.org/tiki-list_file_gallery.php?galleryId=5

it will take you to

http://mi.solcentral.org/Textos%20Codificados

and Sefurls (Search engine friendly url) is OFF

You can see if for yourself in http://mi.solcentral.org/tiki-list_file_gallery.php?galleryId=2

I have changed Theme to see if its a Theme things and the problem persists.

The problem does not arise accessing with IE 7.0 since the Tree Control is not showed up at all (don´t know if this is also an error really, if you know tell me...).

2) Icons change. Instead of showing one type of icon in the tree structure, it shows two types.

Please Help

----
Tiki V 6.0 fresh install
Server: Windows
PHP Version: 5.2.6
Ram: 128 Mb

The {tr} tags are disregarded in the tiki-register.php and tpl.

{syntax type="tiki" editor="plain"}
Verified using Tiki 6.1:

I attempted to create a new page within a structure, by using the structure navigation bar (add page). Tiki creates the page, but does not place it within the structure. Using the "add as child" option makes no difference.

This worked correctly in 5.3

{syntax type="tiki" editor="plain"}
Experienced with Tiki 6.1. Consider the following:

#User adds an image to a wiki page by uploading it to the File Gallery.
#After successful upload, Tiki automatically inserts the necessary code:
+{CODE()} {img fileId="99" thumb="y"... {CODE}
#At a later date, the user wants to update/replace the image. There is no way for the user to find the image in the File Gallery, if you only know the __fileId__.
Attempting to search the file gallery for the __fileID__ will ''__not__'' find the image.

Proposed solutions:
#Make the fileID searchable.
#When editing an image via the Edit Plugin, there should be a way to automatically go to the correct file gallery.
#Add an optional field in the __img__ plugin for fileId.

{syntax type="tiki" editor="plain"}
On updating Tiki 5.2 and earlier to 6 errors occur during installation.

^Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement
fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO MYSQL_ATTR_USE_BUFFERED_QUERY attribute.^

The problem is discussed [http://tiki.org/tiki-view_forum_thread.php?comments_parentId=39458&topics_offset=5&topics_sort_mode=lastPost_desc&forumId=6|over here]

--
Chealer:
This does not happen upgrading from a clean install of 5.3 to 6.0. But it happens when upgrading from 5.0 to 6.0. The most problematic script appears to be 20100927_better_column_fix_tiki. The first query (getOne() on information_schema) seems to be the sticky unbuffered query sometimes, since the following, second query fails. I tried but couldn't find how to confirm what query is stuck. It's odd that this problem only happens in the installer. getOne() just like query() use fetchAll() so we shouldn't see this problem. Setting MYSQL_ATTR_USE_BUFFERED_QUERY doesn't seem to help. After some 10 hours of debugging I'm under the impression this is a PDO bug. This looks like http://bugs.php.net/bug.php?id=44081 If anyone wants to try fixing, I recommend speaking to me first. The PDO documentation is very poor, making this really difficult.
20100927_better_column_fix_tiki was introduced in 5.3.

I found upgrades would work with PDO in certain environments. I had the bug on PHP 5.2.13 but upgrading to 5.3.3 fixed. PHP 5.3 can use mysqlnd, which I suspect doesn't have this problem. The upgrade worked for me on vanilla PHP 5.3.3 or PHP 5.3.3 from EasyPHP, both with mysqlnd. I have no clue why this problem seems to only affect Windows, but I saw reports of similar problems on Debian etch, so it may not be completely Windows-specific. Anyone who experiences this problem, please report your PHP version, and if you use PHP 5.3, indicate whether you use libmysql or mysqlnd.

{syntax type="tiki" editor="plain"}
{maketoc}
!Problem Summary
The dialog structure for uploading a file and adding a link to it in wiki page is much better than it was, thanks to the introduction of the __File__ icon in the toolbar of the wiki editor. But it is still cumbersome and error prone. Here is the process below and the usability issues that I found at various spots.

# Click on the __File__ icon
# Pick __File Gallery/Archive__ in __Type__
# Click on __Pick a file__ link
# Click on the __Upload File__
# Click on the __Browse__ button
# Click on __Upload__ button
# Browse the file system and pick the file.
# Once the file is uploaded, click on its name.
# Click on __Insert__ button

Besides the fact that this is long, there are many places where it is misleading to the user (details later). I had to try this more than a dozen times, clicking on different items, to figure out how it works. And I had help from some experts on the mailing list!

Fortunately, there are a number of very small fixes that we could implement to address those issues. See below for a discussion of the various issues and proposed fixes.

!Issue 1: __Type__ should have a reasonable default
Currently, the type is set to empty. It really should be set to either __File Gallery/Archive__ or __Attachment__ by default. Personally, I would favour __File Gallery/Archive__, because I think it's generally a bad idea to attach files to a wiki page, because it limits your ability to link to those files from other pages. But the point is: the value should default to what users most commonly use.

In some cases, the picklist only has one option in it anyways (ex: if the feature for attaching files to wiki pages is off). In those cases, then the picklist should DEFINITELY default to that single value.

^Fix: Set the __Type__ to a sensible default... I vote for _File Gallery/Archive__^

!Issue 2: __Pick a file__ link looks more like a caption than something you can click on
I never realized that I could click on it to choose the file. Someone had to actually point that out to me. Others on the mailing list have said that they need to point this out to users all the time.

^Fix: Change the link to a button^

!Issue 3: Too easy to miss the __Upload__ button
Once you click on __pick a file__ link, you are presented with the general screen for navigating and managing the File Gallery. But at this point in time, you are only intersted in uploading or choosing a file from the gallery, and seeing this complex dialog is very disorienting. In my case, I managed to miss the fac that there was an __Upload__ button on that screen, and I thought I had mad a mistake and someone pressed the wrong button or link in the previous screen. I had to go back to the previous screen several times and click on different things, and finally come back to clicking __pick a file__, and then I saw the __Upload__ button.

^Fix: Instead of having a single __Pick a file__ link (well, button, if we implement the fix to Issue 2), we should have two buttons: __Upload__ and __Choose from Server__. Or something like that (I can't think of a good workding). The __Upload__ button will take you directly to the place you currently get to after clicking on the __Upload__ button in the File Gallery screen. The __Choose from Server__ button will still take you to the __File Gallery__ navigation and management menu.^

!Issue 4: Not clear that you have to click on the file name after uploading
In Step 8, there is nothing that tells you you need to click on the file name after you uploaded it. I went through the whole process several times and it never occured to me that I had to do this until someone from the mailing list told me.

Note that there is a message to that effec that appears if you hover the mouse over the file's name. That message really should be visible at all times, not just when you hover over the file name.

^Fix 1: Make it so you don't need to click on the file name altogether.

Fix2: If that's not possible, at least put a very prominent messages saying that the user needs to click on the file name^

!Issue 5: Insert button is not clear.
In Step 9, you are back at the original pop up, and you need to click on the __Insert__ button, otherwise the link to the uploaded file does not get inserted.

Again, I had to do the process several times before realizing I had to do this. My natural tendancy was to close the popup, either by Xing it or clicking on the __Close__ button. The result is that the file does not get inserted on the page.

I think the problem is that the two buttons at the bottom say:

__Close__ __Insert__

And you naturally tend to click on the first of these two, i.e. __Close__.

^Fix: Change the order and caption of the two buttons as follows:

__Insert link__ | __Cancel__

Also, if the user clicks on the X to close the window, the link should be inserted (in other words, __Insert link__ should be the default). The reason is that it's easier to recuperate from that error (you just need to erase the link) than to recuperate from the other error (you have to start again from the beginning, to insert the link).
^

I had tested and finally used in 5.3 HTML into the sub-tile of the Header.

This allows to comment or to have longer information and to be free of the content and look.

The 6.x version don't allows this anymore. So the title and subtitle is poor (fivealive style).

I do believe that the best way should be a table (not a frame because of HTML5) and the ability to define the content of to line (<tr>), one for title, the other for sub-title.
(then the sub-title could not be written, if long enough, under the login button... which can overlay it)

Both they could content HTML.

The style of each <tr> has the actual default value but HTML with common tags as <span> or <img> allows to build a good title.

Naturally there is a downside : The title and subtitle must be sometime used as text (to be print for example). Then we obviously discover (invent) that we have two different GUI objects :
*the title HTML block which should be displayed into the header
*the title as text

The technical solution is simple :
The syntax of an HTML title and subtitle "must" be :
<span id="site_title" title="the text title" ... {other attributes} > ... HTML content ... </span>
So it is easy to parse the content to get "text_title" and "text_subtitle".

This could be implemented for 6.1 and after into 7.x trunk

{syntax type="tiki" editor="plain"}
This isn't so much WYSIWYG as the wiki editor but see no such feature checkbox.

Anyway if you click a wiki editor button twice, like bold, I expect it to undo the action, like the WYSIWYG editor. Instead it tries to make the text doubly bold, which is apparently not possible.

Also if you use a button and drop focus from the editor, I expect the preview Ajax to update as usual, but it does not.

{syntax type="tiki" editor="plain"}
WYSIWYG editor is displaying theme background inside of edit box using darkshine. This results in the red and red stripe background behind your editing, but this background does not appear behind the wiki page when viewed (displayed on white, as is desired)

Images that are added using the wiki editor (anyway the normal editor, I didn't check the wysiwyg editor yet) don't have a default class. This is the simple case of no containing box or anything added along with the image. Therefore it isn't possible for them to have a default style such as margin or border unless it is added manually by the page author. Or if it is specified by the stylesheet (.postbody img or .wikitext img, etc.) then ''all'' images in those divs get the treatment, including smileys and external link icons, etc.

I suggest adding a default class like "contentimage" to enable a default style. Page authors can always add a second class if needed.

The watch object names for trackers in My Watches could be more descriptive -- i.e. use the subject name.

{syntax type="tiki" editor="plain"}
A wiki link in combination with a equation tag parses falsely.
This editor entry

{CODE()}((Fire weather index|{EQUATION()}FWI{EQUATION})){CODE}

displays the text output:

<img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle">§1a7e9ee2385aa1db7956a7f63689955f§

In HTML code:

<a class="wiki" title="Fire weather index" href="tiki-index.php?page=Fire+weather+index">&lt;img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle"&gt;§1a7e9ee2385aa1db7956a7f63689955f§</a>

The same in version 4.2 which is correct:

<a class="wiki " href="tiki-index.php?page=Fire+weather+index" title="Fire weather index"><img align="absmiddle" alt="FWI" src="lib/equation/pictures/04d4e88879dbf4f876f4b62fea56172f.png"></a>

{syntax type="tiki" editor="plain"}
__Tiki:__ 6.1
__Firefox:__

Wiki text returned by the SQL plugin is not translated. I used the "Quote" plugin to verify if this problem exists for all plugins returning Wiki text and the value translated as specified in the data passed.

We make fairly extensive use of the SQL plugin on our internal department site. A technique for implementing this plugin we use is to enclose the return value of a column in double parenthesis. This enables us to have a web page reference for each of the returned rows.

This technique is used in several circumstances. One is that we select from our database stored information on hundreds of servers making the server name a link to a detailed info page. The example below is used to link to project detail pages describing individual active projects.

{CODE(caption="Example SQL",wrap="0")}
select
concat( '((', p.project_name, '))' ) as "Project Name",
u.user_username as "Project Owner",
tdv.value as "Project Status"
from
projects p,
departments d,
project_departments pd,
tsi_dp_valsets tdv,
users u
where p.project_id = pd.project_id
and pd.department_id = d.dept_id
and d.dept_name = 'TSI-KPHC'
and u.user_id = p.project_owner
and tdv.ID = p.project_status
and tdv.value != 'Archived'
and tdv.value != 'Complete'
order by tdv.value;
{CODE}

This issue is not restricted to link specifications as bold (double underscores) no longer work when returned by SQL either.

I have rated this a "9" strictly from a personal importance perspective and not as a definition of impact to the overall Tiki project. The customers of our department rely on these returned links for information and updates.

I have been all through the Administrative areas hoping to find a feature flag to turn on wiki text parsing of plugins (before trying the above referenced "Quote test") and am also unable to find such a flag specific to the SQL plugin.

--Steve

{syntax type="tiki" editor="plain"}
When I create a link to a Wiki page, the editor changes the reference of the link until the fourth time when I edit the page, but this is not a problem. The problem occurs when the link points to a wiki that has a special character, for example - cabeçalho - which means header (in Portuguese from Brazil), since the editor corrupts the link and it crashes.

Here I have an example.

The link should point to the wiki - Projeto de Pesquisa Social: Quem somos nós ? Proeja 2010 - is corrupted by the editor and points for - Projeto+Pesquisa+Social:+Quem+somos+n%C3%83%C3%83%C3%83%C3%83%C3%83%C3%82%C2%B3s?+Proeja+2010 -


Here we have a wiki page as an example:
http://www.biblioteca.ifc-camboriu.edu.br/criacitec/tiki-index.php?page=Example

{syntax type="tiki" editor="plain"}
When editing or creating a page using the WYSIWYG_6x editor, setting any text as a header then saving the file works correctly, however if the page is edited again, the WYSIWYG editor inserts a ! before or sometimes after the text you decided to format as a header.

Looking at the source, it appears that it is inserting the following into the page:

<p>
!</p>

Attempting to remove it by deleting the ! in the WYSIWYG editor just results in it showing up again, either immediately after saving or on the next edit of the page. This results in people not wanting to use the header feature or finding other workarounds such as larger font size.

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