Category: Easy for Newbie Dev

{img fileId="1618" thumb="box"}
Those radio buttons should look like bootstrapped Tiki (colors, borders rounded, etc).

In /lib/prefs/forum.php there is a forum pref, where the name of the pref directly contradicts it's description. In line 175 you'll find

{CODE(Colors="Tiki")}
'forum_inbound_mail_ignores_perms' => [
'name' => tr('Allow inbound email posts from anyone'),
'description' => tr('Allow posts from non-users in forums using inbound posts from a specified email address.'),
'type' => 'flag',
'default' => 'n',
],
{CODE}

Mail-in allowed for "everyone", or only for "specified addresses"? Since no parameter that could specify such an address is asked and stored, I guess the name is correct, but the description isn't. Affects all languages...

{syntax type="tiki" editor="plain"}
At https://doc.tiki.org/tiki-browse_freetags.php you can click on any tag and it will initiate the search (after it as been fixed with https://dev.tiki.org/item7924)

However the results are "hidden" from the user eyes down at the bottom of the page.
If the user doesn't catch the quick refresh of the page he will have the impression noting happened (no search) as it will see the same list of tags in front of his eyes. True on Desktop, super-true on mobile.

The results should be visible right away after a search is done for a better UX.

See the attached screenshot:
{img src=https://dev.tiki.org/tiki-download_item_attachment.php?attId=498&display thumb=box}

To reproduce:
# edit a wiki page on https://doc.tiki.org
# in the edit mode switch to fullscreen edit mode using the icon in the toolbar

The global navbar color assigned on tiki-admin.php?page=look is ''always'' applied, so when assigning a menu module and giving it a parameter like "navbar_class=navbar navbar-expand-lg navbar-light bg-light", when the global pref is "dark", this is the result in the page source: -+ <nav class="navbar navbar-expand-lg navbar-light bg-light navbar-dark bg-dark" role="navigation"> +-

The combination of color classes causes problems for link colors, etc.

There are times when, because of the theme colors, both navbar-dark and navbar-light are needed, like when the topbar zone has a dark background and the page footer has a light background, so when a per-module color parameter is specified on admin-modules, it should __replace__ the Look and Feel global setting, not be added to it.

Google complain (now?) that there is an issue with my sitemap /tiki-sitemap.php?file=sitemap-index.xml

============

Sitemap can be read, but has errors
Unsupported file format
1 instance

Your Sitemap does not appear to be in a supported format. Please ensure it meets our Sitemap guidelines and resubmit.

============

The file look like this : cat /home/domain/public_html/storage/public/sitemap-index.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated by https://git.io/phpseo -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9”>
<sitemap><loc>https://www.domain.com/storage/public/articles.xml</loc><lastmod>2021-09-12T07:31:23+00:00</lastmod></sitemap>
<sitemap><loc>https://www.domain.com/storage/public/blogs.xml</loc><lastmod>2021-09-12T07:31:23+00:00</lastmod></sitemap>
<sitemap><loc>https://www.domain.com/storage/public/blogposts.xml</loc><lastmod>2021-09-12T07:31:23+00:00</lastmod></sitemap>
<sitemap><loc>https://www.domain.com/storage/public/sitemap.xml</loc><lastmod>2021-09-12T07:31:23+00:00</lastmod></sitemap>
</sitemapindex>

This file shows error with tools like: https://www.xml-sitemaps.com

XML Validation Results

error Problem detected, please check details below
Sitemap URL http://www.domain.com/tiki-sitemap.php?file=sitemap-index.xml
Character Set
Sitemap is valid No
Warnings -
Errors
Incorrect http header content-type: "text/html; charset=iso-8859-1" (expected: "application/xml")

(If I check https://www.domain.com/sitemap.xml it says it is ok)

Something turned wrong at some point OR Google changed the way it works ?

PS : As temporary mesure on my site I set in Google the sitemap to look for https://www.domain.com/sitemap.xml

===

Update 2021-12-06 after last Tiki23 upgrade:

When I look at the xml produced there : https://example.com/tiki-sitemap.php?file=sitemap-index.xml

I see this and it is rejected of course.
{CODE()}
https://example.com/articles.xml2021-12-06T20:58:02+02:00https://example.com/sitemap.xml2021-12-06T20:58:02+02:00
{CODE}

If I try to split the url and submit those link with date or without is is still rejected.

At some point I see where are my sitemaps: https://example.com/storage/public/sitemap-index.xml

<!-- Generated by https://git.io/phpseo -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/storage/public/articles.xml</loc>
<lastmod>2021-12-06T20:58:02+02:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/storage/public/sitemap.xml</loc>
<lastmod>2021-12-06T20:58:02+02:00</lastmod>
</sitemap>
</sitemapindex>

This is accepted but Google find 0 url...
So I have to submit separately:
https://example.com/storage/public/articles.xml
https://example.com/storage/public/sitemap.xml

{syntax type="tiki" editor="plain"}
We have now a new option to set the "Content of the tag title" on the properties of a Wiki page.

We had a previous metatags field, "Page Description (used for metatags)" that can be enabled at tiki-admin.php?page=metatags

Enabling it add a field "Description (used for metatags)" to the properties of a Wiki page.

We have also "Will be added to the sitemap".

While these fields are related they are not grouped in the wiki page properties and all options seems mixed without any consideration as you can see in this example.

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

Note: This is just an example other option, preferences and parameters based on admin settings should checked.

Anyway, these should be grouped in a more logical way having in mind the user experience.

At https://tiki.org/tiki-syslog.php we have a link to "Log SQL".
If we click on it we have the following error.

{CODE()}
×
Error
This feature is disabled: adodb
{CODE}

The link shouldn't be displayed if the feature is disabled.

In Tiki BS4 -+<blockquote>+- tag has no visual styling (looks like plain text paragraph).

I get these notifications. on tiki-admin_toolbars.php. Im guessing its because our icons are missing in an updated version of font-awesome.

NOTICE (E_USER_NOTICE): Icon not found: monitor
At line 181 in lib/theme/iconsetlib.php
NOTICE (E_USER_NOTICE): Icon not found: monitor
At line 181 in lib/theme/iconsetlib.php
NOTICE (E_USER_NOTICE): Icon not found: dashboard
At line 181 in lib/theme/iconsetlib.php
NOTICE (E_USER_NOTICE): Icon not found: dashboard
At line 181 in lib/theme/iconsetlib.php
NOTICE (E_USER_NOTICE): Icon not found: shorten
At line 181 in lib/theme/iconsetlib.php
NOTICE (E_USER_NOTICE): Icon not found: shorten
At line 181 in lib/theme/iconsetlib.php

{syntax type="tiki" editor="plain"}
I'm on Tiki Wiki 29 I enabled the Tiki Tags feature.
I'm using some tags on wiki page and I have set some tags.
But the keyword tags are not displayed in the head.

I went at tiki-admin.php?page=metatags (admin metatags).
I checked that "Include tags" is enabled. But I have also noticed I no Keywords set in the field Keywords.

As result I have no keyword on the page.
If I add just one keyword in the field, on the page i see this keyword but also all other missing keywords.

The condition for the elseif branch only triggers if either metatag_keywords or metatag_local_keywords is non-empty.

NOTE: I don't use forum so I didn't touch anything related to the way the forum fill its keywords. It may worth to have a look at it.

When you enable the article feature, and you create some article types and topics, you will eventually come across a listing of topics. Topics can be activated or inactivated.

But contrary to what could be perceived as being intuitive, topics start de-activated, signalled by the red oneway sign. And even more counter-intuitively, the option you get with the wrench symbol is to de-activate them (deactivate them again?), which is signalled by a green check logo.
See the screenshot.

This is beyond confusing :-)

Thanks
hman

{syntax type="tiki" editor="plain"}
On an upgraded Tiki to version 29.1 I have articles using their own image and no "Image alternative text" was set as this is not mandatory.

However if I try to modify the content an old article on save the page reload no save and I don't see an error.
Only when I go to the "Image" tab of the edit article interface I can see an error message.

Add a value for the field "Image alternative text" solve the issue.

If a value is mandatory NOW, a red asterisk or something on the field should show it is mandatory.
If a user edit an article that was created BEFORE the change then the issue should be pointed inside or outside the tab Image so the user see what is the problem.

{syntax type="tiki" editor="plain"}
The parameter thumb="box" is not applied anymore.

The sample below should be a thumbnail not a full screen image.

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

Tiki has a way to create "user" plugins with: https://doc.tiki.org/Plugin+Alias

At https://doc.tiki.org/tiki-admin.php?page=textarea or on the instance I created:
Go to Admin, Control Panels => Editing and Plugins => Plugin Aliases.
Create Aliases (or edit) and click on "Plugin parameter documentation" you will see a new form with checkboxes.

This happen on Safari 14.1.2 on Mac OSX but not on Chrome

The "Safe" checkbox overlap with text.
{img fileId="1638" thumb="box"}

1. The {include page=“name”} command is tremendously useful for naive wiki users who add content. It lets them create macros and re-use them at will.

So I suggest that this might deserve an alias {macro } and deserve a description in the wiki syntax help.

Also a slight simplification. If there is no ‘page=”name”’ text but there is {macro “name”} then use “name” anyway.

Any user could do {macro “myheader”} at the top and {macro “myfooter”} at the bottom and {macro “myusualrant”} wherever they want. They just have to make an orphan wiki page for each macro they want.

2. This is so useful and flexible that you might deprecate the “apply content template” thing on the Properties tab. It is hardly any easier to use, and it allows the user to choose only one macro at the beginning. It should keep working for the users who have already used it, but there’s no particular reason for anyone to use it again.

3. To really put the icing on the cake, you might let admins have two macros for each user page, one at the top and one at the bottom. These should not be visible when the user edits the page. So for each page category, the admin could decorate it a special way. Some might automatically get polls or other info visible. Or dancing bunnies, or whatever. It lets admins customize user wiki pages without coding, in ways that are hard to do without coding now. Without annoying users with the displayed calls on their edit pages which they might edit wrongly.

At /categories and https://dev.tiki.org/tiki-admin_categories.php we can see the categories list.
It is a bit stiff and when you have a lot of categories and start to open them to see the child categories the UI/UX is not very good.

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

At tiki-admin.php?page=i18n if you enable "Restrict supported languages" you see a text area with 5 languages.
This is too small and make painful selecting several languages.

The text area size cannot be extended.
It should be possible.

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

{syntax type="tiki" editor="plain"}
On a fresh Tiki27 => Trackers

{img fileId="3082"}

In history, a user can view pages, version after version, to find a change.
He can do it using the left and right arrows when viewing a page.

In the top nav bar (t_navbar) the buttons doesn't refers to the actual page he is previewing (displayed) but to the actual version of the page published.

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

# It is a bit confusing for most users are expecting unspecified-target actions to be applied to what they see.
## First button label should be changed to "Go back to the actual page (last version)"
## Second button label should be changed to "Edit actual page (last version)" (or eventually removed)
# To view the source of this version of the page (if I'm looking for a plugin code or some syntax), I have to remember the page version number, go back to the page, go back to history and view the source (if available).
## A "View this version page source" is missing

Gary may be consulted for better wording. ;-)

The survey feature could be improved by two other survey ratings that the user taking part in a survey can answer. In my experience, the two most intuitive ratings you can ask from survey participants are missing from the list of options, and they are VERY easy to add:

School marks and percentages.

The latter is self-explanatory and gives participants a fine grained range of possible answers. The former is subject to localization, so do not forget tra() !

In the US, to my knowledge school marks run from A (best) to F (worst). In Germany they run from 1 (best) to 6 (worst). Also, school marks can be spelled out. In German that would be "sehr gut", "gut", "befriedigend", "ausreichend", "mangelhaft", "ungenügend". I do not know whether that is also possible for US (or UK) school marks.

School marks must be radio buttons, while percentages would be a three (!) digit numerical entry field, and the acceptance of values over 100 could either be always rejected, or depending on a additional option "allow to exceed 100".

Nowadays the voting on forums is confusing in educational or e-democracy scenarios, since it's not easy to understand why a voting of ! makes just 0.40, or a voting of 5 make 1.60, etc. as it may happen nowadays, since voting on forums seems to be linked to karma or score system.

There should be an option to unlink them, so taht a vote of 1, makes 1, and an option of 5 makes 5 to be included in the mean which is shown at the end on the rate value.

{syntax type="tiki" editor="plain"}
The style= attribute passed to {DIV} and other wiki plugins is silently dropped.
I believe (I'm not pro understanding git) it comes from here: https://gitlab.com/tikiwiki/tiki/-/commit/7b9d81b6f30c7532bee770079ddeead22838a3f1

In lib/wiki-plugins/wikiplugin_div.php, the function wikiplugin_div() initializes $style = '' before calling extract($params, EXTR_SKIP). Because EXTR_SKIP skips extraction when a variable already exists, the style parameter from $params never overwrites the empty $style variable.

At lib/wiki-plugins/wikiplugin_div.php
I changed :
{CODE()}
function wikiplugin_div($content, $params)
{
$style = '';
extract($params, EXTR_SKIP);
{CODE}

For

{CODE()}
function wikiplugin_div($content, $params)
{
extract($params, EXTR_SKIP);
$style = $style ?? '';
{CODE}

refreshed the cache en the issue was fixed.

After an install from git, when you open setup.sh you see:

^
Tiki setup.sh - your options
============================

Composer: If you are installing via a released Tiki package (zip, tar.gz, tar.bz2, 7z), you can and should skip using Composer. If you are installing and upgrading via SVN, you need to run Composer after 'svn checkout' and 'svn upgrade'. More info at https://doc.tiki.org/Composer
^

Obviously this need to be updated as we are not using SVN anymore but git and Gitlab.

{syntax type="tiki" editor="plain"}
Apparently it is not possible to create a multi selection field in a tracker "Unterstützungsmeldungen" with the option "Mit einem regelmäßigen Foerderbeitrag".

This results in a permanent name unterstuetzungsmeldungenMitEinemRegelmassigenForderbeitrag, which will produce multiple (seven!) errors when a user fills in the form.

There seems to be a constraint on the length which is not monitored upon creation of the tracker. It should not be possible to create tracker and field names and options that will, as a result, make the tracker fail!

Also, the exact numerical limit is intransparently unknown. I will have to look into the DB to find out...

For some use cases, the arguments for multi selection or checkboxes MUST be quite long. It is legally not sufficient to just record "user has checked a checkbox" when this in effect leads to a contract. The full text of the option, as displayed to the user, must be recorded. This is especially important for options where a user entitels the org running the Tiki to make repeated SEPA withdrawals from bank accounts!