Category: 12.x

When you have more than one calendar, and you have user watches enabled, the display of the icons to watch calendars is not shown. I tagged this as a dogfood a tiki.org site since this is an improvement needed for tiki users to get notified on Tiki fests, for instance. Currently, most powerusers don't know that they can monitor the tiki calendar.

In order to monitor calendars right now, you need to deselect all calendars, re-select just one, refresh, and then you will see the icon to watch / monitor /subscribe to the calendar. And you need to do that one by one.

Expected behavior: some way to see the list of all calendars with the icon to subscribe to each of them next to its name. Maybe through similar popup with the full list of calendars that you have the right to see and monitor, and then, you expose those icons/actions there?

Show.t.o instance:
http://xavi-9794-5877.show.tikiwiki.org
u: admin
p: 12345

There are 3+ calendars already, and when all are selected for display (default behavior), no icon to monitor them is shown:
http://xavi-9794-5877.show.tikiwiki.org/tiki-calendar.php

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

But when you select just one, you can see the icons to monitor it:
http://xavi-9794-5877.show.tikiwiki.org/tiki-calendar.php?calIds%5B%5D=3&todate=1459860043&refresh=Refresh

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

It would be handy to have more internal wiki variables exposed as Wiki Argument Variables.
eg version, description, last author etc

The reason is simple. Reuse instead of repeat.
I for example am setting up tiki to keep and maintain ISO 9001 and HACCP documents and records.
The standards require each file to have version and associative info to it which works fine when viewing online but when printing, all the above have to be re-entered manually and updated on every change on every page.

Hello,

a freshly unzipped Tiki 11.0 installation which is configured to use Tiki and LDAP user accounts can't require_once the Net/LDAP2.php file in lib/auth/ldap.php line 14.

I tried to re-generate the composer autoload files, but without success.

Now, I extended the include_path in my php.ini file for vendor_extra/pear

Please have a look at this issues.

Thanks und regards
Lars

Plugin TrackerIf doesn't seem to accept nesting so far, and we need it to allow customization of the interface to edit data with Pretty Trackers.

*If field_1 is A
** if field_2 is not empty, display value of field_2
** if field_3 is not empty, display value of field_3
** if field_4 is not empty, display value of field_4
** ...
* if field_1 is B
** if field_10 is not empty, display value of field_10
** if field_11 is not empty, display value of field_11
** if field_12 is not empty, display value of field_12
** ...

{CODE(ln="1")}
{TRACKERIF(test="(f_1='A')", ignore='n')}
{TRACKERIF(test="(f_2 ='')", ignore='n')} {ELSE} {$f_2|output} {TRACKERIF}
{TRACKERIF(test="(f_3 ='')", ignore='n')} {ELSE} {$f_3|output} {TRACKERIF}
{TRACKERIF(test="(f_4 ='')", ignore='n')} {ELSE} {$f_4|output} {TRACKERIF}
{TRACKERIF}
{TRACKERIF(test="(f_1='B')", ignore='n')}
{TRACKERIF(test="(f_10 ='')", ignore='n')} {ELSE} {$f_10|output} {TRACKERIF}
{TRACKERIF(test="(f_11 ='')", ignore='n')} {ELSE} {$f_11|output} {TRACKERIF}
{TRACKERIF(test="(f_12 ='')", ignore='n')} {ELSE} {$f_12|output} {TRACKERIF}
{TRACKERIF}
{CODE}

When newsletters are edited using the wysiwyg-html edit, extra lines are added.
Tested on Tiki 12.4svn

Will setup a show instance.

Tiki14 has the same problem. I haven't tested other version.
This problem makes it impossible to work with newsletters in html.

When a page which calls the FADE plugin is printed via tiki-print.php, the call's body is not printed by default. To print the content in my Tiki 18 and 19 installs, once I am in tiki-print.php or tiki-print_article.php, I must cancel the automatic printing, click on the label, and then have the browser print. Having revealed from tiki-index.php does not suffice.

It is arguable how much of a bug this constitutes, but the fact the hidden content is quietly hidden when printing is in my opinion already a problem. I believe if the content is not printed, there should at least be a warning displayed, and ideally an offer to reveal hidden zones ("This page contains hidden zones. Should the content of these zones be printed?").

The current way to reveal the zones - to click in tiki-print.php - is very strange, since one would not expect tiki-print.php to be interactive.

Seen on dev.tiki.org {sign user="marclaporte" datetime="2013-11-26T13:18:26+00:00"}

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.

Some phantom prefs are introduced in each version of Tiki, as devs add/change prefs but don't notice this. So before each major release (ex.: from 11.0 to 12.0, but not from 12.0 to 12.1), a complete check needs to be done, for all admin panels.

# Start with a fresh install (this is important because some of these issues could only happen once)
# Visit tiki-admin.php
# Activate all Preference Filters (Basic, Advanced, etc.)
# For each of the approx 50 panels on tiki-admin.php
## Activate or deactivate any checkbox (any pref really) on the page (only one per URL, no need to do it per tab).
## Confirm that the pref change is reported.
## If any ''other'' pref change is reported, figure out why and resolve.

{img fileId="745"}

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.

The Favorites button does not work consistently without SEFURL on.

Getting file corruption on display/download.

We are getting file corruption in the file gallery. The first byte is getting prepended with a "0a" newline character and the last byte is getting dropped. This is happening on display/download, not upload. We have verified by manually copying uploaded files off the server and the stored files have no corruption.

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.

The backlinks in the file gallery don't appear to work. At lest they do do nothing with my install and configuration.

Not really sure how to proceed, but just to let you know. It could have been a very useful feature to me :(

Happy to give more info if you like. Backlinks for wiki pages seems to be working well. 12 LTS installed. Latest version (installed just over a week ago)

I got a problem to see thumbnail and download file from File Gallery.
What I did are:
1. create a customized a folder for file gallery
2. point the file gallery folder destination to the new folder in setting.
3. upload a file
4. try to view the file and download the file, the system goes to endless loop, and no responds from server to client, logs are continuously generated till disk full.
[Thu Jan 01 12:56:38 2014] [error] [client 192.168.1.102] PHP Notice: ob_end_clean(): failed to delete buffer zlib output compression. in /apps/tiki/tiki-download_file.php on line 147, referer: http://tiki.mydomain.com/file1
5. after I check the code. in the tiki/tiki-download_file.php, line 146, it has below
~~#60F:while (ob_get_level()) {
ob_end_clean();
}// Be sure output buffering is turned off
~~
6. I googled the coding, looks it should be changed as below.
~~#60F:while (ob_get_level()>1) {
ob_end_clean();
}// Be sure output buffering is turned off
~~
7. I changed, the code, the file viewing and download are perfect. problem is solved.

Could any developer please review the code, if it is the way to go, please merge the change into the main trunk for future releases.

Thanks.

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

Clean install of v12.4
Logged in as Admin
Set File Galleries to Store in database
Global permission "Can view file galleries (tiki_p_view_file_gallery) set to Anonymous and "Can download files (tiki_p_download_files)" set to Anonymous (this was the default setting)

Goto File Galleries-->List Galleries List Gallery view
Rollover file names produces popup thumbnail, also in Browse Images view preview images display
Uploading new file displays thumbnail and preview image OK

From Fille Galleries goto Permissions, then edit global permissions and change "Can download files (tiki_p_download_files)" from Anonymous to Registered
Go back to File Galleries, refresh the page and most, if not all, thumbnails turn into question marks as well as the preview images in the Browse Images view. Clicking on the filename downloads the correct file and using the Action Display loads the file in a new page, which is what was expected. (This has the same results with a Registered user and with setting the single object permission)

Resetting "Can download files (tiki_p_download_files)" back to Anonymous brings back the images.

Conclusion: if "Can download files (tiki_p_download_files)" is set to anything other then Anonymous the file gallery will not display thumbnail or preview images for any user.

I had expected to be able to use the "Can download files (tiki_p_download_files)" permission to limit who could download files, not who could see them.

Go on http://demo.tiki.org/trunk/tiki-list_file_gallery.php.

If you click on the title of the page "File Galleries" you'll download a picture (seams the first one in the gallery).

Dear Sir:

This may not sound as a bug, but this could be a problem for people who use tiki to build a professional website.

In an ideal CMS, no one has to know what platform the webmaster is using. Knowing the platform from first sight is considered a huge flaw in the design of the CMS. It's not my position to defend this statement, but you're professional developers, and you understand how this should be the first piece of information any hacker is looking for. Honestly I'd be already surprised if this not clear.

With that said, let's state the problem: The problem is that every php page in tiki has the prefix "tiki-", like "tiki-index.php". Now why?

Let's look at this rationally. Does this benefit the user with anything? Absolutely not. As it looks to me, it's just a show-off of the kind "hey look, this website was made by tiki, and the webmaster couldn't get rid of those urls exposing him".

Trust me, some companies will just refuse to use the whole platform because of this! Usually organizations are paranoid about security.

So please, fix this. Just remove every "tiki-" from every file name. There's not a single good reason to have it done this way.

PS: Renaming the files myself is not considered a solution. Even if it works, an update will mess it up.

Best,
Samer

Consider a tracker 1 that has a field with fieldId=2 of type item link, and multiple values are allowed for this field. Assume that the tracker contains an item 3 where field 3 is a set of 2 item links, one to value "A" and one to value "B". The value of field 3 of item 2 in tracker 1 will show as "A,B".

Now make a trackerlist with trackerId="1" filterfield="2" and filtervalue="B". Due to a bug in trackerlib.php item 3 will not be shown. Item 3 should be shown, because value B occurs in field 2.

The problem is that the code does not handle item links with multiple values, and the filtervalue is checked only against the first link in the link item field.

The bug is due to the following piece of code:

INNER JOIN tiki_tracker_item_fields ttif{$i}_remote ON ttif$i.`value` = ttif{$i}_remote.`itemId`

The ON statement should take into account that ttif$i.`value` can be a list of itemIds, not a single value. Replacing this code with the following code resolves the problem:

INNER JOIN tiki_tracker_item_fields ttif{$i}_remote ON FIND_IN_SET(ttif{$i}_remote.`itemId`,ttif$i.`value`) > 0

We now use htpasswd, which is great for extra security, but can cause issues in certain cases.

We want to block indexing, but fully configured via Tiki, similar to site_closed.

How could we do this? This would be useful for show.tiki.org and for dev and staging sites.

Seem like bottrap idea... (anyone tried it?)

Related links:
* http://perishablepress.com/blackhole-bad-bots/
** http://www.kloth.net/internet/bottrap.php
* https://support.google.com/webmasters/answer/93710

Tablesorter doesn't seem to load when the tiki 12 lts is shown in mobile mode.

Similar approach works on 14.x, but it wpuld be lovely to have our LTS branch work in mobile also

Reproduced here:
http://xavi-9794-5655.show.tikiwiki.org/tiki-index.php?page=Sortable+Tables+demo#step2

U: admin
P: 12345

Switch to mobile and see how the tablesorter ui is lost

There are some tips elsewhere about how to fix this type of issue (I wonder if it's the same or not):
https://forum.jquery.com/topic/tablesorter-with-jquery-mobile#14737000003054153

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"}