Category: Release Blocker

Just too many servers with no datetime setting right now. This needs to be addressed at least at the minimum with a more graceful check and error, perhaps on running the installer?

FYI: There were no issues in the same server with Tiki 12.x installs. (=>"regression" category added)

{CODE()}[root@tikisuite 12]# sh setup.sh

Tiki setup.sh - your options
============================

c run composer and exit (recommended to be done first)

f fix (classic default) o open (classic option)
S clear screen

predefined Tiki Permission Check models:
----------------------------------------

1 paranoia
2 paranoia-suphp w suphp workaround
3 sbox W sbox workaround
4 mixed
5 worry 6 moreworry
7 pain 8 morepain
9 risky a insane

q quit x exit

There are some other commands recommended for advanced users only.
More documentation about this: http://doc.tiki.org/Permission+Check

Your choice [c]?
#!/usr/bin/env php
Some settings on your machine may cause stability issues with Composer.
If you encounter issues, try to change the following:

Your PHP (5.3.3) is quite old, upgrading to PHP 5.3.4 or higher is recommended.
Composer works with 5.3.2+ for most people, but there might be edge case issues.

Downloading...

Composer successfully installed to: /var/www/html/12/temp/composer.phar
Use it: php temp/composer.phar
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension d om is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension d om is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/ phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].

Composer failed, retrying in 5 seconds, for a few times. Hit Ctrl-C to cancel.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- phpunit/phpunit 3.7.28 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for phpunit/phpunit 3.7.28 -> satisfiable by phpunit/phpunit[3.7.28].{CODE}

12.x svn LTS recent regression: mysql table for unified index doesn't exist and page edit displays fatal error (even if edition saved properly)

I recently noticed that, in a few tikis that I migrated from a server to a new one. They were working fine for a few days, unified search index being updated on a cron job at night time, page edits fine, etc.
And suddenly, page edits in some tiki sites started to display this fatal error message of missing mysql table for the index (using Mysql Full Text Search engine for the advanced unified search).

I also noticed that the index update failed for one site because some tracker field had a perm name too long for Mysql Full Text Search as unified search engine.

Anyway, I'll dop a note here just in case other people start to experience similar issues, so that we can look for common patterns to track the issue down.

In myc ase, workaround was to manually reindex again the site through console. Then no error was shown in further wiki page edits for the same users, etc.

After I upgraded a site from 10.x to 12.x, and cleared caches, I got this error when attempting to see or login at the site:

12.x: Fatal error: Unsupported operand types in lib/setup/prefs.php on line 406

using 12.x svn (r53316)

The site uses LDAP, so maybe some pref in LDAP settings interferes somewhere?

our server uses PHP Version 5.3.5-1ubuntu7.2ppa1~lucid1

Image width is set to 600
Image height is not set

Thus, it should be proportional, no?

Please see:
{img fileId="829"}
---
This is happening also to any 12x site based on svn.
Regression was introduced by r52064 in 13.x, and its backport to 12.x (r52066)
{CODE()}
[bp/r52064][FIX] When remote server whre image is down, img plugin will try in vain to get image until timeout which causes page not to load
Authored by: nkoth 2014-07-22
{CODE}

See it reproduced here:
http://xavi-9794-5599.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=1&cookietab=2

u: admin
p: 12345

{CODE()}
Fatal error: Uncaught exception 'Exception' with message 'No template available for n - view' in /var/www/xavi-9794-5599/lib/trackers/trackerlib.php:75 Stack trace: #0 /var/www/xavi-9794-5599/lib/smarty_tiki/function.trackerfields.php(150): TrackerLib->getSectionFormatTemplate('n', 'view') #1 /var/www/xavi-9794-5599/templates_c/en_basic^27844a6db0a459631df676325f554f23b85339c7.file.tiki-view_tracker_item.tpl.php(254): smarty_function_trackerfields(Array, Object(Smarty_Internal_Template)) #2 /var/www/xavi-9794-5599/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(188): content_550af41d208c17_48420797(Object(Smarty_Internal_Template)) #3 /var/www/xavi-9794-5599/lib/init/smarty.php(297): Smarty_Internal_TemplateBase->fetch('tiki-view_track...', NULL, NULL, NULL, false) #4 /var/www/xavi-9794-5599/lib/init/smarty.php(259): Smarty_Tiki->fetch('tiki-view_track...', NULL, NULL, NULL) #5 /var/www/xavi-9794-5599/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(394): Smarty_Tiki->fetch('tiki in /var/www/xavi-9794-5599/lib/trackers/trackerlib.php on line 75
{CODE}

{syntax type="tiki" editor="plain"}
Search for prefs or fulltext search in 30.0beta release (installed from tarball) returns:
{CODE()}
System error.
The following error message was returned:

Variable 'innodb_ft_user_stopword_table' can't be set to the value of 'tiki-fresh/index_pref_en_stopwords'
The query was:

SET SESSION innodb_ft_user_stopword_table = ?
Values:

tiki-fresh/index_pref_en_stopwords
The built query was likely:

SET SESSION innodb_ft_user_stopword_table = 'tiki-fresh/index_pref_en_stopwords'
{CODE}

Similarily for other languages.

I have setup a forum for a freshly upgraded Tiki pre-17 trunk :
''( Last Update from SVN (17.0svn): Wednesday, 22 March 2017, 19:03:57 CET- REV 61822 )''
Then I added an eMail to send to from the forum to the email address, what works.

After that I added another email - a pop account - and saved and then the forum is not accessible in view mode anymore: my.example.com/forum5 shows a WSOD white screen.
Deleting the mail account, the forum works fine again.

As we are using this feature on tiki.org heavily and other users might also, I consider this a a 'Release Blocker'.

#

In Tiki 13, the Admin Modules is always reverting back to the 1st tab and is making the page extremely unusable.

An attempt was made at Tikifest to fix it by using the new way to set the tab via anchor, but it seem to take effect only if coming from other pages, not from the current page. What is a possible fix then? To split up the admin modules page into multiple pages, or to do actions through more AJAX services perhaps?

{syntax type="tiki" editor="plain"}
Currently in master ([https://gitlab.com/tikiwiki/tiki/-/commit/fa7d91ee2af2f24cc5a4c6ffecb0438dfdd138cb] - March 4) the admin option for site theme has no effect. Instead, the admin theme is used for the whole site. Because the global theme can't be set, the theme-switch module also has no effect.

I would say this is a release blocker, as it's essential to be able to set the site theme (and not just by using the admin theme option).

Also, user doesn't appear in filtered list after being added

{flash type="url" movie="display290" width="1028" height="699"}

After a command line installation, I can't log in.

The jQuery dialog boxes used on the Admin Modules page for assigning modules aren't showing up properly.

{syntax type="tiki" editor="plain"}
When assigning a new module, the page layout and process for the user have changed. I'm comparing a Tiki 27 to master - I don't know whether all the changes were intentional but it kind of amounts to a "mini-revamp" with maybe a combination of intentional changes and unintentional results.

In Tiki 27, after clicking the "Add module" button, the page that displays has the "Edit module" tab open and a selector to choose the new module and, below that, the "Module Options" button. It's very straightforward and uncluttered. When you click the "Module Options" button, the page opens to the "Basic" tab where you select the module zone for it, etc.

In master, when you click the "Assign new module" button, the same page displays again, cluttered with the tabset containing the module zone tabs and already-assigned modules, with the "Assign new module" button displaying __again__, then down below the tabset is the selector to choose the module. The button was already clicked; it shouldn't display again. The tabset is just in the way. It isn't needed in this step of the process.

I think the problem is because the tabs aren't quite right. Initially when you navigate to the admin-modules page, the tabs are "Assigned modules", "Custom Modules", and "All Modules". When you click the "Assign new module" button, the page displays these tabs: "Configure new module", "Custom Modules", and "All Modules". But the page also displays the assigned modules. These should display under an "Assigned modules" tab, not under "Configure new module". This tab arrangement can be seen after clicking the "Module options" button, after selecting a module. Now the tabs are "Assigned modules", "Configure new module", "Custom Modules", and "All Modules". This is how the tabs should be on the previous page.

There's another problem in that when you do arrive on this page, to edit/configure the module, there are four new tabs: "Basic", "Module", "Appearance", and "Visibility". In previous Tiki versions, the "Basic" tab is open, which is the logical choice. In master, though, the "Module" tab is open and the user has to switch tabs to "Basic" to specify the module zone, module position, visibility to groups, etc. that I imagine are generally set first, and which was the case in older Tiki versions.

Bootstrap icons are not found with bootswatch themes that have the font icon path set in their less file to a different location than used in Tiki. For example for the bootswatch amelia theme, the {DIV(type=span class=inline_syntax)}styles/bootswatch_themes/options/amelia/less/varibles.less{DIV} file has the variable {DIV(type=span class=inline_syntax)}@icon-font-path{DIV} set to {DIV(type=span class=inline_syntax)}"../fonts"{DIV}, when it should be set to {DIV(type=span class=inline_syntax)}"../vendor/twitter/bootstrap/fonts/"{DIV}.

To avoid having to alter the bootswatch themes which could complicate upgrading them, there should be a tiki specific less file that sets this variable and overrides that in any individual theme less file. This would mean this variable would not need to be set in any theme less file (currently it is set in each tiki theme file). The same should be done for the {DIV(type=span class=inline_syntax)}@icon-font-name{DIV} and {DIV(type=span class=inline_syntax)}@icon-font-svg-id{DIV} variable names as well.

Below is a demonstration of the problem with screenshots of {DIV(type=span class=inline_syntax)}tiki_list-trackers.php{DIV}:

Missing icons with the Bootswatch Amelia theme:
{img fileId="787"}

Icons are present in the bootstrap default theme:
{img fileId="788"}

After changing admin pass in a brand new Tiki install the user is sent to example.com/Homepage even if the preference was not enabled by default, and the server didn't support it, like in the case of show.t.o.

This can produce the awful impression that Tiki is broken just in your first trial/test in a server.

There is a link from the installer (step 8) which is broken:
https://tiki.org/tiki-newsletters.php?nlId=8&info=1

Result is:
---
!An error occurred while performing the request.
Things to check:

* Did you complete the Tiki Installer?
* Is your database corrupt? Please see how to repair your database
* Are your database settings accurate? (username, schema name, etc in db/local.php)

Please see the documentation for more information.
---

Sheds bad light on Tiki if people cannot subscribe to "__Subscribe to Tiki Releases newsletter - Critical & Security update__" as advertised.

Since about last week tiki-browse_categories takes about 10 times as slow as before.

Jonny can you help? I tracked it down to fix in r47923 that luci committed to fix an object count problem. (I sent an email)

I did several upgrade lately from Tiki 15.x, Tiki16.x, Trunk, 15.4 package, 16.2 package and today’s daily from 16.3.

Somewhere near 15.4 release something was broken and the browsertitle pref is empty instead of showing previous data at tiki-install.php / Configure General Settings.

At https://tiki.org/calendar page keep refreshing on and on.
Tested on Mac Safari Chrome and Windows Chrome.

Can not edit Wiki Pages in Tiki 13.0 using Chrome or Netscape. IE10 is working fine.

Details: I upgraded my Server from Tiki 7.0, PHP 5.2, MySql 5.1 to Tiki 13.0, PHP 5.6, MySql 5.5.

I needed to do the Datebase Upgrade with the console.php. Otherwise tiki-install.php stuck with an error in Perms/Context get_user_xxx:

Then I did choose Unified Search and upgraded and rebuild the index with the console.php.

After this I can edit Wiki pages using the IE10 10.0.20 x32 or x64 Browser just fine!

But Chome and Netscape Browser on Windows and Linux both x32 and x64 versions are have all the same error: They do not allow to put the cursor into the edit pane and there seems to be somthing that blocks the mouse and cursor to get to the edit textarea.

Can someone verify this behavior?

Has someone a solution for this?

Now the details of the used browsers:

Working: => Wiki page edit pane is functional and I can edit the content and save it successfull!
*Internet Exporer IE10 Version IE 10.0.9200.17088 x32 Win 8.0 x64
*Internet Exporer IE10 Version IE 10.0.9200.17088 x64 Win 8.0 x64


Failing: => Wiki page edit pane locked. Can not enter or change anything of the content.
*Google Chrome - Version 37.0.2062.124 m (64-bit) Windows 8.0 x64
*Google Chrome - Version 37.0.2062.120 (64-bit) Linux/Debian 7.6 x64
*Mozilla Firefox 32.0.3 x32 Windows 8.0 x64
*Mozilla Firefox 32.0.3 (64-bit) Linux/Debian 7.6 x64

Info: There are no difference if I try to edit a new wiki page or an existing one.

can't upload an image to a file gallery in doc.t.o with elfinder (default UI) since 16.x

To reproduce:
#I'm logged in as user "xavi" (with no admin perms, I mean)
#I edit one page, e.g. ((doc:Tiki17))
#place the cursor somewhere in the text.
#Click at the button from the toolbar to "Choose or upload images"
#The elFinder UI popup is shown with no contents, and I?m not able to click anywhere (browser non.-responsive), while I can't only get access to use the browser again when the wiki pedit page is automatically refreshed with the elFinder automatically disappearing.
#Reproduced also after clearing my Browser cache, and Tiki caches, with Chromium and Firefox.

On module creation :
( ! ) Fatal error: Class 'convertToTiki9' not found in /Users/Bernard/Documents/Shocksite/www/htdocs/retroRGB/lib/modules/modlib.php on line 76

The module is created.

{syntax type="tiki" editor="plain"}
With elFinder enabled attaching as file to a tracker items doesn't work and fails silently (but sometimes you get "File #1550620800 missing (was attached to trackerfield "picture" on item example title".

Seems ok (but ugly) without elFinder.

Reproduced on https://trunkdev.tiki.org/tracker10 - can't find nextdev to try it on 30.x (well, dev.tiki.org live site is already on 30.x {sign user="luci" datetime="2026-07-10T10:42:03+00:00"}) but it also fails on my locals.

--It seems the function -+addFile+- is no longer being called and I suspect {mr id=7598} may have been involved...-- correction, {mr id=6530} seems more likely (so it's been broken for over a year?) - maybe not either of these then...

When a wikipage uses a namespace, one cannot add a comment due that the "add comment" botton does not show up.

When renaming that page to not use a namepspace, it works.

Example:
"MyNamespace:_:MyPage" does not show the add comment botton.
renaming to
"MyNamespace_MyPage" does show the add comment botton.
or
"MyPage" does show the add comment botton.


Effects 14.x Trunk as of 18.1.2015.

For testing i used the standard default bootstrap template.