Category: Consistency

{syntax type="tiki" editor="plain"}
On next tiki org I tested a bug about Archives and find out that all the new files I'll upload take the same filename and use the same date of the original and first file. (on the video you can see the "real" date is displayed for half of a second.

I really think it used to work properly, displaying the date of the upload of the next versions and the filename of the file (not the label of the file in Tiki).

{mediaplayer src="display1864"}

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.

{syntax type="tiki" editor="plain"}
When a user uploads a file on the file gallery, the URL is saved where somebody could download the file. This URL is used by the category browser.
If the client uses a proxy (we use a SSH tunnel to connect to the wiki), the wrong URL is saved in the database (table tiki_objects).
This results in a link to the original tunnel and not the website itself.

__This bug report has been created to emphasise the need for an option to manage duplicates when using the Tiki console to import files__
Fixing it by really rejecting the upload of a duplicate file will be quit bad as it will make the automatisation of the upload unusable for many case (files can't be updated with a new version).

Using the [https://doc.tiki.org/Console|Tiki Console] you can import files from a [https://doc.tiki.org/File-Gallery-User#Batch_uploads|batch upload] folder.
{CODE()}php7.4 console.php files:batchupload 5 --subdirToSubgal --createSubgals --confirm{CODE}
You can automatise the task using the [https://doc.tiki.org/Scheduler|Tiki Scheduler].

Displayed message in the shell and the scheduler about duplicate is not true.
{CODE()}
error: Duplicate file found as `49456187_a.jpg`. Upload rejected.
error: Duplicate file found as `49456187_b.jpg`. Upload rejected.
error: Duplicate file found as `49456187_c.jpg`. Upload rejected.
error: Duplicate file found as `49456187_d.jpg`. Upload rejected.
error: Duplicate file found as `49456187_e.jpg`. Upload rejected.
error: Duplicate file found as `49456187_f.jpg`. Upload rejected.
error: Duplicate file found as `49456187_g.jpg`. Upload rejected.
error: Duplicate file found as `49456187_h.jpg`. Upload rejected.
error: Duplicate file found as `49456187_i.jpg`. Upload rejected.
{CODE}

But in reality the files are created and duplicates just accumulates with the same name without limit. (there 3 pages like this)
{img fileId="1805" thumb="box"}

{img fileId="1365" thumb="box" width=640}
See https://tiki.org/forumthread73548-comments-on-blog-posts

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

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

If you are admin you can create directly users with a username, password and email.

However the field "email" has no validation at all.
Admin can enter anything like "vincent".

If an admin does so and the notifications are enabled for this user on wiki page edit, __all__ users will suffer errors as they save their work. Tiki dependencies go "bongo" as they are fed with an email that is not valid.

Admins should know what they are doing, still a simple validation or a warning should be placed.
Such misuse are not obvious with immediate results; it may take several hours to understand what is going on and more time to find the faulty user(s) record(s).

At https://tiki.org/Consultants the field type Files, Display Mode = image show ^File not found.^ instead of the format parameter default content (default="" in this case).

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

Currently, (2.2) when using the mailin feature to post to a forum, Tiki does not actually check the email until a user views the forum. Only then, is the email checked and new messages posted to the forum.

This means that the RSS feed for the forums, and modules such as last_post will not be correct until a user goes to the forum.

Instead, Tiki should check the email at regular intervals (in the same way that Tiki checks for article mail-ins.

{syntax type="tiki" editor="plain"}
although they have tiki_p_admin_forum permission=__n__ (on v3.2).
My forum mods gets on tiki-view_forum.php?forumId=<int> the "Edit forum" button, which should be visible to forum admin only.
If they click on the button they get the error messages about missing permissions, so there is no serious problem with it, but it's confusing to see this button.

I've looked over templates/tiki-view_forum.tpl but didn't see anything as explanation for this.
(Btw: the if/else clause from line 15 to 19 doesn't make a sense (for me); it makes the same, never mind the case of the if-clause)

Forums tools and names support Tiki Multilingual feature but the breadcrumb that doesn’t display translation.

The plugin forum and the forum list don’t display the same. (probably not re-indexed right-away?)

As they are both visible on the same page at : https://tiki.org/forum26
It’s a bit disturbing.

{img fileId="1135" thumb="box"}

Forum list last post are way back in time than the forum plugin last post.

In /lib/prefs/forum.php there is a forum pref, where the name of the pref directly contradicts it's description. In line 175 you'll find

{CODE(Colors="Tiki")}
'forum_inbound_mail_ignores_perms' => [
'name' => tr('Allow inbound email posts from anyone'),
'description' => tr('Allow posts from non-users in forums using inbound posts from a specified email address.'),
'type' => 'flag',
'default' => 'n',
],
{CODE}

Mail-in allowed for "everyone", or only for "specified addresses"? Since no parameter that could specify such an address is asked and stored, I guess the name is correct, but the description isn't. Affects all languages...

{syntax type="tiki" editor="plain"}
I created multiple forums and when I try to sort by name (asc) or name (desc), it doesn't seem to work.

See screenshot here:
http://dev.tikiwiki.org/show_image.php?id=104

Thanks
Ryan McCain
rmcc4444@gmail.com

{syntax type="tiki" editor="plain"}
When user replies to a forum the pagination changes so that only shows 2 posts:
The topic post and the first reply

It still shows only 2 replies per page don't respecting the configuration for the forum ( 10 replies per page, 20, etc ).

===v2.2===

When an item has a Freetag added and the Freetag menu looks for content with a designated tag it will list ALL content - even if some pages are Categorized and the particular user doing the search does not have permission to access the page.

Obviously the user cannot actually access the page but being able to see it makes them think it is available to them and just knowing a particular page exists may create difficulties.

Need to filter the objects being listed (presumably in tiki-browse_freetags.php in a similar way that tiki-listpages.php does this) so that only objects that the individual user is allowed to see are listed.

For over a year (or even longer?) I have seen many times that I got, when I edited a bug report, I got both (!) success and failure indicated ''__at the same time__''. Now this happened when I edited the "Illogical sorting of the Wishlist" report, see screenshot.

Something in the inner workings of trackers is wrong. How can it be, that a tracker got successfully updated and it's ID is missing in one and the same request? See screenshot...

Thanks
hman

{syntax type="tiki" editor="plain"}
While setting up Tiki 6.0 (upgrading from an earlier version) I found that if you enable Full Text Search but not Tiki search, search is treated as a disabled feature on the admin pages.

Also the top search bar works only for tiki search, while the main search function does work with FT.

The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.

"Fullscreen Edit" is a new cool feature of 2.x

Quicktags are kept, but Wiki & Plugins Help are missing so it makes editing less enjoyable.

"Edit Summary" is missing as well. Maybe it's intentional?

I am poking around trackers trying to maybe copy the code to make a personal module or some such, and I noticed this:

[r@s tw]# grep -R function\ get_item_id ./*
./lib/trackers/trkWithMirrorTablesLib.php: function get_item_id($trackerId,$fieldId,$value) {
./lib/trackers/trackerlib.php: function get_item_id($trackerId,$fieldId,$value) {
./lib/tikilib.php: function get_item_id($trackerId,$fieldId,$value) {

Seems risky to me to have 3 version of the same function. Is that as designed?

On the Control Panel General Settings, tab Navigation, option "The URL that the anonymous user is redirected to when a page is not found" you can redirect anonymous users when then hit a page that doesn't exist.

However if your field value there a wiki page the redirect will go to a endless loop that will display a "Too much redirect" error.

If your value is the full URL (https://....) it work fine.

This problem is quite common and happen to a lot of users, even experimented.

The text for the option is not strict enough and for many "The URL..." is not necessary the full URL path.