Category: 4.x

After creating survey, adding questions and making a test survey I tried to clear survey stats. Unfortunately the button __clear stats__ popup confirmation windows (Click here to confirm your action) in which I can press only cancel button. Pressing __OK__ shortly closes confirmation window and opens it again. Server: Tikiwiki version 4.1 on OS CENTOS 5.4. Client: Ubunty 9.04, Firefox 3.5

I have just migrated a Tiki from one server to another and ran into
UTF-8 Problems. The browser showed Umlauts as the dreaded diamonds with
question marks in them.

Both servers are fully utf-8 compliant as described in
http://tikiwiki.org/UTF-8

The big problem is that on the new server PDO is available while it
isn't on the old one. According to the mailing list PDO is not default,
but as far as I can see in the code PDO will be default, if available
and not set otherwise. Setting

$api_tiki='adodb';

in db/local.php fixes the special character problem.

The issue seems to be that PDO gives a silent fuc# about encodings and
just pumps everything to the database and back as you hand it to it.
Additionally PHP/PDO doesn't read your my.cnf and therefore doesn't know
which encoding to use.
A quick fix is telling PDO which encoding to use - line 39 in
db/tiki-db-pdo.php :

$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki",
$user_tiki, $pass_tiki,array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES
utf8"));

But I think that this is not safe to commit...
e.g. someone started with Tiki on MySQL 4.0 which used latin1 as
default, so all her tables are latin1. She upgrades MySQL to 5.1, but
doesn't change the Tiki database to default to utf-8 and hasn't
converted the database. Then the PDO-fix above will most probably
produce the same problem, just the other way around...

No idea, what to do actually, but wanting to raise awareness here!

This is a dangerous issue as people with utf-8 databases upgrading their
system or Tiki and switching automagically over to PDO will end up with
mixed stuff in their database: clean UTF-8 and double-byte
ansi-control-characters which MySQL converted to their right unicode
codepoints (freaky, hm? ;) ).

I hope, I was capable of describing the problem in a way that's
understandable....

The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever

The "pagename" parameter of ~np~{toc}~/np~ seems to be ignored.

On any new wiki page __~np~ {toc} ~/np~ __ would not be expected to show anything since the page is not part of a structure. This works as expected.

However change that to __~np~ {toc maxdepth=3 shownum=1 structId=15} ~/np~ __ (or any other valid structure Id) and the first three levels of the structure are correctly listed.

From that structure listing, pick a target page, preferably one which is known to have sub-ordinate pages in the structure, for example
__~np~ {toc maxdepth=3 shownum="1" structId=15 pagename=Group#03} ~/np~ __ or __~np~ {toc maxdepth=3 shownum="1" structId=15 pagename=Smith_Fred_1234} ~/np~ __

This should list the structure below page "Group#03" or "Smith_Fred_1234", but instead it lists the root of the structure, as if the "pagename" was missing.

Also, for a page in a structure, the pagename does not default to the current page (as per documentation at http://doc.tikiwiki.org/Structure+User ) when structId is used

Further background at http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=37636&topics_sort_mode=lastPost_desc&forumId=4 This is really hurting us.

We're new to TikiWiki and any work-around suggestions would be really helpful.

Thanks

Martin

U1. Updated with alternate example page names

When you use the tracker field "items list" to link (for instance) offers and demands (or gods from an inventory, etc.), the option to specify to list only the open items, for instance, is needed. If a product is out of stock, would be set as out of stock, and maybe marked as "pending", or if discontinued, marked as "closed". And it shouldn't be listed through the "items list" field.

Nowadays (2.0rc2), it's not clear to me how this could be achieved (if so).

Sometimes we need a checkbox field in a tracker to be mandatory. Like:
^[[ ] I accept the terms and conditions.^
or
^[[ ] I agree with the three rules of tw.o dev community.^

This cannot be accomplished yet because the checkbox can be left empty, even if the field was marked as mandatory, and the tracker item is inserted (without that box checked).

Tracker performance improvements, as agreed with Marc Laporte. He will give it a go with Louis Philippe in January 2010.

{syntax type="tiki" editor="plain"}
If you have a tracker with fields e.g
X text
Y radio buttons, mandatory
Z date
and you would like to offer the user to update X only, or X and Z only, keeping the old value of Y, it won't work. The error message you get is that Y is mandatory.

{syntax type="tiki" editor="plain"}
Just see ((All Patches)): content that is to be mouse-overed is breaking the page.

And on ((DogFood)), there is no mouse-over

See http://dev.tikiwiki.org/TestTrackerlist

You will see that links do not how on the first trackerlist plugin. They work on the second and third one though.

Removing description from the fields shown in the popup seems to fix it. But not all descriptions seem to break it though - see the second plugin filtered differently which works.

{CODE(caption="Current")}
{TRACKERLIST(trackerId=>1,fields=>1:2:3, filterfield=>1, filtervalue=>"A")}{TRACKERLIST}
{CODE}


{CODE(caption="Suggested")}
{TRACKERLIST(trackerId=>1,fields=>1:2:3, filterfield=>1, filtervalue=>"A" or "B")}{TRACKERLIST}
{CODE}

In my installation, on some internal links that are represented in an absolute way, there is a backslash between the domain name and the first slash.

Eg when I try to login on http://mydomain.com/index.php, I get redirected to http://mydomain.com\/tiki-login.php, which the server cannot render.

Clean install of:
MS Windows Server 2003 SE SP2 on x86
Apache 2.2.10
MySQL 5.1.30
PHP 5.2.8
TikiWiki 2.2

Tiki resides directly in the DocumentRoot C:\tiki (as it is a dedicated server).

In tiki-setup.php, there is a line

{img src=images/code.png}%%% {CODE()} $tikiroot = dirname($_SERVER['PHP_SELF']); {CODE}

In the documentation of [http://www.php.net/dirname |((dirname))], they state that since PHP 4.3.0, dirname returns unexpected values. The example implies that on Windows dirname('/x') returns '\'.

Therefore, if you install Tiki in the DocumentRoot, _SERVER['PHP_SELF'] will be '/filename.php' and $tikiroot will be '\'.

On some PHP-Versions (e.g. PHP Version 5.2.0-8+etch16 - not on PHP Version 5.3.1) the file gallery tree view only shows the 1st level of galleries.

See the incorrect
{img id=110}

and the correct behavior
{img id=111}

the parent selection box at the edit form of galleries only shows these 1st level galleries too.

galleries of a deeper level are not shown. Thus you can not create file galleries with level 3 or deeper.

{syntax type="tiki" editor="plain"}
Since stalation I do not succeed to make TW to send e-mails.

When I try to configure e-mail for sending configuration.

I went to the page to config e-mail sending at:
http://wiki.troquei.com/tikiwiki/tiki-admin.php?page=general

however I got an error that says:

A timeout occured while waiting for the script output (in: /usr/www/users/wikilg/tikiwiki/tiki-admin.php).

Tikiwiki 2.3 was upgraded to 4.0. Upgrade went well, DB connection was found, DB was upgraded, installer locked. TW4.0 is unable to connect to the MySQL5 DB it was able to upgrade seconds before. See: http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=6&comments_parentId=35478

I am in 4.2
I no longer able to download my files stored in files gallery
I am able to upload a file, I can see it in file gallery but its adress is http://www.mysite.fr/dl47 instead of http://architudes.fr/tiki-download_file.php?fileId=47 on 3.2 release and my browser return "Error 404 - Not found"

Yahoo! now provides OpenID support for all Yahoo! IDs. However, I am unable to login to any Tiki by using my Yahoo! OpenID.

See http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=28775

{syntax type="tiki" editor="plain"}
After upgrading from 4.0 to 4.2 using a overwrite and save db/local.php I have gotten this error:

The following error message appears now:
-------------------------------------------------
Unknown column 'event' in 'field list'

The query was:
select `event` from `tiki_secdb`

The built query was likely:
select `event` from `tiki_secdb`
-------------------------------------------------

The install and db upgrade complete successfull. Have run the upgrade again and this still happens.
Also I get page errors.

Short version is that the tikiwiki has become unstable. I can not access wiki pages by using the name but edit can find them but save fails also.

When you upload an zip file into file gallery and choose "unzip zip files" the checkbox to choose a catagory has no effect. It would be nice, that all extracted files have the choosen category.

I use TikiWiki 4.2.

I'm sure that nobody is really trying this, but the doc claims that an upgrade from 1.9 to 4.1 should work. When running the DB upgrade, I've hit four errors:
PHP Fatal error: Call to a member function fetchRow() on a non-object
in /var/www/tiki/installer/schema/20090923_mod_change_category_defaults_tiki.php on line 11, referer: http://dc-dev/spwiki/tiki-install.php

PHP Fatal error: Call to a member function fetchRow() on a non-object
in /var/www/tiki/installer/schema/20091004_last_tracker_items_modules_merge_tiki.php on line 11, referer: http://dc-dev/spwiki/tiki-install.php

PHP Fatal error: Call to a member function fetchRow() on a non-object
in /var/www/tiki/installer/schema/20091019_article_by_rating_modules_merge_tiki.php on line 11, referer: http://dc-dev/spwiki/tiki-install.php

Call to a member function fetchRow() on a non-object
in /var/www/tiki/installer/schema/20091019_last_articles_modules_merge_tiki.php on line 11, referer: http://dc-dev/spwiki/tiki
-install.php


Oops, didn't have alter privs on DB. Not sure if that's why this failed.

{syntax type="tiki" editor="plain"}
Error when trying to start the Tiki after Upgrade from 3.1 to 4.1. The installation and upgrade during installation reported "Success":

"System error.
The following error message was returned:

Champ 'version_minor' inconnu dans field listThe query was:

SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`=?
Values:

1.UserPageadmin
The built query was likely:

SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`='UserPageadmin'
"

{syntax type="tiki" editor="plain"}
{CODE()}
UPDATE `tiki_file_galleries` SET `parentId` = (SELECT * FROM (SELECT `galleryId` FROM `tiki_file_galleries` WHERE `type` = 'system') AS t) WHERE `parentId` = -1 AND `type` != 'system'
You can't specify target table 'tiki_file_galleries' for update in FROM clause
{CODE}


Suggestion: use php for this, and rely less on sql

happened on MySQL 4.1.22-standard

Steps:

1. Dump MYSQL tikiwiki 3.3 database (lets call "sql33")
2. Create a new environment where put tikiwiki 4.0 files
3. Import the dumped "sql33" into new sql db (lets call "sql40") through command line
4. Start the configurator of tikiwiki 4.0 and use the upgrade db feature.
5. Try to access the new tikiwiki 4.0 installation:

RESULT: Noone user can access the site. The admin also cannot access the site.

6. Try to reset the admin password:

UPDATE `users_users` SET `password`='admin', `hash`= md5('admin') WHERE `login`='admin';

RESULT: The admin cannot access the site.

During the db upgrade some warning happened, but nothing related with the problem above, I think.
I nevertheless post the messages:

INSERT INTO `tiki_menu_options` (`optionId`, `menuId`, `type`, `name`, `url`, `position`, `section`, `perm`, `groupname`, `userlevel`) VALUES (107,42,'s','Newsletters','tiki-newsletters.php',900,'feature_newsletters','tiki_p_list_newsletters','',0)
Duplicate entry '107' for key 1
-- 2009-09-18 lphuberdeau
ALTER TABLE `tiki_transitions` ADD COLUMN guards TEXT NOT NULL DEFAULT '[]'
BLOB/TEXT column 'guards' can't have a default value
UPDATE `users_objectpermissions` SET `permName`=? WHERE `permName`=?
Duplicate entry 'ef988117becd8cd60924ff5b97c73e43-category-Registered-tiki_p_view' for key 1

~~#f33:__Update!__~~

#~~#f33:Unzip Zip Files (Batch Upload) is Broken for Windows and CentOS~~
#~~#f33:Adding Multiple files one at a time, then uploading in-batch is broken __ONLY for Windows XP__ (CentOS works).~~

System Used:

1) Windows XP
XAMPP
Tiki 4.0 and 4.1 (12-15-2009)
IE 8 or Mozilla FF 3

2) CentOS 5.x
Tiki 4.0 and 4.1
IE 8

In Tiki 3.x it is possible to upload multiple files at one time to any file gallery by one of two methods:

1. Keep clicking the "Add" button and add select multiple files for uploading. Then finally click the "Upload" button.

2. Select a zip file to upload, and check the "Unzip" checkbox.

~~#f00:__In Tiki 4.0/4.1 this feature is broken.__ ~~ The resulting behavior is that the upload progress-indicator (spoked-wheel animation) runs forever, and the Apache server must be restarted before the user can continue to upload any other files after the failed attempt at multiple-uploads.

~~#f00:__For purposes of data/file migration to Tiki, this is a serious issue.__~~
I'm not much of a PHP programmer, and I suspect other Tiki users are not either...so checking out the latest code from the head of a branch is probably not a great work-around (in general).

Add ip to syslog and/or action log, so that when anons (at least) are allowed to add content and it's spam (robots seem to be able to post with our current antibot captcha), there is way to identify the ip of the spammer.

So far, antibot captcha is added (in trunk, at least) to:
* wiki edit
* wiki page comments
* forum posts
* tracker item comments
* freetags
* calendar items
* newsletter subscription

The action of adding content on those features should be logged in syslog and/or action log and IP recorded.