Category: Installer (profiles, upgrades and server-related issues)

Newly created tikiwiki 2.0 site works all the way through setup and initial login. Subsequent http login attempts at http://dev.friendwich.com:100/tiki-login.php return a 404 error.

Expected behavior is a log in page with username/password fields. Actual behavior is 404 error. Oddly, clicking on the URL in this bug report gives the "no input file specified" in Firefox.

I can reproduce this always on firefox or IE7.

As admin, I go to Admin -> Admin mods and select Mods Configuration.

If I Save the Tikiwiki Mods Configuration, I get an error "Notice: this variable may not be empty: username

This prevents me from changing the mods repository.

http://tiki.org/tiki-searchresults.php?find=test&boolean=on&boolean_last=y

{img fileId="831"}

TikiInstall in 6.0 RC1: After pushing Install Button, populates DB and then Blank stops... no other page would appear.

I have tried 2 Browsers: Chrome and IE7. Both on Windws Vista. The problem persists.

It does this with new database, fresh install. Before I run the install procedure, I make sure the DB is totally empty.

So it is a fresh DB install.

If I re-run the intaller, some SQL errors appear.

If I ignore them, then Tiki cannot be used to finishe set up: An error occured while performing the request" when trying to access the Tiki.

The problem persists if using MySQL Improved (mysqlli), and also using MySql Classic


About the server:
Running in Windows Plaform
128 mb ram
php version 5.2.6
mysql is ok

I have other tikis 5.3 running in same server with no problem.

{syntax type="tiki" editor="plain"}
Freshly installed TikIWiki 3.0 beta 4 with the Company Intranet Profile.

Created a tiki sheet (either as admin or as a registered user, this happens in both cases).

Tried to insert a column.... it begins and then suddenly takes me to a new sheet labeled:

ERROR:

A SheetId is required.

-----
* __THIS HAPPENS ON SAFARI 3.2 (macOS)__
* __This behavior does not occur under Firefox 3__

I have configured "tiki and pear::auth" in the login section of tikiwiki on a server which did not have the pear php libraries installed.
Next time I try to login with a user (not admin), I see a blank page.

This happens because on line 756 of file lib/userslib.php
$a = new Auth("LDAP", $options, "", false, $user, $pass);
just dies without any error message.

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 '\'.

Applying the profile "Tracker_as_calendar_12" with php 5.6 or php7.0 (on ubuntu 16.04 64 bits with mysql 5.7) produces this type of error:

{CODE()}
System error.

The following error message was returned:

Expression #8 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'tiki12svn_trackercalendar.ttif.value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

The query was:
SELECT tti.*, ttif.`value`, ttf.`type`, `lastModif` as `sortvalue` FROM ( `tiki_tracker_items` tti INNER JOIN `tiki_tracker_item_fields` ttif ON tti.`itemId` = ttif.`itemId` INNER JOIN `tiki_tracker_fields` ttf ON ttf.`fieldId` = ttif.`fieldId`) WHERE tti.`trackerId` = ? and (`status`=? or `status`=?) AND `ttif`.`fieldId` IN( ?,?,?,?,?,? ) GROUP BY tti.`itemId` ORDER BY `sortvalue` desc

Values:

1
o
p
1
2
3
4
5
6

The built query was likely:
SELECT tti.*, ttif.`value`, ttf.`type`, `lastModif` as `sortvalue` FROM ( `tiki_tracker_items` tti INNER JOIN `tiki_tracker_item_fields` ttif ON tti.`itemId` = ttif.`itemId` INNER JOIN `tiki_tracker_fields` ttf ON ttf.`fieldId` = ttif.`fieldId`) WHERE tti.`trackerId` = '1' and (`status`='o' or `status`='p') AND `ttif`.`fieldId` IN( '1','2','3','4','5','6' ) GROUP BY tti.`itemId` ORDER BY `sortvalue` desc

Stacktrace:
* /var/www/html/12.x/tiki-index.php : 0 -> {main}(array ( ))
* /var/www/html/12.x/tiki-index.php : 686 -> __toString(array ( ))
* /var/www/html/12.x/lib/core/Tiki/Render/Lazy.php : 22 -> call_user_func:{/var/www/html/12.x/lib/core/Tiki/Render/Lazy.php:22}(array ( ))
* /var/www/html/12.x/lib/core/Tiki/Render/Lazy.php : 22 -> {closure:/var/www/html/12.x/lib/wiki/renderlib.php:331-341}(array ( ))
* /var/www/html/12.x/lib/wiki/renderlib.php : 334 -> get_parse(array ( ))
* /var/www/html/12.x/lib/wiki/wikilib.php : 488 -> parse_data(array ( ))
* /var/www/html/12.x/lib/tikilib.php : 386 -> parse_data(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 1589 -> parse_first(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 476 -> plugin_execute(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 1018 -> wikiplugin_tabs(array ( ))
* /var/www/html/12.x/lib/wiki-plugins/wikiplugin_tabs.php : 84 -> parse_data(array ( ))
* /var/www/html/12.x/lib/tikilib.php : 386 -> parse_data(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 1589 -> parse_first(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 476 -> plugin_execute(array ( ))
* /var/www/html/12.x/lib/parser/parserlib.php : 1018 -> wikiplugin_trackerlist(array ( ))
* /var/www/html/12.x/lib/wiki-plugins/wikiplugin_trackerlist.php : 1692 -> list_items(array ( ))
* /var/www/html/12.x/lib/trackers/trackerlib.php : 1274 -> fetchAll(array ( ))
* /var/www/html/12.x/lib/core/TikiDb/Bridge.php : 32 -> fetchAll(array ( ))
* /var/www/html/12.x/lib/core/TikiDb/Pdo.php : 109 -> handleQueryError(array ( ))
* /var/www/html/12.x/lib/core/TikiDb.php : 148 -> handle(array ( ))

{CODE}

Same profile applied on older mysql (5.6) and older svn revision works as expected. Reproduced here:
https://demo.tiki.org/12x/tiki-index.php?page=Tracker_as_Calendar_12
u: admin
p: 12345

I am unable to access info.tikiwiki.org or themes.tikiwiki.org with IE7. (FF and Opera work fine.) I get the following error:
{CODE()}
Warning: session_start() [function.session-start]: open(/tmp/sess_4bf95c633abfec1c2db078c6c7e6cf23, O_RDWR) failed: Permission denied (13) in /home/themetw/public_html/tiki-setup_base.php on line 279

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/themetw/public_html/tiki-setup_base.php:279) in /home/themetw/public_html/tiki-setup_base.php on line 279
header already sent
{CODE}

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

Unable to install 5.0 RC2 just after setting the Database Connection I received this:
Fatal error: Undefined class constant 'MYSQL_ATTR_INIT_COMMAND' in C:\wamp\www\tiki-5.0.RC2\installer\tiki-installer.php on line 432

On a brand new trunk Revision: 63992

{img fileId="1130" thumb="box"}

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}

{CODE()}Version 12.0svn is no longer supported. A minor upgrade to 12.0 is required.{CODE}

{img fileId="691"}

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.

I updated a working Tiki25 today.
With an empty database I can run the Tiki and database:u console command work.

On my local__ (MAMP osx), if I try the same command but this time to update an existing database I have the following error:
{img fileId="2083"}

There is something wrong with the previous default value for the field "date_to" in the table "tiki_banning".
I fixed (temporary) by setting a new default for this field.
No more database error.

{mediaplayer src="display2084"}


This does not happen on a a remote server (debian11 + virtualmin).

upgrade all databases in a multitiki installation in a single go with console.php

with some param like "--site=all":
{CODE()}
php console.php d:u --site=all
{CODE}

{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

Check http://branding.tiki.org/ vs http://nextbranding.tiki.org/

{img fileId="855"}

https://nextbranding.tiki.org/tiki-admin.php reports
{img fileId="856"}

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

Installer needs to take into account that Upgrading to 1.10 from 1.9 version prior to 1.9.8 requires tiki_1.8to1.9.sql