Category: 3.x

Detect browser language is not working to me (to luciash, in fact, in a site which I admin), in a recently upgraded site from 2.4 to 3.0.

This affects Tiki 3 to 7 and is a regression from Tiki 2.

Calendar URLs are currently excluded for spiders and bots, for example:

/calendar?focus=1268089200&viewmode=week

excluded by entries:

Disallow: tiki-calendar.php
Disallow: /tiki-calendar.php

However, the URL /tiki-tell_a_friend.php?url=%2Fcalendar%3Ffocus%3D1268089200%26viewmode%3Dweek would be spidered instead.

{syntax type="tiki" editor="plain"}
One of our users reported that she was receiving watch notifications whenever she clicked the "Discuss" button for a wiki page, even though she was not posting anything in the forum topic.

The cause was a Watch on "A user posts a forum topic (forum_post_topic)" for the Wiki Page Discussion forum. (Our Tiki uses a forum for page discussion instead of page comments.)

The preferred behavior is that this type of watch would only generate a notification the ===first=== time the Discuss button is clicked for a page, when the new topic is actually created, rather than just accessed on successive clicks.

We'll coordinate at ((diso))

for users with tiki_p_wiki_view_comments perm only, it displays the ~np~[comment]~/np~ link on the wiki page bar even when no comments there yet to read, so clicking it does literally nothing...

{syntax type="tiki" editor="plain"}
This is annoying!

Workaround is to remember to pick category again when you save.

{syntax type="tiki" editor="plain"}
Can not ((XML Import-Export)).

tiki-read-artile.php seems to parse code paragraph twice.
I observed that articles parsing worked properly in the preview and in the printable version of an article, but not in the "read" mode.
I edited the "read" and "print" file and "echo"-ed a debug comment in which I tried to display the article body data before parsing:

{CODE(caption="tiki-read-article.php at line 151",colors="php",wiki="0")}echo "<!-- " . $body . " -->"; // The line I've added
$smarty->assign('parse_body', $tikilib->parse_data($body));{CODE}

{CODE(caption="tiki-print-article.php at line 82",colors="php",wiki="0")}echo "<!-- " . $body . " -->"; // The line I've added
$smarty->assign('parse_body', $tikilib->parse_data($body));{CODE}

When I call the "read" one, some things in $body are already parsed.
So when the code calls $tikilib->parse_data($body), the code is parsed a second time.

I found the problem when I was trying to display a BASH code with ~np~--~/np~ parameters

{syntax type="tiki" editor="plain"}
Hello, if I search an "entire site" I expect a search in all sections and as result all objects where I have the correct object permission. But this search is implemented with an inconsistent double permission check.

The "entire site" search fist checks the global view permission in each section. If this is true, the search is sent to the search engine of the section, which gives back results depending on the object permission.

As the default search is "entire site" (can be changed via template), all users without the global view permission in the sections get back an empty result-set. A click on the section search button reveals the searchresult depending on the object permission of the section.

This is somehow between a bug and a feature.

As far as I can tell, the solution to show "entire site" search results according to object permissions is very easy.

{syntax type="tiki" editor="plain"}
when downloading a file from the gallery with IE the result is corrupted. Firefox or Chrome have no problems.
This is related to the general IE(5/6/7/8) inability to handle compressed files correctly.
Tried various suggestions in .htaccess with no result.
example:
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary

the file gallery module is serving from file system, not from the database.
A zip file in the filesystem served by apache directly works fine.

You can see here:
http://dev.tikiwiki.org/tiki-searchresults.php?highlight=mouseover&where=pages&search=Go

Everytime I use the maketoc inside a wiki page on a fresh tikiwiki 3.2 install the whole page content is duplicated every time I hit "save". Even if I delete all the content but one version and hit save the whole PREVIOUS page is duplicated again. Like I hit save: two times the page content. I delete all but one time the content, I hit save: three times the page content. I delete all but one time ... save ... four times the page content.
Only removing the maketoc makes it possible to get rid of the problem. But meanwhile the wiki content has become a bit more (30-40 pages) and the same problem happens more and more often without having any maketoc included when the page is becoming bigger.
That was done with Opera browser on a page with 4 h1 headings but I doubt it is a browser problem. :)

"Dynamic items list" stopped working in trackers with current tiki3 code. It seemed to worked with tiki2, according to the nice documentation and screenshots created by ricks99:
http://doc.tikiwiki.org/Dynamic+items+list

I can provide a testing db if needed (or a site to check this behavior):
http://intercanvis.net

(fields right now only visible to admins, until this field type works again)

tiki-admin.php?page=general
Use direct pagination links:
Maximum number of records in listings:

The two pagination settings should be together in a section "pagination". (on this page is OK)


Would be even better to move all to tiki-admin.php?page=pagination

As suggested by Nyloth at TikiFest Strasbourg,

1- "Sender Email" could be set by default to no-reply@domain.tld
2- It could be requested as part of the install script.

Many features don't work well until it's set (ex.: Inter-User message, registration with email validation, etc)

{syntax type="tiki" editor="plain"}
Edit button at page's top can't work when i enabled Ajax feature

{syntax type="tiki" editor="plain"}
Editing by admin saved the file intact, but the file wasn't renamed. Editing by a registered user created a 0-byte file (also not renamed with -username added). I checked in a Tiki 3.2, which has the same problem.

{syntax type="tiki" editor="plain"}
In RC2 they made some changes to the edit-help (the now blue circle with a question mark).

When you open up the help and go to full screen mode, the text is un-readable while using the Darkroom theme.

Manage items> Edit subject field image and email notification are shown empty.

http://dominio/tiki-edit_topic.php?topicid=xx

In 3.x, the emdash wiki syntax is not working.

In the documentation and previous releases, the following should be represented as an em dash ~--~ but it is not. It is being interpreted as strike out text.

The issue seems to appear when there is more than one em dash in a document ~--~ and seems to be linked to the last tilde.

This was posted on the discussion forums and a suggestion was made that there needed to be a space between the tildes and the dashes ~ -- ~ like so but it does not seem to work.

Links to remove email notification messages come without hash (see below the live example from TikiFestNY)

http://tikiwiki.org/tiki-user_watches.php?hash=

{QUOTE()}
Edit article post: TikiFest NY by lindon at Tue 24 Nov. 2009 06:10 CET

View the article at:
http://tikiwiki.org/article179

If you don't want to receive these notifications follow this link:
http://tikiwiki.org/tiki-user_watches.php?hash=
__''Announcing the first ever TikiFest in New York City being held from January 14-18, 2010!''__

TikiFestNY is a big bug squash! The idea is to knock out as many bugs as possible and have as much fun as possible doing it. If a bug takes more than 30 minutes to fix, then we move on to the next one. Also, invites will be going out locally for an introduction to Tiki presentation on Saturday afternoon followed by refreshments. Hope lots of people can make it! Remote participation is also possible for those that can't. Find complete information at TikiFestNY.

%%%::__~~purple:{COUNTDOWN(enddate=>14-Jan-2010 locatetime=>off)} until TikiFestNY!{COUNTDOWN}~~__::

%%%::''__See you there!__''::
----------------------
{QUOTE}

Could be great to enhance Tiki Integrator to handle:
*http basic auth
*cookies
*frames

This would permit cleaner URLs and easier searching.

__Where?__

Wiki page names
Usernames
tags?
etc.

__What?__
Spaces & underscore to be equivalents
a and A are equivalent. This makes perfect sense for page names, user names, etc Accented characters (äâ) should be as well

For wiki page names (see how Wikipedia does it) but it could be that ~np~((User_Profile)), ((User+Profile)) and ((User Profile))~/np~ are equivalent.


Should hyphen (-) be an equivalent character as well?

How about (,) and (.)

. doesn't play nice with rewrite rules




Moved discussion to: ((Character substitutions))

When I try to create new group I receive this error from MySQL:

Error


An error occured in a database query!

Context:
File tiki-admingroups.php
Url tiki-admingroups.php
Query:
insert into `users_groups` (`groupName`, `groupDesc`, `groupHome`,`groupDefCat`,`groupTheme`,`usersTrackerId`,`groupTrackerId`, `registrationUsersFieldIds`, `userChoice`, `usersFieldId`, `groupFieldId`) values(?,?,?,?,?,?,?,?,?,?,?)
Values:
0 ffff
1
2
3 0
4
5 0
6 0
7
8
9
10
Message:
Incorrect integer value: '' for column 'usersFieldId' at row 1
Built query was probably:
insert into `users_groups` (`groupName`, `groupDesc`, `groupHome`,`groupDefCat`,`groupTheme`,`usersTrackerId`,`groupTrackerId`, `registrationUsersFieldIds`, `userChoice`, `usersFieldId`, `groupFieldId`) values('ffff','','','0','','0','0','','','','')

Trackers can have many fields.

Multilingual is a way to have multiple values.

Native multi-valued trackers would be useful in certain circumstances.

Another way is to use ((doc:Category Tracker Field)) or ((doc:Items List and Item Link Tracker Fields)) or ((doc:Drop Down - Radio Tracker Field)) with multiple choice option. Probably the best is to build upon the ((doc:Relations Tracker Field)).



We would also want multiple sets.

First Name 1 (field 46)
Last Name 1 (field 47)
Address 1 (field 49)

First Name 2
Last Name 2
Address 2

First Name 3
Last Name 3
Address 3

First Name 4
Last Name 4
Address 4

Could we imagine a new tracker field type "Set of fields":
Fields: List of fields in the set. ex.: 46,47,49
Number of repetitions: ex.: 3

This would create artificial fields (in this case 46-2, 47-2, 49-2, 46-3, 47-3, 49-3, 46-4, 47-4, 49-4)

So these fields could be used independently (ex.: 47-2), but since they are linked, we could have some smarter handling for forms, reports and exports.

We could want the input form to by default indicate only the first set of fields, and via jQuery, show additional set of fields.
We could want a report/export of this "Set of fields" which would aggregate everything in one listing.

{draw id="28"}