Category: Regression

The "Upload New Version" action item in file galleries is no longer reliable. Clicking it opens a file selection dialog, but if the wrench icon controlling the menu of action items is not clicked, the dialog disappears quietly, without reporting any error. This is not too misleading, since there is no false confirmation.

http://bsfez-11581-5668.show.tikiwiki.org/tiki-list_file_gallery.php?galleryId=1
Can't upload a new version....

{syntax type="tiki" editor="plain"}
When listing a File Gallery you can select a number of files and use the "Select action to perform with checked ..." drop down list below the listing to select the "Download zip version' which will then download a .zip file with all the selected files inside.

This works OK in 24.6 but just produces a 'white screen' in 27.0

Chose a non-default workspace:
{img fileId="1064" thumb="box"}

Open File Gallery and upload a file:
{img fileId="1065" thumb="box"}

Choose the file and see that the checkbox marking the category corresponding to the workspace is checked:
{img fileId="1066" thumb="box"}

The file is uploaded:
{img fileId="1067" thumb="box"}

Browse the file gallery - it is empty, where did the file go?
{img fileId="1068" thumb="box"}

Open the file gallert from the default perspective (workspace), the file is shown, thus, it was uploaded:
{img fileId="1069" thumb="box"}

Let's see its properties:
{img fileId="1070" thumb="box"}

It doesn't belong to the category it was said to belong during the upload:
{img fileId="1071" thumb="box"}

We add it to the category that we intended it to belong to:
{img fileId="1072" thumb="box"}

We switch back to the desired workspace, open the file gallery, our file is there:
{img fileId="1073" thumb="box"}

__Very low usability!__

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.

At themes.tiki.org, theme .zip packages and screenshot image files added since Sept.15 aren't showing hits information. Hits says "0" in the standard UI and "unknown" in elFinder. I haven't tested yet on other sites.

I'm seeing the same problem at a trunk site. Hits are shown as "0" in "browse" mode, and the "Hits" column (including header) doesn't even display in list mode (in Trunk).

Update: This is still a problem at themes.tiki.org, and I can reproduce it in my localhost branch 16 site.

From r46361 when uploading a new file to a File Gallery the upload fails and (perhaps because of) the user is logged out

On Tiki 24 when I edit an existing file and try to edit the description it failed.

Reproducible and testable at https://doc.tiki.org/tiki-list_file_gallery.php?galleryId=1726

{file type="gallery" fileId="1816" showicon="y"}

PS: On some other Tikis I tested, changing the file name didn't worked neither. (no error)

Here on this site I get:
{CODE()}
Fatal error: Uncaught --> Smarty: Not matching {capture}{/capture} in 'layout_view.tpl' <-- thrown in /var/www/virtual/dev.tiki.org/html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_capture.php on line 139
{CODE}

Steps to reproduce:
# go to https://dev.tiki.org/File-a-bug
# in Description field click the {icon name=image} icon with the tooltip saying "Choose or upload images" from the toolbar
# in the popped-up window click the "Browse Gallery" button
# click on "Bug report images" folder trying to step inside

You will get the error reported above with the following URL:
https://dev.tiki.org/tiki-list_file_gallery.php?galleryId=13?filegals_manager=area_5e20296fb945a

__Duplicate of__ https://dev.tiki.org/item7267-It-is-not-possible-to-select-a-gallery-when-uploading-an-image-using-the-toolbar-tested-dev-tiki-org

When the info icon for a file is hovered over, and if there is a lengthy description for that file, the popup box is oversized and does not render properly.

See file named Spokeshave Bottom Grinding.jpeg and hover over info icon at http://tpwtestuser.com/tiki/tiki-list_file_gallery.php?galleryId=5 for working example of oversized info box.

A show instance will be created.

I’ve being fighting with a weird phenomena since I’m trying to upgrade Tikis 20 to Tiki21.

My server is ClearOs 7 and I use php7.2 and file directory a storage.

I upload files, most appear ok and can be displayed.
Once in a while the upload is ok and the image appear in the file gallery but can’t be displayed in a wiki page sometimes the image doesn’t appear in the file gallery itself. ( I see a jpg or a png icon over the file in the file galleries)

Metadata shows:
{CODE()}

Metadata Extraction Time

Tuesday February 25, 2020 14:43:57 IST
File Data
File Type

JPEG
File Size

8916 bytes
Width

80 pixels
Height

80 pixels
{CODE}

To solve this:
#I re upload (new version)
+Sometimes when I upload a new version (or replace since I set archives to none) and it work or sometimes I have a WSoD:
+{img fileId="1362" thumb="box"}
+{img fileId="1363" thumb="box"}
+{img fileId="1364" thumb="box"}
+I also get from time to time :
++Error
++Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
# If not solved I delete the files in the file gallery and upload a new image (it create a new file object).

When I copy back the folder on my local server (to test on a clone before upgrading) or create a clone on the same server most of them are not displayed (jpg or a png icon).
On my local OSX if I preview the files from the finder I can see the image, but Tiki doesn’t:
{CODE()}
<img src="https://domaine.fr/dl18?display" alt="The image “https://domaine.fr.fr/dl18?display” cannot be displayed because it contains errors.">
{CODE}

Once everything solved, I do a files:check from the Tiki console.
{FADE(label="Console.php output on files:check" icon="y")} php console.php files:check
== Image Gallery ==
Configured to stores files in Database
Files in DB: 0
Files on Disk: 0
No Issues found

== File Gallery ==
Configured to stores files on Disk: ../domain_files, files/
Files in DB: 0
Files on Disk: 53
Found 2 Issues, details below:
The following files are missing
+----+----------------------------------+----------------------+
| Id | Name | Path |
+----+----------------------------------+----------------------+
| 5 | 0d28012a77a423c970d528bfd96091dc | ../domain_files |
+----+----------------------------------+----------------------+
The following files are unknown, exists in the folder, but not in the database
+-----------+----------------------+
| Name | Path |
+-----------+----------------------+
| index.php | ../domain_files |
+-----------+----------------------+
...{FADE}
It look ok (the extra file is certainly because of my numerous attempt during the last 3 days but not related to this issue).

I create a dump of the database and copy the Tiki themes folder and files folder on my local (I delete the old one) using Cyberduck (something I’ve being doing for ages) to create a local clone.

I check the files (OSX preview) and I can see the images properly displayed.
I create a new database and dump in the sql file (the database).
I create a new Tiki (git Tiki 20) and do the install process
I place the files folderand the theme folder where it should be.
I place the theme
I re update DB, re-index files, clear cache (you never know)
And check files using the console and I got the same than on my remote.
Look to me like a perfect clone to me.

But now, start the chaos. (can’t say there is a pattern) :-)
*A few images are not displayed on the wiki page.
*A few of images show the jpg or a png icon over the file in the file galleries. (images that are displayed in the wiki pages)

I tested this behaviour and got similar results cloning to Tiki20x and to Tiki21x.
In time and after re-uploading problematic files I narrowed the issue to a few images and I re-upload them manually in my clones.

We are talking about a few files (53) and I’m enough experimented and wanted to report properly the problem (and I’m stubborn :-) ) to solve one by one the issues. I doubt Tiki admin upgrading have the same "patience"...

Uploading png files to file galleries get them corrupted somehow. See screenshots (I'll upload them here in short). And a pdf file I uploaded to the file gallery, after I downloaded it again from tiki, I couldn't see its contents properly (see the other screenshot; some font seems to be missing). If I open the source pdf file (not passing through tiki file gallery but directly the one I had in my computer from elsewhere), I can see the contents of that pdf as expected
{img fileId="1191" thumb="box"}
{img fileId="1192" thumb="box"}
{img fileId="1193" thumb="box"}
{img fileId="1194" thumb="box"}

Fairly standard setup on Ubuntu 16.04 (see ((doc:Ubuntu Install)) ), with mysql 5.7.x, and php 7.0.x (originally, but same issue with php 5.6, 7.0.x, 7.1.x, 7.2.x). Using gd (imagemagick installed also after I hit the bug the first time, just in case it automagically helped, but it didn't - I didn't remove gd, btw)

I've tested also using tiki15svn, and I couldn't use it due to some weird error I had never seen before of zend session validator class not finding Id.php in place. (!). Therefore, I couldn't test tiki15svn in the same server.

I tested using tiki17svn, and file uploads worked as expected (nice!).
I tested using tiki18svn, or tiki trunk, and I got the issue I reported.

----
Gosh, similar issue might be happening on dev.t.o (at least for me; is it only me???): try to see the png files that I produced as screenshots, e.g.:
https://dev.tiki.org/tiki-list_file_gallery.php?galleryId=1&fileId=1194&view=page
----
Update: avoided the issue by means of changing the storage of files in file galleries from db to file system. {sign user="xavi" datetime="2018-05-10T14:07:57+00:00"}

Therefore, the issue might be specific to Tiki18+ and Mysql5.7 maybe? (in another production server of mine, the setup is fairly similar in Ubuntu 16.04, but with MariaDb instead of MySQL 5.7, and I didn't see the issue of images getting corrupted).
As a consequence, I removed the tag "Release blocker", since I'm not sure how many production server are out there with MySql 5.7 and storing files in database. Feel free anyone to re-tag to release blocker if this is too critical for someone else.


I removed "19.x" categorization because branch 19 doesn't exist yet. The category "regression from version 18 to 19" is accurate here and already assigned. {sign user="chibaguy" datetime="2018-07-12T07:47:53+00:00"}

Using plugin __TrackerList__ to filter records, if a negative filter is desired, it fails, if the field being selected on is an "item link" field, while it works if the field is a regular text field.

See: __http://omstefanov-10438-5580.show.tikiwiki.org/__
(where I had to reset the pswd for user=admin to the value "12345")

Two pages exist:
===__Demo 1__===, accesses TrackerId=1, and shows a text field, fieldId=2, containing names of cities, and one of the values is "Washington, DC". Here both:
trackerId=1,filterfield=2,exactvalue="Washington, DC"
and:
trackerId=1,filterfield=2,exactvalue="not(Washington, DC)".
work.

===__Demo 2__===, accesses trackerId=3, filterfield=6, and also contains the same set of city names, except that the field is defined as an "item link" to trackerId=2. This time, while positive filtering works:
trackerId=3,filterfield=6,exactvalue="Washington, DC" and
trackerId=3,filterfield=6,exactvalue="Ottawa"
===negative filtering "__not(...)__" __does not work__===. Both these cases result in no records found:
trackerId=3,filterfield=6,exactvalue="not(Washington, DC)" and
trackerId=3,filterfield=6,exactvalue="not(Ottawa)".

Originally I thought it had something to do with the comma in the value, as in my production system negative filtering on another field was working, but that was because the other field was not an "item link" field.

This form of selection worked/works in tiki 6.15 and earlier versions.

This regression is hindering upgrade of the meanwhile almost 7 year old JIAMCATT site, with 1001 users, from tiki 6.16 to tiki 12.

The "Find" button on tiki-listpages.php only, when clicked, causes some page reloading but no form appears. I didn't see an JavaScript errors reported.

It should get 1.1 but it is omitted for the first heading section on the page, e.g.:
{CODE()}!!# Introduction - A Historical Context{CODE}
on the https://dev.tiki.org/Hello-World

Or you can see the bug here:
https://tiki.org/201911-TAG-Meeting
(the "Who" section should have 1.1)

When Fivealive is used with mod-logo in the Top module zone, with Site layout Classic Tiki (3 containers) and with a Site title defined, that title will be displayed too much to the left, unless the site logo is large enough to make it start in the colored zone.

This makes the header ugly, in particular because there is an important loss of contrast between the text and the background. Thanks to the shadow effect, some contrast remains, but readability is affected.

This bug appeared in Tiki 13.
I do not know if this persists in trunk. I do not see the colored background there.
This persists in 15.x as of r59957.
Note that the title is also too high.

After upgrading from Tiki 9 to Tiki 15, my site's header became half-broken. Functionally, the login_box and quickadmin modules were invisible. quickadmin could be seen when hovering over its 2 icons with the mouse, otherwise there was no contrast. login_box is completely invisible; there is no contrast even when hovering. Both are however usable if one knows where they are.

This problem is specific to the Fivealive theme.

chibaguy pointed out that this could be worked around by switching site_layout from the default option Basic Bootstrap to "Classic Tiki (3 containers - header, middle, footer)". While this does solve the functional issues, this still doesn't display correctly. Most importantly, the title's position remains incorrect.

This persists in trunk as of r60030. Version 12 is not affected. This was presumably introduced in version 13.

This affecteds 2 browsers on 2 tested (Iceweasel and Chromium). The attached file shows how this used to display. While this is trivial to reproduce, I created an instance which constitutes a testcase.

On https://nextthemes.tiki.org/Themes (use next/next to authenticate) you can see the "grape" theme option is not displaying in the grape colors but it uses the default blue instead.

See the screenshot: {img fileId="1344" thumb="box"}
Ctrl+refresh this site to see it live.

__Update:__ Better but now there is a transparent bg when scrolling down
{img src="tiki-download_item_attachment.php?attId=529" thumb="box"}

See:
https://dev.tiki.org/Tiki19?fullscreen=y
{img src=https://dev.tiki.org/tiki-download_item_attachment.php?attId=497 thumb=y}

On a Tiki23 if the layout option is set with : Classic boostrap (Fixed top menu) the menu is lost when navigating on the admin pages.

The original website logo (brand icon) is changed for a Tiki icon making things more confusing.

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

Bottom module is also lost...

All bootstrap themes or themes bootstrap adaptation will suffer from this problem.
This block upgrading websites.

11.x: http://tiki.org/tiki-view_forum_thread.php?comments_parentId=49820

12.x: http://next.tiki.org/tiki-view_forum_thread.php?comments_parentId=49820

{flash type="url" movie="display525" width="928" height="602"}

Comparing https://themes.tiki.org/ and https://nextthemes.dev9.evoludata.com/ , the nextthemes site seems to have trouble using the correct font and some other prefs/styles. Clear the cache and it's ok, but then on the next page view the font family is wrong for body text and the child theme switches to "None" (it should be "Grape" at that site).

Other themes seem to look and work ok, so this problem could be due to the theme, FiveAlive-lite, which isn't updated as completely as most of the others (regarding CSS variables, etc.). I'll commit the updates soon and recheck the sites.

With a simple wiki page that uses the standard wiki editor the drop down menus for font colours and background colours are blank.

Occurs in 12.x at r49095

The editor settings when this occurs are:
Full WYSIWYG editor
BUT Wiki syntax is NOT used
Content is parsed like a wiki page

A show instance has been created which shows this bug/regression

fixed commit id=49334 - thanks jonny

In Look and Feel admin, switching the font set to Glyphicon seems to have no effect. The font set being used is Font Awesome instead. Switching to the legacy icon set (.png images) does work ok. (Checked on my localhost branch 15 and trunk so far.)

I created a show instance (http://chibaguy-342-6164.show.tikiwiki.org) that confirms the bug: after switching to Glyphicons, Font Awesome is used instead (icons have a class like "icon icon-admin_search fa fa-search fa-fw ").

Didn't think it was related, but just to be sure I emptied the caches and rebuilt the search index, but no change.

Thanks for the feedback. I realize I was only checking the admin anchors (feature icons) on the admin pages, which aren't changing to Glyphicons, and assuming none of the icons are switching (although icons other than the admin anchors are switching). I'll rename the bug.

When the FOOTNOTEAREA plugin is called more than once for a single context, footnote numbers are duplicated. For example, if a single wiki page contains 2 footnotes and that each is displayed in its own footnote area, both notes have the number 1. Moreover, clicking on the second footnote reference brings to the first footnote's content.

When a page displays several footnote areas because it contains several objects, it is OK to re-use footnote numbers. For example, if reading a list of articles and 2 articles use footnotes, it would be bad to use different footnote numbers than the numbers which would be used if viewing the articles individually. It is good that each article is displayed with a footnote number 1.

Unfortunately the parser has no idea about context up to Tiki 19. In Tiki 19, the second footnote area displays both footnotes, as in Tiki 16 and below, so the first footnote is duplicated. In Tiki 17 to 18, each footnote is displayed just once, the problem is a conflict between these.