Category: 6.x

One can ask for the realName "admin" and get it with no problem. In fact, all the 1000 users of a site could be called admin.
TW51

{syntax type="tiki" editor="plain"}
If you have a clean tiki 6.1 install, the default preview is made with some kind of ajax include above the edit area.
but this preview has no linebreaks in it.
if you disable this and have the "standard" (like in tiki 3.x) preview you have linebreaks in the preview

In earlier Tiki versions, the CAPTCHA for the registration was separate from other anti-bot protection. It was possible to have CAPTCHA protection for some areas (such as comments and trackers) but not other areas (such as registration).

I have several sites that use "Require Admin Approval" and/or passcode options for Registration, so the CAPTCHA is not needed.

In Tiki 6, CAPTCHA was made global -- there is no longer any way to have CAPTCHA support for some items, such as comments, but not other items (such as registration).

When Using IE 7.0

Also if you click on the Slideshow button, it opens a ie window but it shows only the "Close" button and no other image.

I have seen in Tiki File Gallery site a differente approach that may solve the problem. If any one knows...please share

The following (without a space between braces) does not work anymore:

~np~
you can use the ~np~{{user} }~/np~ ~np~~/np~~/np~ ~np~((doc:Argument Variables|Argument Variable))
~/np~

Instead the Argument Variable which is inside __np__ gets parsed as current user login name.

__Update:__ updated the Subject field to more reflect what is the report about

Usability bugs - not showstoppers but could use some polishing.

* no handling or warning if you subscribe a user without an email.
* No way to skip the confirm your subscription?
* Download the log file displays a blank page in the browser - temp/public/newsletter-log-2.txt
* adding a subscriber, selecting a user but checking "Add Email" crashes Tiki. (unhandled null)
* no way to filter or recognize anonymous spam bots

In general, wiki syntax is not parsed in notification mails. For example, the "New article post" notification email includes the full body of the newly posted article. However, Tiki includes the full wiki coding/syntax within the body of the message, and sends the mail message as plain text. Tiki should either:

1. Send the message as parsed HTML

or

2. Strip all formatting and send only the text.

{syntax type="tiki" editor="plain"}
number of tracker items shown by default: customizable in a tracker by tracker basis. To avoid (at least) the problems of huge memory consumption in big trackers (and thus, setting the default number of items shown to a small number), while keeping other trackers with more items shown by default

To reproduce:

1- tiki-admin_menus.php

2- click the permission key

ex.:
tiki-objectpermissions.php?objectName=Go Green&objectType=menus&permType=menus&objectId=56

{CODE()}Permissions
No rows found

Warning
You must select at least one feature.{CODE}

{syntax type="tiki" editor="plain"}
When accesing admin panel I get:

Warning: tempnam() [function.tempnam]: open_basedir restriction in effect. File() is not within the allowed path(s): (/home/httpd/wladcy.mage.pl/httpdocs:/home/httpd/wladcy.mage.pl/wladcy.mage.pl:/home/wladcy/:/tmp:/usr/share/pear:/var/lib/php/session/:/home/kloxo/httpd/script) in /home/wladcy/wladcy.mage.pl/lib/init/initlib.php on line 135

I don´t seem to find a way to do this.

To order and filter Tasks by user (that the task was send to).

If this is not done in Tiki, I will be nice to have it.

If this is done please point me to right direction.

Thanks

Using Tiki 6.2

{syntax type="tiki" editor="plain"}
There needs to be a restriction on the group handler similar to the mode in some of the other handlers.

Currently, if user A creates "Group A" and becomes the admin, then user B comes along and also creates a group called "Group A", then user B gets the same admin rights as user A.

This could be a problem any time two users are trying to create the same named groups.

In some enterprise enviroments tikiwiki is installed on a windows server which is also used as fileserver. Using tikiwiki as a knowledge platform requires the ability to upload documents and files to the machne, browse the upload directories and edit these documents. In such a scenarios users upload downloadable files, like word docs or pdfs directly to the share and use the file module to embed links to these files.

{CODE()}{FILE(filename="path\filename")}Filename{FILE}{CODE}

This is rather painful for new users as they have to learn the syntax of the module and have to copy and paste paths and filenames.

It would be more convenient to use the upload capabilites of file galleries in such scenarios. Currently they cannot be used. For this purpose file gallieries that create a hierarchic directory structure in the upload directories are needed. These directories can be used to organize uploads. Additionally, to ensure that people can edit their files, the files would have to be renamed to human-readable names and not to md5 as it currently is.

In short:
- no renaming of filenames in image and file galleries besides the replacement of spaces with "_".
- mime type filtering for uploads
- the ability to create and browse directories in order to organize uploads.
- ability to set multiple upload directories.

Please consider these suggestions, thanks in advance!

{syntax type="tiki" editor="plain"}
__Background:__ I'm in the process of an overdue upgrade of two Tikis from version 2.2 to the new LTS version 6.x. Testing and adaptation of styles was done on XAMPP localhost under Windows and all worked fine. Problems began with installing on public server (Debian). Installation is done from shell (tar.gz and running setup.sh) and a fresh install works fine.

__Problem:__ When I use the existing database (no problems at database upgrading to 6.2 reported) then it also works fine for anonymous user. But as soon as I try to login as admin user, I get a long wait and then:

__Fatal error:__ Out of memory (allocated 110100480) (tried to allocate 157 bytes) in /home/hrusccbo/tikitest.hruschka.com/tiki-6.2/lib/init/initlib.php on line 185
''(Note: the line number 185 varies)''

In order to locate the error, I entered the following line in initlib:

171: print ("a:$errno, b:$errstr, c:$errfile, d:$errline");

The result is that Tiki starts displaying thousands of times, in an endless loop, until memory exhaustion:
a:2, b:DateTimeZone::__construct() [datetimezone.--construct]: Unknown or bad timezone (M), c:lib/tikidate-php5.php, d:182

From that I deduct that the error originates from line 182 of tikidate-php5.php


===Some other findings which might be useful:===

The last days I tried to enter dev.tiki.org and themes.tiki.org, but could not because the sites displayed exactly the same error. Yesterday I went to IRC chat and was advised to clear the cookies of my browser. After that it worked.

Looking at the cookies now, I found that "local_tz" (I assume that has to do with timezone) of my working tw_2.2 had the content "22%3A37%3A23", the cookie from tiki.org has now the content "UTC", but the cookies from working XAMPP/localhost and from the not working Debian 6.2 installation have both the content "M".

This fits to the origin of the error, as line 182 is "function setTZbyID" which calls "function convertMissingTimezone", where "M" is used in a switch/case statement.

But probably the bug is not really in the tikidate script, but where the cookies are set !!! (see below under "workaround")

Hope that helps to locate the bug and that it can be solved in 6.3. In the meantime I'll wait with migrating.

Thanks to all of you for your great work.
Felix
(running 3 tiki sites since 2005)

If you have a pagename with a colon in it, like user:person, it will not work because Firefox will think user: is a protocol.

{syntax type="tiki" editor="plain"}
I put together a tracker about a year ago (4.2?) that used a page selector field to go to a wiki page (that uses the tracker plugin) in order to edit the tracker record. After installing 6.1, the fields are not populated on the wikipage with the tracker plugin after clicking on the page selector field - they are all empty. If I look at the tracker directly, there is data in the fields.

FWIW: I tried to create another tracker from scratch with the same functionality and got the same results.

{syntax type="tiki" editor="plain"}
The attached file updates the SQL wiki plugin so that the user has a choice whether the returned data should be Wiki parsed or not instead of just preventing it. Parsing is the default with "noparse=>1" preventing the parsing. There are also two additional features added to the code:
# "raw=>1" will eliminate any headers or formatting.
# "delim=>'|'" will set the data delimiter for columns to being an "or" bar. Any other separator can be used.

These additional features are useful when selecting summary data like "count(*)" and resultant headers are unwanted or when selecting data normally, but wanting to format the output aside from the standard SQL return.

There is a remaining issue with the submitted patch. While I have updated the help array at the top I don't know how to make the new parameters reflected in the GUI help system as seen by the user when accessing the plugin through the help system.

I will update the SQL plugin documentation on the Tiki site if this patch is accepted. Doing so before-hand will only set false expectations for functionality not yet there.

--Steve

Staging & Approval fails if incorrect $edit_minor parameter type is supplied to the function update_page. This is the case in Tiki 6.3

This causes the whole staging & approval mechanism to fail.

Noob here enjoying the site, enjoying the software and finding my way around. Thank you.

It means spending a *lot* of time at the Tiki sites.

I get the message already about the dogfood. Cool.

But every day, every page load, I must dismiss this notice to uncover what is underneath. Or scroll the viewport out from under it.

It is located on top of the navigation.

Can we not have it fixed in the page above the navigation, or permanently dismissable once logged in, or ...?

Can we just use the site now, and stop swatting at the javascript? :)

I'm just setting up svn etc now. And wouldn't have the balls to make such a visible change right off the hop anyway. It's not real important obviously. But if somebody is there and knows and can do, it would make surfing the sites more pleasant...

Cheers!!

Here's a little plugin that allows to easily integrate [https://flattr.com|Flattr] with the wiki. Since this is my first attempt to write a plugin it would be great to review the code (especially since I'm no expert for php).
One thing that would be nice to solve would be the inclusion of the javascript part which should be added into the head-element when the rendered page contains a flattr plugin. I just did that while using a simple switch. Really ugly but it works for me.

Bye

e

{syntax type="tiki" editor="plain"}
Using Plugin Edit to amend a FancyTable in WYSIWYG submitting a change causes all line breaks in the table body to be removed.

The PluginEdit shows the field "Rows separated by >> in the header; for the table body, one row per line. Cells separated by | in both cases."

Creating a working FancyTable with table body rows like this:

row 1 cell 1 | row 1 cell 2
row 2 cell 2 | row 2 cell 2

after inserting with the plugin edit tool this changes to:

row 1 cell 1 | row 1 cell 2 row 2 cell 2 | row 2 cell 2

Hello,
I've been using the plugin FreeTagged with the following options ~np~{freetagged type="all" maxRecords="10" h_level="-1" titles_only="n"} ~/np~ on a TikiWiki page
There are some pages (mostly those we're still writing) on our site that should not be accessible by all users . The permissions for these pages seem to be set correctly because a tagged search doesn't list the forbidden pages for restricted access users. However, they do appear in the list generated by plugin FreeTagged.
I think this is a bug because I don't think I can see options to hide the pages on the documentation.
Regards Peter

For multipage wikis the display of the "table of content" using __maketoc__ isn't ideal as this statement requires to be placed on every page otherwise it wouldn't be visible for other pages.
Usually this "table of content" is used for quick navigation purposes. Therefore an alternate to the __maketoc__ statement should be provided which should allow to specify the wikipage which shall be outline. Such a statement can then be used in a module nearby the original wikipage.

No UI checkbox for the following.

INSERT INTO `tiki_preferences` (`name`, `value`) VALUES
('wiki_validate_plugin', 'n');