Category: 2.x

Users in groups without the "tiki_p_admin_file_galleries" group permission set cannot see any file galleries in the "List Galleries" page, even if "tiki_p_list_file_galleries" (or all file gallery permissions) are switched on for the group and/or the File Gallery.

However, the user can still access the gallery directly if they know the exact URL, eg:
http://site.com/wiki/tiki-list_file_gallery.php?galleryId=2

The "List Galleries" page loads, but the list of galleries shows only "No records found". If "tiki_p_admin_file_galleries" is enabled, all permitted galleries appear in the list.

{syntax type="tiki" editor="plain"}
The list of actions that can be perform is limited to <move to> when others actions (individual list) could be performed as <delete>

I recently upgraded our tiki install to version 2. Most things survived the upgrade, however the most obvious thing that was broken is the file galleries feature.

All links to files previously in the gallery still work correctly, however when I select the option to list galleries, none of the existing galleries are displayed. It just shows "No records found"

Looking in the database, all files and galleries are there.

When i attempt to upload a new file, I am still given the option to select a file gallery (all gallery names are still shown). When I select the appropriate options and confirm the upload I can link to it as usual but it does not appear when I select to browse the gallery.

[http://tikiwiki.org/tiki-download_forum_attachment.php?attId=231|Screenshot]

In 2.0, Flash files (.flv) stored in the file directory don't play with the FLASH wikiplugin. The movie source url, etc., look ok in the page source, but still nothing displays. File gallery Flash files work with the FLOWPLAYER plugin, though.

Bug 1: In a File Gallery the Actions Icon opens a pop-up list of Options. The Replace option does not appear to be a link (No link selector pointer or Status bar message). It does actually work, which is very confusing. Browsers: Firefox and SeaMonkey on Linux.

Bug 2: When a file is replaced, the Name property is set to null. Really annoying because you then have to use the Properties Action tab to set the Name, if you remembered what it was.

The first image displays but is badly distorted (available image lib is GD). The name of the second image moves into place, but the first image (its right-hand side) continues to display. Then it moves offscreen at about image name number three and no other images display.

When trying to move a file from one Gallery to another, the "Perform action with checked: Move Selected Files" option does not seem to list the Galleries that are an immediate sub-folder to the existing folder. All other folders are listed except these.

This is why Toggg created ((tw:TogggDeletorPhp))

Features would be:

*Ability to select how many rows/columns for presentation
*Embeds photo, flash or just a link based on file type
*Clicking the image or link starts download of the file (if allowed)
*Ability to view full size image
*Ability to open a slide show

Would include last comments to each file. Related:
Comments to individual files in file gallery
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=719

Logged as user xavi here on dev.tw.o/tracker5 I can't filter by summary (text field): no text input field is shown. Some other type of filter fields work as expected (I didn't try all) but not filter by summary.
Reported April 2nd. Using Firefox 2.0.0.13 ca on GNU/Linux
---
Reproduced as user xavidp (admin rights) using 2.x here again on dev.tw.o/tracker5 using Firefox 3.0 ca on GNU/Linux.

When assigning a module, I would like to have a section-specific parameter to control in which sections (wiki, blog, forum, etc.) the module displays. See [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=26153|this forum thread] for details.

{syntax type="tiki" editor="plain"}
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

This is Tikiwiki v2.0 -Arcturus- © 2002–2008 by the Tiki community Sun 07 of Sept., 2008 22:51 EDT


Firefox mis-displays when "menu" option is selected in Look and Feel > Top Bar

Does not occur in IE7

Mis-display is that menu appears in proper place, but all of the rest of the page is to the right of the end of the menu div

The first "title" provided in an external RSS feed is displayed as if it is the channel's title (description). Many RSS feeds provide a "title" element immediately after the "channel" element, containing a description of the channel. But if no channel title exists, the title of the first item is displayed as if it were the channel title, resulting in the first title being displayed twice.

Author/creator of an article/sumission is replaced by user who last modified article or submission causing:

*Original author with no general edit_article perm to be unable to edit his article or submission once modified by someone else although he has creator can edit perm.
*Sumission to be automatically validated under a new author if modified by someone who has edit_submission and autoapprove perms.

on the features selection page there is a checkbox for each feature with its name next to it. In normal Web UIs a checkbox is next to a &lt;label&gt; tag which contains the text referring to the setting the checkbox controls. If you set up the name= and title= for both the input and the label then clicking that text automatically selects the checkbox.

This is not always implemented properly across the web but it is the way forms are supposed to be used and it is easy and no one ever complains about it. It increases the effective size of the checkbox and cements the relationship with the word.

On the features selection page, however, the text instead links to the tikiwiki.org descriptions of the features. This confused me and happened several times before I retaught myself to not click the words.

After running "./fixperms.sh fix" on the server side (Debian based, having root perms on server), and using 1.10svn code from mid May 2008, admins of the tiki site can still install mods on the server through the Tiki admini mods interface.
It used to work before (months ago, when I last used that).
our server, afaik, has www-data and www-data as user and group.
We are using a multitiki installation, with tikis under subdirectories.

I'm afraid that admins of the other tikis from the same multitiki are able to remove mods that we are using and need, etc.
...

See screenshot

Please see:
http://www.wikimatrix.org/wiki/feature:Text%20Files

In 5 years, there has not been a real need expressed for this feature so it will probably never happen. If you think it's important, please comment this tracker item.

Tiki supports sqlite so this would be similar (to avoid full db) but it would be slow for active sites and not really provide any benefit (vs MySQL, Postgres, etc).

Right now, users always make too many variations of tags. One way to solve the problem is to have Flickr style auto-complete of tags when entering them.

{syntax type="tiki" editor="plain"}
When I click "Install" for FlowPlayer I get the error:

wiki-plugins/flowplayer/flowplayer/flowplayer.js to lib/flowplayer/flowplayer.js impossible to copy

It won't install and I have no idea what to do next.

Thanks for any help.

{syntax type="tiki" editor="plain"}
If you choose to use the flowplayer module, you are required to have Tikiwiki installed in the root of the domain.

ie: http://www.domain.com/tiki/tiki-index.php?page=Bob will not work, while
http://www.domain.com/tiki-index.php?page=Bob will work.

The cause for this seems to be that the lib/wiki-plugins/wikiplugin_flowplayer.php file is hard coded to work from the '/lib/flowplayer/' folder.

(Search words: flowplayer, tikiwiki, broken, no video, blank)

When creating menu options (tiki-amdin_menu_options), Tiki shows a Preview of the menu being built. However, when creating a SECTION option, Tiki does not show the folder icon (as defined on the tiki-admin_menus page).

Tiki 1.9.x forums have improved nicely over the last few months. One more thing to make them cleaner is to make the default threading to plain.

Let's face it, it looks cleaner :-)


{img src=images/code.png}%%% {CODE()}
===================================================================
RCS file: /cvsroot/tikiwiki/tiki/comments.php,v
retrieving revision 1.31.2.50
diff -c -r1.31.2.50 comments.php
*** comments.php 11 May 2007 23:15:50 -0000 1.31.2.50
--- comments.php 31 May 2007 04:01:10 -0000
***************
*** 386,392 ****

if (!isset($_REQUEST["comments_style"])) {
// TODO: Make this an option.
! $_REQUEST["comments_style"] = 'commentStyle_threaded';
} else {
$smarty->assign('comments_style_param', '&amp;comments_style='.$_REQUEST['comments_style']);
$comments_show = 'y';
--- 386,392 ----

if (!isset($_REQUEST["comments_style"])) {
// TODO: Make this an option.
! $_REQUEST["comments_style"] = 'commentStyle_plain';
} else {
$smarty->assign('comments_style_param', '&amp;comments_style='.$_REQUEST['comments_style']);
$comments_show = 'y';

{CODE}

the problem is moderation of forum posts.

This is best explained with an example:

~pp~
Paragraphs are parsed

just fine here

{TAG(tag=ul)}foo{TAG}

but now

paragraphs and

line breaks aren't working!
~/pp~

This only happens for tag=ul, not even for tag=ol.

This happens regardless whether wiki paragraph formatting is enabled and regardless of whatever is inside the ~np~{TAG(tag=ul)}~/np~, even ~np~{TAG(tag=li)}~/np~'s.