Category: Administration

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.

How are the various *.tiki.org sites different in their configuration?

How about compared to the default setting?


How could we have a diff of 2 site's config? Perhaps this could be exported as a profile, and thus an easy way to "copy"/migrate configs from one site to another.

Ex.: in a staging & prod setup...

See: ((Configuration Management))

Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=539151

{syntax type="tiki" editor="plain"}
On the latest Beta Version of TikiWiki (5.0 Beta 2) the admin email settings under General option cannot set SMTP. This works fine in 4.x versions.

For example my smtp server address is auth.smtp.1and1.co.uk

Some how the number 1 here is translated to auth.smtp.oneandone.co.uk hence giving the error that the smtp is not valid.

Thank you.

Just downloaded 12.o.beta from SourceForge following Jonny's Tiki-devel email of Fri. 22 Nov 2013. Unpacked fine (using zip file). ran "sh setup.sh" going through three standard steps, (c) composer, (f) fix and (x) exit, smoothly.
Started up, automatically switched to install. Went through all steps smoothly.
Entered tiki.
Went through Wizzard. Getting better and smoother all the time; congrats all who are working to make this better.

Before logging off as admin from every new Tiki I create, I always create myself a new user. Did so again this time, and get an annoying (and confusing) error message:
---
__Error(s): No index available.__
---
directly above the information:
"Notice: Account validated successfully.
Information
Account validated successfully. "

The only option provided is in the upper right, to "clear errors".
---
For the record, during the Admin Wizard, I did NOT chose the "Basic Search" but the "Advanced Search" with "MySQL Full-Text Search as my "Unified Search Engine" and "Incremental Index Update".

I think this is just a small annoyance, but can see how this confuses and worries a new user/admin.

Just downloaded 12.o.beta from SourceForge following Jonny's Tiki-devel email of Fri. 22 Nov 2013. Unpacked fine (using zip file). ran "sh setup.sh" going through three standard steps, (c) composer, (f) fix and (x) exit, smoothly.
Started up, automatically switched to install. Went through all steps smoothly.
Entered tiki.
Went through Wizzard. Getting better and smoother all the time; congrats all who are working to make this better.

Before logging off as admin from every new Tiki I create, I always create myself a new user. Did so again this time, and get an annoying (and confusing) error message:
---
__Error(s): No index available.__
---
directly above the information:
"Notice: Account validated successfully.
Information
Account validated successfully. "

The only option provided is in the upper right, to "clear errors".
---
For the record, during the Admin Wizard, I did NOT chose the "Basic Search" but the "Advanced Search" with "MySQL Full-Text Search as my "Unified Search Engine" and "Incremental Index Update".

I think this is just a small annoyance, but can see how this confuses and worries a new user/admin.

Switching language from admin panel produces blank page (tiki not showing) under some circumstnaces, along the last weeks (repeated today-13th june 2007 again with latest 1.9cvs code)


I have a selection (through "Admin > login") of themes chosen by admin to allow users to change among those themes.
Moreover, mod-switch_theme is assigned to registered users in left column.

From time to time, when I change the theme under "Admin > General", I get this message:

^
Notice: unserialize() [function.unserialize]: Error at offset 239 of 250 bytes in /home/httpd/tiki19/modules/mod-switch_theme.php on line 15
header already sent
^

plus a blank page. After that, I see on top of each page:

^
Notice: unserialize() [function.unserialize]: Error at offset 239 of 250 bytes in /home/httpd/tiki19/modules/mod-switch_theme.php on line 15
^
I cannot change the selecetion of themes any more through "Admin > login": I'm geeting
^
Notice: unserialize() [function.unserialize]: Error at offset 239 of 250 bytes in /home/httpd/tiki19/modules/mod-switch_theme.php on line 15

Notice: unserialize() [function.unserialize]: Error at offset 239 of 250 bytes in /home/httpd/tiki19/tiki-admin_include_login.php on line 522
^
on top of that page, and the selecetion of themes is not showing properly (names of themes), but it produces this hatml lines at that multiple selection box (taken from the html source of the page):

{CODE()}
<b>Warning</b>: in_array() [<a href='function.in-array'>function.in-array</a>]: Wrong datatype for second argument in <b>/home/httpd/tiki19/templates_c/precarios/es^%%00^00C^00CB4449%%mod-switch_theme.tpl.php</b> on line <b>33</b><br />
{CODE}


(until I delete that selection directly from the db).

I just upgraded an old -+18.0svn (Revision: 64806)+- to latest -+18.3svn (Revision: 67723)+- and I got an unexpected error during the database upgrade step.

{CODE(label="just normal steps")}root@firstheberg01:/var/www/luci-199-6485# svn up
…
Updated to revision 67723.

root@firstheberg01:/var/www/luci-199-6485# php console.php c:c
Clearing all caches

root@firstheberg01:/var/www/luci-199-6485# php console.php d:u
Update completed.
Installed: 20100909_ckeditor_upgrade_tiki
Installed: 20171010_action_log_info_new_column_tiki
Installed: 20180411_schedulers_change_column_to_text_tiki
Installed: 20180419_scheduler_run_stalled_column_tiki
Installed: 20180421_scheduler_run_healed_column_tiki
Installed: 20180503_fix_throttled_newsletters_tiki
Installed: 20180705_fix_calendaritem_tracker_attributes_tiki
Failed: 20180405_remove_unused_user_id_tiki
Queries executed successfully: 6
Error 0 in 20180405_remove_unused_user_id_tiki
ALTER TABLE tiki_custom_route DROP COLUMN `user_id`
Table 'luci_199_6485.tiki_custom_route' doesn't exist{CODE}

{syntax type="tiki" editor="plain"}
At : tiki-admin.php?page=general#contentadmin_general-3
We have an option : The URL that the anonymous user is redirected to when a page is not found

The work fine.
When an anonymous it a 404 he see the page.
But that doesn't work with registered.

Why not extend to anyone when a page is not found ?
That would be very useful.

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.

When the FAQ feature is enabled, hovering over feature 'Blogs' in the 'Main' tab generates a floating box that says 'Wiki'. Likewise, hovering over 'Mini Chat' on the 'More Functionality' tab generates a floating box that says 'HTML Pages'

I get "Fatal error: Class 'Comments' not found in .../lib/importerlib.php on line 24" when trying to import a forum (at'tiki-forum_import.php').

The feature "Mini-Calendar" does not appear on tiki-tracks.

It would be good to be able to prevent wiki pages in a specified category from being listed by this module (last_modif_pages). For example, at the *.tiki.org sites, there are "Archived" and "Retired" categories for wiki pages that have old content, etc. and so are for admin users or registered users only. When a page is edited to be categorized in one of these categories, it is then listed in the module, but this isn't a change that needs to be, or should be, publicized, since the page is being removed from access.

There should be a field in the module parameters like "Don't list pages in these categories", where category names or ids could be input and pages in these categories wouldn't be listed in the module.

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.

{syntax type="tiki" editor="plain"}
After activating Ajax at features -> Ajax systems tells successful activation. After reloading features page Ajax is deactivated again.

Tested in v3.1. When choosing to store File Gallery items in a directory instead of the database, the directory field requires the full server path. If the abbreviated relative path to the wiki is entered, file uploads fail.

This conflicts with both doc.tw.o (as of today's rev) and Admin > Wiki, which allows the attachment directory to be specified relative to the wiki directory.

> As admin, I can't set the permissions on Registered users to: list_file_galleries or create_file_galleries, though other file galleries settings are selected, including view_file_gallery, download_files, upload_files, view_fgal_explorer, and view_fgal_path. I tried to deselect that last 2 since I don't understand what the file gallery explorer is and I don't know that they need to view the path, but I can't seem to deselect and save it successfully.
>
> When I log in as a Registered user and click on File Galleries, I get this Error message: Permission denied you cannot view this section.
>
> I see a link for Upload file, but when I click on it, I get: No gallery available. You have to create a gallery first! Create New Gallery.
>
> When I click on Create New Gallery, it gives me this Error message: Permission denied you cannot view this section.

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)

If you are admin you can create directly users with a username, password and email.

However the field "email" has no validation at all.
Admin can enter anything like "vincent".

If an admin does so and the notifications are enabled for this user on wiki page edit, __all__ users will suffer errors as they save their work. Tiki dependencies go "bongo" as they are fed with an email that is not valid.

Admins should know what they are doing, still a simple validation or a warning should be placed.
Such misuse are not obvious with immediate results; it may take several hours to understand what is going on and more time to find the faulty user(s) record(s).

On the Control Panel General Settings, tab Navigation, option "The URL that the anonymous user is redirected to when a page is not found" you can redirect anonymous users when then hit a page that doesn't exist.

However if your field value there a wiki page the redirect will go to a endless loop that will display a "Too much redirect" error.

If your value is the full URL (https://....) it work fine.

This problem is quite common and happen to a lot of users, even experimented.

The text for the option is not strict enough and for many "The URL..." is not necessary the full URL path.

The "Help System" link on Admin::General points to non-helpful swamp on doc.tw.o

The URL's for the help buttons are not being built correctly. Users are unable to get help during the initial setup.

Tested on 1.10.0b1. To reproduce:
After a fresh install go to the Administration:Administration page
Click on the General icon.
Click on the help icon at the top of Administration General
The help URL will use the local host name instead of doc.tikiwiki.org

Other notes:
Help shows enabled on the features page (apparently enabled by default)
All pages reached through tiki-admin.php seem to have this problem

{syntax type="tiki" editor="plain"}
On a Tiki24x.

If you use a plugin (like mediaplayer) that require PDF.js but __it is not enable__ this what you see:

PDF.js feature is disabled. If you do not have permission to enable, ask the site administrator.

If you enter the control panels (as admin) and search for "PDF.js" or "PDF" there is no result.

The error/warning message should tell the user/admin exactly what to do.

---

This is not an easy task to get the information... or to work.

If you search in google for Tiki PDF.js you land here : https://doc.tiki.org/PDF.js-viewer
"Starting in Tiki19, installable via Packages."

But on this Tiki the package : npm-asset/pdfjs-dist-viewer-min 2.12.313 is already installed.

I refreshed caches, checked permissions.
I also installed the package mPDF (may be ?)
I enabled "PDF from URL (mPDF)" at tiki-admin.php?page=print

Still something is missing somewhere...

Currently, there are four preference filters available in the Control Panel interfaces: "Basic", "Advanced", "Experimental" and "Unavailable".

As a user new to Tiki, I have on several occasions noted features that looked interesting, but which I have not enabled as I have subsequently found it is planned to deprecate them. In some cases this was obvious (e.g. a 'warning' icon with the deprecation message on hover next to the feature checkbox), in others it wasn't (i.e. I only found out about it from doc.t.o or related places).

On the assumption that it will help with planned deprecations if new installations don't enable and start using deprecated features, I would propose that a "Deprecated" preference filter be added, that relevant controls be assigned to it, and that it be disabled by default in new installations.

I understand the criteria for such might be controversial (indeed, I hope I'm not reigniting a heated discussion by posting this!) and so would understand if this is WONTFIXED. I also recognise that it is less appropriate for a new user to suggest criteria here than for those that have had Tiki installations for some time and/or are directly involved in development, which is why I haven't listed any in this initial report.