Category: Release60
Release of Tiki 6 LTS
Show subcategories objects
| Name | Type |
|---|---|
| No longer any way to have CAPTCHA for some items, but not others | tracker item |
|
NO Navigation aid with IE 7.0 in File Gallery to other Galleries and other anomalies
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 |
tracker item |
|
Non-critical usability bugs in Newsletters
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 |
tracker item |
|
Notifications should parse the body
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. |
tracker item |
|
order and filter Tasks by user (that the task was send to)
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 |
tracker item |
|
Out of memory bug in tikidate-php5.php
{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) |
tracker item |
|
Plugin to display the toc of a selected page.
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. |
tracker item |
|
Plugin validation cannot be turned off, TW5.1
No UI checkbox for the following. INSERT INTO `tiki_preferences` (`name`, `value`) VALUES ('wiki_validate_plugin', 'n'); |
tracker item |
|
PluginAnnotation doesn't work with simple png from a tiki file gallery on 6.x or trunk (reproduced on demo.t.o)
{syntax type="tiki" editor="plain"} PluginAnnotation doesn't work with simple png from a tiki file gallery on 6.x or trunk (reproduced on demo.t.o) Reproduced here: http://demo.tiki.org/6x/ and http://demo.tiki.org/trunk/ I added this code: {CODE(wrap=1)} ^Foo {ANNOTATION(src="http://intercanvis.net/display100",align="center")} Bar ^ {CODE} No image is shown, even if http://intercanvis.net/display100 returns an image at the browser. Only the button to save annotations, between the foo and bar strings. And when you click on that button, then after the button nothing else is displayed (no "bar is displayed, nor the end of the box). On trunk, you still get the same content (box is shown, and "bar", etc.,) |
tracker item |
|
PluginFade Does Not Fade Out in Tiki6
The wiki plugin, PluginFade, no longer fades out, but still fades in. Observed in Tiki6 for IE 8 and Firefox 3.6 !!!!{FADE(label="Click to Reveal, Then to Hide")} ~~#F00:__Reveal works, but Hide Does not work__~~ ~~#00C:Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus nec mollis erat. Morbi cursus nunc quis metus semper euismod. Ut facilisis est ligula, eget lacinia metus. Nulla tempor semper risus ut viverra. In faucibus purus et eros consequat pharetra. Fusce mattis arcu lorem, non hendrerit erat. Nulla eu mauris urna. Pellentesque nec velit mi, eu rutrum eros. Quisque nec leo enim, id rutrum metus. Mauris luctus sapien nec nulla scelerisque ultrices. Cras sodales, justo nec elementum imperdiet, elit nulla sagittis ante, at tempus ante risus ut nunc. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi nec risus eu ante pellentesque adipiscing vel eget risus. ~~ {FADE} |
tracker item |
|
PluginInclude not working properly in Tiki 6.2 and 6.1
Wiki plugin, when using with start and stop parameters does not include any text. It only includes the text when used without these parameters. Using Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1. In using tiki 6.2 the problem persists. |
tracker item |
|
pretty tracker wiki-parses all fields
Inefficient and it is perhaps also a security leak. See [http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2010-10-12,Tue&sel=56#l52|irc log] |
tracker item |
|
Preview Horizontal Scrollbars
{syntax type="tiki" editor="plain"} Live preview always displays horizontal scrollbars, at least with the Feb12 theme, rather than working within the available viewport or even dynamically resizing the webpage. My browser is Firefox 4.0.1 on Windows XP Pro SP3. |
tracker item |
|
Preview Oddities
{syntax type="tiki" editor="plain"} The Ajax preview has some minor HTML rendering weirdness, like this one... No line breaks: http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=3740 If you use HTML special characters (like —), particularly with the wiki-style editor, it will appear OK in the preview but as plain-text on the actual page. As a workaround, I'm inserting the characters themselves, which is not great web practice but works. There are probably others that don't come to mind presently but will add as I think of or come across them again. |
tracker item |
|
Preview with on a wiki-page named with german umlauts leads to an error
{syntax type="tiki" editor="plain"} trying to preview a wiki-page with an name containing german umlauts (e. g. "Grafikdesign - Abschlüsse") leads to the following SQL-Error: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' for (likely) the following query: SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`='Grafikdesign - Abschl�sse' it seems that the request handling of the char-encoding for preview is not propper. |
tracker item |
|
proposals/6x: Edit a Banning rule deletes the rule!
When you edit a banning rule, that rule gets deleted (at least, from the list at the Banning interface in Tiki). To reproduce: * go to tiki-admin_banning.php * add a rule for this ip "91.201.66.6" (real ip of spammers, btw) with the title "91.201.66.6_regular_spammers" * Check all features * Check the setting to activate the rule by dates * Select the maximum possible time frame (btyw, this only allows selecting within the same year: reported by somebody else already in another bug report; see [bug3643]) * add some custom message * save * click at the title of your rule in order to have it open for edition again for you * the rule is deleted from the list of rules, and the edit interface is empty --- confirmed in two different tiksi from different servers... (btw, 5.x is also affected) |
tracker item |
|
Refresh by clicking page title does not work with parameters
{syntax type="tiki" editor="plain"} All wiki pages have the option to refresh them by clicking on their title. For a page e.g. ...&itemId=5, it does not work. TW5.0Beta1 |
tracker item |
|
registration fails if "login_is_email" is set
{syntax type="tiki" editor="plain"} If you set the "login_is_user" flag, registration fails with the message "email_not_valid". |
tracker item |
|
Reinstate the feature_category_reinforce
In Tiki 3, the feature_category_reinforce allowed Tiki to evaluate category permissions with AND operator, to determine if a user can view an object in the category. This __"Permission to all (not just any) of an object's categories is required for access"__ option was removed in Tiki 4 & 5. Now Tiki always evaluates category permission conflicts with OR operator. I would like the feature_category_reinforce option re-instated for Tiki 5 & 6. |
tracker item |
|
Semantic link "alias" broken on 4.1 & still on 6.x in several sites, including doc.t.o
Semantic link "alias" broken on 4.1 for me (regression) See: http://gavarrespedia.org/tiki-index.php?page=Pendents it shows an error page, suggesting similar page, search box, and the option to create the page (as reg. user) However, the page name "Pendents" is defined as an alias of "pendent", as it can be seen here: http://gavarrespedia.org/tiki-index.php?page=pendent which has underneath (inside the "[[+] Fet" box): {CODE()} (alias(pendents)) | (alias(Pendents)) {CODE} So this looks broken to me (at least, with common settings as I have). --- Reproduced in doc.t.o with http://doc.tiki.org/PluginRR (which has an alias link from http://doc.tiki.org/PluginR ) Discussed (with more details) on irc: [http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-02-09,Wed&sel=267#l263] --- UPDATED: Fixed in current branches, at least (9.x, 11.x, 12.x) |
tracker item |
|
smarty_tiki/block.wikiplugin.php is called twice upon a {wikiplugin _name="blah" ...}..{/wikiplugin} in a tpl
{syntax type="tiki" editor="plain"} 6.1: {wikiplugin _name="blah" ...}..{/wikiplugin} is called twice from smarty! After each } you get a call. data is what is between the } and { Read more here: [http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-17,Mon&sel=257#l253] |
tracker item |
|
Split Ajax settings
As discussed at the TikiFest (?), we need more granularity here, for people that want AJAX for some features, but not for others. |
tracker item |
|
Suggest : Pages consultation from a pages selection, "return to list"
Hello, Referring to 5.3, when the a selection of page have been made into listpages, after the access to a page there is no else way to go back to the list with is filters than re-run listpage and set again the filter, browse the list often to view and modify the following element. This is a great lost of operating time. i suggest, as for the structure, to implement a button which returns to the list and into at the previous position. Programmatically this needs to : # - send to page-edit the parameter of the listpage we just have left # - by the button run again listpages with options : ## - filter ## - current position into the list This problems is accurate because of the new category features. when the access rights to a "family of pages" are not the same, the good way is not to use a structure (not designed for this indeed) which access by category is applied to all structure elements, but the category or element access by groups or both. For my own I use structured categories to access lists of pages. This is the right use, but this list can't at this time be use to browse the selected list. |
tracker item |
|
Contact Us feature strips email address
{syntax type="tiki" editor="plain"} The email sent to the admin with the form that was filled by an anonymous user, it shows the email address of the user but only the part that is before de "@" sign. Using Tiki 6.2 and I formerly encountered this error in Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1. |
tracker item |
|
Contact Us feature strips email address
The email sent to the admin with the form that was filled by an anonymous user, it shows the email address of the user but only the part that is before de "@" sign. Using Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1. |
tracker item |
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).