Category: 4.x

It would be nice to add autocomplete for "Find" text boxes for the seach module, header search and advanced seach features.

many x.tw.o sites would benefit from that, for instance...

(I add this request here after Jonnyb explicitly asked me to suggest him places where atuocomplete would be adequate (:biggrin:)
)

This tracker item could not be found

Usability issue, but not so much a bug as feature design:

If the tag cloud is large in tiki-browse_freetags.php, search results are not immediately apparent on the screen. The user has to scroll down past the cloud to see the results, which is not necessarily obvious to new and/or less savvy users.

Ideally, the beginning of the search results should be displayed near the top of the page, but with a portion of the tag cloud still visible for further search filtering. The tag cloud could automatically collapse, with a large obvious control for expanding it again, or it could be positioned side-by-side with the results. Those are the only two solutions coming to mind.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

Some users don't want to understand the difference between "Page Name" and Link when creating an internal link.

This attached patch makes the Page Name field automatically fill in whenever the Link field is changed. The patch was made against tw 4.1.

I think it should be up for debate if both these fields are necessary. Many users of the WYSIWYG feature may be new to the concept of creating links. Less is simpler, and I vote for removing one of these fields.

P.S. Sorry about spamming the mailinglist with this request. Next time I will only submit patch here.

{syntax type="tiki" editor="plain"}
Hello,

!The basic problem
The function that are called from external should be declared "public static";
Why : because they are used in http request and href definition.

!Consequences
Often the navigator hangs on the babelfish request http://... babelfish
It can be necessary to restart the computer.


!Solution

public static function host

public static function url


trebly 04/28/2010 3h33 Paris

I have a 3.3 Tiki Application with a File Gallery configured to store files in the MySQL database. It IS possible to upload zip files and unzip them during the upload. Very useful!

I'm testing a 4.0 instance of the same application, and now the "batch upload" feature does not upload and unzip *.zip files.

I noticed the following comment in the Tiki docs....

~~#f00:"Note that you can use the Batch uploads only when you don't use the database to store the content of the files!"~~

Was some functionality taken away?! I sure miss it.

If I change to storing files in a directory (instead of the DB),
will that also mean the loss of full-text search capabilities?

I want to enable comments on wiki pages.

I have two options right now, both have advantages and disadvantages.

Enabling comments on pages

* Pros
o Easy to configure
o Comments are visible directly on the page
* Cons
o No way for people to monitor all posts on the site. Often people post a comment on a a page and never get feedback.


Associating a discussion forum thread to each page

* Pros
o Everyone on the site gets to see every posting that's made on any page. Increases the likelyhood that someone will respond to a post.
* Cons
o More difficult to configure.
o Postings are not visible directly on the page.

It would be nice if we could have the best of both.

What I would like is something where:

* A discussion forum for the wiki can be enabled at a single click of the mouse.
* This single click of mouse would result in threads being a
utomatically created on this mailing list for each of the wiki pages
* The top 5 messages for a given page would be displayed directly on that page.

Tiki has internal ((doc:search)). It is fully integrated, checks permissions, and works on shared server, etc.

However, in some contexts, better support for external search technologies would be useful.


Related:
http://framework.zend.com/manual/en/zend.search.lucene.html
http://www.sphinxsearch.com/
http://www.google.com/sitesearch/
http://lucene.apache.org/solr/
http://ir.dcs.gla.ac.uk/terrier/

It would be great to be able to bind arbitrary actions to user creation.

For example, I would like to have a blog created on user registration, named after the username.
Then I might want to have only that user with permissions for some items.
Maybe point the user's group homepage to something user-specific.

And et cetera :)

CSS... Themes...

{syntax type="tiki" editor="plain"}
Sometimes, wehn sending a braodcast message to a given group, the message body is empty.

It is empty for the recipients, but also in the sent box of the sender.

No error message is issued, en the message is delivered with the correct sender, the correct subject, but a totally empty body.

{syntax type="tiki" editor="plain"}
Both bugs 2687 and 3076 are marked as duplicate of each other.

After updating tikiwiki3.3 to 4.1, the following fails to load
/tiki-admin_categories.php
/tiki-admin_polls.php and
/tiki-wiki_rss.php?ver=2

I checked memory and execution time therefore the problem due to this is ruled out. Problem must be somewhere which I could not figure out.

Time does not show correctly while date is perfect. It needs me to set time of publication of articles manually.

The module since your last visit does not work properly.

On my part I reinstalled it several times but errors persists.

{syntax type="tiki" editor="plain"}
The number count in a password is rated using this piece of code in lib/tiki-js.js:

// Numbers
var nNumberCount = countContain(strPassword, m_strNumber);
// -- 1 number
if (nNumberCount == 1)
{
nScore += 10;
}
// -- 3 or more numbers
if (nNumberCount >= 3)
{
nScore += 20;
}

This causes a password with 1 number to get 10 points extra, a password with 2 numbers extra points, and a password with 3 or more numbers 20 extra points.

EDIT @joel.magene 2026/06/02:
Current master still miscalculates password number scoring, but differently from the original report.

In lib/tiki-js.js, the current fallback branch gives +10 points when nNumberCount is less than 3, including when it is 0. This means passwords with no digits are overrated.

Expected:
0 digits = +0
1-2 digits = +10
3+ digits = +20

Fix: only apply the +10 fallback when nNumberCount > 0.

When a new user register, the admin receives an email notification with two links. One for validating the registration, one for assigning the new user to groups.

The first link is fine, but the second one only works if Tiki is installed in a subdirectory 'tiki' of the apache root. But Tiki may be installed anywhere. In my case, I installed it under a subdirectory 'tw' of the apache root. And lots of folks install it at the root of the apache server itself.

Below is an example of such a mail message.

>> -----Original Message-----
>> From: alain.desilets@nrc-cnrc.gc.ca [mailto:alain.desilets@nrc-
>> cnrc.gc.ca]
>> Sent: October 16, 2009 6:27 PM
>> To: Desilets, Alain
>> Subject: User Registration Request
>>
>> Hi,
>>
>> alain_desilets <alain.desilets@nrc-cnrc.gc.ca> has requested an
>> account on rte-nte.notrewiki.net
>>
>>
>> To validate that account, please follow the link:
>> http://rte-nte.notrewiki.net/tw/tiki-
>> login_validate.php?user=alain_desilets&pass=e1c159c6d72116808b642e2c0
>> 63
>> ffa73
>>
>> Assign to a group: http://rte-nte.notrewiki.net/tiki/tiki-
>> assignuser.php?assign_user=alain_desilets
>>
>>
>> Best regards
>>
>>
>
>

{syntax type="tiki" editor="plain"}
On http://profiles.tikiwiki.org, if I enter the following in the "Search Wiki Page (new)" field:

Multilingual_Wiki

I only get one hit for the following page:

Multilingual_Wiki_Test_Data

Yet, there IS a page called Multilingual_Wiki:

http://profiles.tikiwiki.org/Multilingual_Wiki

I have installed TikiWiki 3rc1 on an IIS (Windows Server 2003) installation with PHP 5 and MySQL. This is a root-level installation. For some reason having to change PATH_TRANSLATED to SCRIPT_FILENAME in line 31 of lib/setup/tikisetup.class.php, which if I don't do I get errors relating to directories not existing and the site not loading at all; this is not the purpose of the support request.

Once I make these tweaks, as well as after setting the tweaks identified in tiki-filter-base.php (that is, changing forward slashes to double-backslashes in quotes), I get the site up and running. ***But*** on administration pages, the buttons created by lib/smarty_tiki/function.button.php (such as "CLEAR CACHE" on the Modules admin page) don't seem to work when accessing the site from Safari or Firefox (Internet Explorer works fine for this).

Instead, in Safari, the clicking on the button will load the script name where the domain name is supposed to go; if my site was on http://site.com/somescript.php?something, it would load http://otherscript.php?something. I don't have my machine handy, so I can't get the Firefox results up at the moment, but IIRC they involved the format http://site.com/\/otherscript.php?something (with a backslash and forward-slash inserted).

A Linux installation of TW3 works fine in Safari and Firefox, so my guess is that it's an IIS issue that has something to do with backslashes and root-directory determination, but I'm somewhat clueless here. I've examined lib/smarty_tiki/block.self_link.php and some tweaking there has produced no viable results.

Also note that this goes away when TikiWiki 3 is placed into a non-root directory; it only affects a root installation at /, rather than at a server subdirectory.

{syntax type="tiki" editor="plain"}
Bug:
*New all-day events are not created.

To reproduce:
*Create an event, select a start-day in the future, select "All-Day", and then save it.

Reason:
*The event doesn't get created because the end-day is before the start-time.

Problem:
*This is confusing for the user.
*No error message or warning is generated.

When creating (editing) some event and change start date to the value that is newer than end date, user must change end date manually

The "Tentative" status for a calendar event always reverts to "Confirmed" after it is saved.

{syntax type="tiki" editor="plain"}
Unable to add calendar module

Fatal error: Cannot use string offset as an array in /home/tiki/public_html/modules/mod-func-calendar_new.php on line 72

Changi.

tikiwiki v 4.3 does not have possibility of reminding on events in calendar

Only the 1st level of File Galleries are shown. Further sub-galleries at a deeper level are hided in the tree view.