Category: Admin Interface (UI)

This setting:
Contact Us
Contact Us (Anonymous)
here: tiki-admin.php?page=features

And this one:
Contact user:
tiki-admin.php?page=general

Plus, "Contact user" should be a drop-down menu with the user list


Should be added to a new admin tab "Contact us":
tiki-admin.php?page=contact_us

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

These settings:
Categories
Show Category Path
Show Category Objects
here: tiki-admin.php?page=features

And this one:
Ignore category viewing restrictions :
tiki-admin.php?page=search

Should be added to a new admin tab "category":
tiki-admin.php?page=category

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

This setting:
User Messages
here: tiki-admin.php?page=features

And these ones:
Users can opt-out internal messages:
Users accept internal messages by default:
Maximum mailbox size (messages, 0=unlimited):
Maximum mail archive size (messages, 0=unlimited):
Maximum sent box size (messages, 0=unlimited):
here: tiki-admin.php?page=login

Should be added to a new admin tab "Inter-user message":
tiki-admin.php?page=inter-user_message

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

tiki-admin.php?page=general
Use direct pagination links:
Maximum number of records in listings:

The two pagination settings should be together in a section "pagination". (on this page is OK)


Would be even better to move all to tiki-admin.php?page=pagination

As suggested by Nyloth at TikiFest Strasbourg,

1- "Sender Email" could be set by default to no-reply@domain.tld
2- It could be requested as part of the install script.

Many features don't work well until it's set (ex.: Inter-User message, registration with email validation, etc)

These settings:
Theme:
Slideshows theme:
here: tiki-admin.php?page=general

And theses ones:
Theme Control
General Layout options (all)
Edit Templates
Edit CSS
Tiki Template Viewing
Use Tabs
here: tiki-admin.php?page=features

And this one:
Reg. users can change theme:
here: tiki-admin.php?page=login

Should be added to a new admin tab "Theme & Layout":
tiki-admin.php?page=theme

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

{syntax type="tiki" editor="plain"}
As the calculated size of the line, depends of the size of the panel (resizable) is wrong (too of some ... <unable to translate, in printing in french the length unit "point">).
Then the line is always too long of a few for the panel (words or half of words cut before splitting the line).

This makes the blog edition unusable in normal conditions because to edit a text we have to make horizontal scroll continuously.

Analysis : the calculation of the length of line written in text editors is always complex. Generally today there is no problem, but the system which is behind editors is very complex to take in account all display configurations.

(nota : For my own I had developed some years ago a draw system - for engineering, Computer Assisted Drawings - system for windows displaying HPGL2 language drawings with fonts conversion from HPGL2 fonts system to True type, then I know well in details the whole problem)

~~#F0C:__With this problem, I can't let use the tikiwiki 5.3 by my bloggers.__~~

So I have written a warning take care "sorry very difficult to use"

{syntax type="tiki" editor="plain"}
I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

To keep the whole (responsive) table in view in large displays, a CSS rule was added to break words (and other character strings like multi-digit numbers) anywhere in the string. This does help to narrow the table, but also makes content readability much worse in some cases. If a solution better than "word-break:break-all" can't be found, I would at least like it to be optional (a Look and Feel preference) so site admins who prefer better typography in scrolling tables can have that option.

{syntax type="tiki" editor="plain"}
The original Pagetop Hero idea included some JavaScript to dynamically relocate a -+top-image+- class image from the wiki page, blog, article, etc. text to the topbar module location. This is demoed at https://themes.tiki.org/Topbar%20hero. This way, the image can be easily specified while editing the page or post content, can easily be specific to the page or post, and there's no need to do any content editing in the admin modules interface. If this JavaScript and the dynamic function it enabled were added to the implemented module code, I think the module would be greatly improved.

Seen at: https://branding.tiki.org/tiki-admin.php?page=search

{CODE()}Warning: htmlspecialchars() expects parameter 1 to be string, array given in /var/local/branding.tiki.org/www/templates_c/ffee1decad4274a7207219e1b5c29ec879c6ef23.file.shared-flags.tpl.php on line 61 Call Stack #TimeMemoryFunctionLocation 10.00151062168{main}( )../tiki-admin.php:0 20.480828653752Smarty_Tiki->display( )../tiki-admin.php:687 30.480828654408Smarty_Internal_TemplateBase->display( )../smarty.php:261 40.480828654568Smarty_Tiki->fetch( )../smarty_internal_templatebase.php:374 50.480928657200Smarty_Tiki->fetch( )../smarty.php:169 60.480928657440Smarty_Internal_TemplateBase->fetch( )../smarty.php:194 70.483129066568content_526d6655a42833_95209110( )../smarty_internal_templatebase.php:180 80.522629819344Smarty_Internal_Template->getSubTemplate( )../en18b660cf6951a7bde07357befc24a4e5^0b68810b83d274feeef37f17fa11a02daa468f3e.file.tiki-admin.tpl.php:273 90.522629848648Smarty_Internal_TemplateBase->fetch( )../smarty_internal_template.php:286 100.523930090424content_526d6c33904fa7_01674674( )../smarty_internal_templatebase.php:180 110.606233752648smarty_function_preference( )../en18b660cf6951a7bde07357befc24a4e5^2f839e7ac915760773273f738f44946d9190e15c.file.include_search.tpl.php:121 120.607033767840Smarty_Internal_TemplateBase->fetch( )../function.preference.php:80 130.607533842240content_526d666807aa49_83245061( )../smarty_internal_templatebase.php:180 140.607633843240Smarty_Internal_Template->getSubTemplate( )../eb55ed0463a99692426fd50fb96c614846cdaaff.file.text.tpl.php:54 150.607633872968Smarty_Internal_TemplateBase->fetch( )../smarty_internal_template.php:286 160.607833917888content_526d6667d67489_17610669( )../smarty_internal_templatebase.php:180 170.608133918264htmlspecialchars ( )../ffee1decad4274a7207219e1b5c29ec879c6ef23.file.shared-flags.tpl.php:61 " />{CODE}

Some phantom prefs are introduced in each version of Tiki, as devs add/change prefs but don't notice this. So before each major release (ex.: from 11.0 to 12.0, but not from 12.0 to 12.1), a complete check needs to be done, for all admin panels.

# Start with a fresh install (this is important because some of these issues could only happen once)
# Visit tiki-admin.php
# Activate all Preference Filters (Basic, Advanced, etc.)
# For each of the approx 50 panels on tiki-admin.php
## Activate or deactivate any checkbox (any pref really) on the page (only one per URL, no need to do it per tab).
## Confirm that the pref change is reported.
## If any ''other'' pref change is reported, figure out why and resolve.

tiki-admin.php?page=general

1- favicon box is limited to 32 characters. This is not enough for people using multiki.

2- When I try to change path to favicon, it doesn't save.

3- How do I deactivate this feature?

Shouldn't this feature be in Site identity?

Currently, Tiki does not have a feature to lock a specific user account.

Such locks can be essential. E.g. when you created a user account, but the user doesn't use it. For security reasons, you must lock it after a certain grace period. Either automatically or, as a fallback, manually.

Deleting is not a way to do this, because then you delete all preferences, so in order to preserve user preferences, but secure the site, a lock feature is IMHO essential. Admins should have the ability to lock user accounts. Actually this should be a perm of its own "Can lock user accounts", given by default only to members of the Admin group.

As a workaround, an Admin can create a new password (only known by him/her), but I believe a locking mechanism is more elegant. Also it removes the necessity for the user to re-establish his/her password after the lock gets lifted.

In a more sophisticated version, Tiki could inform members of the Admin group if a user that has a lock imposed on his/her account tries to login, that a login attempt was made.

A missing/disable preference displays an error about "Preference fgal_list_ocr_state" at: tiki-admin.php?page=fgal#contentfgal_admin-3
(this is a new Tiki26 mostly default)

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

Logged as admin, when you navigate inside the File Galleries you can see the name of the Gallery you are in and close to it a wrench. The wrench tootip let you understand that you will be able to interact with THIS file gallery settings but in reality you are sent to the Admin Control Panel "File Galleries".
https://dev.tiki.org/tiki-admin.php?page=fgal#File%20Galleries

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

This is quite confusing for new Admins.

Right now, it's a group permission (tiki_p_batch_upload_files) but if I give tiki_p_admin_file_galleries, it included tiki_p_batch_upload_files, which is not always what I want. (It adds clutter to the interface, when uploading a file)

It should be an option here:
tiki-admin.php?page=fgal

And maybe add a check to see if this is supported by the server (if easy)

We now use htpasswd, which is great for extra security, but can cause issues in certain cases.

We want to block indexing, but fully configured via Tiki, similar to site_closed.

How could we do this? This would be useful for show.tiki.org and for dev and staging sites.

Seem like bottrap idea... (anyone tried it?)

Related links:
* http://perishablepress.com/blackhole-bad-bots/
** http://www.kloth.net/internet/bottrap.php
* https://support.google.com/webmasters/answer/93710

The "Find" button on tiki-listpages.php only, when clicked, causes some page reloading but no form appears. I didn't see an JavaScript errors reported.

on the features selection page there is a checkbox for each feature with its name next to it. In normal Web UIs a checkbox is next to a &lt;label&gt; tag which contains the text referring to the setting the checkbox controls. If you set up the name= and title= for both the input and the label then clicking that text automatically selects the checkbox.

This is not always implemented properly across the web but it is the way forms are supposed to be used and it is easy and no one ever complains about it. It increases the effective size of the checkbox and cements the relationship with the word.

On the features selection page, however, the text instead links to the tikiwiki.org descriptions of the features. This confused me and happened several times before I retaught myself to not click the words.

On a Tiki23 if the layout option is set with : Classic boostrap (Fixed top menu) the menu is lost when navigating on the admin pages.

The original website logo (brand icon) is changed for a Tiki icon making things more confusing.

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

Bottom module is also lost...

All bootstrap themes or themes bootstrap adaptation will suffer from this problem.
This block upgrading websites.

In Look and Feel admin, switching the font set to Glyphicon seems to have no effect. The font set being used is Font Awesome instead. Switching to the legacy icon set (.png images) does work ok. (Checked on my localhost branch 15 and trunk so far.)

I created a show instance (http://chibaguy-342-6164.show.tikiwiki.org) that confirms the bug: after switching to Glyphicons, Font Awesome is used instead (icons have a class like "icon icon-admin_search fa fa-search fa-fw ").

Didn't think it was related, but just to be sure I emptied the caches and rebuilt the search index, but no change.

Thanks for the feedback. I realize I was only checking the admin anchors (feature icons) on the admin pages, which aren't changing to Glyphicons, and assuming none of the icons are switching (although icons other than the admin anchors are switching). I'll rename the bug.

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

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

When defining a field in a mirrored Tracker, the Description of the field is not stored. This was in 2.0, and I'm told on IRC that mirrored trackers are not supported. But mirroring is an option in Admin>Trackers.