Category: 18.x

It is frequent you have to set a Tiki in a single language that is not english.

However due to the nature of the documentation and the way the information is shared among tiki users it is way much easier to perform admin in english.

Activating multilingual may answer some issues (there are still a few when you are using a non latin language) but it brings a lot of unwanted behavior like displaying to the other users translation information or tools on the wiki page they shouldn’t see.

It would be nice to have a simple option to set language = english for the Administration interface (based on Admins or other Super Users or feature Admin) without activating the multilingual feature.

The module "Tiki Assistant" (to help newbie admins) calls for an icon that does not exist (/img/icons/arrow_small.png). This is not configurable...

When editing a calendar event, some characters in the event title displays as HTML code, in the modal title. For example, John's "Birthday" displays as ~np~Johnĵs "Birthday" ~/np~.

The file is tiki-calendar_edit_item.tpl, I believe.

Also, the wrench/spanner icon at the right side of the modal title doesn't seem to do anything. Is it meant to be just an icon to indicate the edit screen is displaying? If so, it's misleading since other instances of this icon are clickable to produce a popup list of links, etc. IMO it should be removed if it is just an icon. Or if it is meant to be clickable, it doesn't seem to be working.

The demo link at tiki.org is failing to load. Please see https://tiki.org/Get+Tiki#Tiki_Demo:_Try_Before_You_Install

Please see screen shot of physical link location at https://tiki.org/Download
{img fileId="1155" thumb="box"}

If have two Tikis running on 18.8 (before anyone asks: I cannot go to 21.x, because 21.x breaks my CSS layout...). As I discussed in the Forums before I started this bug report, one (the older) just recently stopped searching. Only when logged in as Admin I could see the reason behind that: A COLLATE clash...

{CODE(Colors="Tiki")}
Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='

Die Abfrage war:
SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits`

The built query was likely:
SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits`
{CODE}

This older Tiki began YEARS ago (on 2.something?) and went through numerous updates, so far with no problems. The newer one started on 18 (or 12).

Interestingly, both databases have default collation set to utf8_general_ci.

When checking collation with
{CODE(Colors="Tiki")}
SHOW TABLE STATUS
{CODE}

I found that almost all tables were set to utf8_unicode_ci, but some were not (galaxia_workitems,index_628bfa7e573fa,index_pref_de,tiki_activity_stream_rules,tiki_addon_profiles,tiki_credits_usage,tiki_galleries_scales,tiki_goal_events,tiki_h5p_contents,tiki_h5p_contents_libraries,tiki_hp5_libraries,tiki_h5_libaries_cachedassets,tiki_h5_libraries_hub_cache,tiki_h5_libraries_languages,tiki_h5_libraries_libraries (!),tiki_hp5_results,tiki_h5p_tmpfiles,tiki_object_scores,tiki_output,tiki_scheduler,tiki_scheduler_run,tiki_search_queries (!),tiki_stats,tiki_tabular_formats,tiki_user_monitors).

Now that looks like a bug in one of the upgrader scripts.

However, a look at the tables of the newer Tiki showed that there was only one table that used the same collation as the database's default: index_pref_de. ''__All others were set to utf8_unicode_ci!__'' Now that would then be a bug in the installation procedure...

I am not a SQL expert, but I would like to recommend that Tiki sets the default collation to whatever Tiki shall use in the future and then leaves the default (i.e. not declare individual collation). Any individual collation definition is prone to be a future source of trouble...

I know Tiki Mobile is deprecated, but IMHO as long as it is still there it should at least be configurable. But the parameters are labelled illogically:
{CODE(Colors="Tiki")]
'description' => tra('Currently only shows switch to and from mobile mode.'),
'prefs' => ['mobile_feature'],
'params' => [
'to_label' => [
'name' => tra('To Label'),
'description' => tra('Switch to normal site label'),
],
'from_label' => [
'name' => tra('From Label'),
'description' => tra('Switch to mobile site label'),
],
{CODE}

To switch __to__ mobile, the 'switch to normal site' label is offered, and to switch __from__ mobile, i.e. to normal, the 'switch to mobile' label is offered...

This shows the World we are keeping up to date, and help with troubleshooting if a bug is discovered

* For major versions (ex.: 17.0): since last minor version of previous branch (16.3)
* For minor versions (ex.: 17.2): since previous minor version of same branch (17.1)
* Would be slick to have a chart like the following for all dependencies, like the "Package" table at https://distrowatch.com/table.php?distribution=clearos

I have problems with Tikis statistics function. I entered it in order to translate it, and most of it works well (except for some icons that are missing, I prefer classic style, and there are missing icons. But that's not a problem, icons fall back to some (newer) style).

But the very first statistic, first page request, shells out an error I cannot explain:

DateTime::__construct(): Failed to parse time string (Bislang keine Seitenaufrufe) at position 0 (B): The timezone could not be found in the database

"Bislang keine Seitenaufrufe" is the translation of "no page views", but this cannot be correct. This Tiki exists for several years now. Actually EVERY Tiki where you call the statistics page must have at least from this very session a "first" page view... So there can be no Tiki without a first view...

Possibly the second part of the error message clears it up: A timezone problem. But the timezone is correctly set, it's set to "Europe/Berlin". Although it's not stated there, I guess this sets UTC+0100, because we are one hour ahead (east) of Greenwich. At the moment actually two hours, because it is DST.

So why is this PHP error thrown? And how can it be rectified?

Tiki offers a data type "email adress". This does basic syntax checking. Actually, it is VERY basic. It only checks is there is an at sign (@) in the string. A little bit more might be wished for, in order to reduce spam and clutter from anonymous users.

IMHO it should also be checked if a domain name is entered. So it should be detected whether there is a full stop after the at sign, and at minimum one letter before and after the full stop.

Now Tiki accepts a@b, IMHO it should at least check whether it is a@b.c (I would not recommend to check acutal TLDs, because they change too often nowadays.

While translating, I came across Tiki User Credits. Sometimes they seem to be called "User Level Credits", but not consistently.

This feature is by and large rather undocumented... What precisely are they? Are they some token "currency", because you can use it in CART, are they some system of points (sometimes "User Level Credits" are mentioned), which users can gain through Wiki activity? Then I don't understand "(level credits always 0)" also "Use User Credit". Use them - for what?

Then there are "plans"? Is this some system of automatically gaining points that are to be expended on - which - activity? They seem to be able expire...

And as I wrote in the related bug report, you can create new types of credits, but cannot alter or delete them... Text like "Is Static Level Credit" are a mystery to me :-)

Is there some documentation that I did not find (nor did Google...) ?
Thanks

I set up a Tiki19 with user tracker information.
When I register ONE user the tracker is populated with one item but at tiki-view_tracker.php?trackerId=1 I see the same item twice.

{img fileId="1249" thumb="box"}
They both have the same itemId.

Further to my report [https://dev.tiki.org/item7001-tiki-stats-php-Day-with-fewest-pageview-duplicates|item7001-tiki-stats-php-Day-with-fewest-pageview-duplicates] that the behaviour of tiki-stats.php has changed between v15 and v18 with regard to number of dates reported against "Days with the fewest pageviews", we are continuing to see that list grow (including more duplicates) since we upgraded from 15.5 to 18.3.

(I've attached five images showing the situation, but can't work out how to include them within this text. The choose or upload image feature on this edit field seems to lack an upload and I have no idea where to find images that I've directly attached to this page)

The first screen shot shows 31 Jan, 02 Feb (twice) and 03 Feb. has having only 1 pageview. We know our wiki was used on those dates (from notifier e-mails for example), so these dates are being included in error.

Also the "Most viewed objects in period" for single day ranges (eg 01 Feb 2019 to 02Feb 2019) shoes our home page alone was hit 200 plus times. Again screen shots attached.

Whilst I would be happy to create a show instance for you, I'm not sure how to do that practically with this type of issue.

On page tiki-stats.php, if the start and end dates for "Most viewed objects in period" are equal or if the start date is AFTER the end date, no error is given and the section disappears when he screen is reloaded after pressing the Filter button.

(I have attached before and after images but can't but work out with the "Choose or upload images" icon on this input field "Description" how to include them. Sorry.)

Since a new show instance will have no history when initially created, I can't immediately demonstrate it here.

However using the show instance from another of the issues I've previously reported, I see the same behaviour ...
See [http://emmarrbee-11078-6959.show.tikiwiki.org/tiki-stats.php]

On line 465 of the -+templates/tiki-admin_calendars.tpl+- file, the heading "Delete old events" is missing translations markers; they cannot be localized (in ALL languages, that is...).

The admin interface for modules is partially localized (German). The parts that are not cannot be manually localized with custom.php (even if the array_merge is added). But what is even more strange: Module location "Left" is translated correctly into "Links". But "Right" isn't. Now I wanted to see whether tra() or tr in curly braces are missing but I could not find the source of the texts displayed here. So I wanted to look for a word that would not give me a hundred hits when doing a recursive grep through all Tiki directories, so instead I searched for "Pagebottom".

But most peculiar, there is only one file that contains "Pagebottom", and that is custom.php! Yet this string clearly is displayed. Now where might the string "Pagebottom" come from?

Here is my search:

{CODE(colors="tiki")}
/media/XXXX/Home/WWW/XXX/agim/tiki-18.6 $ find . -type f -exec grep -l
'Pagebottom' {} \;
./lang/de/custom.php
{CODE}

??!

Look at the screenshot...

The help for calendar import seems to be broken, some translation markups are missing, thus it does not get correctly localized into ANY language. And even in English the text does not make much sense. There is no <br> markup in CSV files. So guess those line breaks should format the help output, but not be displayed as themselves in the output of the help. Everything after line 25 should be checked.

Calling tiki-check.php (via the drop down menu of control panels) causes my rented webspace to crash. Literally. First, a 500 is thrown (internal server error), and afterwards the entire webspace goes offline for a couple of minutes! Eventually it does recover, but I have no idea by what mechanism of my ISP this happens. Probably a restart of the (assumed) Docker instance.

This can possibly lead to disturbing the online presence of other customers of the same ISP, depending on the grade of encapsulation of the ISP!

Something dangerous is happening inside tiki-check.php. This must never happen, because this spells out that there is something that can lead to a DOS, either involunaterily by co-admins not aware of the danger of the function, or even by attackers who somehow manage to do whatever tiki-check.php does when this happens. Possibly even by attacking other Tikis hosted by the same ISP, if the ISPs encapsulation is weak...

I therefore propose that tiki-check.php be split up into segments that can be called individually (this eases finding the culprit) and then to have an admin configurable set of functions, so admins can disable dangerous functions.

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

Firstly, congrats there seems to be a marked performance improvement when running tiki-stats.php in v18.3 over v15.7.

We are seeing two issues with the new tiki-stats.php on our upgraded system.

With v15.7 the statistic "Day with the fewest pageviews" reported only a single entry, which was the FIRST date on which the lowest number was seen.
See {img fileId="1272" thumb="box"}

With v18.3 the same statistic now seems to report EVERY date on which our system has had minimal activity, which is making the page extremely long. This issue of increased page length is exasperated by the repeating of some dates.
See {img fileId="1273" thumb="box"}
and {img fileId="1274" thumb="box"}

My wish would be to have only the first and most recent day with fewest pageviews reported within tiki-stats.php
If the full list is useful to others, then perhaps it should have its own page linked from tiki-stats.php

I've rated this with importance 5 as we use this feature on a daily basis to see what the activity has been over the past 24 hours, but recognise others may never use it.

tiki-tracker_view_history.php throws some SQL erorrs.

eg.
https://doc.tiki.org/tiki-tracker_view_history.php?itemId=5310
https://doc.tiki.org/tiki-tracker_view_history.php?itemId=6291

-----
SYSTEM ERROR

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
The query was:

select ttifl.*, ttf.* from `tiki_tracker_item_fields` ttifl left join `tiki_tracker_fields` ttf on (ttf.`fieldId`=ttifl.`fieldId`) where
The built query was likely:

select ttifl.*, ttf.* from `tiki_tracker_item_fields` ttifl left join `tiki_tracker_fields` ttf on (ttf.`fieldId`=ttifl.`fieldId`) where
-----

Tiki.org is not being update properly since a few days.
Last update from SVN (18.2svn): Monday 07 May 2018 - REV 66281

It should be updated on a regular basis every 24h (as I remember).

When a pref has a help text, this text must not contain colons, because Tikis help system separates a help headline from body text with a colon. Unfortunately there are texts containing colons, and where they could not be easily avoided, for instance for the setting of namespace separators.

/templates/admin/include_general.tpl contains this:

{CODE(Colors="Tiki")}
{preference name=namespace_indicator_in_structure}
{preference name=feature_use_three_colon_centertag}
{preference name=wiki_pagename_strip}
{remarksbox type="note" title="{tr}Information{/tr}"}
{tr}To use :: as a separator, you should also use ::: as the wiki center tag syntax{/tr}.<br/>
{tr}Note: a conversion of :: to ::: for existing pages must be done manually{/tr}.<br/>
{tr}If the page name display stripper conflicts with the namespace separator, the namespace is used and the page name display is not stripped.{/tr}
{/remarksbox}
{CODE}

This results in a headline "To use " and body text ": as a separator, you should also use ::: as the wiki center tag syntax" which is destroying the crucial information. The number of colons is vital here! And it likewise affects all translations as well...

The date picker range is fixed to 2013 to 2028 and does not change with settings in the Control Panels -> General -> Date and Time; Start Year and End Year.

When a wiki syntax field calls maketoc and the FADE plugin, the table of contents generated may contain bogus entries at the beginning. All the titles in the body of any call to FADE are taken into consideration by maketoc.

This bug is very similar to {wish id=5496}.

! Example

With the following field content, the TOC contains 2 headers, instead of just "Normal header":
{CODE(color="tiki")}
{maketoc}

! Normal header
This is a test page for the FADE plugin.

{FADE(label=Label)}
!! Header which should not be in the TOC
Lorem ipsum...
{FADE}
{CODE}

https://dev.tiki.org/How-to-release?structure=Developer+Documentation
vs
https://dev.tiki.org/How-to-release


See image