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

I installed a brand new Tiki24 and below the "do you want to lock your Tiki installation" I saw the following
{CODE()}
Upgrading and running into encoding issues?
We can try to fix it, but make sure you have backups, and can restore them.
Oops. You need to make sure client charset is forced to UTF-8. Reset the database connection to continue.
{CODE}

It doesn't really make sense, it is wrong (the db is UTF-8, utf8mb4_unicode_ci) and un-consistent.
It also propose 0 action.

I guess some conditions or logic are wrong.

This is the second Tiki24 I install from new files (git clone) and update the database in the last 48h that shows the issue. (one on my local OSX, another one a Debian10 Virtualmin)

On database update it keep coming back on the Tiki Installer Security Precaution page.
Then it is in loop as long as I keep being on the tiki-install.php.

If I then jump directly to the Homepage I can see an incomplete installed Tiki.
I have to complete manually using the console (see the workaround I added)

---
Update 2022-08-14
Just tried again on a Debian10 Virtualmin and this time the installation wasn't stuck on the Tiki Installer Security Precaution page. BUT seems it didn't complete the final stages (index rebuilt...).
I completed manually again and this fixed the issue.

{syntax type="tiki" editor="plain"}
Three queries fail during the installation of version 6.1 when using Mysql 5.5.9 because the deprecated syntax __timestamp(14)__ has been removed and should now be __timestamp__.

The queries that fail are the table creation queries for tiki_banning, tiki_friendship_requests, and tiki_users_score.

This is essentially a duplicate of Ticket ID 2213 except to clearly note the solution and that it affects TikiWiki 6.1 and Mysql version 5.5.9.

When upgrading my trusty old installation of 12.14, which seemingly went through without errors, after it was completed, there is a mentioning in the installation wizard that sometimes the ability to log-in as admin might be lost.

This has struck here. Unfortunately, once you dismiss this information and proceed to log-in (with or without locking the installer) you'll never see this text (and the help offered therein) again...

After finishing the installer, I could not log-in as admin to unlock the site. And, as I wrote, the info is never shown again...

So I went to the database and I think I found the culprit.

In the table users_users I see that the record containing the admin carries a new password. According to my backup, the PW should be starting with "$1$9", but it is "$2y$10$".

According to PHP documentation the first characters before the dollar signs merely indicate the cryptographic method used for hashing. And it should be normal that from time to time PW will be re-encrypted by new methods like blowfish, or key lenghts. PHP docs even recommend automating this.

But due to the one-way nature of hashing it is impossible to re-encrypt passwords without help from the user, here the admin. The PW has to be entered fresh and then encrypted with the new method. It's impossible to decipher and re-crypt.

So if in the short time-span between the backup I drew and the run of the installer, the PW changes in the DB and changes cryptographic method, it must have been tampered with!

One more nail in Tikis coffin for me.

On a new installation (clean DB), Tiki does not set the site's default language.

Doing an upgrade of an 18.x tiki (using the console command didn't work at all) i am presented with this big red error box:
{REMARKSBOX(type="error" title="Encoding Issue")}Something is wrong with the database encoding. The database has UTF-8 as default encoding but some tables in the database have a different collation, utf8_unicode_ci. Converting to UTF-8 may solve this but may also make matters worse. You should investigate what happened or only proceed with backups.

etc...{REMARKSBOX}

This doesn't make sense because -+ utf8_unicode_ci+- is a UTF-8 collation.

{syntax type="tiki" editor="plain"}
when you try to run the installer 5 beta 2 with german language selected, the creation of the DB failes.

you run the db installer, you get an empty screen. When reloading, it gives an SQL error.

it stops at "users_users" table.

Hello,

we don't get tikiwiki installed into oracle database. we used instantclient_11_1, compiled oci8 against the libraries, loaded the extension in php.ini, configured apache2 environment (LD_LIBRARY_PATH etc). then we restarted apache2 and started tiki-installer.php. Connection seems to work, but then the installion process aborts with following error:

PHP Fatal error: Call to a member function fetchRow() on a non-object in /srv/www/htdocs.oracle/installer/tiki-installer.php on line 43, referer: http://192.168.5.37/ora-tiki/tiki-install.php

{syntax type="tiki" editor="plain"}
Am trying to install 1.9-BRANCH (1.9.8) on my server. 1.9.7 worked fine, 1.10 worked fine after a tweak, but this 1.9.8 install seems to barf.

Running Mysql 4.1.1, and have even copied the db/tiki-1.9-mysql.sql contents for the create table segments that failed and used phpMyAdmin without success. A full example is:
{CODE()}

Command: CREATE TABLE tiki_articles (
articleId int(8) NOT NULL auto_increment,
topline varchar(255) default NULL,
title varchar(80) default NULL,
subtitle varchar(255) default NULL,
linkto varchar(255) default NULL,
lang varchar(16) default NULL,
state char(1) default 's',
authorName varchar(60) default NULL,
topicId int(14) default NULL,
topicName varchar(40) default NULL,
size int(12) default NULL,
useImage char(1) default NULL,
image_name varchar(80) default NULL,
image_caption text default NULL,
image_type varchar(80) default NULL,
image_size int(14) default NULL,
image_x int(4) default NULL,
image_y int(4) default NULL,
image_data longblob,
publishDate int(14) default NULL,
expireDate int(14) default NULL,
created int(14) default NULL,
heading text,
body text,
hash varchar(32) default NULL,
author varchar(200) default NULL,
nbreads int(14) default NULL,
votes int(8) default NULL,
points int(14) default NULL,
type varchar(50) default NULL,
rating decimal(3,2) default NULL,
isfloat char(1) default NULL,
PRIMARY KEY (articleId),
KEY title (title),
KEY heading (heading(255)),
KEY body (body(255)),
KEY nbreads (nbreads),
KEY author (author(32)),
KEY topicId (topicId),
KEY publishDate (publishDate),
KEY expireDate (expireDate),
KEY type (type),
FULLTEXT KEY ft (title,heading,body)
) TYPE=MyISAM AUTO_INCREMENT=1
Message: Incorrect sub part key. The used key part isn't a string, the used length is longer than the key part or the storage engine doesn't support unique sub keys

and

Command: CREATE TABLE tiki_blogs (
blogId int(8) NOT NULL auto_increment,
created int(14) default NULL,
lastModif int(14) default NULL,
title varchar(200) default NULL,
description text,
user varchar(40) default NULL,
public char(1) default NULL,
posts int(8) default NULL,
maxPosts int(8) default NULL,
hits int(8) default NULL,
activity decimal(4,2) default NULL,
heading text,
use_find char(1) default NULL,
use_title char(1) default NULL,
add_date char(1) default NULL,
add_poster char(1) default NULL,
allow_comments char(1) default NULL,
show_avatar char(1) default NULL,
PRIMARY KEY (blogId),
KEY title (title),
KEY description (description(255)),
KEY hits (hits),
FULLTEXT KEY ft (title,description)
) TYPE=MyISAM AUTO_INCREMENT=1
Message: Specified key was too long. Max key length is 500

which ultimately cause:

Command: # --------------------------------------------------------
INSERT INTO tiki_modules (name,position,ord,cache_time,groups) VALUES ('login_box','r',1,0,'a:2:{i:0;s:10:"Registered";i:1;s:9:"Anonymous";}')
Message: Table 'tiki-19branch.tiki_modules' doesn't exist

because the table never gets created.
{CODE}
I'm not sure how to go about fixing this problem.

If you install a brand new Tiki6 site, and your database was created with latin1 charset (by sys admin, phpmyadmin, by whatever means), Tiki doesn't warn you at installation time that the db is using latin1.

Only when you upgrade the Tiki6 site, tiki detects that db and tables are not utf-8, and allows converting them to utf-8.

This can be reproduced easily with the TikiLiveCD 0.6, which came (from a customized Slax GNU/Linuxd distro) with an empty db called "test" with latin1 charset, that is to be used for Tiki installation.
http://tiki.org/TikiLiveCD

On a new install, when using the installer you are asked to select your language on the second step.
Once done the Tiki change language to whatever you selected instant (no validation).

After I choose a language it should keep up to the first entrance of the Tiki I just install.
Let say I choose french on step 2, it should be the language selected till I complete the install process (and may be after as default language). However, on step 7 "Configure General Settings" the language is reset back to English (translation exist but not performed) and then back to the selected language on the step 8.

This is wrong a give a poor image of Tiki on the first run.
Note that new Tiki user has __no way__ to go change back the language.

I have migrated one of my Tikis from my personal webspace to one of an organization for which I admin the IT, and therefore I did have a look at the installer (but edited db/local.php instead).

The installer throws several warnings, that --might -- will become errors in the next PHP versions. This is what you get on PHP 7.4:

{CODE(Colors="Tiki")}
Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/init/initlib.php on line 221

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/vendor_bundled/vendor/h5p/h5p-core/h5p.classes.php on line 2590

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/vendor_bundled/vendor/h5p/h5p-core/h5p-development.class.php on line 70

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 414

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 1858

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 4483

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 4483

Deprecated: Array and string offset access syntax with curly braces is deprecated in /homepages/0/MYHOME/htdocs/tiki-18.8/lib/tikilib.php on line 5779
{CODE}

Since r20087, database errors during the installer have an empty error handler, because failures in queries from upgrade scripts are already properly reported.

This unfortunately also has the bad effect of quieting all other errors in queries outside upgrade scripts.

In the installer all steps other than the current one are white on a white background - bad first impression, hence a blocker i reckon {sign user="jonnybradley" datetime="2020-02-12T17:37:14+00:00"}

Not sure if it's due to a combination of MySQL version, PHP settings, or InnoDB, but installer times out in some cases when doing a FRESH install (not upgrade).

See http://comments.gmane.org/gmane.comp.cms.tiki.devel/34097

I installed a new Tiki26 from git on my local computer.
When I updated the DB using the Tiki installer front this was the output;

{CODE()}
Fatal error: Uncaught Error: Call to a member function writeLn() on null in /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php:41 Stack trace: #0 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php(13): applyAlterForTable(Object(Tiki\\Installer\\Installer), 'tiki\_actionlog\_...', 'DROP PRIMARY KE...') #1 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/Installer.php(186): upgrade\_20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki(Object(Tiki\\Installer\\Installer)) #2 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/Installer.php(141): Tiki\\Installer\\Installer->installPatch('20231008\_fix\_pr...') #3 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/tiki-installer.php(511): Tiki\\Installer\\Installer->update() #4 /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/tiki-install.php(137): include\_once('/Users/bernards...') #5 {main} thrown in /Users/bernardsfez/Documents/Shocksite/www/htdocs/tsaharoniki.com\_tiki26/installer/schema/20231008\_fix\_primary\_key\_issues\_on\_several\_tables\_tiki.php on line 41
{CODE}

Using SSH I ran the update through the console -+php console.php database:u+-
It completed and I could re-run the installer.

I also installed on a Debian remote server and had the same issue.

After successful install,
final page suggests that PHP's memory_limit should be >= 16M.
But, big red box warns that the PHP memory_limit is 16M!

No problem technically, but confusing to new, non-tech, or inexperienced users. Installers are very important for the initial experience of new users.

After unzipping and uploading, OR uploading and uncompressing, php pages doesnt open, with error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster@themediamonkeys.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.




http://themediamonkeys.com/tikibeta/


actual site is working fine at http://www.themediamonkeys.com

{syntax type="tiki" editor="plain"}
Upgrading from 7.2 to 8.x revision 38517
Upgrading from 7.2 to 8.2 tweetId still missing

Operations failed: 1 SQL queries.

ALTER TABLE tiki_shoutbox modify tweetId BIGINT(20) UNSIGNED NOT NULL default 0
Unknown column 'tweetId' in 'tiki_shoutbox'

At the end of the installer when launch is run we can get a crash with an exception :

__"Session already opened"__

This has been reported since two years may be six times.

I have not made various test, so may be it depends of the context which is :

#Data upgraded from existing connection
#Run without inhibiting installer

This should not have effect. So I don't understand why others don't seem to observe the problem that I had always.

I need to run again directly index.

{syntax type="tiki" editor="plain"}
(Not yet checked for trunk)

After running installer with upgrade we get the message "Invalid database run installer..."

Running installer don't changes anything to database, but the message is still displayed.
It is a consistency "deadlock by soft".

The lonely thing generated by installer is a reset which needs to reset manually the admin account and clear all caches and cookies (see #4066 admin login problem).

~~#090:!!!Going on 12/06/2011~~

I need to check the soft.

The message is sent by "installer" $installer instance of class installer in installib
It checks before the validation of patches on db using $installer->recordPatch($patch) for each one.
recordPatch function in installer records the patch into tiki_schema as done with his full date.

The concerned (got by a var_dump) patch is "20110904_shoutbox_def_tweetid_tiki"
is not into the tiki_schema table.
So the test functions, but the tiki-install failed to make this patch on another version OK, as it is defined.

__~~#F00:When it runs now (installer at 8.1 level) it don't tries to make the upgrade. This is the deadlock.
__What is done if an old patch is not there !!!__

More there is no report at all.~~__

The conversion and upgrade went well except that page names were not converted

So I had to manually rename some pages for these characters:
é -> é
É -> É
à -> à
è -> è

Wiki page attachments were associated the corrected page name. Thus, if I didn't rename the page, attachment wasn't available.

{syntax type="tiki" editor="plain"}
Install a Tiki 8.2 via Softaculous on a site managed by http://www.webhostingpad.com/

Then, after the install, click on the regular link to get the featured profiles, and you get an error message.

If you type a profile name in the search box, it works fine.

To reproduce, search "wiki" in the admin panel here:
http://branding.tiki.org/tiki-admin.php

And you will get:
"No preferences were found for your search query."

Ideally, the problem is solved, but this is maybe tricky. It could be related to:

{QUOTE(replyto="http://framework.zend.com/manual/1.11/en/zend.search.lucene.index-creation.html")}"Zend_Search_Lucene uses flock() to provide concurrent searching, index updating and optimization. According to the PHP » documentation, "flock() will not work on NFS and many other networked file systems. Do not use networked file systems with Zend_Search_Lucene."{QUOTE}

At the very least, Tiki should detect and report to the site admin that he should use MySQL Full Text Search instead.

Ideally, MySQL Full Text Search would work for tiki-admin.php

{syntax type="tiki" editor="plain"}
__unified_incremental_update doesn't check for feature_search__

Unified Search with Lucene is awesome and is "the future of Tiki".

Now, on certain server configurations, it doesn't work well. An easy workaround is to simply revert to the legacy MySQL Full Text Search.

However, even when using MySQL Full Text Search, unified_incremental_update is defaulted to yes, and tried to update Lucene index, and generates an error message

Workaround is to deactivate unified_incremental_update, or even better, upgrade to 12.x and use Unified Index, with MySQL as storage.
---
Update: this issue has been reproduced in 12.x svn (and untested in 14.x so far, afaik) also with Mysql Full Text Search as unified search engine (on a multitiki install). See: [item5673] . {sign user="xavi" datetime="2015-05-19T09:10:57+00:00"}