Category: Admin Interface (UI)

In 3.2, one can create a personal page in MyTiki and use an Avatar (I see from the Community it wasn't always available & I appreciate the feature), but I would like an Administrative feature that could turn these off while still allowing users to access their Preference Screen, especially for changing their password and email address.

User pages and avatars could take up a great deal of space if there are a lot of users. I'd like to turn off the ability of users to have user-pages and avatars. If there's a way to do that now, please let me know, because I've looked everywhere for a way to do that (and there's a note not to edit templates unless you really know what you're doing and I somewhat know, but I'm afraid of creating a problem).

{syntax type="tiki" editor="plain"}
I think it would be good to have the option to have Automatic quarantine of forum posts that contain an external link. There would be an alert informing users that posts containing an external link will display after being approved by a moderator.

This would effectively end the kind of (likely AI or other automatic) spamming for link placement that we've seen in the tiki.org forums, I think.

This could be generalized to enable site admins to quarantine posts containing other content as well, such as hate speech. Maybe the admin preference would include a checkbox for "external link" and a text field for other content.

About the implementation, on the edit-forum page (such as tiki-admin_forums.php?forumId=14&cookietab=2#content_admin_forums1-2) there is an "Approval type" admin pref with options "All posted", "Queue anonymous posts", and "Queue all posts". To me the wording is a little unclear but maybe "Queue posts with external links" could be added here.

(I think "Require approval for" would be clearer than "Queue" in the wording of the options.)

It might also be good to extend this to also apply to comments, or to be ready to, if spam starts showing up there.

The apply buttons in the admin panel are pretty inconsistent. Some are Apply, others are something else. The size and type of button are also the wrong ones in terms of bootstrap classes

See video:

{FLASH(movie="tiki-download_item_attachment.php?attId=62",width=>876,height=>677,quality=>high)}{FLASH}

{syntax type="tiki" editor="plain"}
When assigning a new module, the page layout and process for the user have changed. I'm comparing a Tiki 27 to master - I don't know whether all the changes were intentional but it kind of amounts to a "mini-revamp" with maybe a combination of intentional changes and unintentional results.

In Tiki 27, after clicking the "Add module" button, the page that displays has the "Edit module" tab open and a selector to choose the new module and, below that, the "Module Options" button. It's very straightforward and uncluttered. When you click the "Module Options" button, the page opens to the "Basic" tab where you select the module zone for it, etc.

In master, when you click the "Assign new module" button, the same page displays again, cluttered with the tabset containing the module zone tabs and already-assigned modules, with the "Assign new module" button displaying __again__, then down below the tabset is the selector to choose the module. The button was already clicked; it shouldn't display again. The tabset is just in the way. It isn't needed in this step of the process.

I think the problem is because the tabs aren't quite right. Initially when you navigate to the admin-modules page, the tabs are "Assigned modules", "Custom Modules", and "All Modules". When you click the "Assign new module" button, the page displays these tabs: "Configure new module", "Custom Modules", and "All Modules". But the page also displays the assigned modules. These should display under an "Assigned modules" tab, not under "Configure new module". This tab arrangement can be seen after clicking the "Module options" button, after selecting a module. Now the tabs are "Assigned modules", "Configure new module", "Custom Modules", and "All Modules". This is how the tabs should be on the previous page.

There's another problem in that when you do arrive on this page, to edit/configure the module, there are four new tabs: "Basic", "Module", "Appearance", and "Visibility". In previous Tiki versions, the "Basic" tab is open, which is the logical choice. In master, though, the "Module" tab is open and the user has to switch tabs to "Basic" to specify the module zone, module position, visibility to groups, etc. that I imagine are generally set first, and which was the case in older Tiki versions.

Since the use of Bootstrap in Tiki (13.x+), wide tables (like many of the ones we use in dev.t.o to display bugs and their associated variables) display a bunch of columns hidden, and the scrollbar is only shown at the bottom of the whole table.

New users might not notice that there are columns on the right hand side of the table, designed to be shown (like in our case, the column "Comments", which indicates which bugs have been commented, by whom and when, to facilitate info to the viewer about bugs that received feedback and more opinions/replies might be expected, etc).
Example (from https://dev.tiki.org/Tiki14+Blockers on a wide screen):
{img fileId="985" thumb="y" rel="box[g]"}


I was searching for something like what you can doo with doodle on wide tables, but couldn't find any jquery plugin for that.
|| ::Default view on wide table (doodle.com ):: | ::Expanded view after clicking at the shrinked columns (doodle.com)::
{img fileId="983" thumb="y" rel="box[g]"} | {img fileId="984" thumb="y" rel="box[g]"} ||

The floss solutions that we might explore to integrate might be (after 30' of searching around):
# Footable jquery plugin: (MIT licensed)
+ http://fooplugins.com/footable-demos/
# Table column toggle, from jquery mobile (compatible with using Bootstrap?)
+ http://demos.jquerymobile.com/1.3.0-beta.1/docs/tables/table-column-toggle.html

Try the demos, and see
Alternatively, some sort of custom trick could be desinged using colResizable jQuery Plugin? (MIT licensed)
http://www.bacubacu.com/colresizable/

If equally complex to implement, I would cast my vote for Footable jquery plugin, for what I've seen in their website as end user.

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.

{syntax type="tiki" editor="plain"}
When the user navigates to a page in the "Global Settings" section of the left column of the Unified Admin Backend layout, that section of the menu stays open and the current name of the active page is highlighted. But when the user navigates to a page in the "Manage" section, the section closes and the current page isn't highlighted. This isn't good UX practice and should be improved, if possible.

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?

In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.

When I preview a blog post at themes.tiki.org, which is now at version 17.0, instead of the blog post title displaying, the text "No object information provided." displays.

This isn't a big problem as a practical matter since I don't really need to see a preview of the post title, but it would give a blog author the impression that something is broken in the preview function.

CSS... Themes...

As discussed in the TRM 2021-12-19

Hi all,
sorry if is completely wrong what I do... (and maybe entered above), but I'm totally new to Tiki and installed the 14beta to get an impression, as -seen from my requirements list- Tiki14final is what I want to use live. So I'm really testing around - and thought this may not only help me, but also you. Okay, enough introduction.

I created a forum and tried to add more forums by copy the existing one. Maybe I did something wrong, but to me everything seems to work in the process - there was just no new forum in the end.

Thanks for taking care and
best regards
Uli

Hi Uli,

I did reset the admin passwort of your show-instance to 12345, as it's the only way, we can access and check the bug (or error 40) .
More then in the comments.

Greetz
Torsten

PS:
are you German language?
If yes, pls see: [tiki.org/detug]

Is it a bug or a feature, that truncates the output of strings after a pipe symbol?
Example to illustrate: /lib/prefs/feature, line 2425:
{CODE(Colors="Tiki")}
'feature_wiki_argvariable' => [
'name' => tra('Wiki argument variables'),
'description' => tra('Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}'),
'type' => 'flag',
'help' => 'Advanced+Wiki+Syntax+usage+examples',
'default' => 'n',
'keywords' => 'arg var vars',
],
{CODE}

The output of this descriptions stops at the pipe symbol between paramname and default, supposedly in all languages, including English. I cannot translate into German with this entry in custom.php:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname|standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
but when I replace the pipe with a slash, all is well:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname/standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
So please check whether this is a bug or a feature of tra(), and depending on this check either fix it or change in English this description, to use text without a pipe.

Side remark: The pipe doesn't show here, just as the the arguments in double curly braces! Although I enclosed my code sample in CODE tags! ({sign user="Jyhem" datetime="2022-03-03T14:30:00+00:00"} Arguments are interpreted first before anything else. That's what ~np~~~/np~np~nonparsed~np~~~/np~/np~ is for)

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.

At the last step in the tiki installer, site admin is offered to enter tiki with or without locking it . The two buttons to choose those actions overlap, and not all text from the second button can be read. Even in standard computer screens (not narrow)

{syntax type="tiki" editor="plain"}
Fact : when you submit "preview" for a new event, a great part of data are lost, there is no real preview, and when you return to creation most of optional data are lost.

Too many things don't function : the job is not ended.

Sometimes, first day of the week is Sunday, even if you set that to be Monday on Calendar settings.

This bug shows up for us (catalan interface, time zone "Europe Madrid (UTC+1)" when we have in tiki-admin.php?page=general, at preferecnes syntax:
"1.10 - $prefs.feature_foobar..."

When we swich this parameter to
"1.9 - $feature_foobar"

then fist day of the week in calendar is Monday, as expected

When I try to delete a forum post at tiki.org, the modal header (not body) appears to confirm the delete action, but then disappears, so the delete confirmation action isn't possible, so the post isn't deleted.

At my localhost branch 20, this problem doesn't exist, so it's either a file version difference (REV 70641 at tiki.org compered to REV 70742 at my localhost) or some environment difference at tiki.org.

Selecting a plugin alias (tiki-admin.php?page=textarea) and clicking "delete" gives a error (blank page) and nothing happen.

I've had this issue with different tiki versions:
9.4 (production website, using tiki since 2005)
9.4 (test website, fresh install)
9.6 (test website, updated from a 9.4 fresh install)

I could no reproduce it on tiki 9.4 on show.t.o, but I just tried a 9.3 instance, and I get the issue back with the following error message:
{QUOTE()}Fatal error: Call to undefined method ParserLib::set_preference() in /var/www/pianoliv-11386-4715/lib/parser/parserlib.php on line 701{QUOTE}

Dunno if this is a bug or a "Features", but if it's a "Feature", then it still needs to be addressed because I wasted 20 mins trying to figure out how to drag and drop modules.

Here is the problem:
* Start with a barebone installation of Tiki
* Go to Admin > Modules > All Modules
* Click on any module and drag it to the right hand side of the page
** Nothing happens.
* Click on any module and drag it to the left hand side but into a blank space somewhere below the menu.
** Nothing happens
* Double click on any module (as per the instructions on the Admin > Modules > All modules page) in order to edit it
** Nothing happens

It seems the only places you can put the modules are:
* Top or bottom
* Or on the right hand side, but you have to drop it over the menu.
** This is not intuitive. I am not trying to insert the module into the menu. I am trying to put BELOW the menu. So it never crossed my mind to drop the module ON the menu.

A tracker is used for the contact form at tiki.org. Normally when somebody leaves a message, the tracker item can be edited, like to change the status and make a comment, but currently (Aug. 3 2020), when I click save (or preview) the form just refreshes with its original content -- no edits saved. I haven't checked if this happens at Tiki instances other than tiki.org.

{img src=https://dev.tiki.org/tiki-download_item_attachment.php?attId=567}

The "Quick Admin" module is no longer assigned in default installs starting from {commit id=67387} (Tiki 19).