Category: Admin Interface (UI)

{syntax type="tiki" editor="plain"}
I have several tikiwikis (v 3.0 beta 4) on the same domain. Both behind the same .htaccess protected directory. The goal was to setup a working instance of InterTiki between these two Tiki's.

By way of example
* Apache .htaccess limit: http://www.mydomain.com/p/
* Master e.g. http://www.mydomain.com/p/master
* Client e.g. http://www.mydomain.com/p/client

__BACKGROUND__
A few setup issues have been noted (these details have now been added to the InterTiki documentation). Most notably is correctly specifying the location of "/remote.php" for the above case. For our above example to following is req'd:
* host: http://www.mydomain.com
* path: /p/master/remote.php

On the master, I have successfully made contact using either the IP shown in the Apache logs, or by simply using "127.0.0.1" in this case.

Likewise (also added to InterTiki docs) there was some oddity related to order of events with how the server info was being plugged into MySQL tiki_preferences interlist table. I have not properly tracked this down so will not go into it further at this time.

Also of note (for another bug or support request) is that I am unable to get InterTiki on the master to log out anything.

__BUG/FEATURE REQUEST__
''Note: InterTiki operates as designed and is simply unable to get behind an Apache Basic Auth wall. However, hard-coding in setCredentials line for the XML_RPC_Client should work in this case but does not.''

After getting setup dialed in like above, the client received the following message:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 401 Authorization Required)''

Some digging into /lib/userlib.php finds the calls for setting up the XML_RPC_Client at lines (around) 228, 2812, 2831, 2860 and 2905. Looking into the XML_RPC_Client class in /lib/pear/xml/rpc.php shows that there exists a setCredentials($username, $password) method. The setCredentials method exists to allow for RPC calls to get through Basic Apache Authentication.

__Possible Bug__
I went ahead and modified the clients (and eventually the master's) /lib/userlib.php in the above locations with a simple addition of:
$client->setCredentials("myApacheUsername", "myPassword");

This time, when logging in from the client, the response was:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 302 Moved Temporarily)''

And with that I am stuck. It seems like (as a workaround hack for the time being) the ability is there in the XML_RPC_Client methods to get through an Apache Basic Auth, but the return code is weird at best.

__Possible Actions__
#Ignore -- Explicity note that InterTiki masters/clients must not exist behind Basic Auth walls.
#Investigate why a hacked userlib.php returns a 302 code and determine if this is as designed or a bug.
#Possibly add a basic username/password entry field in the client administration page for driving the setCredentials method.

The tabs in the administrative interface use an onclick to run some AJAX code to change the interface. The problem is that they don't work in Chrome 17. They seem to work fine in Chrome 16.

More strangely, the method signatures of the tikitabs function actually appears quite different between the two browsers.

On Chrome 17 it is


function tikitabs(focus,max,ini) {
var didit = false, didone = false;
if (!ini) {
ini = 1;
}...

function tikitabs( focus, tabElement) {

The problem appears to be that the ini variable is not set, so it we set the ini to 1, then it skips down all the way to if (didone && ...) which gets bypassed, and we exit right away.

Why do you have different code for different versions of the same browser?

in debug mode (eg. when debugging ldap logins) many log entries are created at the same time so sorting by time is not sufficient to get the entries in their real order. Sorting by ID is better then.

Unfortunately sorting by ID leads to an unexpected result.

Looking at the code the problem can be fixed easily: The problem is that two tables are being joined (actionlog and actionlog_conf) and sorting by ID leads to sorting by actionlog_conf.id instead of actionlog.actionID.

Both needs to be fixed - in the SQL query the table for sorting must be added in the sort statement, in the template the columnname must be changed from Id to ActionId.

See patch.

When groups are synchronised with a big LDAP organisation many empty groups may end up in Tikiwiki.

This enhancement / patch adds an option to let the administrator of a tikiwiki instance decide whether during synchronisation of groups only the user assignments to existing groups will be done or if non-existent groups will be created in tikiwiki.

The default behaviour - as of now - is that when a LDAP user logs in all the groups he belongs to will be created in tikiwiki and he is being added as a member of these groups.

This enhancement adds the preference "ldap_create_groups_tiki" which is "y" by default - which corresponds to the current behaviour.

If "ldap_create_groups_tiki" is set to "n" and a LDAP user logs in the group synchronisation process will silently ignore groups that exist in LDAP but not in tikiwiki. Existing groups will be synced, though.

{syntax type="tiki" editor="plain"}
Fatal error: Call to a member function toArray() on a non-object in /var/www/rtsdata/apps/WiP/tiki/tiki-8.3/lib/prefslib.php on line 243

New install, following "Tiki for Smarties" examples,
Install is successful. No problems.
Log in as admin. ... good.
change password ... good.
go to Admin page from menu ... good.
select "general" ... fatal error.

try ..."Getting started using Profiles" ... same error.

{syntax type="tiki" editor="plain"}
!!!After upgrade the admin can't login anymore

!!!The failure sequence :
#Create a new directory or repository for the new version
#Update with your files (particularly images or icons)
#Site enable (example a sub-domain) on Apache
#Copy the database on new name
#Install manually .htaccess (compare and insert your valid options )
#Update "local.php"
#run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
#~~#F00:__Try to login as admin : You will be rejected as wrong password __~~

!!Analysis - many possible reasons :
There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

#If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :
- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

#The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

#Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

#Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

#Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

It is sure that if you use only one site close everything and upgrade you will get the minimum of problems but you will get someone anywhere.


!!~~#099:This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.~~
It is not seen generally by developers, because it is not at all their common upgrade process nor test.

I am referencing forum post: https://tiki.org/tiki-view_forum_thread.php?comments_parentId=43682&topics_offset=1

I would like the ability for users in child domains to access the TikiWiki site the same way users in the parent site are able to access it. According to the forum post, "Tiki is not currently capable of authenticating against multiple domains (or multiple LDAP servers)" and "The code could be modified to search, say, the global catalog for the user's DN and then authenticate against the corresponding domain, but this would be custom coding"

I would like an option to specify multiple domains, or a custom code I could use to search the global catalog for the user's DN.

Basically I want all of my users in all of my offices to access the Tiki site. Not just the home office users.

((doc:Edit CSS))
((doc:Edit Templates))

Was in Tiki 8.x too. Hoped it is fixed in Tiki 9 but it is still there.

Categories are rather useful things. However, in a site with hundreds of objects, being able to add items to a category at maximum 50 a time makes life unnecessarily hard.

The use case in question: a site which needs review. I need to add all the wiki pages and articles to a "Requires Review" category following an update of a very old site with lots of content. I cannot, because this limit of 50 stops me from adding the lot in one go, and the lack of any discernible way to select objects which are *not* yet in the category for addition stops me from adding 50 at a time. I seem to be at an impasse, short of writing my own PHP code to add objects en-masse.

Something more like the page wiki index doesn't seem like it would be a very hard thing to add? However, I am not familiar with Tiki's internals so this is hard to estimate.

This is a complementary report to bug [item4278|#4276]. Essentially the Category object browser seems to be too limited in it's options for selecting objects to manipulate to realise the full potential that categories might offer. Specifically, the lack of a way to select all objects, or all objects *not* in a category prevents practical application of categories to large numbers of objects.

The use case in question: a site which needs review. I need to add all the wiki pages and articles to a "Requires Review" category following an update of a very old site with lots of content. I cannot, because the limit of 50 items on a page stops me from adding the lot in one go, and the lack of any discernible way to select objects which are *not* yet in the category for addition stops me from adding 50 at a time. I seem to be at an impasse, short of writing my own PHP code to add objects en-masse.

As user "xavi" (plain registered user, I mean, not a user with admin privileges, etc), I created a new bug report here at dev.t.o/t5. Once saved, I attempted to:
* click at the Rating field - Stars (system), and I saw no effect.
* edit the tracker item, and clicked at one radio button option, and saved, but saw no effect.
In both cases, I still see that zero votes have been casted, etc.

As far as I remember, the choice of the user was stored, and showed somehow highlighted or similar. Nowadays, it seems as if nothing is stored.

Reproduced, as example, here:
http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4361

I confirm that these perms are granted to registered users on the tracker object permissions, as well as at global permissions:
* Can view rating result for tracker items (tiki_p_tracker_view_ratings)
* Can vote a rating for tracker items (tiki_p_tracker_vote_ratings)
* Can re-vote a rating for tracker items (tiki_p_tracker_revote_ratings)

Using services like http://www.stopforumspam.com can help to identify and handle spam-related mail addresses trying to create an account.

stopforumspam provides an API to test a mail address against a "known spammer"-list. This could be used to warn an admin before confirming an account.

trying to upgrade a 6.x (was 6.4) site using ''svn up'' gets it only to 6.8, but not 6.9.
Checking on sourceforge I see that the directory for 6.9 is called simply that, not tiki 6.9, as the subversions 6.0 through 6.8 are called. Could this be why svn up isn't upgrading to 6.9? If so, can someone with authority on sourcefourge fix this please.
Also switching to a specific version, e.g.
svn switch https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/tags/6.9/
results in the msg that there is no such directory.
Running tiki-install.php also fails to upgrade the site from 6.8 to 6.9.
So, how best upgrade? (I really don't want to do a fresh parallel install.)

For info: Before doing the svn up, I had done
svn switch --relocate https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/branches/6.x http://svn.sf.net/tikiwiki/code/branches/6.x


I first asked the question in irc, but got no responses.

I have updgrade Tiki 10.0 to 10.2. i have facing problem with both version.
Problem is when i click on Red Cross Delete button then it will displayed Blank page. but if i select remove option then it is working properly. so i have facing problem with delete button.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

{syntax type="tiki" editor="plain"}
Even with the feature turned off (being able to assign an icon to each menu item), when I look at the page source I see many lines of JavaScript containing the Font Awesome icon information for the icons that can be used by the feature. This doesn't affect the interface, but it seems like more unneeded data to transfer. At the April 2023 Roundtable meeting we talked about features that aren't activated shouldn't load scripts that won't be used. This looks like an example of that.

After activating "Chosen", form labels and selectors are broken visually and selector dropdowns are displayed as standard HTML lists, so Chosen is not working at all. (Without Chosen the forms display and function as expected.)

The version of Chosen in trunk may need to be updated. The script vendor_bundled/vendor/jquery/plugins/chosen/chosen.jquery.js says Version 1.6.2 but at packagist.org the latest non-RC version is 1.8.7.

Whatever else was done for Chosen to work with Tiki/Bootstrap 3 probably needs to be done again.

There is also a library to give Chosen selectors Bootstrap 4 styling (https://haubek.github.io/ - not on Packagist.org as far as I can tell) but that could be checked out after Chosen is functioning properly.

UPDATE: After adding chosen.css as custom.css, the selectors work and look good (well, the look like jQuery Chosen selectors, not Bootstrap 4 selectors, but they do work. So the fix seems to be to reconnect the CSS, which I'll work on. {sign user="chibaguy" datetime="2018-07-12T10:29:45+00:00"}

For example, on the wiki edit page, in the help dialog, when you select a plugin such as "IMG", the modal for entering the parameters (a jQuery UI dialog box) has the close button, but there's no "X" icon or character.

''I thought they were already an ticket for this''

jQuery-UI Chosen Select Boxes is not working and broke the page when an RTL language is selected.

https://share.vidyard.com/watch/Tonurm4FTGZEQQh6r8zBcd?

I found this : https://harvesthq.github.io/chosen/#right-to-left-support
May be this bit is missing ?

js and css borked in doc.t.o while testing how to avoid issue in elfinder which prevented to upload any picture: please help

Login to https://doc.tiki.org and try to click at any wiki page icon section at the topright corner of the page: nothing is shown.

If you click in control panels to avoid using tabs, nothing happens.
etc.

Even for themes with no theme option, the option selector is being displayed, with every theme option (of all themes with options) listed. Selecting an option doesn't do anything, but it's a regression for the selector to even display for no-option themes.

The "Directory Batch Upload" page states "Please do not use this feature to upload data into the database." The page is stating that it should not be used, thus rendering it unusable. Clarification is needed.

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.