Brainstorming page for how to improve efficiency of team communications

Tavi to tiki conversion

gbuonfiglio writes:

  • doesn't tiki have "import from alien wiki" feature ?
gbuonfiglio: No, it doesn't, but it has other migration scripts for popular software like Postnuke that we can use to create a Tavi2Tiki conversion script.

Some links:

[General 2TikiWiki conversion information]

[PostNuke2TikiWiki conversion scripts]

But I guess the most promising is [html2wiki] perl script that converts from html to several wiki formats, including TikiWiki?.

It can read from standard input so I'm thinking about a script that:

The pages table is easy to convert:

<not-available> = page_id (sequential for each page)


This code is used by the wiki search. It is terrible, and slow:

SELECT t1.title, t1.body, t1.version FROM efi_pages AS t1, ( SELECT title, max(version) AS maxv FROM efi_pages GR
OUP BY title ) AS t2 WHERE t1.title = t2.title AND t1.version = t2.maxv    AND ( t1.title LIKE '%searchterms%' OR t1.body LIKE '%MembersPage/JanSaenen%' )

This is sharkey's hint:

SELECT t1.title, t1.body, t1.version
   efi_pages AS t1,
   ( SELECT title, max(version) AS maxv FROM efi_pages GROUP BY title ) 
AS t2
WHERE t1.title = t2.title
   AND t1.version = t2.maxv
   AND ( title LIKE '%trigg%' OR body LIKE '%trigg%' )


Critical - webpage header

Our site design is old, outdated. Brainstorming.


Revert attack - automatically

Turing test related - reopened

Turing test - still a bit annoying

Other wishes

The big question: how to store info?

There are some information that must be stored in CVS (or SVN), some that must go to ofbiz, but for some information it is not clear where would be best (most efficient).

In many case, the format (of human readable info) is a question. Information should be organized by content, not by layout. Major goal is that anyone can find the interesting info relatively fast. This requires an established index and easy maintenance of content.

Note that email is not sufficient to store information, it's just useful for a nudge.

Now looking for wiki engines that have CVS or SVN backend (or provide CVS or SVN interface to the page-set) tools that work on local files:

When I last looked at wiki engines, I wasn't sure of what's most important.

Having used many systems since, now confident about the necessity of CVS/SVN interface.

Have to review wiki engines, in this perspective.

clean up the rest sometime... - note: not just delete, that does not solve the discussed issues.

target audience of change

As our wiki traffic increases, people want to filter what they read and what they skip.

The good way is to have explicite information of the target audience - in some cases.

Which wiki has this feature?

a clumsy workaround would be offchannel notification: email groups (a few more than what we have now) that are manually notified for major changes - with the link included. Ofbiz workeffort will be the perfect way to keep such meta-info noise out of the wiki, but still available.

Search engine proposals

To find information in wiki easy, we need some conventions:

Search for Ionsense first (verified there is an ionsense page).

Broken google links, like ionsense site:www.vems.hu

were caused by a change in CGI location (a /wiki/ prefix was added). I'm sure he had a good reason because this broke all external links. The google links fixed themselves by now, but the other external links will become broken.

Also searched on wiki itself and got the following results:

Find ionsense

So we obviously have a problem. the Ionsense page is about 20th down on the list. the exact match for the title and its child pages should be first. maybe we should try to glom on google? set it up so that the search is effective?

See also