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

For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]

Add a feature to move files in between the file system and the database

This feature:
tiki-admin.php?page=trackers
tiki-admin.php?page=fgal
tiki-admin.php?page=wikiatt

should be added here:
tiki-admin.php?page=gal

(In fact, it should be backported from 1.10) "Move images from filesystem storage to database storage"

I have test-upgraded my test site (which is a copy of the productive site with slightly less content, but duplicate files, layout, CSS) and upgrading failed. Miserably.

First, there was one (1) SQL error:
{CODE(Colors="Tiki")}
UPDATE `users_objectpermissions` SET `permName` = 'tiki_p_read_article' WHERE `permName` = 'tiki_p_topic_read' AND `objectType` = 'topic'
Duplicate entry '4dadd7eebd7a5fc8790114f9f5aaa8b6-topic-Anonymous-tiki_p_read_art' for key 'PRIMARY'
{CODE}

For the moment, I checked the checkmark in order to proceed (it's not the productive site anyway, and I have a backup of both the files and the DB).

After logging in, I was flabbergasted. I thought my layout (originally done by Gary to imitate a standard layout of 12.14 that was dropped with later updates: Geo) was kind of conservative, absolutely nothing fancy. Standard, classic Tiki layout with 3 containers, a header, a left module zone, a center wiki content and a right module zone.

There is one horizontal menu which was VERY hard to create on 18.8 (because creating menus from scratch is simply not possible (at all) on 18.8., due to an unfixed bug. I made it possible with a trick, I created a second standard menu, exported it, modified it as needed, and re-imported.

Since at that time I did not want to indulge in the depths of the CSS, I created style directives in the context of the menu, which worked satisfactorily. Most of the site is classic Wiki content. Some articles for news, a calendar (which was horribly bug-ridden and thus dysfunctional on 18.8) and a small shop (CART).

So nothing fancy at all. No categories (besides what CART brought with it), no perspectives, etc.

And now the catastrophe: The left module zone is now sitting on the right, and the right module zone went to far-right. Yes, both left and right module zone now sit on the right-hand side.

The menu is a mess with wrong fonts, wrong sizing, wrong spacing etc.

When I call the control panels, they come up as one column (!) in a seemingly endless page, hardly usable at all.

This is the worst upgrade I have ever witnessed. And I thought 12.14 -> 18.2 was a bad. Little did I know...

I checked the look & feel setting, found nothing special in there, it is still on "classic Tiki 3 container". The admin setting was off, to "1 container", but setting that to "Classic Tiki 3 container" to match the site's default changed nothing...

If Tiki keeps breaking my layouts, I am seriously considering to let go. If it weren't for more than one decade of content, I would be gone already. Enough is enough.

After upgrading 1.9.4 to 1.9.5, a search entire site returns the following error. I looked in db/fulltext.sql and didn't see a create fulltext index statement for tracker. What tables/columns should be indexed?

~pp~
in /home/lampp/htdocs/kniki/lib/tikidblib.php on line 134

Context:
File /kniki/tiki-searchresults.php
Url ///kniki/tiki-searchresults.php?highlight=draw&where=pages&search=go
Query:
SELECT ttif.`itemId` AS name, LEFT(tt.`name`, 240) AS data, tt.`trackerId` AS hits,
tti.`lastModif` AS lastModif, tti.`itemId` AS pageName,tti.`itemId` AS id1,1 AS id2,
MATCH(`value`) AGAINST ('draw') AS relevance FROM `tiki_tracker_item_fields` ttif LEFT
JOIN `tiki_tracker_items` tti ON (ttif.`itemId`=tti.`itemId`) LEFT JOIN `tiki_trackers`
tt ON (tti.`trackerId`= tt.`trackerId`) LEFT JOIN `tiki_tracker_fields` ttf ON
(ttf.`fieldId`= ttif.`fieldId`) WHERE ttf.`isSearchable` = "y" AND MATCH(`value`)
AGAINST ('draw') ORDER BY relevance desc, tt.`trackerId`

Values:
Message:
Error Message Can't find FULLTEXT index matching the column list
~/pp~

On tiki-install.php, in the install menu "help" the first icon is missing as it refer to "img/favicons/favicon-16x16.png" and there is no such folder or file.

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

I am trying to test 5.0 RC1 on locahost, but after installing database i received this error message


''Table 'dbxxxxxx.tiki_rss_items' doesn't exist
The query was:
SELECT * FROM `tiki_rss_items` WHERE `rssId` IN( ? ) ORDER BY publication_date DESC
Values:

1. 8

The built query was likely:
SELECT * FROM `tiki_rss_items` WHERE `rssId` IN( '8' ) ORDER BY publication_date DESC''

It was the same with 5.0 beta 2, and when i look to my database tiki_rss_items doesn't exist.
Is it a new table with tiki 5? not install with upgrader?

I got this on October 25th 2006:

Warning: mysql error: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2) in query:

select count(*) from `tiki_banners` where `wed` = ? and `hourFrom`<=?
and `hourTo`>=? and
( ((`useDates` = ?) and (`fromDate`<=? and `toDate`>=?)) or
(`useDates` = ?) ) and
`impressions`<`maxImpressions` and `zone`=?

in lib/tikidblib.php on line 134


How could we show a more meaningful error message?


---

mysql tables sometimes crash.

When they do, the error message is cryptic, at best.

An average Tiki admin won't know what the problem is and could think it's Tiki's fault.


A graceful error message would inform the admin that:

"There are problems with the following tables: ". Please repair (link to how to repair)

Especially the tiki_sessions, which shuts down the site completely...

Some others are not so bad. Just a path disclosure.
{img src=images/code.png}%%% {CODE()}
Warning: mysql error: Can't open file: 'tiki_images.MYI' (errno: 145) in query: select count(*) from `tiki_images` where `galleryId`=? in lib/tikidblib.php on line 134
{CODE}
---

Another error to watch for:
{img src=images/code.png}%%% {CODE()}
Unable to connect to the database !
User droit_tiki has already more than 'max_user_connections' active connections
{CODE}
---
Maybe Tiki admin email should be in db/local.php? So the system could send email alerts when DB can't connect.

When a tiki is on a server which has several domain names, have an option to force a redirect to one in particular (similar to force with/without www). Should be a "permanent redirect" HTTP/1.1 301 Moved Permanently

This is related to the recently introduced feature to remove www or add www to Tiki sites

Specifically, all *.tikiwiki.org domains will progressively move *.tiki.org Both URLs will be kept forever but tiki.org should be the new main one that people see in their browser (and copy-paste from)

I attempted to install a multitiki on subdirectories, based on trunk (Nov 29, 2008), and it failed. I installed two subdir
{CODE()}
setup.sh
www-data
www-data
site1 site2
{CODE}

and through tiki-install.php, I clicked on site1, entered details, and clicked on enter as admin and lock installer.

I couldn't see the site1 tiki

1.9.0DR4 worked fine. 1.9.0 fails.
If you have a multitiki and create custom css/tpl files, they are not traversed. For example, If you have a multiwiki on www.foo.com and create a style called 'bar', the correct place to put the customized css files is
/styles/www.foo.com/bar.css
But this no longer works. It has to be in /styles/bar.css

The tpl files should be in
/templates/www.foo.com/styles/bar/
But this no longer works. It has to be in /templates/styles/bar

Please put back the old way. The current (broken) way prevents me from having styles of the same name on different multiwikis. each with customization.

In current tiki3 proposed branch , multitiki installation is broken.
At the last step of installation through tiki-install.php, the folders inside /templates_c for each domain are deleted.

Thus, when in this step:
http://localhost/site1/tiki-install.php?nolockenter

tiki reports that
The directory '/var/www/proposed/modules/cache/learning' does not exist.
The directory '/var/www/proposed/templates_c/learning' does not exist.

And they did exist in the step before (double checked), but not just after that step.

( see http://doc.tikiwiki.org/Manual+Installation of multitikis if needed )
----
Update in Oct'09: This is a duplicated bug report with [bug2271]
Closing.

moved to ((WikiFarm))

Hi,

It just occurred to me that when upgrading to 1.10, users will need a script or something to create tiki_p_edit_categories perms for each tiki_p_view_categories perm that category objects have in the db.

This is necessary to preserve backward compatible state when upgrading, because tiki_p_edit_categories does not exist in 1.9.

Anyone good enough in SQL to write this purely in SQL, or should this be part of the PHP in the upgrade/install script for 1.10?

Neihter show_image.php?id=NN nor imageNN work as-is after upgrade from 9.x to 12.x

for show_image.php?id=NN inside img plugin, they work again if I add this extra bit to the urls inside the __img src=""__ bit: &scalesize=0

So that this works in Tiki12:

{CODE()}
{img src=show_image.php?id=NN&scalesize=0}
{CODE}

But the default syntax written in the Tiki9 site didn't work after the upgrade to Tiki12:

{CODE()}
{img src=show_image.php?id=NN}
{CODE}

I just installed a brand new tiki trunk on local (Ubuntu GNU/Linux 8.04, using Mysql 5.0.51a), and tiki-install.php returned those error messages:
{CODE()}
SELECT patch_name FROM tiki_schema
Table 'tikitrunk_svn.tiki_schema' doesn't exist
CREATE TABLE tiki_tracker_fields (
fieldId int(12) NOT NULL auto_increment,
trackerId int(12) NOT NULL default '0',
name varchar(255) default NULL,
options text,
type char(15) default NULL,
isMain char(1) default NULL,
isTblVisible char(1) default NULL,
position int(4) default NULL,
isSearchable char(1) NOT NULL default 'y',
isPublic char(1) NOT NULL default 'n',
isHidden char(1) NOT NULL default 'n',
isMandatory char(1) NOT NULL default 'n',
description text,
isMultilingual char(1) default 'n',
itemChoices text,
errorMsg text,
visibleBy text,
editableBy text,
descriptionIsParsed char(1) default 'n',
PRIMARY KEY (fieldId),
INDEX trackerId (trackerId),
) ENGINE=MyISAM AUTO_INCREMENT=1
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ENGINE=MyISAM AUTO_INCREMENT=1' at line 23

#2008-11-05 rook1666
ALTER TABLE tiki_calendar_items ADD COLUMN allday tinyint(1) NOT NULL default '0'
Duplicate column name 'allday'
#2008-11-20 JohannesMoser
ALTER TABLE `tiki_polls` ADD `anonym` ENUM( 'a', 'u', 'i', 'c' ) NOT NULL DEFAULT 'u'
Duplicate column name 'anonym'
#2008-11-25 kerrnel22
ALTER TABLE tiki_tracker_fields CHANGE type type VARCHAR(15) default NULL
Table 'tikitrunk_svn.tiki_tracker_fields' doesn't exist
{CODE}

nextdev.t.o Fatal error: Class 'TikiCachedContainer' not found in /path/www/lib/init/initlib.php on line 56

Just visit http://nextdev.tiki.org and you will see it. As of Jan 19, 2016. {sign user="xavi" datetime="2016-01-19T22:35:56+00:00"}

{img fileId="548"}

Hello,

tried to do fresh installation of Tiki-21 (from *.xz tarball) on my production server and the installer seemingly choked after selecting "Inno DB", iow. pressing the button did not show any effect and it looked as the installed just died.

After several attempts, I had to leave the process working for some time having some non computer-related tasks to do and after returning back to the computer, discovered that installer did finish the job, but no progress-bar dialog was visible, although the feature did work during my testing of Tiki before release, so it is certainly a regression.


Sincerely,
Gour

We have now a background behind the installer links.
It doesn’t look nice and a picture worth a 1000 words. ;-)

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

On a new 1.10 installation...

When logging in as the ADMIN for the first time, the Change Password Enforced page appears (requiring new admins to select a new password). The OLD PASSWORD field should be maintained (pre-filled) with the existing admins password (by default: ADMIN). This __used__ to be the case in 1.9.

Pre-populate the OLD PASSWORD field with the user's existing password. This field should be disabled, so the user cannot change it.

(it's a property of wiki pages). The other pages should not be changed compare to current situation.

OPcache is supposed to be built-in PHP 5.5 but we need to check for it.

We are documenting some ((info:Use Cases)) which will become profiles. To be able to developer/test/improve these profiles, we would need a site like [http://www.opensourcecms.com/index.php?option=com_content&task=view&id=180|Open Source CMS] but for all profiles. This site only shows one profile.

These 20+ demo sites would provide admin access to easily test any profile. It would encourage people to generate and improve various profiles as well.

Related:
((Profile Manager))
((TRIM))

To reproduce , install a fresh Tiki 13. x from SVN.

{CODE(caption="spurious svn directory")}root@:/var/www/13x# svn st
? components
root@:/var/www/13x#{CODE}

What is this for? Why doesn't it get stored in vendor like the others?

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))