Category: 18.x

On a field of type ''text'' with options ''multilingual'' and ''autocomplete'', the autocomplete displays the json array of the field which has all languages instead of text strings.

Like: ~np~{"en":"3rd Test Event","fr":"3rd Evenement de Test "}~/np~

This bug is similar to {wish id=6703}, but about the FOOTNOTE plugin instead of SUP. As explained there:
{QUOTE(replyto="Chealer")}The auto-TOC implementation does not know how to deal with advanced titles. When titles contain plugin calls, since the links can't contain HTML, auto-TOC just strips HTML tags (see the declaration of ''aText'' in autoToc.js (''var aText = $.trim($this.text());''), which may or may not give a valid result.{QUOTE}

For FOOTNOTE, this causes the footnote number to be displayed raw (not in superscript), and clicking on the number brings to the section, rather than to the footnote. For example, with the following heading:
~np~! Buggy{FOOTNOTE()}For now{FOOTNOTE} heading~/np~
...the TOC entry would just display a raw "Buggy1 heading".

I believe it would be best to hide the number, as Microsoft Word 2013 does in TOC-s. Otherwise, it should be in superscript.

This bug (like #6703) is similar to its maketoc pseudo-equivalent: {wish id=4235}.

I've recently noticed that current trunk (r67636, soon to be 19.x) has Profiles Wizard feature fixed finally (yay, thanks to all those of you who made it possible!), but 18.x still shows spurious errors (for the end user experience) in the basic path to apply the featured profiles from the profiles wizard.

We need whichever fixes are needed in 18.x implemented in the LTS version of Tiki
Help!
---

Fixed, afaik,. even if profiles don't get loaded any more succesfully when coming from a link in the profiles wizard. Tested in 18.x and 20.x today again {sign user="xavi" datetime="2019-07-06T16:17:21+00:00"}

On the admin-modules page, when you select "menu" as the type of module to assign, at the top of the page, first thing, an alert box appears saying "Error - One of these parameters must be set: Menu, Structure."

It would be appropriate for this alert to appear when an attempt is made to submit the module configuration info without a parameter set - then the user has made an error. But why should the user see an Error message before doing anything?

The alert box should be an Info type because it's giving information about what the user should do next, or a Warning type, to be more emphatic. I looked at the files but couldn't see how to change the "Error" text.

In /lib/prefs/feature.php is a help string that does not work in English __and__ makes life of translators hard, because it is badly escaped (actually, not at all):
In line 550 you will find:

{CODE(Colors="Tiki")}
'feature_comments_send_author_name' => [
'name' => tra('Add author name in From email header'),
'description' => tra('Add the name of the comment author in the email header "From", making the email look like sent from "John Doe <noreply@example.com>"'),
'help' => 'Comments',
'type' => 'flag',
'default' => 'n',
'tags' => ['basic'],
],
{CODE}

The problem is the mock sender's mail address contained in braces. It IS the notation most mail clients use, real name and address in less than and greater than signs. But tra() seems to be unable to handle this. Possibly tra() interprets it as HTML entity (?) and discards it, so output of this description stops after John Doe. The address is omitted, as well as the closing quote sign.

And for translators this is hard, because if you add the string that is displayed to your custom.php, the pattern matching won't find it.

The parameters "URIs where the banner appears only" and "URIs where the banner will not appear" are broken.
I tried in many way starting by the one from the help:
{CODE()}#/tiki-index.php?page=HomePage#{CODE}

For "URIs where the banner appears only", once something is set the banner doesn't appears at all.

For "URIs where the banner will not appear", no matter what the banner is displayed.

If a banner is placed in a col (left_col) and is wider than the col it will spill over the main page data.

#left_modules {overflow: hidden} would work it out ?

From several discussions;

The learning curve of Wiki page editing, which pretty a basic need, is longer than a lot (if not most) other web application. Things require knowledge and too many clicks to be found and understandable.

Improving the way a wiki page is edited by default is mainly a design UX/UI aspect as all the code is here already.

For example and comparing to Confluence that, from users point require 15mn to have someone working;

* The editing space by default is all full-screen so you have focus on tool you are using right now and not everything your Tiki has
+ ~~#F00:and not confined in a tiny space with what’s left from a screen with menus, preview, header, footer etc~~
* The toolbar by default is a simple as possible (one line) with very clear options for not-techy first time user better comprehension
+ ~~#F00:and not configured by and for admins / techies that don’t want to customise their toolbar~~
* The "main" plugins (they call it macro) are available under a dropdown
+ ~~#F00:and not with the help menu, tab plugin, search it in a small space~~
* You can see/search all the plugin in a large space using "common" terms and big icons
+ ~~#F00:The plugin/macro name is reduced to what is does as short as possible and not a weird name someone gave to its plugin or a long list of words attached to say what it does in a tight space with small text and small icons~~

I think we should have a look at the way it is done and we could improve pretty quickly the way it work.

__Screenshot__
Full screen simple editing by default (the macro/plugin access is under the "plus" button, a dropdown for the common one and direct access to all the others);
{img fileId="1212" thumb="box"}
{img fileId="1213" thumb="box"}

The plugin/macro access is elegant and easy to read
{img fileId="1214" thumb="box"}

The help for the survey features says this about option "Wiki textarea":
"Options are: rows,columns,toolbars.
Example: 10,60,n (toolbar can be "y", "n" or "c" for comments toolbar)"

Actually it's not rows and columns, but height and width. No matter how small you define it, user can enter text (virtually) limitless.

And the option c for comments toolbar is without any effect that I could notice?

Currently, the blog feature features only limited information, both for users and for admins.

For users, new blog entries should IMHO be listed in the since last visit module, currently they aren't.

For admins, blogs AND blog entries should be part of the statistics page, currently both aren't, so as admin, you only see the total number of blog page views, and have no clue, which of your blogs is more popular, and inside blogs, which entries generated the biggest audience...

No matter how often I visit the three blogs in my installation of 18.5, and no matter whether I do that as registered user, as admin or as anonymous and no matter how many blog entries I click:

All three visits counters are stuck at zero!

Verified in the latest 17.1.7 release. Could not get demo site or show instances to run so not sure there. Verified still in SVN trunk and on branch 18.x (in file tiki.sql)

The menu item "File Galleries" and its first entry "List File Galleries" does not SEF URL rewrite to "files". Using the SEF "files" does not work either.

It appears the tiki.sql file, in line 3335, has the entry for SEFURL rewrite of "files" set to 'tike-file_galleries.php' which no longer exists. The menu entry simply has 'tiki-list_file_gallery.php' without any parameter; which is what seems to work and is what the URL appears as when listing all user galleries. Just changing the table entry in the DB of an active system does get the SEF URL output rewrite to work (so the the /files appears instead of the PHP file reference). After making the change in the DB table, selecting via the menu errors back to the site HomePage (or similar) so likely something else needs to be fixed; not just the table entry (and tiki.sql entry). Checked the secDB menu tables and the template files; all seemed already changed as well (from what my naive eyes to the code can see).

Longer term, especially since image galleries are deprecated, would be nice to change the SEF URL rewrite for the general galleries page to something more recognizable than "files". Especially since hierarchical galleries are allowed. Maybe "dirs", "directories", "folders", or "galleries" (if really gone) is appropriate. But I guess I should submit a "wish" instead of cluttering up this focused bug report :)

(note: ShowTiki still not working. Get error on startup of missing third party extensions)

/templates/layout_fullscreen_check.tpl line 8: Broken icon call.
{CODE(Colors="Tiki")}
{self_link fullscreen="y" _ajax='n' _icon_name=expand _title="{tr}Fullscreen{/tr}"}{/self_link}
{CODE}

_icon_name is set to expand, without quotation marks around 'expand'. Whether _title is correct with a starting underscore I don't know. Also, there is no icon named "expand" (with quotation marks), but there is an "expanded", that is redirected to bullet_toggle_minus.png.

On Tiki 18 and 19

On Trackers when you insert a tracker field type file you can (have to?) select a gallery for your files. It is the gallery where files you upload using this field will be saved. You have also an option to "browse" if you want the user to be able to select a file from your files gallery.

When editing an item you can then browse a gallery but the modal show ALL the files in the complete files gallery. It should show (by default or restricted) the files from the selected gallery.

One of the wizards displays one particular bubble help beginning WAY off the browser window, that is Random Header Images on /templates/wizard/profiles_useful_micro_confs.tpl. It starts a couple of hundred pixels outside the browser window, which means that all lines start with invisible (!) sentence beginnings... This is so far the only bubble help that starts off-screen, the others behave normally.

There are also those bugs, whose inner workings look like a miracle to someone who is not familiar with the code.

For instance, I cannot translate "Sticky Popup" from the admin page of calendar. There are two different features by the same GUI (!) name on lines 62 and 826 of /lib/wiki_plugins/wikiplugin_trackerlist.php:

{CODE(Colors="Tiki")}
'stickypopup' => [
'required' => false,
'name' => tra('Sticky Popup'),
'description' => tra('Choose whether the popup tooltip will stay displayed on mouse out (does not stay open by default)'),
'since' => '2.0',
'filter' => 'alpha',
'default' => '',
'options' => [
['text' => '', 'value' => ''],
['text' => tra('Yes'), 'value' => 'y'],
['text' => tra('No'), 'value' => 'n']
]
],

[...]

'calendarstickypopup' => [
'required' => false,
'name' => tra('Sticky Popup'),
'description' => tra('Calendar item popups will stay open if set to y (Yes). Not sticky by default'),
'since' => '6.0',
'doctype' => 'calendar',
'filter' => 'alpha',
'default' => 'n',
'options' => [
['text' => '', 'value' => ''],
['text' => tra('Yes'), 'value' => 'y'],
['text' => tra('No'), 'value' => 'n']
]
],

{CODE}

As you can see, both (!) call the translation subroutine, and both (!) have a description, so that help string should be visible under a blue question mark icon, next to the feature checkbox on tiki-admin.php?page=calendar, but they don't !! And I cannot translate the name, so it shows only "Sticky Popup" and the checkbox, and that's it.

The reason must lie deeper than what I can see in the code by going over it...

And yes, I did check that the space between "Sticky" and "Popup" is really a space (0x20) and not something weird like a shift-space...

Pls see the attachment.

The class 'opaque calBox' from the calendar is broken. It is supposed to show the details of a calendar event, insted it shows raw Tiki syntax, in the case of a test event from admin on my site it is this that gets presented as text (!) to all users:
{CODE(Colors="Tiki")}
<div class=\'opaque calBox\' style=\"width:200px\"><a href=\"tiki-calendar_edit_item.php?viewcalitemId=323\" title=\"Details\">Testevent #3<\/a><p class=\"text-muted\"><strong>Erstellt von:admin<\/strong><\/p><br><\/div>
{CODE}

When placing the mouse over an event in the calendar, a mousover popup comes up informing of the event's text and it's date/time (or duration .i.e. whole day). That is nice and comes in handy, thanks for that

But:
After those lines comes "created by" and then nothing. It can be debated whether or not the event's creator should be displayed, but even if some rule somewhere dictates that the creator is NOT to be displayed, then the line "created by" should IMHO also be omitted.

Thanks
hman

At https://tiki.org/calendar I created an event : https://tiki.org/tiki-calendar_edit_item.php?fullcalendar=y&calitemId=182

It is visible when I log as admin
It is not visible (no events are visible) as anonymous

Anonymous can:
Can browse the calendar (tiki_p_view_calendar)
Can view event details (tiki_p_view_events)

So they should see the events.

When the main calendar is in quarter mode, skipping to next or previous quarters is completely inexplicable.

I skip the discussion whether or not quarters should be aligned to years. One could argue that the first quarter starts with January (method #1). But it could also be assumed that it starts with the current month (method #2). Personally, I am undecided on this. But the problem is somewhere else, and it is severe.

If you switch to quarter mode starting today (today is February 6th) you end up here: /tiki-calendar.php?viewmode=quarter which displays February through April. That can be considered correct (see the above caveat), being method #2.

Then a click on "Previous Quarter " SHOULD bring you to November through January. But it doesn't. It brings you to October through December. This is wrong, because this is method #1, while the start was method #2.

Tiki's calendar cannot asssume both, and switch between them...

Further, if you go another quarter in the past, you will get two possible correct results:

Assuming method #1 you would get July through September.
Assuming method #2 you would get August through October.

Calendar does none of those, it yields June to August...

The German localization breaks the layout of the calendar list list mode. If an event spans several days, and each of those days are entirely covered "whole day" calender obviously introduces the text "whole day" in that. But in the German localization it reads "den ganzen Tag" which is considerably longer in pixels than "whole day", and thus breaks the layout, overwriting the finishing date of the event.

Either the localization has to be abbreviated, or the layout should adapt to the rendered length of the text in pixels...

Not really an important bug, but looks really awful...

The Calendar of 18.5 does not support repeating events with NO final date. Not only relevant for birthdays, but also for commemorative events. And I have tested to enter 0 as number of repetitions, that doesn't work.
Thanks
hman

Hi,

On two installs of Tiki (18.1 and 18.2svn) it seems the Calendar feature 'Sticky Popup' is not working. Also just tested in Tiki 15.5, did not work either.

Settings > Control Panels > Calendar > General Features > Stick popup

Pop's up, but it disappears when you hover over it, so it makes clicking on links impossible.

Though, stick pop up is not even needed for this,. I just don't understand why the pop-up disappears when you hover over it.

Thanks,
Mike

The template displays arrows to navigate to the previous and to the next period the calendar shall display, but the template pumps the raw internal values into the tooltips, and even that without translation, breaking the GUI, because "Previous" and "Next" get translated into the target language, but not the period label (e.g. "week") so giving the user a mixture of target language and English that is actual raw Tiki code.

{CODE(Colors="Tiki")}
{*previous*}
<div class="cal-prev" style="display:inline-block; padding-right: 6px; position: relative; bottom: 20px; right: 100px">
<a class="tips" href="{query _type='relative' _ajax=$ajax _class='prev' todate=$focus_prev}" title=":{tr _0="{$viewmode|escape}"}Previous %0 {/tr}">
{icon name="previous"}
</a>
</div>
{CODE}
and
{CODE(Colors="Tiki")}
{*next*}
<div class="cal-next" style="display:inline-block; padding-left: 6px; position: relative; bottom: 20px; left: 100px">
<a class="tips" href="{query _type='relative' _ajax=$ajax _class='next' todate=$focus_next}" title=":{tr _0="{$viewmode|escape}"}Next %0{/tr}">
{icon name="next"}
</a>
</div>
{CODE}

Calendar output (through the 'upcoming events' plugin) uses two differing formats for date output, ignoring the pref:

* Events spanning a whole day are output numerical, example: "03.02.2022".
* Events with beginning and ending at specific times are reported with weekday, but without year . Example: "Montag, 07. 02". Note the missing full stop after the month!

So factually dates are output (whole day) formatted as (strftime())
{CODE(Colors="Tiki")}
"%d.%m.%Y"
{CODE}
and with specific times formatted as (strftime())
{CODE(Colors="Tiki")}
"%A, %d. %m"
{CODE}

The pref (long date format) is set to
{CODE(Colors="Tiki")}
"%A, %e. %B %Y"
{CODE}
The pref (short date format) is set to
{CODE(Colors="Tiki")}
"%Y-%m-%d"
{CODE}
(the Japanese format, which has the beauty of automatically sorting alphabetically in correct order, because the most significant digit is on the far left).

So the output is both inconsistent AND violates the setting in the pref...

strftime() constants:
https://www.geeksforgeeks.org/php-strftime-function/