Category: Admin Interface (UI)

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.

{syntax type="tiki" editor="plain"}
tiki-contact.php is an "incomplete feature"

To be useful, it would need

A- An optional "from" field for visitor's email (some people leave comments and ask for a reply but they forget to leave their email. A specific field for email would help so people don't forget.

B- An option for the visitor to receive a copy of the message.

C- Subject should be used in title of internal message. Assuming the subject is "Question about forums"

Current:
New message arrived from tikiwiki.org

Proposed:
New message arrived from tikiwiki.org (Question about forums)


It is possible to do all this with trackers. So is worth improving this feature or better to document trackers? Related: ((Trackers Examples))

This comes out with new Chosen lib
{img fileId="256"}

It is also strange in mobile mode.

People don't know what this page is for and how to use it...

More "general" choices would be nice too.

Ex.:
watch all wiki pages
watch all file galleries
etc...

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

I just downloaded and installed TikiWiki yesterday (tiki-12.0.zip), and have already found this bug. When I insert my AdSense Javascript code into a banner, so that I can use it in a module as described under "Banners Method" on this page: https://doc.tiki.org/AdSense, I run into a problem.

Specifically, TikiWiki inserts a into the "script" at the beginning and end of my Javascript code. As you might expect, this prevents the ads from displaying correctly, and instead a text string of most of the script is displayed.

According to this much earlier wish: https://dev.tiki.org/item1848 this was fixed way back in version 4.x, so I have marked this as a regression.

I don't currently have this module enabled (because it makes the site ugly) but if you'd like to view it in action, just let me know, and I'll re-enable it for you.

Tracker plugins are great.

There should be something about them in the tips, when creating trackers.

I noticed today a bunch of trackback spam in my Tiki-powered blog.

According to Wikipedia, "Many blogs have stopped using trackbacks because dealing with spam became too burdensome."
http://en.wikipedia.org/wiki/Trackback

If you get trackback spam in Tiki, here is how to clean:

Using phpmyadmin, go to the table: tiki_blog_posts

And find the colums "trackbacks_to" and "trackbacks_from". They should contain:

a:0:{}

instead of the spam.


Now, a more permanent solution to avoiding Trackback spam would be nice. Checking how other blogging software does it should provide some tips.

Some ideas:
0- A way to turn it off (this exists in more recent version of Tiki 1.9.x, see "Trackbacks Pings" in the admin panel)
1- Easier mass deletion
2- Email notification to blog owner
3- Using an online service to check for spam.

Once such example is: tracker_insert_allowed is activated in the admin panel when activating trackers

To reproduce:
# Get a fresh install
# Visit tiki-admin.php?page=trackers
# Activate "Trackers" but nothing else
# Notice tracker_insert_allowed being activated without being checked

Another is: user_trackersync_trackers in tiki-admin.php?page=login

So please, on a fresh install of 12.x, go through each admin panel and activate or decativate the 1st available checkbox, and check if other prefs are turned on or off, and please resolve them.

Please do these fixes in 12.x unless you think they are risky, in which case trunk or ask for help.

The new plugin manager in 3.0 is much more intuitive. It helps uses build plugins with a javascript plugin, documents each syntax, show mandatory fields in bold and offers a global link to the documentation.

This is precisely what we would need for the trackers field type helper.

On tiki-admin.php?page=look, the "Fixed width" checkbox appears under both the "Theme" and "Layout" tab. But the input for the width appears on the second tab only. In the code comment, I see that the rationale is that this checkbox is important so it should be under the first tab to be quickly visible, but I think it would be more logical to have it only under the second tab, where it logically belongs. Arguably, setting the layout - basic bootstrap, classic Tiki, classic Bootstrap - is as important as setting fixed with or fluid width, but we don't put these under the first tab.

If the fixed-width admin form parts were complete under both tabs, I wouldn't be bothered so much, but the first tab has only the checkbox, so the admin sees that first "because it's important" but doesn't see where to specify the width because the input is not displayed together with the checkbox. If/when the admin goes to the second tab, then there's the input for the width. I think if we assume the input can be found there (and it should be since this is the "Layout" tab), then we should assume the checkbox can also be found there, and so there's no need for one under the first tab.

There is a typo in /lib/prefs/short.php which makes displaying the help texts impossible, and it is carried on (through copy&paste by the dev).

Look at these code snippets:
{CODE(Colors="Tiki")}
function prefs_short_list()
{
return [
'short_date_format' => [
'name' => tra('Short date format'),
'descriprion' => tra('Specify how Tiki displays the date (shorter version)'),
.....
'descriprion' => tra('Specify how Tiki displays the time (shorter version)'),
{CODE}

The error is in lines 13 and 23: "descprion" should read "description"... This results in help texts that contain a heading (contained in 'name'), but no text...

This affects ''all'' languages, including English...

{syntax type="tiki" editor="plain"}
Currently in master, on Unified Admin Backend pages, modals are opening behind the top navbar. This can be seen at tiki-objectpermissions.php by clicking the "Assign" button. The modal has a z-index value of 1055 and the navbar's z-index value is 9999. Considering the default Bootstrap z-index values that range from 1000 to 1090 (https://getbootstrap.com/docs/5.3/layout/z-index/), and Tiki's global fixed-top navbar z-index of 1050, the UAB navbar's z-index does seem to be quite a bit out of line and should be made the same as the global navbars unless there's a reason for it to be higher.

Because I keep finding bugs where translation is impossible due to missing tra(), tr() or tr in curly braces, I opened this new umbrella bug report.

Here I will add only newly found bugs, I will not integrate the already existing bug reports into this!

/lib/prefs/calendar.php has this on line 78:

{CODE(Colors="Tiki")}
'description' => 'Interval to show between minutes on time selectors',
{CODE}

Without tra(), the description cannot be translated into any language...

When adding a new quicktag (for inserting YouTube videos) I wasn't able to add it to more than one feature. I.e., after adding it to the forums and then attempting to add it to articles and wikipages, rather than create a new instance, the forums instance would disappear and the new instance would take its place.

It took me some time to find out why I could not translate a particular string in /lib/prefs/freetags.php, and this is it:

{CODE(Colors="Tiki")}
'freetags_normalized_valid_chars' => [
'name' => tra('Valid characters pattern'),
'description' => tra('Click on the links below to set or clear a pattern to limit characters accepted in tags. '),
'type' => 'text',
'size' => '30',
'hint' => 'Useful to eliminate characters such as “,” which users can enter by mistake instead of a space.',
'default' => '',
],
{CODE}

This looks decent, it also carries calls to the tra() subroutine. But I could not catch it with this entry in custom.php:
{CODE(Colors="Tiki")}
"Useful to eliminate characters such as “,” which users can enter by mistake instead of a space." => "Nützlich, um Zeichen zu eliminieren wie Kommata, die Benutzer anstelle von Leeerzeichen eingeben können",
{CODE}

The string for pattern matching is exactly identical to it's declaration in the source code, but it was not caught. Until finally I pumped the string into GHex, to look at its real composition.

{CODE(Colors="Tiki")}
echo -n "Useful to eliminate characters such as “,” which users can enter by mistake instead of a space." | od -A n -t x1
55 73 65 66 75 6c 20 74 6f 20 65 6c 69 6d 69 6e
61 74 65 20 63 68 61 72 61 63 74 65 72 73 20 73
75 63 68 20 61 73 20 e2 80 9c 2c e2 80 9d 20 77
68 69 63 68 20 75 73 65 72 73 20 63 61 6e 20 65
6e 74 65 72 20 62 79 20 6d 69 73 74 61 6b 65 20
69 6e 73 74 65 61 64 20 6f 66 20 61 20 73 70 61
63 65 2e
{CODE}

So what's looking decent are actually Unicode characters

{CODE(Colors="Tiki")}
e2 80 9c 2c e2 80 9d
{CODE}

I have absolutely no idea how to escape that so PHP will find it in pattern matching... Devs, please do not use Unicode unless really really necessary...

Even after the "Add default modules" button is clicked to add the modules, the button continues to display. Clicking the button again takes the admin to the admin-profiles page to find that the profile is already applied. The button should no longer display after the default modules are added, or should change to "Remove default modules". Also, IMO it would be good if there was a notice that the page is going to change/navigate to the admin-profiles page, maybe with a tooltip or helpblock text like "Apply Profile".

Also, the profile creates a wiki page called "Instructions - Admin UI Dashboard" that just contains a redirect to tiki-admin.php. This is confusing because there's no actual page, content-wise, and no instructions. Is this the stub of a feature that isn't finished yet?

Even when the new unified admin backend isn't turned on, adminui.css is active and imposes style details like link color that conflict with the active theme stylesheet in many cases.

I suggest the page elements of the new backend be given a unique parent class to distinguish them from, for example, the standard navbar that appears in the top or topbar zone when the new backend isn't active, so its CSS rules aren't erroneously applied.

Alternatively, adminui.css could just not be activated unless the feature is.

(Actually, IMO adminui.css (the visual rules like foreground and background colors, etc.) should be a theme (or two - light and dark) that can be selected, or a standard theme selected consistent with the "make it optional" rule. The adminui appearance could be the default for new installations, but could then be deselected for sites where maybe organization or corporate branding is a priority (and at sites that live on the wild side and don't need black and white menus ;-) ).

We need the footer at the bottom of the new Admin Unified Backend dashboard.

With a default Bootstrap menu in the footer, on the Unified Admin Backend page, menu item dropdowns drop down and the page isn't scrollable to reveal the dropdown.

With Smartmenus turned on, the dropdowns in the footer menu will scroll upward away from the bottom margin but only a few items can be seen because the dropdown is hidden or blocked by the div above the footer. It seems like maybe a z-index problem.

A new user will want to through all menu items in the admin panel. In the new Unified panel: at one point, admin is yanked out and loses navigation.

There are over 2000 prefs. Searching is critical.

When the menu is open, we have a nice search. Quick Access to that search should be always visible. Maybe a search-all-over-admin-panel action button in the top left?
{img type="src" src="tiki-download_item_attachment.php?attId=769"}

There are text strings that resist being translated. But although they clearly show up on the admin UI, they cannot be found anywhere in the source code? How can that be?

Example: Stop words for unified search index (tiki-admin.php?page=search).

The preset value is
{CODE(Colors="Tiki")}
a,an,and,are,as,at,be,but,by,for,if,in,into,is,it,not,of,on,or,s,such,t,that,the,their,then,there,these,they,this,to,was,will,with
{CODE}

But a grep through the entirety of Tiki Wiki sources yields no hit?! These values must be defined somewhere... And stop words, if they are not reserved magic keywords i.e. reserved by PHP or MySQL, would be language dependant and thus in need of localization... IMHO.

Using latest tikitrunk_svn from today (Jan. 24th, 2009)

I had a tiki site based on trunk from several weeks ago.
I added today another tiki site (using the same tiki files on server, thus using multitiki on subfolders)

Once the 2nd tiki site was up & running, I wanted to check the 1st tiki site, and it was complaining about mysql table missing, etc. So I went to run the "automatic database upgrade" ((doc:Tikiwiki 3)).
It needs to go through tiki-install.php, therefore so I did.
I had an (extracttoppath) issue, so that I attempted to go to tiki-admin.php from site one. The problem then was that tiki-index.php was complaining about:
^
The directory '/home/httpd/tikitrunk/modules/cache/javaoptics' does not exist.
The directory '/home/httpd/tikitrunk/templates_c/javaoptics' does not exist.
^

They seemed to have been deleted by the tiki-install.php script, since they were there a minute ago.
I tried also the other tiki site, and it happened the same, both folders were missing (deleted)

__Is this that tiki-install.php is not multitiki ready?__

---
duplicated bug report (by my mistake :-) ) with [bug2736]

This is a useful feature for an Intranet. However it's not so good if the emails are not to be disclosed. I think some code has been done in 1.10 for this. However, the feature probably needs more work.