Category: 16.x

For some reason, permissions related to structures are not shown any more, even if you are in the homepage of a structure attempting to set permissions for the whole structure tree, etc. Global permissions show them, but this section is not shown when you are in an object such as the homepage of a structure

That worked in 12.x while showing the permissions under the wiki section.
In theory Tiki 15.x comes with a section of permissions of its own for structures, but for some reason, they are not shown, not even selecting all features (including wiki structures and the hidden featuers) to be shown.

To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345
----
Issue still there! {sign user="xavi" datetime="2016-09-26T21:55:41+00:00"}

The text in nearly all themes - even Readable - is not pure black (RGB # 00 00 00). This lowers readability. While this may not have a hard effect on accessibility, it certainly reduces reading comfort.

I have compiled the following list of default text color for functional themes (excluding themes with non-white backgrounds) on trunk.

-=000000=-
*Jqui
*Utopias

-=222222=-
*Tikinewt
*Yeti

-=333333=-
*Default Bootstrap
*Cosmo
*Darkshine
*Feb12
*Fivealive
*Fivealive-lite
*Readable
*Strasa
*Thenews
*United

-=363636=-
*Didiem

-=555555=-
*Cerulean
*Lumen

-=515151=-
*Greenvalley

-=666666=-
*Paper
*Spacelab

-=737373=-
*Business

-=777777=-
*Journal
*Simplex

Flatly and Sandstone are slightly special cases, as the text is tinted. The former uses #2c3e50, the latter #3e3f3a.

This problem is developing. Grey fonts have become a fashion, as recently [http://www.telegraph.co.uk/science/2016/10/23/internet-is-becoming-unreadable-because-of-a-trend-towards-light/|reported by The Telegraph]. In Tiki 9, the default color was pure black. In Tiki 15, it has become #333333.

I am not asking for a strictly pure black or pure white interface. I understand that other colors can be aesthetically or functionally better. What am I asking is to increase the contrast for the main content (the context of a wiki page, or of the blog post being viewed, for example).

Revisions 63507 and its backports 63508 and 63509 broke language selection at step 1 of the installer. Selecting a language other than English causes a JavaScript error.

The only released version affected is Tiki 16.3.

This bug does not prevent changing the site language, only doing so from the installer.

With a new Trunk install, then applied the Collaborative Community Profile.
Did not want a right column.
Went to tiki-admin_modules.php
*Clicked Right tab
*Saw 2 modules assigned. Quick Edit and Since your last visit.
**Hovered over the key
***Clicked unassign
Got an error even though it did actually remove the module.

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

If I hit the back button, the module is no longer on the list or on the right column.

Looking at my MySQL, in fact the table does not exist.
*Table jabi.tiki_user_assigned_modules

Perhaps this query should be inside some "IF exists" logic?

t.o calendar: warn the user about the time zone being used at time selection by the user

I added an event at a calendar in Tiki.org community site, and selected the chosen time for the event (13h UTC).
https://tiki.org/tiki-calendar_edit_item.php?viewcalitemId=142

There was no indication of which time zone was Tiki going to understand for my selection, so I chose the time in my time zone: 15h (UTC+2). Tiki stored that time as if it was at 15h UTC, and then display the time of the saved event to me as 17h (UTC+2).

So Tiki was expecting the user to introduce the time in UTC, apparently, but there was no indication about that to the user. Some info should be shown. Maybe that will depend on the settings being set in the tiki site (there are a few combinations to test, I guess). So at least I'll leave the bug report here about it.

I recall Jonny saying that there was some new jquery library that was aware of time zones for time and date pickers? :-)
---
In addition, the time recorded for the item doesn't match the time the user selected in the edit form, or even shown when the user opens the item for edition again. This type of issue seems to have been solved recently (months) in tracker fields date and time (date picker, by developer kroky6), so it may probably just need porting similar fix to the calendar feature itself {sign user="xavi" datetime="2017-01-12T14:51:14+00:00"}

t.o: page alias feature not working because some duplication exists (not prevented at edition time and feedback gone too quickly)

Reproduced here:
https://tiki.org/Community+Servers

alias added at the bottom was:
{CODE(colors="tiki")}
(alias(Servers))
{CODE}

When saving the page, some remarksbox is shown for less than a second reporting some duplication of the alias link, and the page is saved removing that remarksbox with the info. And I can't find where else in the t.o site that alias name is written.

Searching for "alias(Server" didn't bring the other page but dozens of pages.

In Tiki12, if I recall properly, if an alias link existed, you were not allowed to save your page, and you were told where that alias name was used already, so that you could at least go there and the duplication by hand before saving your page.

Tablesorter doesn't allow to filter on Tracker item status

See it reproduced here:
https://dev.tiki.org/Trackers#Pending_and_Closed

Tablesorter doesn't allow to sort on tracker item status

See it reproduced here:
https://dev.tiki.org/Trackers#Pending_and_Closed

Reproduced here:
http://xavi-9794-6037.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12#contentTracker_as_Calendar_Tabs-2
u: admin
p: 12345

See field "Location" shown as text input field, evevn if defined as dropdown.
When you change the param server=y to server=n, dropdown is shown as expected.

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

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

Backup script not working.
This is a test...

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-wizard_admin.php?stepNr=0&url=index.php is not accessible after 16.3 upgrade via svn. Nor is it accessible on new 16.3 install.

tikiwiki/stats does not work, and displays "An error occurred while performing the request."
However, I would expect, that it displays the statistics.
I use tikiwiki 16.2, mysqld is 5.7.17-0ubuntu0.16.04.1

It seems that the error happens in function site_stats() from lib/stats/statslib.php.
I uncommented every call to functions, in tiki-stats.php, to find the position with the error.

It seems that some sql statements are wrong, and only work with some relax settings.
mysql 5.7.17 uses sql_mode=only_full_group_by .

I took the select-Statement from line 235 and inserted it into mysql.
select SUM(`pageviews`) AS views, `day` AS unixtime FROM `tiki_pageviews` GROUP by FROM_UNIXTIME(`day`, '%Y-%m-%d') ORDER by views DESC LIMIT 1;
ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'tikiwikitestdb.tiki_pageviews.day' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

We group by date. However there are many seconds matching the same day.
So SQL does not know which unixtime to return.

select SUM(`pageviews`) AS views, ANY_VALUE(`day`) AS unixtime FROM `tiki_pageviews` GROUP by FROM_UNIXTIME(`day`, '%Y-%m-%d') ORDER by views DESC LIMIT 1;

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))

Go at https://dev.tiki.org/tiki-view_tracker.php?trackerId=5

Check the url for the status bullet above the tracker items table:
https://dev.tiki.org/tracker5&status=p&sort_mode=created_desc

It is wrong and not working.
It should be :
https://dev.tiki.org/tiki-view_tracker.php?trackerId=5&status=p&sort_mode=created_desc

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

I wonder if this issue is just happening in show.t.o and why.
But in any case, it's preventing to report any bugs in trunk (16.x), so I hope someone can have a look at this issue.

trunk (16.x) in show.t.o: I can't do the first login as admin admin

Reproduced here:
http://xavi-9794-6009.show.tikiwiki.org/

I can't login to the new trunk show.t.o instance just created, neither with Chrome nor Firefox, with the usual credentials for the first connection:
u: admin
p: admin

I get __invalid username__ with this url produced in the first attempt to connect:
http://localhost/trunk/tiki-change_password.php?user=admin&oldpass=admin&newuser=y

or with this other one:
http://localhost/trunk/tiki-login.php
I get:
__Error__
__Invalid username or password__

---
Update:
I checked today table users_users and I confirm that there is no user admin created at all. {sign user="xavi" datetime="2016-07-07T12:26:00+00:00"}

__Describe precisely what you did (how to reproduce).__
During creation of a Content Template, the "Paddle Lock" symbol seems to be inoperable. Also the list page for Content Templates, has a "Paddle Lock" symbol that is no operating either.

__Describe exactly the faulty consequences.__
After Content Template creation, there is a "Paddle Lock" when clicked, does nothing.

__Explain what you expected instead of the faulty consequences. __
I expected the "Paddle Lock" symbol to lock itself upon clicking, thus rendering the Content Template only editable by admin.

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.

The existing Tiki importer which supports MediaWiki needs updating to support the latest MediaWiki spec. The Tiki importer seems to be several years out of date. Supporting the latest MedaWiki spec would help increase Tiki adoption from other platforms, where many users have large amounts of existing data that they want - and are currently unable - to migrate over.

The current spec for the XML format is here: https://www.mediawiki.org/xml/export-0.10.xsd

I don’t remember for sure but I think the last supported format in the Tiki importer is 0.6 (maybe 0.4?). If that’s the case it does not look like the changes since then are massive. Certainly it would take time to implement support in the import parser to handle the additional tags, but if they don’t map to anything in Tiki they can just be ignored, and since they were never supported previously, it seems like that would not be much of a loss. In other words I believe that supporting the updates to the format should not be tremendously labor intensive.

Linking to my original forum post and feature request here for details and explanation of why I think this is important and valuable for the Tiki project:
https://tiki.org/forumthread65578#threadId65617

Uploading a new version of a file is not expected UX standard and display wrong information.

When uploading a new version, just after initiating the upload, the screen stay put like nothing happen. It is confusing especially for big size file as the"on hold" time will be significantly longer.
We should display a loading wheel, upload bar, whatever so the user is aware something is going on.

Once the upload is completed the page is refreshed (same display as you were in the gallery with ALL the pictures in it) and it shows only a single picture in the gallery (path/explorer is displayed). The one you just uploaded. This is misleading and look like incomplete job.

Or we should show the gallery with all the picture after the new version upload.
Or we should show a page with the single image uploading success and a link to get back to the gallery.

While these are not bugs but request, it is on a very used and popular feature.

hi i have a problem when create new page . some time it is create in correct character then tiki can search and show correctly
http://localhost/tiki/tiki-index.php?page=แผนที่

but when it is show like this , page not found occur.

http://localhost/tiki/tiki-index.php?page=%E0%B8%88%E0%B8%B1%E0%B8%87%E0%B8%AB%E0%B8%A7%E0%B8%B1%E0%B8%94%E0%B8%AA%E0%B8%A1%E0%B8%B8%E0%B8%97%E0%B8%A3%E0%B8%9B%E0%B8%A3%E0%B8%B2%E0%B8%81%E0%B8%B2%E0%B8No value assignedE0%B8%88%E0%B8%B1%E0%B8%87%E0%B8%AB%E0%B8%A7%E0%B8%B1%E0%B8%94%E0%B8%AA%E0%B8%A1%E0%B8%B8%E0%B8%97%E0%B8%A3%E0%B8%9B%E0%B8%A3%E0%B8%B2%E0%B8%81%E0%B8%B2%E0%B8%A3

how to fix it please.

this is also the same problem https://tiki.org/forumthread65410#threadId=65438

best regards,
yanadhorn