Category: 1.9.x

I am using tikiwiki for a project at work, and one of the features we needed was the "mail-in" forum posting. The way we use this is a sales rep will e-mail an issue to a PDL. One of the e-mail addresses in the PDL is the pop account for one of the forums for our site. The site moderator reads the new "post" (e-mail) and decides which forum the discussion belongs in and moves the post to the "correct" forum.

The problem is that once moved, replies via the PDL do not follow the original thread (to the moved forum). The best case is that they end up in the "mail-in" forum location.

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.

It's a little annoying that when I want to post to my blog, and click on the post link, I am given a pull-down menu of blogs, all but one of which is not mine. Any reason not to filter this list to the set of blogs that I can post to? And, even better, jump to mine if there is only one such blog?

The e-mail notifications of watches (wiki, tracker, article, etc.) are sent out when changes are made. This means that the user submitting the change has to wait for the PHP-Code to send out all the mails before he can continue browsing. This is annoying and even...

... more evil is that with thousands of users to notify of the change the PHP-script will tend to time out and not all the notifications are sent!

One possibility would be to set the timeout higher, but that isn't really a solution at all. So the sending of mails needs to happen asynchronously. One simple solution would be to have a daemon running on the same system, which sends out the mails and the PHP-script just notifies the daemon of what to do. This would make installation a lot harder though and can't really be a desired solution.

Any possibilities to solve this in PHP directly?

Galaxia supports assigning a name to a process instance, and stores this value in the galaxia_instances table in the name field. This can be assigned through the API using the setName() method of the Instance class. (It is also assigned from the Javascript popup window which opens when you select a Start activity from the User Activities page)

However, there are many places (for example, User Instances, and Monitor Workitems) where this value is not displayed, only a bare (and meaningless, from a user's perspective) process ID number.

This is a clear usability obstacle.

I would like the java irc client pjirc to use grab the usernames from the tikiwiki database to log the people in when they want to use the irc channel. it is very similar to the mod for Simple machine forums http://pjirc.dtmdotexe.com/index.php?option=com_smf&Itemid=26. It will only work for registered users and does not need to work with wiki markup or group permissions (works as long as you are logged in). You do need a php script to input the irc server/channel to connect to.

Illori

Could someone please make the fields this tracker uses available to the community, please? (easily done, since there's an export/import feature!)

I'm trying to create a support web site, so obviously need much the same thing as this site. Trackers are quite a learning curve, so a couple of good examples would be really useful!

If someone does this, I'll add an export of the fields I end up using and make them available too (I've got a couple of other tracker apps up my sleeve too).

Cheers!

Too many people are having issues:

[http://tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|tikiwiki.org open_basedir issues]
[http://dev.tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|dev open_basedir issues]
[http://doc.tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|doc open_basedir issues]


We need someone who is strong with server administration in a shared hosting context to solve all these issues once and for all.

[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=26696|maybe a hint to the solution?]

and add in the menu like the other features.

[15:41]<ohertel> marc, what's tiki mobile? :)
[15:42]<damian> the HAWHAW interface
[15:42]<damian> for WAP, PDA, and VoiceTiki browsing
[15:42]<marclaporte> de.tikiwiki.org/tiki-mobile.php
[15:43]<marclaporte> you have this on without you knowing
[15:43] *** marclaporte sets topic for #tikiwiki : http://dev.tikiwiki.org/tracker5 For the next 1-2 hours, please keep all discussions focused on 1.9.0
[15:43]<ohertel> ah that one. :)
[15:43]<ohertel> marclaporte: so what you want for it? perms?
[15:44]<marclaporte> naw, just on / off
[15:44]<marclaporte> from main admin panel
[15:44]<ohertel> is only 1 entry in the prefs table
[15:44]<ohertel> no biggie
[15:44]<marclaporte> perfect!
[15:44]<ohertel> so it needs no read db change
[15:45]<ohertel> just a feature_mobile = y/n :)
[15:45] *** ohertel doing update and starting debugger.
[15:45]<marclaporte> in theory default should be on be y by default to respect 3 rules, but since it isvery specialized, you can put n by default. Your choice!
[15:46]<damian> respect the rules.
[15:46]<damian> it causes less hassle for everyone that way
[15:46]<cpw> I'm going to submit what I have for my Japanese translations then
[15:46]<ohertel> we switch it off and write that to the release notes.

When going to Admin mods (tiki-mods.php) on a new install, make it report the directory name when the mods directory hasn't been created or lacks correct permissions.

The error reported asks to run ./setup.sh but is not specific about the directory affected here. This would be helpful to manually fix the individual directory instead of running ./setup.sh (which may not be possible in some situations like FTP installs).

When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.

I initially reported the bug as if it happened only when you had more than 10 groups, and wanted to assign the users to a group greateer than the 10th postition. Now I've realized that it also fails for any group in the list (also for one of the groups within the first 10 listed): the selection of users is lost, thus no user is assigned to the group you select.
:-/

----
To reproduce the bug:
You need to have more than 10 groups defined in the Tiki.
And also several users (+100 in my case)

From admin users menu:
* Select several users (in my case, I selected to view 20, ordered by last login)
* click on manage groups assignments

^
__GROUP PART__
If the group you want to assign them to is not in the list of the first ten (for instance, it's the eleventh in the list alphabetically ordered), then you cannot select that group for those users.
If you try to go to next page of groups (I guess), then the selection of users is lost.
Using 1.9.2.
-----
This bit was fixed by sylvie last week. Xavi (31/01/06)
^
Still buggy:
^
__USERS PART__
To reproduce:
Reorder the list of users by any field so that you get some users in the list that where not seen at the default view of users (that's a __key point __to reproduce the bug).

Select some of those users, to assign them to a group. After I click on submit button (with "manage group assignments" selected), then the page is loaded with the default ordering, so that those users are not listed in the page. If I select then the group to have them assigned to, and submit, the users are not assigned to that group.

However, if I restart the process, but request to show 1000 users (what ever number, but ensure you list ALL of them). Reorder again users (last connected, for instance). Then select some of them. Click to "manage group assignments), and then, the page will loose the ordering, but at least you'll be able to see your users among the long list, and tehy keep the box toggled on (so that __selection is not lost!__). In this case, assigning to a group worked!

The bug must be somehow related to the registers that are ot selected to be shown, even if they are still selected to be assigned to the group.
Hope this helps to fix the bug. Xavi 31/01/06
---
This second part was fixed by sylvie after the report, later on the same 31/01/06...,
at tiki-adminusers.tpl ^

This manual time / date selection (code below) should be optional off

__Sorry, code plugin doesn't work so below looks weird...__

{CODE()}
<input type="text" name="start_freeform" value="{$start_freeform}">
<a {popup text="{tr}Format: mm/dd/yyyy hh:mm<br />...}{/tr} {tr}See strtotime php function{/tr}"}><img src="img/icons/help.gif" border="0" height="16" width="16" alt='{tr}help{/tr}'></a>
{tr}or{/tr}

<input type="text" name="end_freeform" value="{$end_freeform}">
<a {popup text="{tr}Format: mm/dd/yyy hh:mm<br />...}{/tr} {tr}See strtotime php function{/tr}"}><img src="img/icons/help.gif" border="0" height="16" width="16" alt='{tr}help{/tr}'></a>
{tr}or{/tr}
{CODE}

when editing fields in a tracker the option "Field is mandatory?"
does not work, when I check it, it has no effect and one can leave that field empty.

amette: I just changed the subject - "Bug with trackers" doesn't tell anything

For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]

The menu cache can't create the directory at /templates_c, when the user loged has a lot of assigned groups. The name of the directory are the concatenation of the groups names.

When "site menu bar" is selected under "site identity features", and a menu is specified in the "tiki-top_bar.tpl" file, as below:


{if $feature_phplayers eq 'y' and $feature_siteidentity eq 'y' and $feature_sitemenu eq 'y'}
<br><br>
{phplayers id=44 type=horiz}
{/if}


If the menu does not have any options that are permitted by the current user (no sections to display - prior to loggin in to site, for example), the system crashes because of an empty string.

To recover it is necessary to manually edit the tiki database to add a menu section that has no permission requirements.

In the example above, menu id 44 has no sections or options that are viewable by unregistered users. When the site is entered, tiki halts because of an empty string, apparently because there is no menu selection possible for the user (not logged in yet.)

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"

I think this feature refers to the small calendar that can appear in a left or right module. The help link currently points to the calendar page, which only describes the JS navigation calendar.

Tiki login page wrongfully increments tiki_pageviews hit count

When a tracker was created, you can't afterwards switch the option "Use "explicit" names in the mirror table" on or off.

You get a lot of database errors. Best to try out and see yourself. Things get worse, when there are already fields defined in the tracker. Then the tracker is completely lost. Without any fields defined, you can still access and use the tracker - you just get errors in the top-bar

UPDATE: Switching back solves the problem - errors disappear and you can access the tracker again

If I timeout a session, it tells men:
"You have mistyped the anti-bot verification code; please try again."


It should be something else.

header.tpl should contain something like below for trackers.

{if $feature_directory eq 'y' and $rss_directories eq 'y'}
<link rel="alternate" type="application/xml" title="{tr}RSS Directories{/tr}" href="tiki-directories_rss.php?ver={$rssfeed_default_version}" />
{/if}

After upgrading 1.9.4 to 1.9.5, a search entire site returns the following error. I looked in db/fulltext.sql and didn't see a create fulltext index statement for tracker. What tables/columns should be indexed?

~pp~
in /home/lampp/htdocs/kniki/lib/tikidblib.php on line 134

Context:
File /kniki/tiki-searchresults.php
Url ///kniki/tiki-searchresults.php?highlight=draw&where=pages&search=go
Query:
SELECT ttif.`itemId` AS name, LEFT(tt.`name`, 240) AS data, tt.`trackerId` AS hits,
tti.`lastModif` AS lastModif, tti.`itemId` AS pageName,tti.`itemId` AS id1,1 AS id2,
MATCH(`value`) AGAINST ('draw') AS relevance FROM `tiki_tracker_item_fields` ttif LEFT
JOIN `tiki_tracker_items` tti ON (ttif.`itemId`=tti.`itemId`) LEFT JOIN `tiki_trackers`
tt ON (tti.`trackerId`= tt.`trackerId`) LEFT JOIN `tiki_tracker_fields` ttf ON
(ttf.`fieldId`= ttif.`fieldId`) WHERE ttf.`isSearchable` = "y" AND MATCH(`value`)
AGAINST ('draw') ORDER BY relevance desc, tt.`trackerId`

Values:
Message:
Error Message Can't find FULLTEXT index matching the column list
~/pp~

I tried the mod blogroll with an example opml file from wikipedia, and the rss icons doesn't link to the expected mp3 but to the same url as the url of the browser in tiki (tiki-list_file_gallery.php?galleryId=1, tiki-admin_modules.php, ...)

This happened with this blogroll:
[http://static.userland.com/gems/radiodiscuss/playlist.opml]

The one I used for documentation. After fixing the problem, if so, please, check documentation page to see if it's correct (I didn't understand that much about the whole thing myself ...):
[http://doc.tikiwiki.org/Mod+blogroll]


Moreover, with this other opml file:
[http://www.scripting.com/feeds/top100.opml]

The rss icons point to xml files, but no text is shown between the number of the item and the rss icon. (error). See attached image to this tracker item.