I have found that, if I want to find something on tw.o sites, I should disregard TW's search feature and use Dogpile to look things up. The TW search capability is so weak that it is almost "a missing feature." At the very least, "TermA TermB" searches should be "termA AND termB" not "termA OR termB." The plus/minus markers are fine if you're in the know, but they don't work well either. Using the category/group filters renders a whole different set of answers; not GOOD answers, just different. Without those filters, unauthorized users see parts of pages they are not supposed to see at all. Not a missing feature, a broken feature.
Gosh, I hate to be so negative.
Bill
This page caught my eye while I was looking for something else and I htought I might say something regarding marclaporte's comments about and API and application integration. I have long considered trying to integrate several applications into TikiWiki. One approach is to modify existing application to be included through the "mods" process. The biggest hurdle I see is to replace the existing applications authentication with the Tiki authentication creating a single sign on for use of the integrated application. This problem and the need to have access to the authorizations structure once authenticated or even to understand Tiki state requires a well defined API or at least documentation of what variables and functions are used to achieve these tasks and how they are used. Also of great use would be a definition of baseline CSS selectors to assist bringing the application look and feel in line to the Tiki once integrated.
Example applications:
*Outreach Project Tool (OPT)
*OSCommerce
*WebCalendar (I do realize Tiki already has calendaring)
Hi Vranicoff,
Thanks for your message.
About Single Sign On / shared user base: TikiWiki supports about 10 external authentication services (LDAP, Active Directory, PAM, Auth, HTTP, CAS, IMAP, Shibboleth, OpenID, etc) so the simplest is that the other application supports one of these and just use that.
Tiki also has InterTiki which permits sharing credentials (groups, user settings, etc) amongst TikiWiki powered sites. This could be implemented in the another app. TikiWiki can be either the slave or the master (depending on where you want the master userbase to be)
Look & feel: it could be pretty tricky depending to which point the other app is themeable or not. Since TikiWiki is a CMS, it's designed to be themeable. This may not be the case with genealogy software for example. The shopping carts will be themeable though.
WebCalendar and Outreach Project Tool (OPT) -> IMHO, too much feature overlap to make it worth it. It's less work to add/fix whatever is missing in TikiWiki and/or to create data migration tools than to try to maintain some glueware.
A bridge with OSCommerce or ZenCart would be most welcome! This is a totally different feature-set.
But in any case, do these apps integrate well with any existing CMS/Groupware/frameworks? I mean, is there an example that OSCommerce integrates with Postnuke because of a "well-defined API for building applications on top of, or integrating application". A good example is: CiviCRM has a port for Joomla and another for Drupal. What I want to hear is that "ZenCart" or "OSCommerce" (or something which brings totally new functionality to TikiWiki) has glueware with Drupal/Postnuke/Xoops/Joomla/etc and if we did things differently, we could too.
I am not against the principle. I just want to make sure that any time invested here will be worth it. On the wishlist, we have nearly 300 open or pending feature requests and over 300 open or pending bugs.
Best regards,
M 😉
Task Juggler is a flat file based project management system that currently has a QT interface in KDE. Would it be candidate for a tiki based interface?
dthacker