Category: Consistency

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

{syntax type="tiki" editor="plain"}
I assume that the system suppose to display the image, but it downloads it instead.

I mean when in file gallery, click on Actions icon, then Display. It downloads it instead.

When hovering over an item, there opens a tooltip. This tooltip got a titlebar that reads the time and some title. For changes in the Wiki it reads e.g. "17:43 - Wiki". But for Blogs it reads "17:43 - Name of the blog". Perhaps better would be "17:43 - Name of the blog Blog" or "17:43 - Blog: Name of the Blog".

This is especially interesting for Forums, because the "o" as an icon for forums doesn't tell most people anything.

{syntax type="tiki" editor="plain"}
When you look at tiki-admin.php?page=textarea with basic pref. filter the Markdown section is not visible.

With the Advanced pref filter the section title is visible but no options are available.

This doesn't look right.
Or we show it with options to use or not. Seeing the title...

I have learned that "support request" is now used just for paid support. But I need support not from external programmers, but from the very devs who wrote this. There is a (actually quite many, but I'll start with a prime example) string that is fed into tra() that I don't understand.

/templates/wiki_plugin/wikiplugin_snarf.tpl contains this call to tr() (via tr in curly braces) in line 1:
{CODE(Colors="Tiki")}
{tr}{$snarfParams.ajax|escape:html}{/tr}
{CODE}

What does that mean? Obviously it's a call to a PHP variable to be inserted in runtime. But why is the output fed into tr() and not one step earlier the contents of said variable? And how is this supposed to be translated? Of course, in language.php it could be directed upon itself (with key==value), but then why feeding into the translation function in the first place?

And as I wrote, this is just one example, more than half a dozen others are there, too... Enigma to me...

Thanks
hman

Noticed some odd behavior today with the email that users receive for reports. If the user has the option: receive a report even when nothing has happened enabled, sometimes the link at the end of the email that is supposed to redirect to user watch preferences is broken. This only occurs when the email is reporting that no changes have been made.

For example, if the report has changes included the email is:
---
Report on wiki for User
Last report sent on Monday June 27, 2016

Changes in detail:
(Changes)

You are receiving notification emails grouped in a periodic digest. To receive them individually when posted instead, change your preferences at https://wikiurl/tiki-user_watches.php
---
That last bit is what seems to be inconsistent. If no changes have been made the email instead looks like (notice the link at the end).
---
Report on wiki for user
Last report sent on Monday June 27, 2016

Changes in detail:
Nothing has happened

You are receiving notification emails grouped in a periodic digest. To receive them individually when posted instead, change your preferences at http:///tiki-user_watches.php
---
So, if nothing has happened to report the link to the user watch preferences is replaced with ///tiki-user_watches.php, which is obviously a broken link. Also worth noting for anyone trying to debug, the URL begins with https:// when there are changes to report and http:// when there are no changes to report.

This bug is tied to [http://example.com|http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1964&trackerId=5&show=view]

I have had various issues navigating my wiki seemingly because $base_url is not getting built correctly, or at all. The first of these issues happens at login where the user puts in a bad username or password. The redirect to the error page fails on Firefox and has a URL with doubled forward slashes after the domain because the $base_url is not getting passed. URLs get built as follows (where 'example.com' is my domain):

Firefox:
{img src=images/code.png}%%% {CODE()} http://example.com\/tiki-error.php?error=Invalid+username {CODE}

IE:
{img src=images/code.png}%%% {CODE()} http://example.com//tiki-error.php?error=Invalid+username {CODE}

This happens with relative URLs all over tikiwiki in my installation, which is a WAMP with virtualHost entries in the httpd.conf to resolve 2 distict domains on the same server.

{syntax type="tiki" editor="plain"}
When showing a page in print view (tiki-print.php), attachments do not show. Instead, a message called "No such attachment on this page" appears.

NOTE: I was able to fix this for tiki-print.php, but not for tiki-print_multiple_pages.php

I installed a brand new Tiki24 and below the "do you want to lock your Tiki installation" I saw the following
{CODE()}
Upgrading and running into encoding issues?
We can try to fix it, but make sure you have backups, and can restore them.
Oops. You need to make sure client charset is forced to UTF-8. Reset the database connection to continue.
{CODE}

It doesn't really make sense, it is wrong (the db is UTF-8, utf8mb4_unicode_ci) and un-consistent.
It also propose 0 action.

I guess some conditions or logic are wrong.

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

On a new install, when using the installer you are asked to select your language on the second step.
Once done the Tiki change language to whatever you selected instant (no validation).

After I choose a language it should keep up to the first entrance of the Tiki I just install.
Let say I choose french on step 2, it should be the language selected till I complete the install process (and may be after as default language). However, on step 7 "Configure General Settings" the language is reset back to English (translation exist but not performed) and then back to the selected language on the step 8.

This is wrong a give a poor image of Tiki on the first run.
Note that new Tiki user has __no way__ to go change back the language.

I have migrated one of my Tikis from my personal webspace to one of an organization for which I admin the IT, and therefore I did have a look at the installer (but edited db/local.php instead).

The installer throws several warnings, that --might -- will become errors in the next PHP versions. This is what you get on PHP 7.4:

{CODE(Colors="Tiki")}
Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/init/initlib.php on line 221

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/vendor_bundled/vendor/h5p/h5p-core/h5p.classes.php on line 2590

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/vendor_bundled/vendor/h5p/h5p-core/h5p-development.class.php on line 70

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 414

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 1858

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 4483

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 4483

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 5779
{CODE}

This may or may not be considered an error, but is not-as-expected behavior.

!!Problem
When setting up InterTiki, one would assume that 127.0.0.1 would work as an IP filter for localhost. However, it was pretty clear that this was not working in 3.0 (beta 3, beta 4, rc1)

!!Regression
* Turned on the XMLRPC debugger in /lib/userlib.php around line 2817 ''$client->setDebug(1);'' to look at the response back from the server and do a bunch of printouts.

Traced InterTiki problems to the IP security check to the following (line 55) in /remote.php.
{CODE()}
if (!isset($prefs['known_hosts'][$key]) or $prefs['known_hosts'][$key]['ip'] != $tikilib->get_ip_address()) {
{CODE}

By changing the line to the following, the IP check problems went away:
{CODE()}
if (!isset($prefs['known_hosts'][$key])) {
{CODE}

*.tiki.org sites send out notifications to users who have become inactive or have been deleted causing bounces which are often not detected.

For example, group category or tracker watches can generate a lot of mail failures which we need to prevent.

{syntax type="tiki" editor="plain"}
It seems to be an error only by the first settings (creation) of a wiki page, maybe depending on the staging and approval system:

* Every time a new wiki page is created initially in the staging version the creators name is correctly shown under "created by" and "creator" (in the listing of the wiki pages and below the page in the collaborative-listing of creator and contributors).

* Then after approval

** the page description disappears (I mentioned this in another posting before) and

** the creator of the page is changed, I mean: __instead of the user's name (who created the page)__ now __there is shown the IP of the approver__.

* So

** below the page and in the page listing the IP (of the approver) is shown as creator,

** and in the history the "user" of the page and the "comment" are changed.

Please see the screenshots I attached, for better explanation of this. The page in the three screenshot was created by admin and approved by admin. But it's the same, if created by an user:

__Always the name of the creator of a wiki page is not correctly shown in each area (wiki page listing, below the page and in the history).__

* By edit of an existing page, this doesn't occure! - You see in the screenshot, that in the second and third version of the page there are correctly shown the "user" with his name and "comment" with an comment, that the page was approved by named approver.

At : tiki-admin.php?page=login
It is possible to enable "Use pretty trackers for registration form" without indicating a template in "Registration pretty tracker template". That lead to a broken registration page.

There should be a control mechanism to block/warn the user to apply without indicating a template.

{syntax type="tiki" editor="plain"}
'ziit_tikiwiki.tf.galleryId' isn't in GROUP BY

Die Abfrage war:
SELECT tab.* FROM ((SELECT 0 as `isgal`, tf.`fileId` as `id`, tf.`galleryId` as `parentId`, tf.`name`, tf.`description`, tf.`filesize` as `size`, tf.`created`, tf.`filename`, tf.`filetype` as `type`, tf.`user` as `creator`, tf.`author`, tf.`hits`, tf.`lastDownload`, tf.`votes`, tf.`points`, tf.`path`, tf.`reference_url`, tf.`is_reference`, tf.`hash`, tf.`search_data`, tf.`lastModif` as `lastModif`, tf.`lastModifUser` as `last_user`, tf.`lockedby`, tf.`comment`, tf.`deleteAfter`, tf.`maxhits`, tf.`archiveId`, '' as `visible`, '' as `public`, tf.`fileId`, tf.`galleryId`, tf.`filesize`, tf.`filetype`, tf.`user`, tf.`lastModifUser`, '' as `files`, count(tfh.`fileId`) as `nbArchives` FROM `tiki_files` as tf LEFT JOIN `tiki_files` tfh ON (tf.`fileId` = tfh.`archiveId`) WHERE tf.`archiveId`=0 AND tf.`galleryId`=? GROUP BY tf.`fileId`) UNION (SELECT 1 as `isgal`, tfg.`galleryId` as `id`, tfg.`parentId`, tfg.`name`, tfg.`description`, 0 as `size`, tfg.`created`, tfg.`name` as `filename`, tfg.`type`, tfg.`user` as `creator`, '' as `author`, tfg.`hits`, 0 as `lastDownload`, tfg.`votes`, tfg.`points`, '' as `path`, '' as `reference_url`, '' as `is_reference`, '' as `hash`, tfg.`name` as `search_data`, tfg.`lastModif` as `lastModif`, '' as `last_user`, '' as `lockedby`, '' as `comment`, '' as `deleteAfter`, '' as `maxhits`, 0 as `archiveId`, tfg.`visible`, tfg.`public`, tfg.`galleryId` as `fileId`, tfg.`parentId` as `galleryId`, 0 as `filesize`, tfg.`type` as `filetype`, tfg.`user`, '' as `lastModifUser`, count(distinct tfc.`fileId`) as `files`, 0 as `nbArchives` FROM `tiki_file_galleries` as tfg LEFT JOIN `tiki_files` tfc ON (tfg.`galleryId` = tfc.`galleryId`) WHERE 1=1 AND tfg.`parentId`=? GROUP BY tfg.`galleryId`)) as tab ORDER BY `isgal` desc

===My Setup===
I have file galleries set up with categories, so each category grants permission for a specific group to view and edit file galleries which are categorized to that group. E.g., I have a "group 1" category which grants the group "group 1" permission to access the "group 1" file gallery.

I have a "group administrator" group which has the "tiki_p_remove_files" permission granted in each category. This gives me one group which I can add to a user to give them permission to remove files from whichever file gallery they have permission to view.

Technically, the group admins have permission to remove files from all sections, every category grants them this permission, but because they cannot see the other sections, this is not an issue.

===My Problem===
Even having the "tiki_p_remove_files" permission, group admins are unable to remove files which they did not upload.

I have "tiki_p_remove_files" set for the "group administrator" group in global permissions but the issue still remains.

To do some testing, I granted registered (thus all groups) "tiki_p_remove_files" in the global permissions, and in the category permissions, but section admins (and normal users) were still only able to delete their own uploaded files.

I have a sym link set to my old tiki version, so I can access it via tiki-url/old. I used to this to determine that this is an existing bug, and not a regression. When adding the "/old" to my url, and going back to Tiki6, group admins were still unable to remove these files. The perms are stored in the db, so this would be a valid way to determine this correct?

This makes me think that the bug has been around for a while, as it was present in Tiki6 as well.

I cleared the tiki cache before each testing of permissions, and also cleared my browser cache (just to be sure) multiple times while testing this as well.

It makes it difficult to assign a single user to be a file gallery manager if I cannot give that user the ability to delete other user's files.

{syntax type="tiki" editor="plain"}
setting User Module parameter to flip=yc does not change enything, even when module shade global is set to Module, tested on tiki 6.3 and 6.4.

Also there is no parameters separator for User Module parameters mentioned anywhere in documentation.

{syntax type="tiki" editor="plain"}
In tra.php (8.1) it is necessary to check if an entry exists, the function used is always "getOne".

Unfortunately the instruction used {CODE()}! $tikilib->getOne(....){CODE} seems to return always true and generated the crash.

{syntax type="tiki" editor="plain"}
After 8.1 installation, I need a long time to be able to login as admin (not tested till now for other, two many problems to solve, test are programmed).
I was upgrading data from 7.2.

In fact the lonely way needs all these steps :
- clear all local cookies
- clear caches of server (temp/cache; module/cache)
- reinit as new (tiki.sql and some complements as the length of passw is we don't change the admin pass, no object, the SQL import file reset admin user and checks admin configuration)

Then when you login admin admin you are normally asked to set a new password, as for new installation. Everything seems OK, it is not true.
!!!~~#F00:__If you quit the browser you will be reconnected automatically even though "you have not checked remember me".
__~~
!!!~~#F00:But if you quit~~, for example to login for test with another login (the reason why for dev I don't check remember me) ~~#F00:and try to reconnect you get __"Invalid login or password"__ ~~

No other solution than a full reinit of admin login.
__
I checked :__
*clear local cookie alone : no result
*clear only tiki caches : no result
*clear cookies and cache (the db data are good for admin identification) : no result
*clear cookies, caches, reset admin as new install : OK

{syntax type="tiki" editor="plain"}
The default value for styles which supports "fixedwidth" parameter title "layout... " is 990px.

This option is useful and should be included in a module (I will do when if will function globally). Depending of the job done 990px on a 1920 is often a straight workplace.

If it is activated and you set any value you will get as the option "fullwidth".

This option make a wrong calculus of the real available width (a problem with js functions and margins) and generate a larger layout that the width of the display device.

{syntax type="tiki" editor="plain"}
(Not yet checked for trunk)

After running installer with upgrade we get the message "Invalid database run installer..."

Running installer don't changes anything to database, but the message is still displayed.
It is a consistency "deadlock by soft".

The lonely thing generated by installer is a reset which needs to reset manually the admin account and clear all caches and cookies (see #4066 admin login problem).

~~#090:!!!Going on 12/06/2011~~

I need to check the soft.

The message is sent by "installer" $installer instance of class installer in installib
It checks before the validation of patches on db using $installer->recordPatch($patch) for each one.
recordPatch function in installer records the patch into tiki_schema as done with his full date.

The concerned (got by a var_dump) patch is "20110904_shoutbox_def_tweetid_tiki"
is not into the tiki_schema table.
So the test functions, but the tiki-install failed to make this patch on another version OK, as it is defined.

__~~#F00:When it runs now (installer at 8.1 level) it don't tries to make the upgrade. This is the deadlock.
__What is done if an old patch is not there !!!__

More there is no report at all.~~__

{syntax type="tiki" editor="plain"}
I TRIED TO SUBMIT THIS BUG BUT I CAN'T FIND IT AFTER SUBMIT. SO I AM TRYING TO RESUBMIT IT AGAIN. SORRY IF IT CAUSES A DUPLICATE.

I upload an image to the File Gallery, which gets assigned id=19.

Then I go to a page and insert the following Tiki markup:

~np~[tiki-download_file.php?fileId=19]~/np~

~np~{img fileId="19"}~/np~


To (a) provide a link to download the image, and (b) insert the image inside the page.

Works up to here.

But then, I do:
* File Galleries > List Galleries > Browse Images
* I locate the image I just uploaded, and click on the the wrench icon, and then on "Upload New Version".
* I upload a new version of the image
* If I go back to File Galleries > List Galleries > Browse Images, I see that indeed, the old image has disappeared, and it has been replaced by the new version

The problem however, is that the new image has id=20, not the old id=19. But the id has not been changed on the link and IMG plugin that I inserted on the page. So they still point to the old image with id=19.

The weird thing is that I can still download image id=19 (even after clearing my cache), eventhough I can't see that image in the gallery anymore. In other words, the image is still in the DB and can still be accessed.

This is definitely not how things should work. If I upload a new version of an image, then all references to that image should be updated accordingly, and I should not be able to access the old version, except in a "view history" kind of context. No?

{syntax type="tiki" editor="plain"}
The two icon flags (eye.png and eye_magnifier.png) that are used to show the "watch" status of a forum are always switched together, so one doesn't really know what kind of watch he set on the forum.
See also {img id=128}.