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

In the new version of tikiwiki 3.0 is the tiki-3.0-pgsql.sql wrong. It looks like a copy of the mysql file. BUT: not only the pgsql, also the sqlite and oci8-file.

There are still the ENGINE elements, and some special types from mysql like KEY instead of INDEX or Triger for pgsql

And some cleanup of theses pages would be nice:
http://doc.tikiwiki.org/tiki-index.php?page=Rewrite+Rules
http://tikiwiki.org/TikiWikiRewriteRule

tiki-backup.php was like performing surgery on yourself. It can work but it's risky.

For some reason, svn update FAILS to update on show.t.o instance linked to dev.t.o bug tracker item

Example:
https://dev.tiki.org/tiki-view_tracker_item.php?itemId=5493

Click at svn update.
It doesn't seem to update the instance, which still is at
Last update from SVN (12.5): Sunday 17 of January, 2016 15:28:05 CET - REV 57249 (MyISAM)

(as seen on http://xavi-9794-5493.show.tikiwiki.org/tiki-admin.php?page=general )

and to check the bug fix we need to update to r57742

---
I believe it to be a server-side issue, the AJAX request returns with a "504 Gateway Time-out" error, will ask the sysadmins... {sign user="jonnybradley" datetime="2016-03-14T18:59:33+00:00"}
---
update, the server side issue is fixed - was a disk space issue that was caught by monitoring but I had to figure out a way to delete instances logically from the oldest ones that are linked to closed tracker items. There is however still front-end issues (it seems that I have to click more than once for the user feedback spinner to appear, which is weird as well as it seems I have to scroll down {sign user="koth" datetime="2016-03-14T12:18:33+00:00"}

Installer allows to set language for the tiki site admin in the first screen of tiki-install.php. This used to work for years. I tested in 20.x and 21.x and it doesn't change lang of the interface. Tested with Catalan and Spanish, in case it matters. No change, installer continues in step 2 in English.

Revisions 63507 and its backports 63508 and 63509 broke language selection at step 1 of the installer. Selecting a language other than English causes a JavaScript error.

The only released version affected is Tiki 16.3.

This bug does not prevent changing the site language, only doing so from the installer.

I applied profile ((pr:GeoCMS_Maps))

Then whent to the blog created by the profile, edited it, and attempted to enable the comments on that blog, which triggered this error:

{CODE()}
System error.
The following error message was returned:

Incorrect integer value: '' for column 'related_max' at row 1
The query was:

update `tiki_blogs` set `title`=? ,`description`=?,`user`=?,`public`=?,`lastModif`=?,`maxPosts`=?,`heading`=?,`use_title`=?,`use_title_in_post`=?,`use_description`=?,`use_breadcrumbs`=?,`use_author`=?,`add_date`=?,`use_find`=?,`allow_comments`=?,`show_avatar`=?,`always_owner`=?, `post_heading`=?, `show_related`=?, `related_max`=?, `use_excerpt`=? where `blogId`=?
Values:

My Personal GeoBlog
Random daily thoughts and travel stories
admin
n
1501966273
10
Never a dull moment!
n
n
y
y
n
n
n
y
n
n
{* $Id: blog_post_heading.tpl 58008 2016-03-19 22:26:34Z lindonb $ *} {if $blog_data.use_title_in_post eq 'y'} {capture name="blog_actions"}{include file='blog_actions.tpl'}{/capture} {title url={$blogId|sefurl:blog} actions="{$smarty.capture.blog_actions}"}{$blog_data.title}{/title} {/if} {if $blog_data.use_breadcrumbs eq 'y'} <div class="breadcrumb"><a class="link" href="tiki-list_blogs.php">{tr}Blogs{/tr}</a> {$prefs.site_crumb_seper} <a class="link" href="tiki-view_blog.php?blogId={$post_info.blogId}">{$blog_data.title|escape}</a> {$prefs.site_crumb_seper} {$post_info.title|escape}</div> {/if} {* below is example code. In case you desire to add more info to the default blog heading * remove the line above (starting curly bracket then asterisk) and the last line to enable <div class="bloginfo"> {tr}Created by{/tr} {$post_info.user|userlink} {$post_info.created|tiki_short_datetime:on}<br> {tr}Last post{/tr} {$post_info.lastModif|tiki_short_datetime}<br> </div> *}
n
n
1
The built query was likely:

update `tiki_blogs` set `title`='My Personal GeoBlog' ,`description`='Random daily thoughts and travel stories',`user`='admin',`public`='n',`lastModif`='1501966273',`maxPosts`='10',`heading`='Never a dull moment!',`use_title`='n',`use_title_in_post`='n',`use_description`='y',`use_breadcrumbs`='y',`use_author`='n',`add_date`='n',`use_find`='n',`allow_comments`='y',`show_avatar`='n',`always_owner`='n', `post_heading`='{* $Id: blog_post_heading.tpl 58008 2016-03-19 22:26:34Z lindonb $ *} {if $blog_data.use_title_in_post eq \'y\'} {capture name=\"blog_actions\"}{include file=\'blog_actions.tpl\'}{/capture} {title url={$blogId|sefurl:blog} actions=\"{$smarty.capture.blog_actions}\"}{$blog_data.title}{/title} {/if} {if $blog_data.use_breadcrumbs eq \'y\'} <div class=\"breadcrumb\"><a class=\"link\" href=\"tiki-list_blogs.php\">{tr}Blogs{/tr}</a> {$prefs.site_crumb_seper} <a class=\"link\" href=\"tiki-view_blog.php'n'blogId={$post_info.blogId}\">{$blog_data.title|escape}</a> {$prefs.site_crumb_seper} {$post_info.title|escape}</div> {/if} {* below is example code. In case you desire to add more info to the default blog heading * remove the line above (starting curly bracket then asterisk) and the last line to enable <div class=\"bloginfo\"> {tr}Created by{/tr} {$post_info.user|userlink} {$post_info.created|tiki_short_datetime:on}<br> {tr}Last post{/tr} {$post_info.lastModif|tiki_short_datetime}<br> </div> *} ', `show_related`='', `related_max`='n', `use_excerpt`='1' where `blogId`=?
Stacktrace:

* /var/www/html/17.x/tiki-edit_blog.php : 0 -> {main}(array ( ))
* /var/www/html/17.x/tiki-edit_blog.php : 155 -> replace_blog(array ( ))
* /var/www/html/17.x/lib/blogs/bloglib.php : 481 -> query(array ( ))
* /var/www/html/17.x/lib/core/TikiDb/Bridge.php : 27 -> query(array ( ))
* /var/www/html/17.x/lib/core/TikiDb/Pdo.php : 120 -> handleQueryError(array ( ))
* /var/www/html/17.x/lib/core/TikiDb.php : 162 -> handle(array ( ))
{CODE}

---
Unable to reproduce in the show.t.o instance linked to this bug report, but only reproduced at home, which uses Mysql 5.7 (Ubuntu 16.04.x GNU/Linux which comes with Mysql 5.7) {sign user="xavi" datetime="2017-08-05T22:09:51+00:00"}

In case it matters, I enabled also this bunch of comment-related features:
{CODE()}
The following changes have been applied

Preference feature wiki comments enabled (Preference name: feature_wiki_comments)
Preference feature inline comments enabled (Preference name: feature_inline_comments)
Preference feature article comments enabled (Preference name: feature_article_comments)
Preference comments vote enabled (Preference name: comments_vote)
Preference feature image galleries comments enabled (Preference name: feature_image_galleries_comments)
Preference tracker show comments below enabled (Preference name: tracker_show_comments_below)
Preference feature poll comments enabled (Preference name: feature_poll_comments)
Preference comments archive enabled (Preference name: comments_archive)
Preference feature file galleries comments enabled (Preference name: feature_file_galleries_comments)
Preference wiki comments simple ratings enabled (Preference name: wiki_comments_simple_ratings)
Preference wikiplugininline trackercomments enabled (Preference name: wikiplugininline_trackercomments)
Preference wiki comments displayed default enabled (Preference name: wiki_comments_displayed_default)
Preference wiki comments form displayed default enabled (Preference name: wiki_comments_form_displayed_default)
{CODE}

In 1.9, templates_c existed with some administrative files (templates_c/index.php, etc.):
http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/?pathrev=BRANCH-1-9

Since we moved to SVN, in time for 2.0, this was "lost"
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/2.0/

This causes that people that install TikiWiki via FTP, from zip file, --need to manually create this folder (useless annoyance)-- Actually, it was created by tiki-install.php but I see no reason not bundle this folder.

People that use sh setup.sh to install are OK because this script creates this directory (and others?)

A lot of people install with FTP.

They do not have shell access and do not run setup.sh

Up to 1.9.11, templates_c was part of the .zip

However, for some reason, in 2.x and 3.x, --you need to manually create this directory.-- Oups, no, installer created. Nonetheless, the directory is back in 3.0

This should be restored to previous behavior.


1- It should have an index.php to prevent directory browsing
2- ((TRIM)) cleaner should not delete this index.php
3- clear caches in tiki-admin_system.php?do=templates_c should not delete this index.php

The only things I can see in my home page was some errors :
The first error message on my site was :
{img src=images/code.png}%%% {CODE()}
Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s):
(/tmp/:/www/magowiz.net/:/var/lib/php5/:/var/lib/php4/:/usr/share/php:/usr/local/php4/share) in /www/magowiz.net/www/lib/init/initlib.php on line 101
{CODE}

Suggested message if PHP5 is not detected:

^
__TikiWiki 3.0 requires PHP 5.x__

Your currently detected PHP version is: (versionnumber)

Please contact your web host to request an upgrade. If there is no way you can have PHP 5.x, please use Tiki 2.x instead. Some features in Tiki 2.x, such as profiles and TikiTests require PHP5, but all the other hundreds of features work perfectly with PHP 4.1+

For more information:
http://www.gophp5.org/
http://tikiwiki.org/
^



(9:59:42 AM) marclaporte: turning on TikiTests crashed by site :
(9:59:42 AM) marclaporte: Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /home/profiles/public_html/tiki_tests/tikitestslib.php on line 59
(9:59:53 AM) marclaporte: I suspect because I don't have php5
(10:00:01 AM) marclaporte: http://profiles.tikiwiki.org/

This would avoid this type of issue:
http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=6&comments_parentId=21274

Maybe at each release, we could add one test of the DB to see if the most recent sql additions were done.


phplist does this well. Once click and your DB is in the right format.

I upgraded from php4 to php5. I had some sites with white pages and nothing in the error log.

Finally, it was:

"this web application requires mysqli php extension. We have enabled it and it look ok now."

Tiki could have detected and reported this.

Move discussion here:
((Test server compatibility))

tiki-admin.php?page=gal tells me if GD or Imagick is installed. Nice.

But sometimes, it's installed, but it doesn't work as it should. To rule out that the problem is with Tiki, here is an example of a simple php to test GD in real life. It would be nice to add to tiki-admin.php?page=gal

{img src=images/code.png}%%% {CODE()}
<?php
header("Content-type: image/png");
$im = @imagecreate(110, 20)
or die("Cannot Initialize new GD image stream");
$background_color = imagecolorallocate($im, 0, 0, 0);
$text_color = imagecolorallocate($im, 233, 14, 91);
imagestring($im, 1, 5, 5, "A Simple Text String", $text_color);
imagepng($im);
imagedestroy($im);
?>
{CODE}

{syntax type="tiki" editor="plain"}
Today I installed a new Tiki28.x from CVS (gitlab).
After importing the database I went on the General setting screen.
The Browser Title displayed was "My Tiki" as it should have been on a default install with a new database.
Not with an update.
Other informations (like my email) where ok.

I changed it to the original Browser Title.
I have no idea if only the display on the install screen was wrong or if saving would have obliterate the initial Browser Title of this Tiki.

Tested on a second Tiki, continued the installation... the Title Browser is replaced with My Tiki.
Highly unpleasant and damageable for SEO if you don't pay attention it happened.

Screenshot: https://ibb.co/zKW33B6

After 20 years no one has a real idea of who is using Tiki and where and users are not effieciently converted into members. Some even struggles to get in contact with other members of the community and it is an active action and sometimes time consuming.

We have no idea of the areas, country or continent where Tiki is used or popular and who, among the power users or consultant will be able to better provide support.

The Tiki ecosystem critically need to regroup, understand where it stand, help its users to find support when needed and be kept in the loop of information.

While we don't want to be intrusive, it is fairly possible to include at the installation process (the page where we talk about the Community) an __optional__ automatic registration on the user (admin email address) to tiki.org. This should include some way to have an area or country information

This will provide better way to be informed about our software popularity, inform our users about Tiki (news, progress, event and updates) as well as help the dozen of users fighting to be registered (or simply moving away) from being new member of the community.


While completing this bug report I found out the following (another proof there are things we are not very good at and we should improve by using such automation):
* https://dev.tiki.org/item8589-Registering-to-tiki-org-register-option-is-barely-visible-at-t-o-on-the-login-box-popup
* https://dev.tiki.org/item8590-Registration-should-be-brought-forward-at-tiki-org-get-involved-page

{syntax type="tiki" editor="plain"}
Please see https://info.tiki.org/Version+Lifecycle to say what we do, and do what we say

{img fileId="949"}

People will thus expect security fixes on 6.x and 11.x (which they shouldn't)

The end of life should be announced on info.tiki.org

Maybe some of you will think of this as a "marketinhg" thing, but let's face it : for most users on the Web "wiki" is synonym with "MediaWiki-powered sites that look like wikipedia".

What I propose is to create the theme and tools to facilitate migration of mediawiki powered sites to tikiwiki the (very) easy way : fill a form during install that points to the Mediawiki database, and extract all the info to automagically populate the Tiki. I'm willing to participate, but I do not feel I have the required knowledge at this moment to be able to do something useful in the coding part : I know little to no PHP or MySQL stuff, I even wasn't able to install Tiki properly here (shame on me).

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

At the Cartograph set up page under the "Instructions" heading. Item number 5 has an invalid URL directing the user to a website to obtain mapping icons.

{CODE()}5. Upload in the File Gallery (in the "Icons" gallery folder) some icons that can be used as markers on the maps. A great source is: https://mapicons.nicolasmollet.com/category/markers/. You can upload a zipped file and ask Tiki to unzip the files.{CODE}

The website url https://mapicons.nicolasmollet.com/category/markers/ appears to be either invalid or non-existent.

The following url is the url I believe we are trying to reach https://mapicons.mapsmarker.com/

Trying to install tiki 25.1. New clean directory next to 25.0.
Only changed apache2 sites available config paths from /25.0 to /25.1
Copied local.php from 25.0/db to 25.1/db
Restarted apache2, cleared browser cache.
PHP 7.4.33 (cli) (built: Feb 14 2023 18:31:54) ( NTS )

Is there something missing from 25.1 ?

Hello,

I have reached the end of an installation of 5.0 with à database upgrade by 4.2 installer form a 3.3 site.

To reach this point after one month, I need to find and make the patches of bugs form which 3 on 5 are corrected into the current 5.x (SVN repository)

After I could obtain the home page, this appends :

1 - the "main admin" sends the message :

__INVALID DATABASE run installer__,

2- You run installer again, the installer says __"Database upgraded successfully"__

3- You run normally tikiwiki and then come back to point 1, eternally

If I join documents they can be the HTML page capture from Zotero but I don't think that they will be useful or the .zip of the database (600ko) for test.

I have surely no information to try to understand this issue.

When I try to execute some command I have quite not any command which can be run without an error :
- All displays are like UTF8 on a latin1 display (while Firefox say Page encode UTF8)
- Try to edit user pref : -> system error table ".tiki_trk_1" not found
- Try to display Wiki page or article content : the url called misses any module (*.php) tu run and no query "?" but only a part of the query content (like "http://mysite/<article_name>.

- Modify-edit page or article leads to an empty page

etc.

Trebly

If have two Tikis running on 18.8 (before anyone asks: I cannot go to 21.x, because 21.x breaks my CSS layout...). As I discussed in the Forums before I started this bug report, one (the older) just recently stopped searching. Only when logged in as Admin I could see the reason behind that: A COLLATE clash...

{CODE(Colors="Tiki")}
Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='

Die Abfrage war:
SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits`

The built query was likely:
SELECT DISTINCT c.`title` AS name, LEFT(c.`data`, 240) AS data, p.`hits` AS hits, c.`commentDate` AS lastModif, CONCAT(p.`pageName`,': ',c.`title`) AS pageName,outputType ,p.`pageName` AS id1,c.`threadId` AS id2, MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) AS relevance FROM `tiki_comments` c, `tiki_pages` p left join `tiki_output` on `tiki_output`.`entityId` = p.`pageName` WHERE c.`objectType` = 'wiki page' AND p.`pageName`=c.`object` AND MATCH(c.`title`,c.`data`) AGAINST ('Kämpfer' IN BOOLEAN MODE) ORDER BY relevance desc, p.`hits`
{CODE}

This older Tiki began YEARS ago (on 2.something?) and went through numerous updates, so far with no problems. The newer one started on 18 (or 12).

Interestingly, both databases have default collation set to utf8_general_ci.

When checking collation with
{CODE(Colors="Tiki")}
SHOW TABLE STATUS
{CODE}

I found that almost all tables were set to utf8_unicode_ci, but some were not (galaxia_workitems,index_628bfa7e573fa,index_pref_de,tiki_activity_stream_rules,tiki_addon_profiles,tiki_credits_usage,tiki_galleries_scales,tiki_goal_events,tiki_h5p_contents,tiki_h5p_contents_libraries,tiki_hp5_libraries,tiki_h5_libaries_cachedassets,tiki_h5_libraries_hub_cache,tiki_h5_libraries_languages,tiki_h5_libraries_libraries (!),tiki_hp5_results,tiki_h5p_tmpfiles,tiki_object_scores,tiki_output,tiki_scheduler,tiki_scheduler_run,tiki_search_queries (!),tiki_stats,tiki_tabular_formats,tiki_user_monitors).

Now that looks like a bug in one of the upgrader scripts.

However, a look at the tables of the newer Tiki showed that there was only one table that used the same collation as the database's default: index_pref_de. ''__All others were set to utf8_unicode_ci!__'' Now that would then be a bug in the installation procedure...

I am not a SQL expert, but I would like to recommend that Tiki sets the default collation to whatever Tiki shall use in the future and then leaves the default (i.e. not declare individual collation). Any individual collation definition is prone to be a future source of trouble...

many object names too long for oracle which has max size of 30 for any object (column, table, sequence, etc.)

able to modify some items such as sequence and trigger that are internal to db and not in tiki code.

initial oracle-1.9-oci8.sql had many errors including the use of datatype integer and auto-increment which doe not exist in oracle. additional insert to blob column not formed to use oracle utl_raw.cast_to_raw. oracle quote in sql field insert should be two quotes ('') instead of backslash quote (\')

main tables still not available
tiki_content_templates_sections
tiki_forums
because outbound_mails_for_inbound_mails column
tiki_live_support_message_comments

is there a workaround that if I change the object name in the database to be <=30, that the code will not abort.

- Usage of "CLOB" in Oracle different from "Text" in MySQL, so usage of every table has to be checked.
(especially where LOB-Index is used as a reference (e.g. tiki_languages))

- Oracle can not use CLOBs for indices so search functionality has to be checked (fulltext index?)

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