Category: 1.9.x

Does anyone know of a migration script / strategy for moving tiki forums
from one Tiki to another?

I want to move this Galaxia forum:
http://tikiwiki.org/tiki-view_forum.php?forumId=11
to:
http://workflow.tikiwiki.org/

The themes forum
http://tikiwiki.org/tiki-view_forum.php?forumId=14
to:
http://themes.tikiwiki.org/

And the Multilingual/i18n <tiki-view_forum.php?forumId=13> forum:
http://tikiwiki.org/tiki-view_forum.php?forumId=13
http://tikiwiki.org/tiki-view_forum.php?forumId=10
http://tikiwiki.org/tiki-view_forum.php?forumId=15
http://tikiwiki.org/tiki-view_forum.php?forumId=7
http://tikiwiki.org/tiki-view_forum.php?forumId=8
http://tikiwiki.org/tiki-view_forum.php?forumId=9
http://tikiwiki.org/tiki-view_forum.php?forumId=16
to an eventual i18n.tikiwiki.org

When one hits the preview key on a heavily-populated forum, the preview gets put all the way down at the bottom of the pane. Despite the fact that the active area in the pane is at the bottom, after the preview action, the screen will be positioned at the top. At best this involves a lot of unnecessary scrolling; at worst this can be very confusing to the user.

Say I find a nice/useful forum post and I want to email it to someone, it is very long for no (apparent) good reason.

In the "last forum posts" module, the URL is like this: (which is OK)
http://doc.tikiwiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=438

But if I find that same link from here:
http://doc.tikiwiki.org/tiki-view_forum.php?forumId=1

It is:
http://doc.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=438&topics_threshold=0&topics_offset=0&topics_sort_mode=commentDate_desc&topics_find=&forumId=1

Imagine you have 20 forums (>10 is common case in some educational scenarios).

Forums list indicates 2 pages of forums list.
Then you select the 15 first forums to a categ. with restrictive permissions, so that normal users don't have the perm. to see them. The last 5 are supposed to be seen by users.
The first 15 are in a section called "Salut i Medi Ambient" (without quotes), and the last 5 are in a section called "Salut i Medi Ambient 2005-06"
Those last 5 are not listed in the first page of the forum list, which appears to be empty, and the users see as if there were no forums (they are in the second page of the forums list).

This should be modified so that the available forums to a user are listed in the first page of forums list.

Using 1.10cvs.

In forums:

Topics are first level (discussion starters)
Message are replies. This uses the same code as comments (used in wiki pages, image gallery, etc) and has threading.

In 1.9.x, an admin can move a reply to another topic. This is of limited use. It is as if the admin decides "Your answer is more suited to another question"...

What would be much more useful:
To change a topic (and all threaded replies) to another forum.

So an admin could start with one general forum, and create more specific forums if/when the volume of messages justifies it. Right now, the admin has to plan all these forums in advance. And a list of empty forums is not very inviting...

If someone starts a thread in the wrong forum, it should be easy to correct.

When forwarding messages to a pop "mail-in" account, the forum title is prefixed with "FW: "

I have a TikliWIki as startup in one of two frames. The other frame has a number of links that are supposed to open in the Tikiframe. But if tiki-index.php has been opened in that frame, subsequent documents opens i new windows (in IE) (as if target=_blank had been used) och new tabs (in FF).
If index.php is the only document that has been opened (when the mysql-connection is broken) everything works, but as soon as I try tiki-index.php, the problem comes back.

CLIP from my whining about why the search doesn’t work in TW.



#1 - why isn’t there a proper SEARCH ?

- to start this off can we at least agree on a couple things:
o standard search for - RED BALL would search on RED AND BALL
o TW does RED OR BALL – which is WRONG!!

- BASIC search should be capable of:
o RED BALL = RED AND BALL
o “red ball” = only match “red ball” as quoted
o and then, maybe RED or BALL = RED OR BALL


with a little more digging and some input from marclaporte, redflow and mose I think I have figured out the problem:

- TW supports the concept of FULL TEXT SEARCH (FT)
- this allows user to (from example above) do a search like “+red +ball” to achieve “red AND ball”.
- but these is a bug in concept in searchlib - function _find()
- if FT is set then _FIND does the right thing by doing a MATCH AGAINST sql query
- HOWEVER – if it doesn’t find any results it ALSO will do a simple (i.e. non-FT) search
o in concept this is silly since it defeats whole point of doing FT in the first place
o also, it generates an sql error because for simple search a REGEXP query is done which will choke on the + signs in the search string

The full text search module should provide means to determine what operators work with it. Perhaps a large tooltip or a link to an "advanced search" page. Syntax for the module is [http://tikiwiki.org/tiki-index.php?page=FullTextSearch|here.]

I'm not setup as a developer right now and anyway don't know enough to know which branch is which... Perhaps someone else can get onto this? Simple fix. Obvious error.

tikilib.php, 1.9 CVS HEAD line 3528, revision 1.656

if ($is_categorized && !empty($categperm) && $$categperm != 'y') {
return (FALSE);
}

Use this URL: http://www.flylac.org/tiki-galleries.php

Then hover the mouse over any of the galleries, the galleryId property is not set, this is an example shortcut:

http://www.flylac.org/tiki-browse_gallery.php?galleryId=

The galleryId is missing: ...browse_gallery.php?galleryId=

((doc:PluginCode)) doesn't show colors for php code, as it should according to doc page:
[http://doc.tikiwiki.org/PluginCode]
Tried with param colors=>php or colors=>phpcode:
{CODE()}
{CODE(colors=>php)}
/** Return system defined temporary directory.
* In Unix, this is usually /tmp
* In Windows, this is usually c:\windows\temp or c:\winnt\temp
* \static
*/
function tempdir() {
static $tempdir;
<b>$tempdir = '../tmp';</b>
<b>/*</b> if (!$tempdir) {
$tempfile = tempnam(false,'');
$tempdir = dirname($tempfile);
@unlink($tempfile);
} <b>*/</b>
return $tempdir;
}
}
{CODE}
{CODE}

And it returned:
{CODE(colors=>php)}
/** Return system defined temporary directory.
* In Unix, this is usually /tmp
* In Windows, this is usually c:\windows\temp or c:\winnt\temp
* \static
*/
function tempdir() {
static $tempdir;
$tempdir = '../tmp';
/* if (!$tempdir) {
$tempfile = tempnam(false,'');
$tempdir = dirname($tempfile);
@unlink($tempfile);
} */
return $tempdir;
}

}
{CODE}

---
Update: RFE for plugincode:
Why not using "wrap=>1" as default param instead as "wrap=>0"?

To reproduce:

1- visit as anonymous:
http://doc.tikiwiki.org/tiki-editpage.php?page=dhsgfkjsd&quickedit=edit

2- Click login
http://doc.tikiwiki.org/tiki-login_scr.php

and login

3- I am sent to:
http://doc.tikiwiki.org/tiki-editpage.php

instead of the page I was trying to edit:
http://doc.tikiwiki.org/tiki-editpage.php?page=dhsgfkjsd&quickedit=edit

Currently, when you create a process and initiate an instance, the user is prompted to name the instance, presumably as some way they can remember it in their own jumble of process instances (or tickets, as I like to call them).

I would like the admin to have the ability of eliminating that need on a per-process basis, and instead automatically naming the instance with the instance ID. This should give people the flexibility, if they want, to allow the user to create a memorable moniker, or allow it to traditionally take on a "ticket number" type of designation.

It really depends on the environment that the workflow is being used in. In a high-volume workplace, it may be best to use a ticketing style of identification. In a smaller-volume workplace, I can definitely see how custom names would be beneficial.

If I get time, I'll work on this.

on tiki-gmap-locator.php the check of $p['x'] > -90
should have been $p['x'] > -180

Same with the positive values.
Otherwise, you cannot choose places in China, Australia, etc.

The Google Map key issued for an nternationalized domain name is not accepted by the system with an pop up error saying like "the key is issued for another site"

The following patch adds negated group support to TikiWiki. Using this patch, you can choose to hide modules from users that ''are'' in a given group, by simply specifying the group name as !Group.

The patch is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website. I'll see if I can come up with some screenshots shortly.

Group plugin is very cool to put conditional content on a wiki page.

However, it is only an if. There is no if/else.


Say I want to show a content X to people in a group and content Y to everyone else.

Maybe we could have a new parameter?: notgroups

{CODE()}
{GROUP(groups=>Anonymous)}text for anon{GROUP}
{CODE}

{CODE()}
{GROUP(groups=>notgroups=>Anonymous)}text for the others{GROUP}
{CODE}

I used to broadcast emails to several groups (editors,
members, etc).

Without any change from my side i can now (cvs a
week ago) only broadcast to registered or all (as set un
perm).

Other groups have diseapered.

templates/styles/neat/tiki-top_bar.tpl
templates/styles/simple/tiki-top_bar.tpl

both have a hard coded version i v1.9DR4 (CVS) -Sirius-
Either update it or even better have a variable to show the actual version.

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

Help System is not listed as a feature for Tiki Tracks. Is it the same as WebHelp? If so, then one or the other should be renamed for consistency

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

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.