Fullscreen
Loading...
 
Skip to main content

Category: 9.x

9.x
Show subcategories objects

Name Type
tiki 9.0 install dies with PHP Fatal error Uncaught exception 'SmartyException' in smarty_security.php:381
After I select to use the database connection, tiki-install returns blank page.

Error message logged during a few retries:
Jun 27 19:51:15 kernel apache2: PHP Notice: unserialize(): Error at offset 0 of 5 bytes in /var/www/localhost/htdocs/tikiwiki/lib/setup/prefs.php on line 377
Jun 27 19:51:16 kernel apache2: PHP Fatal error: Uncaught exception 'SmartyException' with message 'directory '' not allowed by security setting' in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php:381
Jun 27 19:51:16 kernel Stack trace:
Jun 27 19:51:16 kernel #0 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/plugins/function.html_image.php(114): Smarty_Security->isTrustedResourceDir('img/icons/green...')
Jun 27 19:51:16 kernel #1 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/function.icon.php(212): smarty_function_html_image(Array, Object(Smarty_Internal_Template))
Jun 27 19:51:16 kernel #2 /var/www/localhost/htdocs/tikiwiki/templates_c/en18b660cf6951a7bde07357befc24a4e5^fa112beffbe935d6123ba78bf16e4de6898a7e56.file.tiki-browse_image.tpl.php(105): smarty_function_icon(Array, Object(Smarty_Internal_Template))
Jun 27 19:51:16 kernel #3 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_internal_templatebase.php(180): content_4feb4814e9bb29_68835866(Object(Smarty_Internal_Template))
Jun 27 19:51:16 kernel #4 /var/www/localhost/htdocs/tikiwiki/lib/init/smarty.php(194): Smarty_Internal_TemplateBase->fetch('tiki-browse_ima...', 'en18b660c in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php on line 381
Jun 27 19:52:18 kernel apache2: PHP Fatal error: Uncaught exception 'SmartyException' with message 'directory '' not allowed by security setting' in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php:381
Jun 27 19:52:18 kernel Stack trace:
Jun 27 19:52:18 kernel #0 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/plugins/function.html_image.php(114): Smarty_Security->isTrustedResourceDir('img/icons/green...')
Jun 27 19:52:18 kernel #1 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/function.icon.php(212): smarty_function_html_image(Array, Object(Smarty_Internal_Template))
Jun 27 19:52:18 kernel #2 /var/www/localhost/htdocs/tikiwiki/templates_c/899478d8f66ae50789ef4567806e9fba159fb70d.file.remarksbox.tpl.php(44): smarty_function_icon(Array, Object(Smarty_Internal_Template))
Jun 27 19:52:18 kernel #3 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_internal_templatebase.php(180): content_4feb485289d963_55269745(Object(Smarty_Internal_Template))
Jun 27 19:52:18 kernel #4 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/block.remarksbox.php(82): Smarty_Internal_TemplateBase->fetch('remarksbox.tpl')
Jun 27 19:52:18 kernel #5 /var/www/localhost/htdocs/tikiwiki/tem in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php on line 381
Jun 27 19:52:56 kernel apache2: PHP Notice: unserialize(): Error at offset 0 of 5 bytes in /var/www/localhost/htdocs/tikiwiki/lib/setup/prefs.php on line 377
Jun 27 19:52:59 kernel apache2: PHP Fatal error: Uncaught exception 'SmartyException' with message 'directory '' not allowed by security setting' in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php:381
Jun 27 19:52:59 kernel Stack trace:
Jun 27 19:52:59 kernel #0 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/plugins/function.html_image.php(114): Smarty_Security->isTrustedResourceDir('img/icons/green...')
Jun 27 19:52:59 kernel #1 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/function.icon.php(212): smarty_function_html_image(Array, Object(Smarty_Internal_Template))
Jun 27 19:52:59 kernel #2 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/block.self_link.php(132): smarty_function_icon(Array, Object(Smarty_Internal_Template))
Jun 27 19:52:59 kernel #3 /var/www/localhost/htdocs/tikiwiki/templates_c/en18b660cf6951a7bde07357befc24a4e5^484698837cbb46d4277f0d8a99265584d63a50a7.file.tiki.tpl.php(84): smarty_block_self_link(Array, '', Object(Smarty_Internal_Template), false)
Jun 27 19:52:59 kernel #4 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_internal_templatebase.php(180): content_4feb487a692cb9_95479002(Object(Smarty_Internal_Te in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php on line 381
Jun 27 19:53:05 kernel apache2: PHP Fatal error: Uncaught exception 'SmartyException' with message 'directory '' not allowed by security setting' in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php:381
Jun 27 19:53:05 kernel Stack trace:
Jun 27 19:53:05 kernel #0 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/plugins/function.html_image.php(114): Smarty_Security->isTrustedResourceDir('img/icons/green...')
Jun 27 19:53:05 kernel #1 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/function.icon.php(212): smarty_function_html_image(Array, Object(Smarty_Internal_Template))
Jun 27 19:53:05 kernel #2 /var/www/localhost/htdocs/tikiwiki/templates_c/899478d8f66ae50789ef4567806e9fba159fb70d.file.remarksbox.tpl.php(44): smarty_function_icon(Array, Object(Smarty_Internal_Template))
Jun 27 19:53:05 kernel #3 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_internal_templatebase.php(180): content_4feb48816e5dc4_03329759(Object(Smarty_Internal_Template))
Jun 27 19:53:05 kernel #4 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/block.remarksbox.php(82): Smarty_Internal_TemplateBase->fetch('remarksbox.tpl')
Jun 27 19:53:05 kernel #5 /var/www/localhost/htdocs/tikiwiki/tem in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php on line 381
Jun 27 19:53:29 kernel apache2: PHP Notice: unserialize(): Error at offset 0 of 5 bytes in /var/www/localhost/htdocs/tikiwiki/lib/setup/prefs.php on line 377
Jun 27 19:53:33 kernel apache2: PHP Fatal error: Uncaught exception 'SmartyException' with message 'directory '' not allowed by security setting' in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php:381
Jun 27 19:53:33 kernel Stack trace:
Jun 27 19:53:33 kernel #0 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/plugins/function.html_image.php(114): Smarty_Security->isTrustedResourceDir('img/icons/green...')
Jun 27 19:53:33 kernel #1 /var/www/localhost/htdocs/tikiwiki/lib/smarty_tiki/function.icon.php(212): smarty_function_html_image(Array, Object(Smarty_Internal_Template))
Jun 27 19:53:33 kernel #2 /var/www/localhost/htdocs/tikiwiki/templates_c/enbdb13e339b46aade55c78ddc060eb364^899478d8f66ae50789ef4567806e9fba159fb70d.file.remarksbox.tpl.php(35): smarty_function_icon(Array, Object(Smarty_Internal_Template))
Jun 27 19:53:33 kernel #3 /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_internal_templatebase.php(180): content_4feb489d7e3299_95750395(Object(Smarty_Internal_Template))
Jun 27 19:53:33 kernel #4 /var/www/localhost/htdocs/tikiwiki/lib/init/smarty.php(194): Smarty_Internal_TemplateBase->fetch('remarksbox.tpl', 'enbdb13e339b46a...', in /var/www/localhost/htdocs/tikiwiki/lib/smarty/libs/sysplugins/smarty_security.php on line 381

apache-2.2.22, php-5.4.4, gentoo install

tiki-8.4 runs fine
tracker item
No fileId on share file url when context menus are unchecked
When context menus are unchecked from look and feel and you applay to "share a link to this file" icon, url for download is served without fileId and tiki returns "File has been deleted (404)"
tracker item
Plugin Alias missing Save button - cannot create or edit new Plugin Aliases after upgrade
Was in Tiki 8.x too. Hoped it is fixed in Tiki 9 but it is still there.
tracker item
Feature request: Smart table of contents (ToC) display (depending on content size)
General idea i mentioned in the irc-channel and which earned at least some positive feedback from @ohertel.

Feature:
Please add some kind of preference(s) allowing Tiki to determine automatically whether a table of contents should display in a given page.

If enabled it would automatically display a TOC in all articles/pages having at least ''x'' main-sections. This would avoid wasting space for superfluous ToC-s, or editors wasting time controlling TOC-s.


Example:
---------
* Intelligent ToC is enabled and set to 3
* I do create a new article which has only a small amount of text/content and is using only 2 main sections (i.e. !SectionA & !SectionB) -> results in an article with no ToC
* If i do change the article now and add i.e. 1 new Sections (resulting in having 3 aka !Sections1, !Sections2, Sections3 including an automatically generated TOC





tracker item
Codemirror treats 2 hyphens used for an em-dash as a strikeout
Not working yet
tracker item
Issue while trying to create a new article with unaccepted chars in title
T
tracker item
Calendar Recurence
I
tracker item
Calendar module not nice in main page
T
tracker item
Allow to add a description / page for each freetags
I feel the need for a tag description field (that could be) associated to each freetag. That'd allow to place a definition (what does this tag mean ? what should it be used for ?) to make it as clear as possible for users to use the tags and know what they mean.

Not sure wether it was possible or not, I posted a message on the forum : http://tiki.org/tiki-view_forum_thread.php?comments_parentId=44367&forumId=4
tracker item
mb_split php function not available
Hi,

After upgrading my tiki install to 9.0, going to my website produced a blank page with the following error:
Fatal error: Call to undefined function mb_split() in /bla/bla/bla/tiki/lib/smarty/libs/plugins/shared.mb_str_replace.php on line 47

Apparently, my hoster planethoster doesn't provide a php install including the mb_split() function.

Regards,
Yannick
tracker item
Unable to upload files larger than ~8Mb
{syntax type="tiki" editor="plain"}
Uploading a file larger than ~8 Mb leads to the following message: An error occurred while performing the request. With suggested comments: 1. Did you complete the Tiki Installer? 2. Is your database corrupt? Please see how to repair your database 3. Are your database credentials accurate? (username, database name, etc in db/local.php).

With smaller files there is not problem. I tried at two different time, but after 40~45 sec. the error occurs.

My Tikiwiki installation seems to limit file size around 128 MB.

In the file php.ini I set both max_execution_time and max_input_time to 60.

Since nowadays 8Mb for files is common, this bug is really limiting the functionality of file gallery.
tracker item
.docx files uploaded as .zip files...
!Docx files are uploaded as zip files
When I upload ''.docx'' files to my Tiki-Wiki server (using the [http://cyberduck.ch/|Cyberduck WebDAV] client on Windows 7) they are uploaded with the mime-type ''application/zip'' instead of ''application/vnd.openxmlformats-officedocument.wordprocessingml.document'' (the correct one). Consequently the browser cannot directly open them which is very annoying.


!!Some attempts to debug the problem
When I try to access a file on the web server directly by manually putting it in the homepage folder and downloading it directly from the web server the file is recognized correctly. For me this means that the mime-type of the Apache server is working properly.

I checked the same issue with a the same configuration and a fresh installation at my home pc: It also didn't work. In both cases I was using the ''9.x SVN branch''.

Strange enough it did work when I tried to upload to [http://demo.tiki.org/|demo.tiki.org], (for both, ''8x'' and ''9x''). However the mime-type was set to ''application/ms-word'' which is strictly speaking also not correct (but at least it then opens correctly). I have no idea why it works there... (?)

My overall ''guess'' is that it has something to do with the fact that ''.docx'' files are actually zip files. Maybe somewhere a content based mime-detection is performed (be it in the WebDAV client, the Apache server or on the Wiki) but instead an extension based detection should have been used to distinguish ''.docx'' files from ''.zip'' files. It might also have something to do with the ''deflate mod'' (not sure).

In any case/whatever the reason the proposed solution below ''seems'' to fix all my issues and probably also some other people's issues.
tracker item
Latex Equation as tracker field
It would be nice if one could choose "Latex equations" as a tracker field type. E.g. for mathematical or chemical formulas.

More generally wiki parsed fields would be nice...
tracker item
Admin unable to use some File Gallery functions, such as "Create File Gallery" due to conflict with (tiki_p_admin) permission.
I am a new user to tikiwiki and have had a problem using File Gallery on two fresh separate installations of tikiwiki 8.4, and 9.0.

I only had one user set up which was the default admin user, and found that I was unable to use the "Create a File Gallery" function was also unable to "Edit" any file galleries that existed. When I tried either of these functions it would take me to a page that said

Error
You are not logged in. Go to Log in Page

even though I was logged in, if I clicked on "Go to Log in Page" it would take me there and show

Log in
Logged in as: admin

I turned on php error reporting and these are the errors I receive after clicking on save in create a file gallery function.

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 12
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 14
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 15
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/init/smarty.php
Line: 176
Type: ob_end_clean() [ref.outcontrol]: failed to delete buffer. No buffer to delete.

I do know small amounts of PHP scripting, html coding, and the like, and dove into some of the script, but I do not know where the user variable is supposed to be created to be passed from page to page, or if the cookie is somehow not being verified when trying to pass information from one page to the next.

I also went on tiki's forums and saw that a few others have posted similar experiences, but no working answers were supplied for me.
tracker item
WYSIWYG doesn't save the new content in wiki pages
{syntax type="tiki" editor="plain"}
Editing a simple wiki page, converted into wysiwyg, added new content, saved page, and nothing of the new content is saved (old content is shown at save time and when visiting the page again)
tracker item
exporting tracker fields fails: nothing is shown in the popup helper
{syntax type="tiki" editor="plain"}
* Select some tracker fields with the checkboxes
* Select in the dropdown at the bottom: export selected.
* Click at go
Some popup box is shown, but no fields exported.

This (equivalent feature to export tracker fields) was working in tiki6
----

tracker export failing: fyi, it might be related to the length of the tracker (and/or the internal url that is generated). Tracker has 55 fields. When I remove the last 20 (or so) fields: export fields works. when I remove the first 20, instead (in another clone of the source tracker), it works also
tracker item
Replacing tracker items at import time inserts them as new items
When you import tracker items, if you don't select the checkbox to create new items, they are supposed to replace the previous items that are there.

But this fails, and new items are created, without replacing the old ones.
---
confirmed still in trunk, SVN (11.0svn): Monday 22 of April, 2013 15:40:50 UTC- REV 45673
http://demo.tiki.org/trunk/tiki-view_tracker.php?trackerId=3
tracker item
Trackerfilter plugin doesn't always show filter boxes
!Trackerfilter plugin doesn't always show its filter boxes

When I add a trackerfilter to my wiki page, then at the beginning everything looks nice (i.e. I see filter boxes on top). But after a while the filter/search boxes are not visible anymore. Below is the code I use on my wiki page:

{CODE()}
{trackerfilter filters="47:66/d:55" action="Search" displayList="y" trackerId="3" line="y" fields="47:48:49:51:55" sort="y" showlinks="y"}
{CODE}

!!Some behaviour can make the filter boxes appear again:

when I edit the page and change e.g. the displayList from {CODE()}displayList="y"{CODE}
to {CODE()}displayList="n"{CODE} and then click ''Preview'', the filter button/boxes appear again and even remain after I click ''Cancel edit''!
tracker item
System Error searching categories with empty search box
{syntax type="tiki" editor="plain"}
Go to tiki-browse_categories.php to browse categories. I have one category defined, some wiki pages are a member of it.

Leave the "Find" box empty.

Select "..and its subcategories" box.

Click "FIND". A "System error" page appears, saying:

{CODE(caption="The system error text" wrap="1")}
The following error message was returned:

The query was:
SELECT DISTINCT c.*, o.* FROM `tiki_category_objects` c, `tiki_categorized_objects` co, `tiki_objects` o WHERE c.`catObjectId`=o.`objectId` AND o.`objectId`=co.`catObjectId` AND c.`categId` IN (?,?,?) ORDER BY `name` asc

Values:

0
-1

The built query was likely:
SELECT DISTINCT c.*, o.* FROM `tiki_category_objects` c, `tiki_categorized_objects` co, `tiki_objects` o WHERE c.`catObjectId`=o.`objectId` AND o.`objectId`=co.`catObjectId` AND c.`categId` IN ('','0','-1') ORDER BY `name` asc
{CODE}
tracker item
Objects cannot be assigned to categories more than 50 at a time
Categories are rather useful things. However, in a site with hundreds of objects, being able to add items to a category at maximum 50 a time makes life unnecessarily hard.

The use case in question: a site which needs review. I need to add all the wiki pages and articles to a "Requires Review" category following an update of a very old site with lots of content. I cannot, because this limit of 50 stops me from adding the lot in one go, and the lack of any discernible way to select objects which are *not* yet in the category for addition stops me from adding 50 at a time. I seem to be at an impasse, short of writing my own PHP code to add objects en-masse.

Something more like the page wiki index doesn't seem like it would be a very hard thing to add? However, I am not familiar with Tiki's internals so this is hard to estimate.
tracker item
Objects cannot be selected for addition to a category by their absence from a category
This is a complementary report to bug [item4278|#4276]. Essentially the Category object browser seems to be too limited in it's options for selecting objects to manipulate to realise the full potential that categories might offer. Specifically, the lack of a way to select all objects, or all objects *not* in a category prevents practical application of categories to large numbers of objects.

The use case in question: a site which needs review. I need to add all the wiki pages and articles to a "Requires Review" category following an update of a very old site with lots of content. I cannot, because the limit of 50 items on a page stops me from adding the lot in one go, and the lack of any discernible way to select objects which are *not* yet in the category for addition stops me from adding 50 at a time. I seem to be at an impasse, short of writing my own PHP code to add objects en-masse.

tracker item
.doc, .xls and .ppt uploaded as application/vnd.ms-office
!Old office documents are uploaded as ''application/vnd.ms-office''

Depending on the Wiki server I use (it works on my home pc but not on the main server I maintain) old office documents (i.e. ''.doc'', ''.xls'', ''.ppt'') are uploaded with mime-type ''application/vnd.ms-office''. Instead they should have the mime-type ''application/msword'' for ''.doc'', ''application/vnd.ms-excel'' for ''.xls'' and ''application/vnd.ms-powerpoint'' for ''.ppt''. Note that the new formats (''.docx'', ''.xlsx'', ''.pptx'') are set correctly.

!!Why do we want the correct (more precise) ''mime-types''?
The reason this is annoying (for me) is because I wanted to setup indexing of binary file content for searching. The search is based on the mime-type and with mime-type ''application/vnd.ms-office'' there is no easy way to assign it a ''binary-to-text-converter''. If however the files had the correct mime-types I could assign the corresponding conversion program for each mime-type...

!!Fixing mime-types based on file extension?
Again it would be nice if there was an option to fix mime-types based on their extension. If it works without that: fine! But I read at several places that ''Fileinfo'' extension is not really reliable. It would be nice if there was an option/program to make sure that all mime-types are set according to a Tiki-Wiki standard (independant of the web server used). It would also be nice if it could correct all existing files. Example:

I uploaded some files before the mime-type fix. They all have the type ''application/zip''. After the mime-type fix the files upload with the correct mime-type but I still have the existing ''application/zip'' files that I now have to search and fix manually by reuploading...

All in all I think it would provide a nice tool for users that have issues with mime-types...
tracker item
WSOD after insert of Wiki Page
{syntax type="tiki" editor="plain"}
When saving a new Wiki page, you get a white Screen of Death.

PHP Fatal error: Call-time pass-by-reference has been removed in ... on line 97

In PHP version 5.4 >



There is no reference sign on a function call - only on function definitions. Function definitions alone are enough to correctly pass the argument by reference. As of PHP 5.3.0, you will get a warning saying that "call-time pass-by-reference" is deprecated when you use & in foo(&$a);.

For example, use:

// Right way!
function myFunc(&$arg) { }
myFunc($var);

Rather than:

// Wrong way!
function myFunc($arg) { }
myFunc(&$arg);
tracker item
LDAP Group Sync in Tiki-9 Broken
I was unable to get group sync for ldap working, and after changing two lines of code in userslib.php I was able to get it working.

The changes I made are the __procedure__ section, and I have included my settings also in case someone is having a similar issue, or is just trying to set up LDAP group sync and would like to see a working example, and in case it is useful in your troubleshooting.
tracker item
images uploaded to tracker field image do not respect multitiki paths
Images uploaded to tracker field image do not respect multitiki paths.

When you upload an image to this type of field, they go to

__img/trackers/__

When you are in a multitiki of, let's say, site1.example.com and site2.example.com, you have a folder for site1 at:

__img/trackers/site1.example.com/__

but your image files don't get uploaded there, but to the general

__img/trackers/__

And the same with all the other multitiki sites.
When you want to backup files, or migate a site to a new server, you are in trouble to know which files belong to which site from the multiki installation.

For consistency with how multitiki works, they should be uploaded to, and used from, the multitiki-aware path:

__img/trackers/site1.example.com/__
tracker item
Show PHP error messages