Category: Error

I can't show on an instance because 11.x instances are no longer available.

http://marclaporte-11197-5000.show.tikiwiki.org/tiki-admin.php?page=general reports:
{CODE()}Version 11.0 is no longer supported. A minor upgrade to 11.2 is required.

Version 11.2 is still supported. However, a major upgrade to 9.0 is available.{CODE}

Type in wiki page:
^
~pp~
!test test
1111
~pp~
2222
3333
~/pp~~/pp~
^
Work fine:
^
__test test__

1111

2222
3333
^
if type russian heading:
^
~pp~
!тест тест
1111
~pp~
2222
3333
~/pp~~/pp~
^
Result is break:
^
__тест тест__

__2222__
__3333__

__3__
~pp~~/pp~~/pp~
^

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"}
On updating Tiki 5.2 and earlier to 6 errors occur during installation.

^Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement
fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO MYSQL_ATTR_USE_BUFFERED_QUERY attribute.^

The problem is discussed [http://tiki.org/tiki-view_forum_thread.php?comments_parentId=39458&topics_offset=5&topics_sort_mode=lastPost_desc&forumId=6|over here]

--
Chealer:
This does not happen upgrading from a clean install of 5.3 to 6.0. But it happens when upgrading from 5.0 to 6.0. The most problematic script appears to be 20100927_better_column_fix_tiki. The first query (getOne() on information_schema) seems to be the sticky unbuffered query sometimes, since the following, second query fails. I tried but couldn't find how to confirm what query is stuck. It's odd that this problem only happens in the installer. getOne() just like query() use fetchAll() so we shouldn't see this problem. Setting MYSQL_ATTR_USE_BUFFERED_QUERY doesn't seem to help. After some 10 hours of debugging I'm under the impression this is a PDO bug. This looks like http://bugs.php.net/bug.php?id=44081 If anyone wants to try fixing, I recommend speaking to me first. The PDO documentation is very poor, making this really difficult.
20100927_better_column_fix_tiki was introduced in 5.3.

I found upgrades would work with PDO in certain environments. I had the bug on PHP 5.2.13 but upgrading to 5.3.3 fixed. PHP 5.3 can use mysqlnd, which I suspect doesn't have this problem. The upgrade worked for me on vanilla PHP 5.3.3 or PHP 5.3.3 from EasyPHP, both with mysqlnd. I have no clue why this problem seems to only affect Windows, but I saw reports of similar problems on Debian etch, so it may not be completely Windows-specific. Anyone who experiences this problem, please report your PHP version, and if you use PHP 5.3, indicate whether you use libmysql or mysqlnd.

{syntax type="tiki" editor="plain"}
Update to previous.

Issue now is the Max size parameter in the Image plugin doesn't resize image on remote server (Ubuntu) but does on local MAMP setup with identical tiki RC2s (27480).

There's an admin login if you want to try.

tiki

pword wiki

{FLASH(movie="http://worldfreemansociety.org/tikimovies/Image-MaxSize-Bug.swf")}{FLASH}

The last updated pages mod shows pages that the user does not have a right to view. This is a bug and could be serious security. The code should only show pages that the user has a right to view.

{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"}
Upgrade database gives a blank page

With PHP memory_limit at: 256 MB.
max_execution_time 60
max_input_time 60

Looks like the upgrade does complete.
When reloading tiki-install.php and skip Install/Upgrade second time it is posible to complete the install.

When trying to upgrade from 20.x to 21.x

I did svn switch and I get this. It prevents to run the database upgrade script.

{img type="src" src="tiki-download_item_attachment.php?attId=532"}

{img type="src" src="tiki-download_item_attachment.php?attId=533"}

Fatal error: Call to a member function get_user_groups() on null in C:\...\lib\core\Perms\Context.php on line 33

From tiki-devel

"I got it - Something must be done before releasing 1.10
Before in 1.9, there was 2 tables tiki_user_watches and
tiki_mail_events.
tiki_mail_events contained the generic notifications and unfortunately
all trackers/ tracker items watches.
In 1.10 both tables have been merged into tiki_user_watches - but I did
not see in the upgrade script something around tiki_mail_events copy to
tiki_user_watches
And effectively I lost all my trackres watches
A volunteer to fix that?"

{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

Using latest tikitrunk_svn from today (Jan. 24th, 2009)

I had a tiki site based on trunk from several weeks ago.
I added today another tiki site (using the same tiki files on server, thus using multitiki on subfolders)

Once the 2nd tiki site was up & running, I wanted to check the 1st tiki site, and it was complaining about mysql table missing, etc. So I went to run the "automatic database upgrade" ((doc:Tikiwiki 3)).
It needs to go through tiki-install.php, therefore so I did.
I had an (extracttoppath) issue, so that I attempted to go to tiki-admin.php from site one. The problem then was that tiki-index.php was complaining about:
^
The directory '/home/httpd/tikitrunk/modules/cache/javaoptics' does not exist.
The directory '/home/httpd/tikitrunk/templates_c/javaoptics' does not exist.
^

They seemed to have been deleted by the tiki-install.php script, since they were there a minute ago.
I tried also the other tiki site, and it happened the same, both folders were missing (deleted)

__Is this that tiki-install.php is not multitiki ready?__

---
duplicated bug report (by my mistake :-) ) with [bug2736]

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

https://doc.tiki.org/tiki-tracker-update_item?trackerId=20&itemId=2735

I try to upload a file (file is uploaded but not assigned and show error)
{img type="src" src="https://tiki.org/dl1996?display" thumb="box"}

I hten use the browse file button (the file was uploaded even if tiki says otherwise) and it end with a weird redirection while the tracker edit was saved.

{img type="src" src="https://tiki.org/dl1999?display" thumb="box"}

Trying to upload files greater than 2 Mb fails.

php.ini allows memnory, files and posts to be 8 Mb

apache has been restarted

According to my tests the bug happens within the insert file to db library when around the $query string and the execution of it.

hi i have a problem when create new page . some time it is create in correct character then tiki can search and show correctly
http://localhost/tiki/tiki-index.php?page=แผนที่

but when it is show like this , page not found occur.

http://localhost/tiki/tiki-index.php?page=%E0%B8%88%E0%B8%B1%E0%B8%87%E0%B8%AB%E0%B8%A7%E0%B8%B1%E0%B8%94%E0%B8%AA%E0%B8%A1%E0%B8%B8%E0%B8%97%E0%B8%A3%E0%B8%9B%E0%B8%A3%E0%B8%B2%E0%B8%81%E0%B8%B2%E0%B8No value assignedE0%B8%88%E0%B8%B1%E0%B8%87%E0%B8%AB%E0%B8%A7%E0%B8%B1%E0%B8%94%E0%B8%AA%E0%B8%A1%E0%B8%B8%E0%B8%97%E0%B8%A3%E0%B8%9B%E0%B8%A3%E0%B8%B2%E0%B8%81%E0%B8%B2%E0%B8%A3

how to fix it please.

this is also the same problem https://tiki.org/forumthread65410#threadId=65438

best regards,
yanadhorn

On a fresh install at Admin -> Log in I enable "Users can register", I uncheck "Validate new user registrations by email" and I set an URL for the field:"URL the user is redirected to after account validation"

So validation is not done using the email link but is done right away after validating the register form.

I create a wiki page: mysuccesspage and tried with page name, a relative path tiki-index.pgp?page= mysuccesspage and an absolute path: http://mysite.com/tiki-index.pgp?page= mysuccesspage

I’m redirected to the default registration page.

I enabled back "Validate new user registrations by email"to check and it worked.

----

I created an instance to demonstrate:
Setting are good : http://bsfez-11581-6095.show.tikiwiki.org/tiki-admin.php?page=login
Success page exist : http://bsfez-11581-6095.show.tikiwiki.org/tiki-index.php?page=success

At this condition,
* Enabled Time Sheet feature
* Apply Time Sheet profile
* Add tracker fields of URL or Items List to the Time Sheet tracker.

And I click the TimeSheet link, I got the following pattern of error messages;

{CODE(caption="System error" wrap="1")}The following error message was returned:

Incorrect integer value: '{"linkToURL":1' for column 'trackerIdThere' at row 1
The query was:

INSERT INTO temp_tracker_field_options SELECT tiki_tracker_fields.trackerId, REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 1), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 1 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 2), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 2 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 3), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 3 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 4), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 4 -1)) + 1 ), ',', ''), tiki_tracker_fields.fieldId, REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 5), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 5 -1)) + 1 ), ',', ''), tiki_tracker_fields.type, tiki_tracker_fields.options FROM tiki_tracker_fields WHERE tiki_tracker_fields.type = 'l';
The built query was likely:

INSERT INTO temp_tracker_field_options SELECT tiki_tracker_fields.trackerId, REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 1), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 1 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 2), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 2 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 3), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 3 -1)) + 1 ), ',', ''), REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 4), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 4 -1)) + 1 ), ',', ''), tiki_tracker_fields.fieldId, REPLACE(SUBSTRING( SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 5), LENGTH(SUBSTRING_INDEX(tiki_tracker_fields.options, ',', 5 -1)) + 1 ), ',', ''), tiki_tracker_fields.type, tiki_tracker_fields.options FROM tiki_tracker_fields WHERE tiki_tracker_fields.type = 'l';
{CODE}

This does probably affect (all) previous Tiki versions, too.

When creating links to pages that have some kind of wiki syntax in them, the wiki syntax will be interpreted and therefore break the links. I noticed this when using links to Germany's premier law website, e.g.:

Here without anything: http://www.gesetze-im-internet.de/bfdg/__2.html
Here as no parse: ~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~
Here as a link with no parse: [~np~http://www.gesetze-im-internet.de/bfdg/__2.html~/np~]

The last one is a working workaround, but it's a bit sick to say the least. I think Tiki shouldn't parse URLs as wiki syntax at all.

I could also reproduce the same behaviour with other wiki syntaxes as for example the one for italics: http://example.com/my''weird_link.html

There are some usability issues with 3.0 (as of 3.0beta1), reproducible in the TikiLiveCD (at least from the upgrade process of a 1.9.11 to 3.0beta1)

See the bugs and issues reproduced at the video in:
http://doc.tikiwiki.org/TikiWiki+3

In summary:
There is a set of three pages which are translations of the same content: ca, es, en. You want them to be set as a translation set, and work with them. __As far as I remember__, there are some issues:
# You cannot add them to the same translation set until you select "Restrict languages", and select some (or all) languages in the restriction rule. However, by default it should list all languages while attempting to translate a page to a new language.
# You need to define your language preferences first. It would be much more usable if asked to the user, at registration time, this (and similar questions), to make his/her life easier (from the usability point of view)
# quantify page change is broken. The video cited above you'll see that the en page is added some more content. then the es page is updated to a complete translation, and marked as such. And the ca page is translated only partially, and marked as such by the user, but Tiki shows as if it was 100% similar to the en page.

HTH

{syntax type="tiki" editor="plain"}
With a home page from an imported Mediawiki at tiki-index.php?page=Main+Page putting either that, or that with http://192.168.2.6/tiki-index.php?page=Main+Page or that with 192.168.2.6/tiki-index.php?page=Main+Page has no effect at all. The documentation for this feature claims that any entry here should override the Use tiki feature as homepage scroll selection, but that remains in control here, and its selection is what is shown.

So either there's a way to get this to work and the documentation's incomplete. Or the feature is broken. If the second, what would the most direct work-around be?

This block of code is not very well behaved, and it appears in a lot of places:
// Now check if the user should be notified by email
$foo = parse_url($_SERVER[["REQUEST_URI"]);
$machine = $tikilib->httpPrefix(). dirname($foo[["path"]);
$machine = preg_replace("!/$!", "", $machine); // just incase
$smarty->assign('mail_machine', $machine);

In my test environment I'm hitting the website via the LAN machine name and not the public URL. Setting $foo from _SERVER[["REQUEST_URI"] is causing the URL to use the LAN machine name and not the fully qualified name.

Technically this will cause the email to use the host name of whatever the user was hitting, but that would be bad in a server farm where you may need to use a scheme such as www1, www2, www3, etc as the user would always go back to that server instead of letting the load balancer figure it out.

I could see this being a problem anywhere the code is using _SERVER[["SERVER_NAME"] as well.

To me the root problem here is that the templates are depending on two different sources for the same data (the hostname portion of the URL).

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)

When I select "Admin > Wiki > Mandatory category in the category tree", the list of categories while editting a wiki page is blank, or it says no category is defined. However, if you click on "admin categories", they are defined indeed.

When you unselect this check box, and clean caches, categ. list is working fine again.

This is not a theme specific issue (reproduced with geo.css, tikineat.css, lesjetesdelencre.css, ...)

----
update: sylvieg fixed that months ago, I think. (thanks sylvie)