Category: 18.x

I set up a Tiki with User Registration with some required fields and using a pretty tracker.

When a user fills the registration form with no value in a ''mandatory'' field, the tracker item is not created and a failure message is displayed with the form so the user can try again. __BUT__ the user is still created.
So, the next attempt will fail again because the user already exist :-(
Also, the admin will not get the email about a new user registration.

In this case, the user should not be created :-(

__More info:__
The issue is only when using pretty tracker templates.
When not using a template, the validation prevents from leaving the registration page, so the issue is not there.

So, a fix would be to make the validation work even when a template is being used for registration.

For reference, the template file -+ask-registration.tpl+- is:
{CODE()}
<div class="registration_form">
<div id="registration" class="panel panel-default">
<div class="panel-body">
<div class="form">
<label for="name" class="control-label titlefield">username</label>
{$register_login}
</div>
<div class="form">
<label for="name" class="control-label titlefield">{tr}Email{/tr}</label>
{$register_email}
</div>
<div class="form">
<label for="pass1" class="control-label">{tr}New Password{/tr}</label>
{$register_pass}
</div>
<div class="form">
<label for="pass2" class="control-label">{tr}Confirm password{/tr}</label>
{$register_pass2}
</div>

<div class="form">
<label for="ins_6" class="control-label titlefield">Not mandatory</label>
{$f_1}
</div>
<div class="form">
<label for="ins_3" class="control-label titlefield">Mandatory field</label>
{$f_3}
</div>

<div>{$register_antibot}</div>
</div>
</div>
</div>
{CODE}

I tried to upgrade my Tiki kipinapartio.fi from 17.1 to 18.0 .

During the database migration phase got this error:

{CODE(theme="default")}Fatal error: Uncaught Error: Call to a member function urldecode() on null in /home/kipinapartio/tiki-18.0/lib/parser/parserlib.php:3682
Stack trace:
#0 /home/kipinapartio/tiki-18.0/installer/schema/20171123_create_object_links_tiki.php(18): ParserLib->get_pages('Lippukuntamme k...')
#1 /home/kipinapartio/tiki-18.0/installer/schema/20171123_create_object_links_tiki.php(43): {closure}(Object(Installer), 'article', '34', 'Lippukuntamme k...')
#2 /home/kipinapartio/tiki-18.0/installer/installlib.php(175): upgrade_20171123_create_object_links_tiki(Object(Installer))
Fatal error: Uncaught Error: Call to a member function urldecode() on null in /home/kipinapartio/tiki-18.0/lib/parser/parserlib.php:3682
Stack trace:
#0 /home/kipinapartio/tiki-18.0/installer/schema/20171123_create_object_links_tiki.php(18): ParserLib->get_pages('Lippukuntamme k...')
#1 /home/kipinapartio/tiki-18.0/installer/schema/20171123_create_object_links_tiki.php(43): {closure}(Object(Installer), 'article', '34', 'Lippukuntamme k...')
#2 /home/kipinapartio/tiki-18.0/installer/installlib.php(175): upgrade_20171123_create_object_links_tiki(Object(Installer))
#3 /home/kipinapartio/tiki-18.0/installer/installlib.php(130): Installer->installPatch('20171123_create...')
#4 /home/kipinapartio/tiki-18.0/installer/tiki-installer.php(1049): Installer->update()
#5 /home/kipinapartio/tiki-18.0/tiki-install.php(102): include_once('/home/kipinapar...')
#6 {main} thrown in /home/kipinapartio/tiki-18.0/lib/parser/parserlib.php on line 3682{CODE}


This is an old Tiki that has been upgraded many times. Reverting now back to 17.1 but I'm available to provide any extra info you need.

There is some failure to get geolocation from searching an address either manually typing address through tracker field location ui or in the backend with params to get address from other tracker field.
No point selected for that address, even for simple cases that used to work in previous tiki versions.

Fancy table
code works in ver 15 but copy and paste into ver 18 causes fault to table sorter list.
The common name shows data function list.
I have used tikiwiki syntax ((around common name)) to make page link.
in ver 15 it works, but the same code in 18 caused common name list to expand and show data function list
If you remove the (( )) the problem disappears
Update
it works on the show.tiki site fancy table page
I am running ver 18 on a home server (debian linux) does this mean the jquery or javascript on the server is wrong or the ver 18 installation
version 15 is on the same server and works okay.


example

{DIV(class="row")}{DIV(class="col-md-12")}{FANCYTABLE(colwidths= "5%|10%|20%|10%|30%|25%" head=" Flower|Common name| Type | Picture | Seedling" sortable="type:reset" sortList="[0,0],[1,1],"tsortcolumns="type:word;group:word|type:word;group:word|type:word;group:word|type:nofilter|type:nofilter|type:nofilter" tsfilters="type:dropdown|type:dropdown|type:dropdown|type:nofilter|type:nofilter|type:nofilter " tsfilteroptions="type:reset" tspaginate="max:50")}
white|((Bittercress))|rosette|{img fileId="286" thumb="box" desc="name"}|{img fileId="287" thumb="box" desc="name"}
yellow|((Buttercup))|rosette spreading|{img fileId="356" thumb="box" desc="name"}|{img fileId="288" thumb="box" desc="name"}
white|((Bramble))|Climbing Tall|{img fileId="369" thumb="box" desc="name"}|{img fileId="355" thumb="box" desc="name"}
{FANCYTABLE}{DIV}{DIV}

When the TRACKERITEMFIELD plugin is called trying to access a tracker item which does not exist, a fatal error like the following occurs:
{CODE()}
Fatal error: Call to a member function getConfiguration() on boolean in C:\xampp\htdocs\tiki\18\lib\core\Tracker\Item.php on line 200
Call Stack
# Time Memory Function Location
1 0.2009 192464 {main}( ) ..\route.php:0
2 0.2617 4607672 include( 'C:\xampp\htdocs\tiki\18\tiki-index.php' ) ..\route.php:306
3 0.5479 18560680 Tiki_Render_Lazy->__toString( ) ..\route.php:645
4 0.5479 18560712 call_user_func:{C:\xampp\htdocs\tiki\18\lib\core\Tiki\Render\Lazy.php:22} ( object(Closure)[521] ) ..\Lazy.php:22
5 0.5479 18560752 WikiRenderer->{closure:C:\xampp\htdocs\tiki\18\lib\wiki\renderlib.php:346-356}( ) ..\Lazy.php:22
6 0.5480 18560984 WikiLib->get_parse( string(16), bool, ??? ) ..\renderlib.php:349
7 0.5484 18565728 WikiLibOutput->__construct( array(34), string(58), array(3), string(1) ) ..\wikilib.php:802
8 0.5484 18566056 ParserLib->parse_data( string(58), array(3) ) ..\wikilib.php:2155
9 0.5485 18568760 ParserLib->parse_first( string(58), array(2), array(2), ??? ) ..\parserlib.php:1667
10 0.5537 18774536 ParserLib->plugin_execute( string(16), string(0), array(3), long, bool, ??? ) ..\parserlib.php:439
11 0.5562 18785784 wikiplugin_trackeritemfield( string(0), array(3), long ) ..\parserlib.php:1031
12 0.5670 20145512 Tracker_Item->canView( ) ..\wikiplugin_trackeritemfield.php:193
13 0.5670 20145664 Tracker_Item->canSeeOwn( ) ..\Item.php:88
{CODE}

Objects which contain such calls cannot be viewed, and reindexing for search is also broken.

This happens since {commit id=37583} and persists in trunk r68584.

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

!! Tiki fatal error while upgrading.

Tiki generates fatal error when attempting to upgrade.
__I've reported this first here in the forums: __
[https://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=68370&threadId=68670&thread_sort_mode=commentDate_asc#threadId=68670|https://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=68370&threadId=68670&thread_sort_mode=commentDate_asc#threadId=68670]
I was suggested that i publish the information here instead in bugs to get help with this issue which is very critical for me, because I cannot upgrade

__I have make a short video that shows the issue here,:__
[https://www.screencast.com/t/Q1Cmsrfw|https://www.screencast.com/t/Q1Cmsrfw]
''(Please turn on your sound, because I am speaking in it)''

As you can see from the video it fails everytime. I also replaced all tiki files. with the newest ones prior to do the upgrade attempt. I deleted all the old files on the server and uploaded a fresh copy.
Now with that said, the same errors occurred while trying to upgrade when the server had the old installation files on it. So there is really not a difference in that part.


I hope that someone can help out with this, I really, really don't wish to reinstall from scratch and then manually transfer all the data from the old system to the new installed copy.

Thanks a lot in advance!
Kind regards
PowerQuest

Currently, Tiki does not have a feature to lock a specific user account.

Such locks can be essential. E.g. when you created a user account, but the user doesn't use it. For security reasons, you must lock it after a certain grace period. Either automatically or, as a fallback, manually.

Deleting is not a way to do this, because then you delete all preferences, so in order to preserve user preferences, but secure the site, a lock feature is IMHO essential. Admins should have the ability to lock user accounts. Actually this should be a perm of its own "Can lock user accounts", given by default only to members of the Admin group.

As a workaround, an Admin can create a new password (only known by him/her), but I believe a locking mechanism is more elegant. Also it removes the necessity for the user to re-establish his/her password after the lock gets lifted.

In a more sophisticated version, Tiki could inform members of the Admin group if a user that has a lock imposed on his/her account tries to login, that a login attempt was made.

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.

In trackers, you have fields, and fields have field types.
Practically all (at least all I checked so far) field types have, under the tab "Advanced" the possibility to change the field type to something else.

I know, changing a field type may lead to loss of data, so this should only be done well thought-through.

But if the field type is "checkbox", there is no field type setting in "Advanced", therefore a field type checkbox cannot be changed.

If you are in the design phase of a tracker loss of data is no issue. But being stuck with a checkbox is. The only workaround is to delete the field with the checkbox altogether and re-create it with the other field type.

But has other side effects: The field ID is always incremented, so the re-created field has a field ID "at the end of all fields", while the former ID is now unused, so you have to rewrite all tracker plugin calls "minding the gap" so to speak B-)

The only way to work around this is erase all fields and re-create them all. Which is, of course, cumbersome. As there is another (unnecessary) obstacle waiting: If you want to make admin life a little easier, you might want to export all fields, edit the export (if necessary), and re-import. But the export dialog does not exist if you have the tracker open. There is only an import button. The export exists only on the wrench icon of the tracker...

I upgraded to 18.0 and got this error, then I upgraded to 18.1 and still got this error.

I erase the website, built a new database, and I still get this error.

When I try to upload a file to file gallery
MetArt01s.jpg
File upload failed: SyntaxError: Unexpected token < in JSON at position 0

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

By default, creating a file gallery marks it as locked (the "Gallery is unlocked." checkbox is unckecked and the public property is disabled). This causes users other than the gallery's owner to be unable to upload files to galleries by default, even if they have tiki_p_upload_files on the relevant gallery.

There are several ways to see the problem:
# An object should not be created locked by default.
# The description of tiki_p_upload_files, "Can upload files", is misleading as it does not mention locking.

This can be considered as 2 different problems, but it would be prioritary to fix at least one, no matter which.



I think that by default "Gallery is unlocked" should be checked, but changing such a default would be dangerous if users relying on the current behavior don't realise the change. So I think my recommendation would be to replace the current checkbox with 2 radio boxes (labelled something like "Only owner can upload files" or "All users with permission can upload files"), with none selected by default.

File galleries have a useful feature: You can store more versions of a file than one. That allows for images to be updated with higher resolution ones etc.

When you browse a file gallery, the wrench icon gives you access to the other archived versions of the file. However, when you access the file gallery by the ID of a specific file (which doesn't change when you upload new versions!), then the wrench icon lists Archive, but does NOT give access to any older, archived versions. Thus, the Archive feature cannot be used (at all) when accessing the file gallery by file ID...

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

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

I'm not quite sure whether this should come into the file gallery involved, or into the tracker displaying (products tracker from Tiki cart). When you delete a product image from the file gallery, the tracker will still show the deleted image. Of course that is just a (browser) caching issue. But once you reload (or if you've never had the image in question cached) you only get the browsers missing image (i.e. broken link) icon.

IMHO it would be better to display an automatic image from TikiWiki instead, just like other webshops do it like "no image available", "no image provided for this article" or something in this fashion.

Thanks
hman

The File Gallery Template feature is still in Tiki, and it seems nobody really knows what it was used for, if you will here is something I wrote a couple years ago on this, at https://tiki.org/forumthread59522
If this is supposed to work somewhere, it sure would be great to have it working if the intentions were to build upload templates from it.
Thanks for looking
John

When you open a file gallery, above the files stored in there are some functions for searching, and one that specifies how many results are to be displayed. The latter is misleadingly labelled "Number of lines". If you set the file gallery for list view that is correct. If you didn't, it's incorrect. In browse view your results will be in five columns, giving __five__ lines (with the default setting of __25__).

Therefore I suggest to rename this to "Number of results" which would be correct in all view settings.

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike