Category: Bug

When entering the admin function of file galleries (http://MYADRESS/tiki-18.7/tiki-list_file_gallery.php?show_details=n&view=admin&galleryId=1), a fatal error is thrown:

{CODE(Colors="Tiki")}
Fatal error: Uncaught --> Smarty: undefined extension class 'Smarty_Internal_Runtime_CheckPlugins' <-- thrown in /MYDIRECTORY/tiki-18.7/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_undefined.php on line 62
{CODE}

I tried one of the simplest possible spread sheets to try the graph feature. After unfruitful attempts to make it run with bar graphs (always got "invalid series" or after five minutes my ISP timed my Tiki out), I tried a pie chart. With that I immediately got a fatal error:

Fatal error: Call to undefined method GD_GRenderer::httpHeaders() in MYHOMEPAGE/tiki-18.6/tiki-graph_sheet.php on line 131

Attached please see the simple spread sheet I wanted to be plotted as pie chart.

If in "payment" "Tiki credits" is used, then a click to see open purchases results in a Fatal Error:

Fatal error: Class 'CreditsLib' not found in MYDIRECTOPY/tiki-18.7/lib/payment/creditspaylib.php on line 9

On a new ubuntu 22.04 aws server apache2 php7.4
Clean build
Installing tiki for first time on this machine
The following is shown on https://mysite/tiki-install.php

Notice: errortracking library not found. This may be due to a typo or caused by a recent update. in /var/www/tiki.squadron6.com/tiki-25.2/lib/tikilib.php on line 88

Fatal error: Uncaught Error: Call to a member function handleError() on null in /var/www/tiki.squadron6.com/tiki-25.2/lib/init/initlib.php:104 Stack trace: #0 [internal function]: tiki_error_handling() #1 /var/www/tiki.squadron6.com/tiki-25.2/lib/tikilib.php(88): trigger_error() #2 /var/www/tiki.squadron6.com/tiki-25.2/installer/tiki-installer.php(217): TikiLib::lib() #3 /var/www/tiki.squadron6.com/tiki-25.2/tiki-install.php(120): include_once('/var/www/tiki.s...') #4 {main} thrown in /var/www/tiki.squadron6.com/tiki-25.2/lib/init/initlib.php on line 104

clean setup first time run of of tiki25.2 php8.1-fpm nginx

Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^91f439aaf06630c3b75af65f02a2b0910ea664a7_0.file.footer.tpl.php:117 Stack trace: #0 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_651d975eb4dd85_74914763() #1 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #2 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #3 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render() #4 /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^8bc5c3b8d55e995fd256f4e80ad11e7d885d4a56_0.file.tiki-install_screens.tpl.php(42): Smarty_Internal_Template->_subTemplateRender() #5 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_651d975ea958a1_27233795() #6 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode() #7 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render() #8 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render() #9 /var/www/tiki/tiki-25.2/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute() #10 /var/www/tiki/tiki-25.2/lib/init/smarty.php(472): Smarty_Internal_TemplateBase->display() #11 /var/www/tiki/tiki-25.2/installer/tiki-installer.php(900): Smarty_Tiki->display() #12 /var/www/tiki/tiki-25.2/tiki-install.php(120): include_once('...') #13 {main} thrown in /var/www/tiki/tiki-25.2/temp/templates_c/en_classic^91f439aaf06630c3b75af65f02a2b0910ea664a7_0.file.footer.tpl.php on line 117

Clean install of tiki-26-0 php8.1.23 apache2 ubunut 22.04
After tiki setup completes eg lock installation and continue, I get a black webpage with this at the top

I wonder is some of the code not compliant with php8.1 the documentation mention arrays have to be a certain configuration:
Note:
Prior to PHP 8.0.0, square brackets and curly braces could be used interchangeably for accessing array elements (e.g. $array[42] and $array{42} would both do the same thing in the example above). The curly brace syntax was deprecated as of PHP 7.4.0 and no longer supported as of PHP 8.0.0.
[https://www.php.net/manual/en/language.types.array.php|https://www.php.net/manual/en/language.types.array.php]


Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, bool given in /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php:49 Stack trace: #0 /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php(49): in_array() #1 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup_base.php(662): AreasLib->getPerspectiveByObjectAndCategories() #2 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup_base.php(668): {closure}() #3 /var/www/tiki.squadron6.com/tiki-26.0/tiki-setup.php(66): require_once('...') #4 /var/www/tiki.squadron6.com/tiki-26.0/tiki-index.php(43): require_once('...') #5 {main} thrown in /var/www/tiki.squadron6.com/tiki-26.0/lib/perspective/binderlib.php on line 49

!!! Issue 1
When I put this:
{CODE()}{favorite objectType="wiki" objectId="PluginFavorite"}{CODE}
in a wiki page as documented here: [https://doc.tiki.org/PluginFavorite], the star can be toggled on and off but in the database I get lines like:
INSERT INTO `tiki_object_relations` VALUES (301,'tiki.user.favorite','user','admin','wiki','mypage');
Instead of :
INSERT INTO `tiki_object_relations` VALUES (301,'tiki.user.favorite','user','admin','wiki page','mypage');

This means that when I put the following code in another page as documented here: [https://doc.tiki.org/Favorites]:
{CODE(theme="default")}{LIST()}
{filter favorite="{ {user} }"}
{LIST}{CODE}
I match nothing.

!!! Issue 2
When I click on a favorite, the LIST plugin is not updated until I do a manual « index:rebuild ».

It will probably be necessary to fix Issue 1 before Issue 2 can be reproduced :-(

! Due to an UX issue, I created the show instance separately
[http://jyhem-9952-15.show2.tikiwiki.org]

Some AJAX services can trigger errors. Since {commit id=33686}, there is a mechanism for services to report such errors. Unfortunately, this mechanism is based on PHP's sessions. Errors are displayed at the next regular Tiki page load, which may or may not be related with the request which causes the errors displayed.

This mechanism used to be implemented in lib/errorreportlib.php. Starting with Tiki 16, it was replaced by the Feedback library, but the approach hasn't changed and remains unreliable in Tiki trunk as of 2018-10-11. The Feedback library uses the tikifeedback element of $_SESSION.

This mechanism was first used by lib/search/searchlib-unified.php, but has since been spread widely, as can be seen in the commits which created the Feedback library ({commit id=58746}, {commit id=58747} and {commit id=58748}). One specific issue which can occur as of Tiki 18 is, after going to tiki-admin.php?page=search (which calls the lookup action of the search controller), to get a "Malformed search query" error at the next page load, which could be on tiki-admin_actionlog.php for example.

Version 18.2

If i navigate as default user to an existing file gallery, select a file, open it's file informations (Get Info) and choose "Edit properties" i do have the option to re-upload a file from disk.

I assume this should upload a new file and replace the existing one. It should as well keep the existing ID.

For the default user i do get a blank page after pressing save, and the apache error log shows the following

[Fri Sep 14 11:15:38.891167 2018] [php7:notice] [pid 12030] [client 172.20.2.114:57704] PHP Notice: Undefined index: fileId in /var/www/html/lib/filegals/filegallib.php on line 3501, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12
[Fri Sep 14 11:15:38.891711 2018] [php7:warn] [pid 12030] [client 172.20.2.114:57704] PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/filegals/filegallib.php:3501) in /var/www/html/lib/tikiaccesslib.php on line 1142, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12
[Fri Sep 14 11:15:42.113287 2018] [php7:notice] [pid 12030] [client 172.20.2.114:57704] PHP Notice: Undefined index: fileId in /var/www/html/lib/filegals/filegallib.php on line 3501, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12
[Fri Sep 14 11:15:42.113706 2018] [php7:warn] [pid 12030] [client 172.20.2.114:57704] PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/filegals/filegallib.php:3501) in /var/www/html/lib/tikiaccesslib.php on line 1142, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12
[Fri Sep 14 11:15:55.943791 2018] [php7:notice] [pid 12032] [client 172.20.2.114:57754] PHP Notice: Undefined index: fileId in /var/www/html/lib/filegals/filegallib.php on line 3501, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12
[Fri Sep 14 11:15:55.944216 2018] [php7:warn] [pid 12032] [client 172.20.2.114:57754] PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/lib/filegals/filegallib.php:3501) in /var/www/html/lib/tikiaccesslib.php on line 1142, referer: http://tiki.x.y/tiki-list_file_gallery.php?galleryId=12

I don't get this error with my admin user account.

Version 18.2

I have configured
* "File Galleries" -> "Listings" -> "ID" to "Show as column"

If i open of the File Gallery i do see the column ID only in "list" view, but not in the "Finder" view.


Current behavior:
* ID column is not shown in all possible views

Expected behavior:
* Show configured column if view-mode supports it

Version 18.2

I have configured 'File Galleries' that the 'default view' is set to 'List' and applied this setting

If i now select 'File Galleries' -> 'List galleries' i do see in fact the selected list view.
If i then navigate into a shown folder the view switches automatically to the Finder view.

I assume this is not the expected behavior of a configured default view or is it?

Current behavior:
* Switches view automatically on choosing/opening a folder

Expected behavior:
* stick to the configured default view until a user selects another view

When producing the report at dev.t.o I tried to upload a screenshot and I had several time an error before on my fourth attempt I could successfully upload a file.

Details on how I proceed to upload an image at dev.
* I click on the img wikiplugin icon on the toolbar of the (this) text area.
* I click on "Browse Gallery", using the side Explorer I navigate to: Bugs report => Bsfez
* I click on the upload icon

There I tried with different options:
"Automatic upload" yes/no
Dragging the file on the upload area, using the "Choose file" button

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

I forgot to mention that I tried on brand new Tiki25 (new DB) and I couldn't reproduce.
No issues for the same operation on 2 Tiki26.
Could be something at dev.t.o only.

When you have more than one version of an image in the file gallery (via the update mechanism) you get an additional property: Archive.

When you select that, you get this images individual archive displayed. All images have the standard properties, and among them is "delete" to delete the image. That works as it should.

But also each and every image gets a checkbox, and underneath the listing, you can perform some task on a set of images collectively (all that got a check in the checkbox).

Among those task is again "delete".

But when you check some archived images and select a collective delete, this will be completely ignored. You do not even get the normal confirmation dialog. Also, no error message. It just does _nothing at all_. Whatever you had selected stays selected. And this is independent from permission, the same happens to the admin, when he or she wants to delete a selection of images.

As I said before, individual deletion works as it should, so it's probably "only" a problem of the collective delete algorithm.

Thanks
Hman

Once the file gallery batch feature is enabled:
At https://next.tiki.org/tiki-batch_upload_files.php?galleryId=17 at the bottom if you enable "Upload into galleries according to sub-directories" other options are displayed but the design alignment and position of sentence is broken. Col-4 and 8 are over lapping instead of being one next the other.

As the additional options are child of "Upload into galleries according to sub-directories" they should look like child options (indent)

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

When downloading file/files from the file gallery the actual download completes in ~1 second. The File Gallery UI download progress bar still thinks the download to progressing at a slower rate and shows 100% complete after 10 or so seconds.

I'm getting a 500 error trying to upload the screenshot so I'll attach

I experience that my site's file galleries get slower and slower. Currently, there are just about 200 Mbyte of mostly images in there, in just about two dozen folders. Although my rented web space will of course not boast performance wonders, but it should't be THAT slow. When I clear caches, just calling file galleries takes up to three minutes. If cache has not been cleared, galleries come up instantly.

I have stopped using tiki-check.php even before that, because it regularly breaks my ISPs five minute quota...

I store the images in the DB, but I don't think this really makes the issue. The DB still has almost a terabyte of available storage. And a DB's speed shouldn't depend on amount of storage taken, but on complexity of SQL requests.

I believe that most of the current slowness came when I uploaded some graphics for my co-admins that are not large in size, but large in dimensions (300 kbyte, but 14,000 x 10,000 pixels) (logo master file in PNG). For them, thumbnail creation fails. Could it be that Tiki tries to generate those thumbnails all the time, and fails?

Thanks
hman

This may overlap with the Bug report that "large file galleries are broken".

I consider mine not to be large, but it's broken anyhow. I first noticed it a month ago, when there were about 30-50 images in the file gallery. An image I knew I uploaded was not to be found anywhere. Back then, I thought it might be my mistake, and uploaded again, everything seemed fine.

But now there are precisely 300 images in the file gallery, and I wanted to upload a newer high-res version of an image I had uploaded last month. Then I had only a very low res version, but I had uploaded it as a stub, and created a Wiki page containing this image.

I could not find the image in the gallery! But the Wiki page containing it looked fine... So it was definitely in there, but was not to be found. Then I looked up the images ID in the page source, and used the search function of file gallery to find it - and there it was.

By the way: A feature request. The search function works, but it does NOT indicated WHERE a file was found. That is not very useful...

Then I uploaded the new high-res version, the Wiki page promptly showed it, everything looked fine again

[Edit: there weren't 238 images vanishing from display, as I wrote in the first version of the bug report. That was my mistake: 238 of 300 images are in one folder, and 62 in another. That is still being displayed correctly.
But the issue remains that sometimes single images vanish from display, and can only be found again using the search function.]

When you are in file galleries, some file galleries may contain more images than others. If you are on page 2 (or subsequent) of the sub-gallery you are currently browsing, the according page is loaded with parameter offset=25.

From this view, you can directly click another gallery from the tree that is displayed on the left-hand side.

But ALL subgalleries in the tree are linked with parameter offset=25, so when you click one that does not have more than 25 entries, you get the error message (information) that there is nothing to be displayed...

So either change the logic that all subgalleries in the left-hand tree are linked with their root (offset 0) or display the last possible page of that gallery, when it gets clicked. I would prefer the former.

Thanks
hman

In the file galleries, hovering over the screwdriver icon opens a mouseover activated list of actions to perform on the file, one of them is to edit the file's properties. That is the regular behaviour.

This does stops working when you do click on the screwdriver icon. This merely reloads the page, adding &view=browse# to the URL. Even stranger, mouseover stops only for the very file where you clicked on the screwdriver. All other screwdriver icons still produce the mouseover window.

After switching to another browser tab and back, all screwdrivers produce the mouseover again. Sometimes this also happens to the results of a search operation in a file gallery.

Seen on Mozilla Firefox 78 running on Linux.

We link to files in our tiki as follows

{CODE()}* {FILE(type="gallery" fileId="877" showicon="y")} foofile {FILE} {CODE}

Renders as (live example):
* {FILE(type="gallery" fileId="877" showicon="y")} foofile {FILE}

The -+showicon+- parameter results in having a nice little icon displayed closed to the linked file which is nice.

Problem:
--
Using the print function in Chrome shows those icons several times bigger then they are shown in the actual / normal article view. For me it looks like the print preview in chrome shows the icons in original filesize of the icon, while in the normal article view the icon is displayed in a way smaller size.

In Firefox it behaves slightly different: Print preview looks fine (small icons) but the actual print is using bigger icons as well.


Possible solution/fix:
--
The print css should use the same fileicon-size as in the normal article view

I create a tracker with a ''Files'' field

If the option of the field ''Upload In Modal'' is ''No'', it is impossible to upload a file.

The message I get is:
^ 194x258_Marc Laporte.jpeg (Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.) ^

Reloading makes no difference.

I tried in 18.x also and I got no error message but I got the "Loading" turning circle forever, which is a bit different but it does not allow uploading either :-(

I tried to filter a search (Elastic search) at info.tiki.org and at themes.tiki.org. In both cases I input the search term and got results and then selected Object Type ("wiki page") and Federated search ("local search") to only get results from the site I was at, and only wiki pages. But nothing changed -- the same results were listed, including forum posts and tracker items at other sites.

Using Firefox, clicking the "Filter" button had no effect at all. In MS Edge, the page refreshed but the same search results were shown as before -- no filtering happened.

Is this a know problem, or is there a method for the user to get this to work?

Editing a WYSIWYG section in a page may leave the semaphore on the page after saving or cancelling the edit, due to a session bug exposed. This can be worked around by waiting the lock's expiration, or by editing the full page and using Cancel Edit.

The bug seems to occur only when session_storage is set to Database. File-based storage apparently does not trigger. When 2 concurrent AJAX requests are processed, changes to the session made by the first can be lost by the second request. Presumably, this is only true because the first request completes after the second one starts but before it ends.

The scenario where the WYSIWYG plugin exposes is that initiating an edit causes 3 AJAX calls to SemaphoreController:
# one to is_set
# one to set
# one to tohtml

Request 2 modifies $_SESSION to add a key storing a UNIX timestamp (on the pre-last line of action_set()). On a wiki page named "TestWYSIWYGPluginNoHTML", that key would be 'semaphore_TestWYSIWYGPluginNoHTML_ wiki_page'.

~np~When cancelling (for instance), 2 requests are made. The problematic one is the call to unset. The call to $this->table->delete() in unset() fails because $lock is empty. $lock is empty because $_SESSION[$this->getSessionId($input)] evaluates to null.~/np~

This affects revision 65380 of trunk.

Note of fixes todo for -+release.php+- hopefully to be tested out on v 22.2
* Fix db connection issue on smarty syntax check step
* Use php -+passtru+- on composer install when using debug-packaging so you can see what's going on
* Use -+php console.php translation:getstrings+- instead of the deprecated get_strings.php

Trying to create a show instance with Tiki 18.x