Category: 17.x

The Table Builder tool offered in the toolbar when using CKEditor with wysiwyg_htmltowiki enabled inserts incorrect code in Tiki 17 and ulterior, although it worked in Tiki 16 and earlier.

For a table with "R1C1" in the first cell and "R2C1" in the first column of the second row, the inserted syntax should be...
{CODE(caption="Proper code" colors="tiki" theme="default")}
||R1C1
R2C1||{CODE}
...but it is actually...
{CODE(caption="Broken code" colors="tiki" theme="default")}
||R1C1 %%% R2C1||
{CODE}

Which is to say, each newline is replaced with 3 percentage signs.

There is no change dialogTableInsert() between Tiki 16 and 17. In fact, things seem to go well in dialogTableInsert(), and even when it calls insertAt(), up to the point where insertAt() calls cked.insertText(), which is where it gets too hard to follow for me.

If the issue is in CKEditor's insertText(), it seems likely that the regression was introduced by the bump of CKeditor from 4.5.11 to 5.7 (done via r61891).

Table editor in wiki edit doesn't open anymore. It did work as expected in 15.x and 16.x

Page contents with this table here (even after updating 17.x to use svn r63071):
http://aspb.llavorspac.org/ASPB+Vehicles

However, I can't reproduce in the show.t.o instance, I don't know why. {sign user="xavi" datetime="2017-06-25T19:20:07+00:00"}

See this code:

{CODE()}
{TRACKERLIST(trackerId="6" fields="20:27:31:33:34:43:46:36" showstatus="y" status="op" sortable="y" server="y" editable="43" tsfilters="type:text|type:text|type:text|type:text|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:dropdown" showlinks="y")}{TRACKERLIST}
{CODE}

The tsfilters code __type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31__ is now {sign user="xavi" datetime="2016-08-12T09:19:21+00:00"} in trunk applied (so that items without date or not matching the date range are filtered out), while in Tiki 15 they were just used to preselect the date of the rate range filter, but those date ranges were not applied (items without date or not matching the date range where also shown in the results of the table).

---
If this is confirmed as a regression and fixed in trunk, I reckon that we need to revert this commit I made before I knew that this looked like a regression:
{CODE()}
[ENH]Warn the user that this apparently is the new default behavior for 16.x. Probably feature fix since it makes more sense to be like this, but it was not the default behavior until short ago, afaik. Subversion: Committed revision 59430.
{CODE}
---
Fixed reference to affected branch. It was trunk, and at the time of the bug reporting, that meant 16.x. This issue is not seen any more in 16.x, however, it is in trunk still. Therefore, I tagged it against 17.x and 17.x regression. {sign user="xavi" datetime="2017-01-03T23:23:27+00:00"}

Reproduced here:
http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6201
Last column for LastModif
u: admin
p: 12345

Currently using:
Last update from SVN (17.0svn): Tuesday December 13, 2016 15:09:21 CET - REV 60628 (MyISAM)

And using 16.x, reproduced here:
https://demo.tiki.org/16x/tiki-index.php?page=Homepage+for+user+Gc
u: admin
p: 12345

Tablesorter: dropdowns in tsfilters and shown as text filters (most of them) when server=y

Reproduced at the show instance from this related report:
https://dev.tiki.org/item6200

http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6202
u: admin
p: 12345

edit the page, and you will see that many of the filters where set as dropdowns, However, they are shown as text filters.

Tablesorter: filtering for an item doesn’t find it if not in the first pagination when server=y


It was going to be reproduced at this show instance but for some reason, I cannot reproduce the issue that we have seen in a development site for a client. :-/

In any case, for the record:
http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6200
u: admin
p: 12345

FYI: this show instance is also used to demonstrate the issues reported in the bug reports:
https://dev.tiki.org/item6201
https://dev.tiki.org/item6202

Tablesorter: with server=n tspaginate is not taken into account (we did set max:2 and it keeps displaying all the 5 items) when js minification is enabled.


Reproduced at the show instance from this related report:
https://dev.tiki.org/item6200

http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6201
u: admin
p: 12345


{CODE()}
{trackerlist trackerId="1" fields="4:2:3:1:5:8:9:10" showlinks="y" popup="6:7" editableall="y" sortable="y" showstatus="y" status="opc" tsfilters="type:text;placeholder:|type:dropdown;placeholder:|type:nofilter|type:dropdown;placeholder:|type:text;placeholder|type:dropdown;placeholder:|type:dropdown;placeholder:|type:dropdown;placeholder|type:dropdown;placeholder|type:text;placeholder" tspaginate="max:2;expand:5;expand:10;expand:20" showpagination="n" max="-1" server=n}
{CODE}

Disable minifcation cehckboxes in the control panels, and it worked for me as expected.

Tags: Add a modern beautiful and advanced filtering with HTML5 and jQuery, such as Filtrify
https://github.com/luis-almeida/filtrify
http://luis-almeida.github.io/filtrify/
MIT Licensed

We would use it to let users browse more easily Profiles from https://profiles.tiki.org

Demos:
* Multiple categories: http://luis-almeida.github.io/filtrify/movies.html
* Load images with Lazy Load: http://luis-almeida.github.io/filtrify/lazyload.html
* Add pagination with jPages: http://luis-almeida.github.io/filtrify/jpages.html

Text area field width and height parameters are not applied correctly.
Width is never applied.
Height is not applied when wysiwyg is on.

the latest release 17.1 no longer allows the theme width to be changed by pixel or percentage. Up through 17.0 the theme width could be fixed at a percentage, or a pixel, 85% or 1170px.

There are only two options now, full width, or default width. The custom theme width no longer seems to be operational.

Please see show instance.
Thank you.

5-16-2019 update: this issue has returned in Tiki19

I was researching a way to become more involved in Tiki that was not beyond my skill level. So Tiki Tester I feel would be a good way for me to give back to the community.
As I was digging into the Tikitester page, I found the links to the tiki test pages no longer are valid, please see:

https://dev.tiki.org/Instructions%20for%20Tiki%20Testers

And click on links to Tiki Test pages.
Thank you for taking a look at this, any further guidance would be appreciated.

There is text in tiki-install.php that is in english without tag or option to translate it.

{CODE()} $title = 'Tiki Installer Security Precaution';
$content = '
<p style="margin-top: 24px;">You are attempting to run the Tiki Installer. For your protection, this installer can be used only by a site administrator.</p>
<p>To verify that you are a site administrator, enter your <strong><em>database</em></strong> credentials (database username and password) here.</p>
<p>If you have forgotten your database credentials, find the directory where you have unpacked your Tiki and have a look inside the <strong><code>db</code></strong> folder into the <strong><code>local.php</code></strong> file.</p>
{CODE}

Would be nice to have this working as the rest of Tiki

tiki-user_preferences.php:
~np~Fatal error: Uncaught exception 'Exception' with message 'DateTimeZone::__construct(): Unknown or bad timezone (leapseconds)' in /<install_path>/wiki/lib/tikidate.php:147 Stack trace: #0 /<install_path>/wiki/lib/tikidate.php(147): DateTimeZone->__construct('leapseconds') #1 /<install_path>/wiki/tiki-user_preferences.php(421): TikiDate::getTimeZoneList() #2 {main} thrown in /<install_path>/wiki/lib/tikidate.php on line 147~/np~

Error is "fixed" by making the following additions to the array __deprecated_tr__ in file __lib/tikidate.php__ :
95a96
> 'leapseconds', // REH
103a105
> 'tzdata.zi', // REH

Not sure how universal the problem with other installations is (maybe I still have some environment setting issues?). On two newly upgraded (to 17.1.7) installations on the same shared hosting site. uname-a yields: Linux <host> 3.10.0-714.10.2.lve1.4.79.el6h.x86_64 #1 SMP Thu Jan 4 14:26:00 EST 2018 x86_64 x86_64 x86_64 GNU/Linux. Can supply tiki-check.php result also (which barfed until i also grabbed a new lib/core/BOMChecker/scanner.php from the trunk :). Basically CentOS release 6.9, PHP release 5.6.30. Can replicate with a fresh (not upgraded) install on the same server. Some other PHP errors / blank pages fixed by refining the PHP5.6 settings or .htaccess file and other settings (SEF URL is turned on).

Put importance lower as not sure how many installation environments will mimic mine (versus what you run tiki.org on). Your demo's for 17.x and 15.x have not been working for a week so cannot replicate there.

At : https://tiki.org/Roundtable+Meeting+2017+04
First time entered was 14:00, 15:00, 16:00, 17:00 and 18:00.
They are displayed in a logical and chronologic order.

A user added an option with time set to 21:00.
It should appear after 18:00 but it is displayed before 14:00.

It is very confusing and wrong.

{syntax type="tiki" editor="plain"}
((doc:Together)) works for tracker items. No reason for it not to work for wiki pages

Let's coordinate ((Together|here))

A tracker is created to included image upload. Image upload browse to gallery is set to a specific gallery to browse, when tracker image upload "Browse" is clicked, the tracker browses entire gallery structure, not only the defined "Browse" to gallery.
Please see show instance.

I set the tracker plugin with transaction step.
So I split the initial plugin tracker into 5 plugin trackers setting the following parameters for each one: transactionName, transactionStep and transactionFinalStep.
Something that looked like:

{CODE()}{TRACKER(trackerId="4" fields="1:2:3" transactionName="new" transactionStep="0" transactionFinalStep="n")}{TRACKER}{CODE}

{CODE()}{TRACKER(trackerId="4" fields="4:5:6" transactionName="new" transactionStep="1" transactionFinalStep="n")}{TRACKER}{CODE}

…/… till the last step a bit different.

{CODE()}{TRACKER(trackerId="4" fields="10:11:12" action="Save" transactionName="new" transactionStep="4" transactionFinalStep="y")}Thanks{TRACKER}{CODE}

The page show an error : You need to define both transaction name and transaction step, or none of the two.

It has been confirmed that it is not working

We often need a way to do conditional things in tracker forms, like show or hide fields depending on the user's input, or require validation on some fields depending on the state of others.

So this is to start a discussion about how this should be implemented, should it be a new field type? Or a function of the tracker plugin (which needs significant tidying up) or what?

So they should look something like:

* Category field
** If Category contains "bug" then
*** Show Workaround and Solution fields
*** Make Importance and Easy To Solve required

When creating or editing a tracker item, multi-line fields (text areas) can offer a toolbar, as wiki pages do. This works fine if the 'Use legacy tracker insertion screen' (tracker_legacy_insert) preference is enabled, but otherwise there are several bugs. Notably:
# The tooltips supposed to use Bootstrap popover are not processed, so they display as native titles, starting with a colon.
# The tools to insert internal and external links are sometimes unusable, at least in Firefox 53. The dialog appears, but clicking the text fields does not focus them. This does not happen in Google Chrome.
# Clicking the question mark quietly closes the edition dialog, losing the changes.

Yet, there are no JavaScript errors. I guess issue #1 occurs because the JavaScript for popovers runs on page initialization, so it does not catch popovers added to the DOM later. Other issues are probably similar, but I tried debugging issue #3 using Chrome developer tools unsuccessfuly. I fail to see an event listener on the question mark icon. I do not understand why the dialog would close when clicking if no JavaScript is run. There is no HTTP request when clicking.

The new edition screen was added notably in r50712 and r50714. This affects Tiki 15, 16, 17 and trunk (as of r63265). I set Importance to 8 because issue #3 can cause a certain data loss. I am surprised not to find an existing report of this bug since the field I am filling right now is affected by this problem.

Each tracker can have 1 title field. When an item of that tracker is listed, the value of that field can link to tiki-view_tracker_item.php. When listing with the TRACKERLIST plugin, the showlinks parameter controls this behavior.

As can be seen in Tracker_Field_Abstract::renderOutput(), this works by surrounding the return value of renderInnerOutput() with opening and closing HTML a element tags.

While this works for simple field types, this is highly unreliable when rendering a textarea field which is wiki-parsed. If the parse generates a link, the result is invalid HTML.

For example, if tracker 1 contains a single Textarea field, and a single item with value "foo\n!!! title
", calling the plugin with "~np~{trackerlist trackerId="1" showlinks="y"}~/np~" will cause the field to show as a link only on the first line ("foo"), at least in Google Chrome, since a header inside a link is invalid. I am not sure why, but if listing the items from tiki-view_tracker.php?trackerId=1 instead, the link only stops between the second and third lines (i.e. the title itself links).

This issue has probably been there from the time TRACKERLIST was written (r3627). If not, it must have been in r33456 (see renderValue() in https://sourceforge.net/p/tikiwiki/code/33456/tree/trunk/lib/trackers/trackerlib.php ).

There are two mysqldump commands in the Tiki ecosystem:
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trim/scripts/tiki/backup_database.php
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/lib/core/Tiki/Command/BackupDBCommand.php

On a very large site, it can take quite some time from the start of the backup to the end. What happens if some data changes during this time? Could there be data inconsistency? Should we do anything to improve what we have?

Firstly, this bug is being submitted assuming I am operating the editing interface correctly.
The main issue is, when configuring the editor tool bar at tiki-admin_toolbars.php there is a drop down menu for Global, Admin, Articles, Wiki Pages.
I have always assumed that when for example, I choose "Admin" from the drop down menu and I click on load to load the admin tool bar, while the "View Mode" is set to "Wiki and Wysiwgy" and if I assign specific tools to the editing tool bar while in the "Admin" preview, and click on save, then I should be able to see a different tool bar other than what a "Global" user would see in both the Wiki and Wysiwyg toolbar.
This would allow me as an Admin to have the ability to use the "code" or source feature, but on the Global tool bar, the "code" or source feature would not be available to non admin users.
Assuming I am correct in how I see this should work:

After customizing the tool bars for Global, and Admin while in "View Mode" for Wiki and Wysiwyg, and when I go to edit a page as an Admin using the syntax tool bar, I do not see the Admin tool bar, I can only see the Global assigned tool bar. Since Tiki15 (I never used Tiki12) I have never been able to have the option of using different tool bars as assigned at tiki-admin_toolbars.php

A show instance will be created to demo this bug.

I don't know how to fix this one myself.

Icons are defined in the sql schema. therefore the logic to display the icon needs to be adapted to use
{CODE()}
{icon name="foo"}
{CODE}

instead of the img html tag.


See it reproduced here:
--http://xavidp-1553-5651.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=43&offset=0&sort_mode=position_asc&optionId=195&maxRecords=25#contentadmin_menu_options-2 --
u: admin
p: 12345

----
Confirmed issues still exists in Tiki18.0 {sign user="xavi" datetime="2018-02-05T19:39:10+00:00"}
---
Re-reproduced in 18.2svn {sign user="xavi" datetime="2018-04-03T16:08:42+00:00"} in a new show.t.o instance (even if the issue is more easily shown when upgrading a previous tiki site where those settings where more easily ticked):
Login as admin here:
http://xavi-9794-5783.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=42
u: admin
p: 12345

You need to ensure that the menu is not using bootstrap but css, plus the setting enabled to use icons for menus (done already in the show.t.o instance)

Cheers

This does probably affect (all) previous Tiki versions, too.

When creating links to pages that have some kind of wiki syntax in them, the wiki syntax will be interpreted and therefore break the links. I noticed this when using links to Germany's premier law website, e.g.:

Here without anything: http://www.gesetze-im-internet.de/bfdg/__2.html
Here as no parse: ~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~
Here as a link with no parse: [~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~]

The last one is a working workaround, but it's a bit sick to say the least. I think Tiki shouldn't parse URLs as wiki syntax at all.

I could also reproduce the same behaviour with other wiki syntaxes as for example the one for italics: http://example.com/my''weird_link.html

During long edit session on Doc or Dev (not only on wiki page) it happens that you have been disconnected without knowing it.

When it happen the page you were working on disappear and instead you have a message you are not authorized to use this feature or other redirection depending of your tiki setting and the feature you were in.

It leads to confusion and unless you keep cold blood, log and reload back the previous page you may loose your precious work. We have to find a better way as this is super frustrating and damage Tiki reputation.

I suggest the following on any submit, save, etc action (click on a button, etc) we have a check if action is possible and user session is still active.

If not without changing page we display a modal over the page with the login module and a cancel button so the user can relog and resume his action or get out of the page.

tiki-wizard_user.php fails after first stage of user configuration. When you progress through the User Wizard, immediately after the first stage of the Wizard, a blank page shows. A show instance is created.