Category: Admin Interface (UI)

Sometimes, we want people to participate to one wiki page, to access their user tracker to update personal information or access a ((workspace))

Right now, we need to

#create a user
#create a group
#assign user to the group
#give permissions to group ( in general or for a specific item)
#inform this person, typically by email, on how to access this page


Instead, I would want to
#add an email
#pick the permissions this person has
#any limitations (works x times, or for x days/weeks)
#an optional message

And the system should send a 1-click login email (an email with a link in it which is unique / very difficult to guess).

Whoever clicks that link
*Would be authenticated with the appropriate permissions and according to the limitations.


Related:
Expiry date for group membership
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1071

Somewhat related:
Send welcome email (by admin to new user or user that has not connected in a while)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1016

I would like a way to invite people to come to a Tiki site after I have added their login. (different of the use where people self-register)

Right now, I simulate a lost password message (which I customize).

Maybe this could become a new feature available to admins when

1- after a successful user creation at tiki-adminusers.php
2- when administering a user account
3- from : tiki-adminusers.php with the batch command to send to many new users.

The system would send an email with a one-click login and be sent to the user tracker
tiki-view_tracker_item.php?view=+user

Person who triggers this email alert should be in BCC. (to have a trace). Even better would be to have this logged somewhere but this could be for phase 2.

We could have a new mail template in templates/mail/welcome_message.tpl or in a wiki page (better!)


What do you think?

So I could show quick_edit module to users with tiki_p_edit

Related:
[wish1783|Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)]

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.

I looked today at http://info.tikiwiki.org/tiki-list_submissions.php and there are nearly 300 spam submissions there so far, and no way to delete them in groups. Maybe that's why nobody noticed my prior submission as info.tw.o editor from last month...

(the user need to be in info.tw.o Admin group in order to see the spam list. If your users is just in the info.tw.o_editors group, you'll see nothing but your own submissions if any.)

A text box to select the amount of rows to be listed would be welcome, and multiple checkboxes to select some or all, like with users, etc.

---
By the way, how can anonymous spammers post submissions to info.tw.o? They can't through http://info.tikiwiki.org/tiki-edit_submission.php (at least, nowadays)... Spam hole somewhere?

Our users keep adding large .ogg files in our files galleries and we have been asked to externalize theses files in a special download directory of the web server. Problem is that the admin screen of the files galleries doesn't have a DISPLACE section. You can set the option for the files to be added in an external directory, and the new ones are indeed placed into it, but the existing files stay in the database.

I have discovered that the *Image* galleries admin screen has this DISPLACE section but it will work only for the image galleries, no way to use it for the non image galleries.

Please increase the limit and make it multilingual

I upgraded my Tiki from 4 to 8. Perhaps it was premature to upgrade a busy Tiki with many users to Tiki8. Anyway, I found a few issues. I am not sure if they would be characterised as bugs, or just stuff that has not yet been implmented. Here are the issues:

(1) The login prompt kept floating around the screen, appearing and disappearing in random places at random times, so I went to Admin-Modules to try to fix it.

(2) The next issue, is that in Admin-Modules, the tabs do not work. Clicking on a tab does nothing. Fortunately, I can proceed by clicking on the "No-tabs" button. Good idea that.

(3) Editing the login module didnt seem to help. So I came up with a cunning plan: Delete the module and then add it back in again. In hindsight, that was a pretty risky thing to do in beta software.

(4) I deleted the login module, but now I cannot add it back in! According to the instruction text, new modules can be dragged from the "All Modules" tab. But this either doesnt work or has not yet been implemented.

My Tiki is at http://lockbox.seanbdurkin.id.au

This is intended as a security feature. However, it is causing lots of support requests.

How can we maintain security but make it easier for admins?

Fact : with the module action_calendar the popup can't be reached.So it is impossible to access to the command buttons of the popup

Analysis : conflict or bad logical test between :
*the popup activation condition "on the date cell"
*"the need to let the popup opened or when the pointer remain over the popup"
*"sticky popup"

Same remarks as for the previous tracker about calendar feature.

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.

Ex.:
tiki-adminusers.php?group=Editors


It will make it easier to manage groups.

Admin -> General -> Navigation

It's very easy to add manually by editing templates/footer.tpl, it would be nicer to have the _uacct saved in the database with the rest of the settings. Upgrades would be easier for site admins.

Please see:
https://www.google.com/support/analytics/bin/answer.py?answer=55488

This would be similar to gmap.

Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1177


Maybe this feature request could be even more generic to include easy ways to add other services and/or make it easy to use with open source apps like phpOpenTracker or phpMyVisites.

http://www.phpmyvisites.us also recommends putting the code just before /body>


Also, there should be a way to exclude certain or all groups from tracking. If I use 1 Tiki for a public website and and Intranet, I don't want my Intranet traffic to pollute my public site stats. I could just want anonymous users to be tracked.


Also, let's integrate more tightly with the new [http://www.google.com/analytics/GATCmigrationguide.pdf|ga.js] code so we can track downloaded files, and take advantage of other nice stats.

If I create a new group in tiki-admingroups.php, and want to add a user, I must go to tiki-adminusers.php

I should be able to add users to groups from tiki-admingroups.php, with a drop-down (if < 500 users) or a search username box (if users > 500) , or something like this...

Keep it optional - even activating something just to see, how you admin it!

Is there any reason this has to be this way?

Bugs & Wish list

It would be lovely to set some new user defaults at
* Admin (home) > Login > User defaults, and/or
* Admin > Groups > (Edit a single group)

The ability to Subscribe/watch/monitor new users in the site or to that specific group, to specific Tiki objects.

Which tiki objects?: I would say, in this order:
# specific forums
# specific blogs
# specific calendars
# specific newsletters (ML: we can already subscribe groups to newsletters)
# specific wiki pages
# specific structures
# specific trackers
# specific categories
# new articles

This is specially useful for new users of the site, where they don't know yet how to subscribe to specific areas, etc. Very needed for educational scenarios, but I can see many other places where new users are a bit lost for some time while they learn how to use the Tiki site.

Related:
*[wish988|Forum: Let forum admins/moderators add groups and/or users as watching the forum]
*[tiki-index.php?page=Business%20Plans|Let small business start ups access collaborative sharing where the document being shared is not visible by anyone else]


Anywhere there is a watch eye, it should be possible for an admin to have group members watch this category

In Opera and IE7 (didn't check yet in IE6), all sublevels of the Tiki Magic admin menu display all the time. Sublevels aren't top-level item sensitive as in Firefox.

In 3.2, one can create a personal page in MyTiki and use an Avatar (I see from the Community it wasn't always available & I appreciate the feature), but I would like an Administrative feature that could turn these off while still allowing users to access their Preference Screen, especially for changing their password and email address.

User pages and avatars could take up a great deal of space if there are a lot of users. I'd like to turn off the ability of users to have user-pages and avatars. If there's a way to do that now, please let me know, because I've looked everywhere for a way to do that (and there's a note not to edit templates unless you really know what you're doing and I somewhat know, but I'm afraid of creating a problem).

See video:

{FLASH(movie="tiki-download_item_attachment.php?attId=62",width=>876,height=>677,quality=>high)}{FLASH}

One of the nice things about Tiki is that, once setup, all the configuration is done Web-based. No FTP access is necessary. However, it can happen that a Tiki admin breaks his site and locks him/herself out.

This can happen in Site Identity as well.

For example, if you use the following code
{CODE()}
{show_image.php?id=13}
{CODE}

in a module, you will get:

{CODE(wrap=>1)}
Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unrecognized tag: show_image.php?id=13 (Smarty_Compiler.class.php, line 436) in lib/smarty/libs/Smarty.class.php on line 1088
{CODE}

and the site will be broken and you will be locked out of your Tiki site. (You need to go via phpmyadmin to delete the offending module)

I just added a warning to BRANCH-1-9 for modules but it would be much better that Tiki wouldn't break in this case.

More background info/ideas below
{CODE(wrap=>1)}
(01:17:27) marclaporte: I am wondering if there would be a way to avoid people locking themselves out of a Tiki site when putting invalid content in modules...
(01:22:27) chibaguy: One way of coping would be to include an admin_modules page (php and tpl files) that has no side columns, so people could input that URL admin their modules without the activated modules being displayed.
(01:23:28) chibaguy: Of course it would be more direct if the bad module just displayed without content when the content is bad, but is this possible?
(01:28:23) marclaporte: depends how bad I guess
(01:28:31) marclaporte: How about a test module page
(01:28:53) marclaporte: So you can test even before assigning
(01:29:18) chibaguy: Yes, if it opened in a new page, it wouldn't kill the main site.
(01:29:24) marclaporte: Some guy locked himself out using {show_image.php?id=13}
(01:29:42) marclaporte: It is very natural for the person to try this syntax
(01:31:27) marclaporte: instead he's locked out Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unrecognized tag: show_image.php?id=13 (Smarty_Compiler.class.php, line 436) in lib/smarty/libs/Smarty.class.php on line 1088
(01:32:52) chibaguy: It does make sense to have a safe test zone for modules before they are assigned.
(01:33:17) chibaguy: Where failure doesn't lock up the site.
(01:33:38) chibaguy: Could that replace "preview"?
(01:33:52) chibaguy: Or "preview" be enhanced?
(01:37:17) marclaporte: where is preview?
(01:38:54) chibaguy: On Admin Modules page under "Assign new module" there's a "preview" button that displays the module in the center of the page.
(01:39:50) marclaporte: woah
(01:40:01) marclaporte: I never noticed that
(01:40:11) marclaporte: 4 years
(01:40:20) marclaporte: and I still discover stuff
(01:40:23) marclaporte: :-)
(01:40:33) chibaguy: Heh. Well, Tiki's got a lot of stuff.
(01:41:41) chibaguy: I'm not sure offhand how preview handles fatal error modules. With Opera, I just hit the back button and have the admin modules page again.
(01:41:56) marclaporte: I just tested
(01:42:03) marclaporte: it crashes
(01:42:11) chibaguy: Ouch
(01:42:31) chibaguy: What if preview previewed in another page or a popup?
(01:42:57) chibaguy: The user would still have control, I think.
(01:43:01) marclaporte: it crashes but just one page
(01:43:10) marclaporte: the site is still accessible
(01:43:17) chibaguy: OK.
(01:43:45) chibaguy: So users should be sure to preview first.
(01:44:29) chibaguy: Maybe Admin Modules needs some large warning messages.
(02:13:46) CIA-9: marclaporte BRANCH-1-9 * tiki/templates/tiki-admin_modules.tpl: Warning message about possibly breaking a Tiki site by improprer use of Smarty Syntax in modules
(02:13:48) marclaporte: incoming
{CODE}
---

Added on 2007-08-17:

Idea for modules:
Maybe tiki-admin_modules.php shouldn't show modules. So you could always get access to your Tiki to remove/fix modules. And it should offer a login box, when not logged in.

tiki-admin_modules.php could have some like (this doesn't work because modules are evaluated even in left & right columns are off, since a module could be in a wiki page):
{img src=images/code.png}%%% {CODE()}

$smarty->assign('feature_left_column', 'n');
$smarty->assign('feature_right_column', 'n');
{CODE}

But it is nice to see the result of what you are doing. We could have &showmodule=y in the URL (with a link next to assign module/left modules/right modules/etc

__Same thing when you use tiki-edit_templates.php__ ->

If I don't close an if, I get:
{img src=images/code.png}%%% {CODE()}
Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unclosed tag {if} (opened line 1). (Smarty_Compiler.class.php, line 317) in lib/smarty/libs/Smarty.class.php on line 1095
{CODE}

Would there be a way that a Smarty error doesn't break Tiki completely? Here again, there could be a light version of tiki-edit_templates.php which has nothing which can break in a module. Maybe everything is hard-coded and it doesn't take any theme into account. And it shouldn't be possible to edit the tpl of tiki-edit_templates.tpl via tiki-edit_templates.php?template=tiki-edit_templates.tpl


__Maybe useful?__
Smarty validation class
http://www.phpriot.com/d/code/smarty/smarty-validator/index.html


Here is another very famous error: "Fatal error: Allowed memory size of 8388608 bytes exhausted"
http://tikiwiki.org/art82

And they often cause blank pages. How can we can catch them and render a simple & descriptive error page (not enough memory) instead of a blank page?


__Related:__
dynamic contents in userdefined modules crashes tiki
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=851

In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.

CSS... Themes...

Fact : when you submit "preview" for a new event, a great part of data are lost, there is no real preview, and when you return to creation most of optional data are lost.

Too many things don't function : the job is not ended.

Sometimes, first day of the week is Sunday, even if you set that to be Monday on Calendar settings.

This bug shows up for us (catalan interface, time zone "Europe Madrid (UTC+1)" when we have in tiki-admin.php?page=general, at preferecnes syntax:
"1.10 - $prefs.feature_foobar..."

When we swich this parameter to
"1.9 - $feature_foobar"

then fist day of the week in calendar is Monday, as expected

Right now, there's no way to resend either the email to the admin to validate a user or resend the email to the user to validate their email address. If either of those emails fail to happen or they get sent to "spam", the user cannot log in.

when you click on the polls icon on the Admin Home page, you are taken to the polls comments admin page instead of the polls admin page. User should not have to make an additional click to start work.

Tiki has a lot of features. But sometime, we have to hack it up with various things that we can't share back to the project.

So we want to modify Tiki, yet, keep upgrades easy.

It is already possible to add custom language strings.
It is possible to override Smarty .tpl files with our own
It will soon be possible to add custom CSS strings


It would be nice to have this for javascript as well.

A custom.js somewhere. If it can be kept in the database, it makes site migration and backup even easier

Or it could be in styles/*/custom.js


It would be nice to have the option of putting towards the top or towards the bottom. Maybe Site Identity custom areas already permit this?

Sometimes, we want to change a few language strings from the original Tiki. It could be because of regional or community expressions.

Currently, we need to change language.php and/or the template (tpl) files.

It would be better to have a custom language file which would override default text. (Like we do for tpl files). Therefore upgrades would be smoother.

Even better if we could edit this language file via the GUI.

Sometimes, users forget their usernames and end up creating duplicate accounts.

Here are two things which would help:
1- Users should be able to have a password reset/reminder while only knowing their email. __fixed in 1.10__

2- In tiki-adminusers.php, the search box should work for emails also (not just usernames) __fixed in 1.10__


Related: [tiki-view_tracker_item.php?itemId=1069]
Also, in 1.9.x, usernames are CaSe SenSitive. __fixed in 1.10__

TikiWiki often has drop-down menus with many choices.

Ex.: drop-down list of users, or wiki pages, etc

That is ok for a few hundred. But what if you have 300 000 users or 300 000 wiki pages?

There should be a setting where beyond a certain number, the drop-down become a search box.

We need to decide about ((tw:DefaultSettingsChanges)) in 1.10

Some of the new features are much better than previous ones (ex new diff engine). People upgrading their Tiki could conserve their setting. However, new installs should take advantage of the new features.

A note should be added in tiki-install.php This must be low maintenance for Tiki dev team.

I would like to have the templates include a comment line such as: <!--start template: tiki.tpl--> and a corresponding <!--end template: tiki.tpl-->. As a non-developer performing minor overrides and adaptations to the existing templates, this would greatly improve the time needed to locate the correct template to override for a certain page, as you could just go into the HTML source code and see which templates are involved in generating the page you are looking at.

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.

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"

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:)

TWiki has the ability to refer to an Admin specified .htpassword file for user control. This is highly useful for having a single point of administration. The tough part is that TWiki doesn't manage the user experience (password changing, etc) very well.

For a TikiWiki enhancement, I would have the following wish:
(1) For the login/authorization, when set to WEB, admin should be allowed to set the path to the apache password file (typically a .htpasswd but names are arbitrary).
(2) Should allow the optional use of .htgroup settings as a means of setting member group. This would then override or augment TikiWiki's groups -- or better yet tikiwiki would manage the .htgroup file in this case.

Benefits of this enhancement:
(1) This would greatly streamline multiple tiki's on a single hosted site (like a corporate intranet).
(a) Single location for user entry for all tiki's that look to the same .htpasswd file
(b) Single location for group entry for all tiki's that look to the same .htgroup file
(b) No mess trying to setup InterTiki
(2) Might also simplify setting up of MultiTikis on a single site by clarifying and simplifying user and group setup.
(3) Would clarify user setup using the Web Authorization method
(a) Right now, one needs to add the user to the .htpasswd file to give them authorization (Locked Area Lite works well for this) and then ALSO add the user to the TikiWiki. The problem is if there are multiple TikiWiki's, then it could be a lot of work adding a username and their groups to each of the TikiWiki's.
(b) The process above (3a) is pretty unclear and takes some figuring out for a newbie tikiwiki admin like myself.

I have this settings at tiki-admin_security.php :
{QUOTE()}
|| Tikiwiki settings
Tiki variable | Setting | Risk Factor | Explanation
fgal_use_dir | ../tiki_filegals/ | unsafe | The Path to store files in the filegallery should be outside the tiki root directory
||
{QUOTE}

However, that folder it outsite the tiki root directory, and outside htdocs.

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?

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)

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.

Calendar should be like the other elements in the menu

for exemple:
Calendar
view calendar
add an event (which means we need an URL for this)
admin calendar

Make it more consistent. The feature has a different name in admin wiki than on wiki pages.

Why do they look different?
tiki-browse_categories.php
tiki-admin_categories.php

If the user didn't change the value of the destination of the help system, it should be updated to what the default value is now.

Need to hunt down what all the previous values were (ex.: http://doc.tikiwiki.org/tiki-index.php?page=) and to update via sql

And for clean installs as well (of course)

However, if someone modified the default value, we don't touch.


Reminder to add a reset to default value in 3.0 (new admin panel should permit this)

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

Levels in tiki-assignpermission.php are confusing to the new tiki admins.

just like this ((text中文))

it can't be parsed correctly as a page referer.

{img src=images/code.png}%%% {CODE(wrap=>1)}
(7:48:16 PM) marclaport1: polom
(7:48:21 PM) ***marclaport1 has an idea
(7:48:31 PM) marclaport1: to make tiki easier to install
(7:48:34 PM) marclaport1: and safer
(7:50:54 PM) marclaport1: say I point to tiki-install.php
(7:51:07 PM) marclaport1: on a tiki which is already in existence
(7:51:27 PM) marclaport1: i get a choice of clean install (tiki.sql) with various profiles
(7:51:59 PM) marclaport1: or to upgrade (1.8.x_to_1.9.x.sql)
(7:52:20 PM) marclaport1: why offer a clean install unless db is empty?
(7:53:33 PM) marclaport1: so if tiki-install.php can only can the upgrade sql (which is designed to be run over & over again) tiki becomes safer
(7:54:55 PM) marclaport1: if the database exists, there should be a note the admin to use phpmyadmin to go and empty the database of create a new one for tiki
(8:00:29 PM) ***marclaport1 feels that must be something wrong with this idea, or else all the smart people in tiki would have though about it.
(8:03:38 PM) ***marclaport1 has the impression that most tiki devs don't use the web installer
(8:04:21 PM) marclaport1: ...
{CODE}

{THUMB(image=>img/wiki_up/Smarter_Tiki_install.jpg,)/}

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.

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.

Contributors

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

Different ajax functions located in the same file suffer from Cross Site Request forgery vulnerability. This makes execute unwanted actions on a web application in which the victim is currently authenticated.
The details has been described and sent in a encrypted email to the security team.

Features Classification

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.

Related:
((MemoryConsumption))


Here is a very famous error: "Fatal error: Allowed memory size of 8388608 bytes exhausted"
http://tikiwiki.org/art82

And they often cause blank pages. How can we can catch them and render a simple & descriptive error page (not enough memory) instead of a blank page?


__Maybe useful?__
Smarty validation class
http://www.phpriot.com/d/code/smarty/smarty-validator/index.html



Related:
Better protection against accidental site breakage with improper use of code in modules + template
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1065

This feature isn't internationalized.

The usage of quicktags is hardcoded in the PHP, like

$quicktags = $quicktagslib->list_quicktags(0,-1,'taglabel_desc','','trackers');

for the trackers. The french translation e.g. reads

Catégorie : wiki, formulaires, etc.

So a french user would enter "formulaires", but never see his Quicktags in the Trackers feature.

In barebones profile and in featured profiles, there is intro text about 1st login being necessary with u: admin p: admin (good)

However, this message stays and needs to be deleted by admin (bad)

Perhaps we should have a module with is only visible if admin password has not yet been set.

Many people use the wiki without structures. It should be optional, like the rest.

During the last few weeks before launch of 1.9.8, many fixes were introduced. They need to all be evaluated and ported to 1.10



Needed in 1.10 script: change password -> 999 days and 1999 days, needs to become -1 (and a warning in tpl not to use these values) 999 become 1000 and 1999 becomes 2000 if you try.

ref: [http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/db/tiki_1.8to1.9.sql?revision=1.79.2.194&view=markup&sortby=date&pathrev=BRANCH-1-9]

Making tiki-admin_modules.php more intuitive (last few commits):
http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/templates/tiki-admin_modules.tpl?view=log&pathrev=BRANCH-1-9

Related:
[wish1887|Modules use should be restrictable with standard permissions]


Read from bottom up:

2008-05-27 00:46:33 Norrin_Rrr mmh
2008-05-27 00:45:57 prozaq you could probably modify that
2008-05-27 00:45:39 prozaq that displays all categories
2008-05-27 00:45:32 prozaq Norrin_Rrr: in 1.10 there is a module called "categories"
2008-05-27 00:41:25 Norrin_Rrr will try it
2008-05-27 00:41:16 Norrin_Rrr the example in the documentation says its for features not sections that s weird
2008-05-27 00:40:51 prozaq oh - yes I think so, but Ive never tried it
2008-05-27 00:40:34 prozaq beg your pardon?
2008-05-27 00:39:45 Norrin_Rrr the section parameter in the menu its to set wich section (wiki/cms/forums) will display the menu ?
2008-05-27 00:38:54 Norrin_Rrr that should be doable
2008-05-27 00:38:19 prozaq so you should be able to copy some of the code from the tiki-browse_categories pages
2008-05-27 00:34:38 Norrin_Rrr yes
2008-05-27 00:34:16 prozaq but isnät that when you are creating a module from scratch?
2008-05-27 00:34:07 Norrin_Rrr i am not sure but there seems a possibility for hacking ?
2008-05-27 00:33:44 Norrin_Rrr "So if you know about Smarty template editing you can use any Smarty tag in your user modules."
2008-05-27 00:33:05 Norrin_Rrr ah okay i am at the module documentation, and its seems there are some conditionals with TW1.10 for modules but unfortunatly none for specific category
2008-05-27 00:32:56 *** franck has left #tikiwikin
2008-05-27 00:29:43 *** kiilo_ has quit IRCn
2008-05-27 00:28:34 Suprano even more if you paste in in a formular :D
2008-05-27 00:28:15 Suprano hmmm copying 4mb text slows down the pc
2008-05-27 00:28:10 Norrin_Rrr and display a menu that gather the various item of this category
2008-05-27 00:27:59 prozaq marclaporte: earlier I posted a bug to the tracker item Bugs & Wish list on dev.tikiwiki.org but how do I post to the "All Bugs" section or the "Release 110 taged bugs" ? section
2008-05-27 00:27:38 Norrin_Rrr yes
2008-05-27 00:27:30 marclaporte the goal would be to show a certain module only if current item (page, etc) is in category X ?
2008-05-27 00:26:07 prozaq eek...
2008-05-27 00:25:45 Norrin_Rrr its seems it works for feature enabled on the site but not for category (?)
2008-05-27 00:25:16 Norrin_Rrr yep i have the doc about the menu under my nose but i don't understand the section parameter
2008-05-27 00:24:39 marclaporte hi prozaq
2008-05-27 00:24:24 prozaq marclaporte: hi
2008-05-27 00:24:19 prozaq but Iäm not sure a specific category would fall under that
2008-05-27 00:23:57 prozaq it seems that you can tell a module which "section" it should appear in
2008-05-27 00:22:37 Norrin_Rrr for now 1.9.9 but 1.10 soon i hope :)
2008-05-27 00:21:20 *** marclaporte has joined #tikiwikin
2008-05-27 00:20:45 prozaq which version are you using norrin?
2008-05-27 00:18:38 Norrin_Rrr i am not sure, a module with a menu would be nice
2008-05-27 00:18:08 prozaq a menu item or a module with menus?
2008-05-27 00:17:29 Norrin_Rrr and hello everybody ;)
2008-05-27 00:16:39 Norrin_Rrr Is it possible to show a menu only when a user reach an item belonging to a given category ?
2008-05-27 00:15:24 *** Norrin_Rrr has joined #tikiwikin







Sylvie has recently added some useful code in BRANCH-1-10 so we can use categories as conditions in templates (.tpl)

[http://dev.tikiwiki.org/Hello+World#To_do_something_specific_in_a_template_ex_tiki_tpl_conditional_to_the_current_item_being_in_a_category_Ex_different_header_picture_|related info in Hello World]

Add a feature to move files in between the file system and the database

This feature:
tiki-admin.php?page=trackers
tiki-admin.php?page=fgal
tiki-admin.php?page=wikiatt

should be added here:
tiki-admin.php?page=gal

(In fact, it should be backported from 1.10) "Move images from filesystem storage to database storage"

Google changed their formula. module should now deal with:
google_ad_client = "pub-xxxxxxxx";
google_ad_slot = "02353245";
google_ad_width = 468;
google_ad_height = 15;


While we are playing here, the module should be re-organized and default should be a public service advertisement

Current Adsense module is too complicated to set-up as we can read here:
http://tikiwiki.org/Module+Adsense

There are way too many forum posts for something which should be really simple to set up:
http://tikiwiki.org/tiki-searchindex.php?highlight=adsense&where=forums

So, I suggest:

The public service advertisement should appear instead of the current "You forgot your Google ad_client number !" message. So people would know right away that the connection with Google is OK.

By default, it should be a fairly small ad so it fits nicely in a module.

And if the user is admin level (check for tiki_p_admin), then, add a link to documentation on how to set pub-xxxxxxxxxxxx and others...
http://doc.tikiwiki.org/tiki-index.php?page=Module+adsense

So, if no pub-xxx number is set, use pub-xxxxxxxxxxxx (which provides the public service advertisement) with a warning for admins.

If the admin specifically wants a public service advertisement, he can set the pub number as pub-xxxxxxxxxxxx. In which case, there should not be a warning to admins on how to set.

Finally, if the pub number is set normally (ex.: pub-1234...), no admin warning should appear.

In recent trunk installs, no module windowshading/flipping icons appear. I noticed a new check for a javascript pref in module.tpl. Is there an admin option for this?

Bugs & Wish list

Tiki 1.9.8 ships with 94 modules. (excellent)


Need a "module manager"

Module should come with a screenshot or preview.

A page listing all modules with descriptions and parameters- grouped by feature.


currently, the "user modules" and "assigned modules" titles are very non-intuitive. Should say "custom modules" and "active modules"




However, all modules are listed at all times. Module listing should check for features which are activated. It would be easier on new Tiki admins. For example, if articles are deactivated, don't show me last_articles in tiki-admin_modules.php



Admin modules does not display titles of available modules or provide easy method for selecting unused modules, such as with a listbox. The missing information is not available unless a Tiki admin has system admin permissions.



Also, all possible parameters for the current module should be listed (or picked from a drop-down)
See:
[http://doc.tikiwiki.org/Module]



Related:
Plugins admin interface
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=502

Part of IRC-Log from 20050709:

[18:48:51] luci amette: imho the quickest fix for the Admin menu would be: 1. rename "Admin home" to "Admin Sections"
[18:49:40] luci amette: 2. clicking Admin folder would bring you list with the same entries like when you expand the folder
[18:50:53] luci 3. rename "Admin mods" entry to "Mods Admin" to prevent listing it as first entry since the menu is alphabetically sorted
[18:50:57] amette luci : Yup, that sounds really clean - Admin Home should be moved to the top of the submenu then though
[18:51:08] luci sure
[18:51:36] amette Ah, just wanted to ask - yeah, alphabetical sort is bad here - I just looked at my menu and it took some time to find "Verwaltung Hauptseite" <- very much at the bottom
[18:52:12] luci "Admin Sections" sounds logical to me because we use "Sections" in title bar there already anyway
[18:52:41] luci amette: good point, that'Ä‘ why i fixed my language.php entry to "Administrace"
[18:55:06] luci ok, we can consider removing that sorting stuff
[18:55:42] amette What would be a good solution imho - It gives you e.g. the option to say "The third entry in Admin menu"
[18:55:52] luci maybe only the module one
[18:55:56] amette And you can sort options by importance!
[18:56:14] amette And I'm often confused, since my admin-account uses English and amette-account uses german
[18:56:20] luci amette: not that easy, some appear depending on fetures enabled

From here on, was discussed, that Admin Items could/should be hidden, when the corresponding feature is not activated. I'm not too sure about that now - because like that you loose the ability to customize a feature and then afterwards activate/release it.

Using 1.10cvs from the last week of October'07.
Multiple assignment of users to a group is not working. Log shows as if those users were effectively assigned to group Editors (in my case), but after that, when I refresh the list of users, those users are still only belonging to registered group, and not Editors.

However, if I assign one by one, through the key icon, they are well set to the Editors group.

http://moviments.net/intercanvisarxius/

(this is the same site as http://intercanvis.net but for testing, using latest 1.10 cvs code)

Read and tried the various methods in the various (sometimes conflicting) MultiTiki documentation. Could not figure out a path to success.

It appears that (although it was claimed otherwise on some other pages) that shell access is required for MultiTiki.

Questions that came about during attempt at integration:
(1) Is it possible to setup MultiTiki when one is on a hosted server (via FTP only)? If so, what is the process? I would be willing to write up the process if I could figure out how to do it.
(2) Which of the MultiTiki's is supported for TikiWiki3 ?
(3) Is there a web-based installer for setting up several tikiwikis on the same domain (but in different folders)?


How can I help vette the install process?

I would really like to setup an InterTiki + MultiTiki site as my coroporate intratnet. This would closely mimic the sub-web functionality in TWiki but allow for group wiki's to get their own distinct identity. At this point, TikiWiki is nearly more functional than TWiki, but the InterTiki/MultiTiki difficulties may be the deal breakers.

I installed Mysql 5 alpha to with 1.9 from the head of the branch and found this error when I tried to enter the tiki...

Warning: mysql error: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '-1' at line 1 in query:
select `permName`,`type`,`level`,`permDesc` from `users_permissions` order by `permName` desc
in C:\isense\icms\lib\tikidblib.php on line 133

Fatal error: Call to a member function on a non-object in C:\isense\icms\lib\tikidblib.php on line 151

When you load the administration page for the first time of a session, you cannot see all icons. It's like if the page was truncated.
So you need to load the administration page a second time in order to see all icons.

These 2 settings:
Use cache for external pages:
Use cache for external images:

Should be tester, better defined, and could go on the new text area admin panel

Move all admin settings which affect all text areas to this new panel.

ex.:
Tables syntax:

In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}

After a recent CVS update, the From: address of newsletter e-mails changed from the configured SenderEmail address to (apparantly) the address of the logged on user sending the newsletter. Since a changing number of users can send newsletters, it is difficult for recipients to configure their e-mail filters to accept all of them. The change caused a number of newletters to fail delivery.

To reproduce this bug:
1) Open Admin Groups Page
2) Number of Displayed Rows will default to 10
2) Change "Number of Displayed Rows" to 20
3) Hit Enter.
4) Additional Rows will display.
5) Add a Group.
6) Hit Save
7) Number of lines displayed changes back to 10.

Thanks for looking at this. dthacker.

Tiki, be default, strips all javascript from all text box entries. This is meant as a security protection.

While most of the time, this is a good thing, sometimes, it is appropriate to use this javascript. For example, an add placed in a dynamic content module.

Many times, I don't want the Orphan page feature. But I do want the list pages. Since they now use the same option (feature_listPages), it's annoying.

Let's create feature_OrphanPages (off on a clean install). Menu items will need an update.

All plugins are on by default. I may or may not want that.

I think we should have an admin panel which lists the plugins which are installed on the server. The admin can then activate as needed.




Related:
WYSIWYCA for module administration
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1294

On a fresh install, I enabled image galleries without realizing that neither GD or ImageMagick libraries had been installed. I was able to create a gallery and attempt an upload of images, which failed with a vague "Upload can not be processed". It was only after visiting the second admin screen (http://localhost/tiki-admin.php?page=gal) that I was able to see that the proper libraries were not installed.

This code in db/tiki_1.8to1.9.sql used in upgrade script, is causing duplicate menu items.

{img src=images/code.png}%%% {CODE()} INSERT IGNORE INTO tiki_menu_options (menuId,type,name,url,position,section,perm,groupname) VALUES (42,'o','Mobile','tiki-mobile.php',37,'feature_mobile','','');
{CODE}

{img src=images/code.png}%%% {CODE()} INSERT INTO tiki_menu_options (menuId,type,name,url,position,section,perm,groupname) VALUES (42,'o','Users map','tiki-gmap_usermap.php',36,'feature_gmap','',''); {CODE}


Duplicates also happen for 187, and 188, 900, 1191, 1235, and in a minor way, 189, 780,

See screenshot attached.

The login settings page should be refactored to eliminate the presentation of unneeded configuration options.

Some desktop applications have a way to report errors. This would help us know which bugs happen the most often. For example, we could check for sql errors or hard php errors.

Of course, this would be totally optional. Even better would be for people to be able to share their Tiki configuration (anonymously) at the same time so maybe we could detect that bug X only happens with a specific combination of on/off settings.

Firefox talkback:
http://www.mozilla.org/support/firefox/faq#talkback

Of course, knowing about all the bugs doesn't automagically fix them. However, some are super easy to fix if we notice them, like this one:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1399

The same way TikiWiki community members can vote on bugs and feature request, the "crowdsourcing" of error reporting will make it easier to distinguish the most common issues. It would also be a hint that some very rarely reported issues are probably related to a rare server configuration.

The same way I invest to address the most voted on features/bugs, I would do the same here. Specifically, I would like to see reports of the top-10 Postgres-related errors. I am sure these are easy to fix and could make TikiWiki more useful to Postgres users. I would like to use Tiki on Postgres eventually.

http://yro.slashdot.org/article.pl?sid=09/01/24/1938224

Copied some suggestion I just throwed on irc..., after fighting each time on some of my production sites to manually send messages to many users which are kind of lost some times at the beggining of their participation in a tiki-site-powered community.

{QUOTE()}
(11:37:39) xavi: I was just wondering about a new and easy improvement of the registration process of new users to a community sit eusing tiki
(11:38:07) xavi: just through allowing an admin to add acustomized welcome message to new users successfully registered to the site...
(11:38:29) xavi: ... with the text and links he might need to tell to new users....
(11:38:52) xavi: ...in a similar way to what mailman does for the welcome message to new users...
(11:39:48) xavi: ...I imagine a simple text area, like site identity does, where the admin can write any simple text (with or without wiki markup? like the newsletter feature does/allows)...
(11:40:45) xavi: ...so that the admin can set that message easily (without manualy searching for the appropiate template to hack through ftp)...
(11:42:48) xavi: ..and the the new user, can review the infos and tips that he/she needs to know on that site: "now you can: # watch that forum where that important thing is discussed.... #join that newsletter/blog/articlefeature to be up to date about news from that community, #review and/or subscribe to that tracker..., ...
(11:45:22) xavi: oh well, I can't code php+mysql myself (yet, at least ;-) ), but I guess that this shouldn't be that difficult nor time consuming to an experienced coder, provided that that person agrees on that this feature is "low hanging fruit" to improve the experience of newcomers to a community, through improving the communication while the first steps of that person in the community site...
{QUOTE}

This could also be important for ((Workspaces)), and ((Organic Groups)). So that, not just to register (join the registered group), but as a customized message per group, so that, when joining a new group (at registration time, or later on through the subscribe groups plugin), you get the specific message with hints, links and remindings of things adapted for that group.

New users are linking to:

tiki-assignuser.php?assign_user=


It should be:

tiki-user_information.php?view_user=

for users that don't have tiki_p_admin_users

A lot of people who install this aren't doing it via Fantastico and trying to change email settings to suit your hosting provider is a pain. Editing the php.ini isn't always wise either because what works for one app will break another. I know that you can copy the php.ini to the directory, but that's something of a security risk. There's a reason that the default php.ini is stored outside the web root directory.

I know that I see a lot of users posting on the TikiWiki forums with questions about configuring SMTP.

We can now use the login box but it's not very obvious. There should be an icon / button somewere in tiki-adminusers.php

Just after creating a user or adding to a group would be a good time to Switch User and see what (s)he sees.

This would avoid this type of issue:
http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=6&comments_parentId=21274

Maybe at each release, we could add one test of the DB to see if the most recent sql additions were done.


phplist does this well. Once click and your DB is in the right format.

tiki-admin.php?page=gal tells me if GD or Imagick is installed. Nice.

But sometimes, it's installed, but it doesn't work as it should. To rule out that the problem is with Tiki, here is an example of a simple php to test GD in real life. It would be nice to add to tiki-admin.php?page=gal

{img src=images/code.png}%%% {CODE()}
<?php
header("Content-type: image/png");
$im = @imagecreate(110, 20)
or die("Cannot Initialize new GD image stream");
$background_color = imagecolorallocate($im, 0, 0, 0);
$text_color = imagecolorallocate($im, 233, 14, 91);
imagestring($im, 1, 5, 5, "A Simple Text String", $text_color);
imagepng($im);
imagedestroy($im);
?>
{CODE}

I think what's needed is a Gallery of "Tiki Sites in a Box". In other words, Tiki sites that are preconfigured to meet a particular kind of needs. The needs should be defined not in terms of features, but in terms of GOALS of the end user or organisation.

This could be a list of descriptions like this:

- I want a site to enable collaboration inside my organisation.
- I want a site to broadcast my ideas to the world and allow people to add to them and comment on them.
- I want a site that will act as an open knowledge base on a particular topic.
- etc...

Each of these could point to an example which would be a "fake" site that could act as a sandbox. People could go to this fake site, play around with it (but not reconfigure it), to see if it's what they are looking for.

This would allow easy single click configuration of Tiki. The user would simply click on one of the items in the Gallery, and the Tiki site would be configured accordingly.

One issue is: what happens if the user choose wrong and later wants to switch to a different model? I guess if no content has been created in the site it's fine, but what if content has already been created and that content is somewhat incompatible with the new model that the user is choosing?


Related:
*[tiki-view_tracker_item.php?itemId=1513|OpenSourceCMS type demo to test/develop and show off profiles]
*[http://info.tikiwiki.org/Use+Cases|Use Cases]

__Moving discussion of this wish to ((Profile Manager))__

There are some settings to
#force a user to validate an email addresses by clikcing a link
#for admins to need to click a link in an email to approve a new account.

But what if emails aren't getting through or to go faster?

An admin should be able to validate an account manually








__Duplicate__
{wish id=1710}

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

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

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.

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.

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.

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.

So we know which admin created a login...


We currently have a log entry when a user is assigned to a group, but not when he is unassigned.

Also, we have:
unassigned perm tiki_p_broadcast from group admin

but not:
assigned perm tiki_p_broadcast from group admin



Maybe adding failed login attempts would be good too...

Users can have several status:
*new account (needs to be validated)
*normal account.

Maybe we will want more in the future (ex.: suspended)

It would be good for the admin to be able to see the status in tiki-adminusers.php, filter by type and change/override the status. Ex.: a user never received the validation email because of spam filter.

I have no idea what version I have.

Hello,

This flaw was found in the search page "TIKI WIKI," which allows XSS attacks when a User is an argument in the variable "words" with a code for XSS. The failure occurs on the search page when it tries to recover the value passed in the variable "words", the server tries to redirect to tags <a> some links in the value paced past. But the server does not check the value and allows the execution of JavaScript code with a code like this.

http://info.tiki.org/tiki-searchresults.php?searchLang=en&words=111%22%20onmouseout=%22alert%28document.cookie%29;//&search=Go


Vulnerable code in HTML code:
<span class="button"><a href="http://doc.tiki.org/tiki-searchresults.php?words=111" onmouseout="alert(document.cookie);//&where=wiki">Tiki Documentation</a></span> or
<span class="button"><a href="http://www.google.com/search?q=tikiwiki+111" onmouseout="alert(document.cookie);//">Search all over the Web with Google</a></span> or

<span class="button"><a href="http://www.google.com/search?q=site:tiki.org 111" onmouseout="alert(document.cookie);//">Search *.tiki.org with Google</a></span>

I could see how we can add an event "onmouseout" tag for <a> that allows javascript code execution.

Kind Regards,
Mario Gomes.

When the system (in this case was a Linux box) runs out of disk space, a Tiki user cannot login. Basically, the user is sent back to the home page. In other words, it looks like the user has authenticated, but is not logged in. So it looks like a PHP session issue. It could well be.

If the user enters a wrong password, a wrong password message is seen.

It would be nice if Tiki could detect that the disk space is low and alert admin users, especially during install. Low priority of course, but still nice to have.

MoinMoin example:
{THUMB(id=29, url="tiki-browse_image.php?imageId=29")}{THUMB}

You can get to help easily enough, but it's kind of hard to find the "wishlist" page.

Please see ((workspace roadmap))

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

Contributors