Category: Administration

If you do not load a specific bug tracker (e.g. by a bookmark), but insted start on the search page for bugs and feature requests, the whish list, under

https://dev.tiki.org/Wishlist

you simply get a 503 ("Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.")...

Thanks
hman

{syntax type="tiki" editor="plain"}
When you enable SEFurl you want to redirect all traffic to the SEF counterpart.

To have them also correctly out of reach of robots you have to uncomment the following elements in the robots.txt file.

{CODE()}
# == Begin SEF URL Section ==
# Remove pages in favor of the SEF counterpart (Enable only after SEF URL’s are enabled in tiki will otherwise prevent indexing.)
# Disallow: /tiki-forums.php
# Disallow: /tiki-view_forum.php
# Disallow: /tiki-index.php
# Disallow: /tiki-read_article.php
# Disallow: /tiki-view_blog.php
# Disallow: /tiki-list_file_gallery.php
# == End SEF URL Section ==
{CODE}

It was working till Tiki28.
But if you do it in Tiki29, a <meta name="robots" content="index, follow, NOINDEX, NOFOLLOW"> will be added to all the pages.

May come after this : https://gitlab.com/tikiwiki/tiki/-/merge_requests/6653

I switched from LDAP Pear:auth to "Tiki-Only" where Users can Register BUT need a confirmation from the admin.
The admin got a Message like this
[...]
To Confirm.... klick:
tiki-login_validate.phpuser=user1&pass=c3746eb1baa6d209128b392680a5329c
[...]
The question mark for PHP-Code is missing so and the Link is invalid. I've to copy the Link and paste the question mark manually

Kind of an edge case, but if layout theme names change between versions or due to development work, so there's a mismatch between the stored layout preference and the layouts listed in the files, then a blank screen is the result. The database needs to be edited directly to correct the problem (tiki_preferences site_layout updated to match available layout names).

There should be a fallback to a default layout ("basic") if the preference name isn't found, similar to how the site will fall back to the default theme if the selected theme or stored-preference theme isn't found.

When I click a user, I am offered to send him a message. But then I get:

User XYZ can not receive messages
ERROR: No valid users to send the message

1: WYSIWYCA: I should not be offered to send a message if the user has disabled that. (frustrating to write such a message for nothing)

2: tiki-user_preferences.php: "Allow messages from other users" default should be yes

3: tiki-user_preferences.php: "Send me an email for messages with priority equal or greater than:" default should be "3"

tiki-admin.php?page=login
3- Users accept internal messages by default: default should be yes -> $allowmsg_by_default

4- Users can opt-out internal messages: default should be yes -> $allowmsg_is_optional


All these should be the default settings (most logical) if a Tiki site admin choose to activate inter user messages.

Related:
Easier Inter-user message management for Tiki admins:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=959

Also related:
Should sender email be disclosed when receiver gets notification via email? goals: balance privacy & facilitate communication/collaboration

Started in 3.0, needs to be used in tiki-admingroups.php and propagated to various places where permissions are set.


Also on wish list: A way to put more emphasis on more important permissions.

Either basic vs advanced or an ordinal column (top put more important stuff at the top)

So for a wiki page, view, edit and history should be at the top or in basic while tiki_p_use_as_template and tiki_p_export_wiki should be in advanced

WYSIWYG is now a basic feature in 12, but the panel is not visible from tiki-admin.php

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.

When setting preferences in each of the modules that Tiki supports, it would be of HUGE benefit and assistance to be able to click on a HELP ICON and get comments on what the setting or preference means and whether this should be used by you.

After a new calendar is created, the create calendar form is still populated, and subsequent changes will edit the already created calendar instead of creating a new one. This behavior is not apparent to the user until the edit has taken place.

Admin -> General -> Navigation

{syntax type="tiki" editor="plain"}
Add new Group fails with error:
An error occured in a database query!
Built query was probably:
insert into `users_groups` (`groupName`, `groupDesc`, `groupHome`,`groupDefCat`,`groupTheme`,`usersTrackerId`,`groupTrackerId`, `registrationUsersFieldIds`, `userChoice`, `usersFieldId`, `groupFieldId`) values('IHS','','','0','','0','0','','','','')
--------------------------------------------
No error was reported in error.log

The two last parameters correspond usersFieldId and groupFieldId fields in the users_groups table and defined as int(11) there.
The problem seems to be in default values of those parliaments as they defined in add_group function in userlibs.php:
{CODE()}function add_group($group, $desc='', $home='', $utracker=0, $gtracker=0, $rufields='', $userChoice='', $defcat=0, $theme='', $ufield='', $gfield='') {{CODE}

All stats related features/settings/options should be next to one another.

tiki-admin.php?page=features
Stats
Referer Stats

tiki-admin.php?page=general
Count admin pageviews:

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike

ex.:

# Redirects
# This is useful if you are migrating from an old site, and you want the old URLs to still work.
# Just uncomment and edit the line below.
Redirect 301 /oldpage.html /tiki-index.php?page=newpage

{syntax type="tiki" editor="plain"}
Assign Permissions with Level Configuration,
thus drop-downs in the table
tiki-assignpermission.php?group=Admins&advanced_features=y
ordering by level does not order correctly.

Admin categories is not listing all categories created in the site, using 1.9.cvs (from several days ago)

For instance:
http://edu.tikiwiki.org/tiki-admin_categories.php?parentId=0

Shows only WSDOC category, but if you go to browse categories, you can see that tehre are many more created:

http://edu.tikiwiki.org/tiki-browse_categories.php?parentId=0&deep=off&type=

---
update:
using cvs from today (May 2nd, 2007), problem dissappeared.

tiki-list_comments.php does not parse comments in column "Comment", regardless of whether section_comments_parse ("Parse wiki syntax in comments in all sections apart from Forums") and feature_forum_parse (Accept Wiki syntax) are enabled.

This is a regression from r20794 / r22511.

I upgraded from 1.85 to 1.9.0 without any problems. Things were working fine. Today, however, I logged in to access the admin area, and no admin links from the menu! All gone! What do I need to do to fix this? How can I access the admin area without links?

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

{syntax type="tiki" editor="plain"}
When clicking the Assign white plus sign on green background icon in Admin modules User modules tab, PostgreSQL fails complaining:

The following error message was returned:

ERROR: invalid input syntax for integer: "mnu_application_menu"

The query was:
select * from "tiki_modules" where "moduleId"=?

Values:

1. mnu_application_menu

The built query was likely:
select * from "tiki_modules" where "moduleId"='mnu_application_menu'

Stacktrace:
* /var/www/tiki/trunk/tiki-admin_modules.php : 0 -> {main}(array ( ))
* /var/www/tiki/trunk/tiki-admin_modules.php : 63 -> get_assigned_module(array ( 'moduleId' => '\'mnu_application_menu\'', ))
* /var/www/tiki/trunk/lib/modules/modlib.php : 60 -> query(array ( 'query' => '\'select * from `tiki_modules` where `moduleId`=?\'', 'values' => 'array (0 => \'mnu_application_menu\')', 'numrows' => '', 'offset' => '', 'reporterrors' => '', ))
[...]


Indeed, the query would expect an integer argument, not a string. This is a regression from r8873, which changed modlib's interface. get_assigned_module() now expects its first argument to be a moduleId, not a module name.

Guys, I have to set up a company wiki, which is completely structured from top to bottom. So I noticed a very annoying thing about tiki.

Currently if you want to create a page, that is destined to be part of a structure, you have to create it using the navigation bar and set the option "as child".

But what if a user creates a new page from within a structred wiki page? I.E. If he simply sets up a new link to an non existing site. The new page is created as an orphan which is definitely a "no go" for a completely structured wiki. Pages like this have to be manually assigned to a structure by the admin.

So I request an option, that __forces pages created from within a page in a structure to be automatically part of the same structure__.

I guess even in pages like doc.tw.org this would be very helpful.

In Google Chrome 1.0.154.59 and 3.0beta4 the admin pages do not
look good. The check boxes are a line above the text and everything is centered.

Did a fresh CVS checkout and install of BRANCH-1-10 at 1600 UTC on 2007-08-12. After installation and the initial login, there is no admin menu available. This means there is no menu item to get to the admin page to start enabling features.


{THUMB(id=33)/}