Category: 3.x

Currently, Tiki allows anonymous visitors to subscribe to a newsletter (via the "subscribe any address" feature. It would be nice if anonymous visitors could "watch" items simply by adding their email address.

When using the Mail-In feature with Articles, Tiki places the entire email in the article's Header. I would like a way to specify portions of the email to placed in the article's header, the rest in the Article body. Perhaps by some sort of text marker?

When adding a new item to the directory, it would be great if I could upload an image for the link.

Currently (2.2), if you enable the RSS feed for individual Tracker items, Tiki will create a valid RSS feed for __every__ tracker. I would like to have a method, when creating a new tracker, to specify whether or not Tiki should create the RSS feed for that tracker.

The current wiki syntax does not allow commas when specifying the page name for an external wiki link. This is a problem for example when trying to setup an external wiki link to a list of Bugzilla bugs. In "Admin external wikis" I can create this entry
|| __Name__ | __Extwiki__
buglist | https://bugzilla.mozilla.org/buglist.cgi?bug_id=$page||
But using ~pp~((buglist:1000,1001))~/pp~ on a wiki page does not work.

I would like to be able to have nested categories in my FAQ and/or Forums. This is a pretty simple change (I think, I'm no coder) as it's just adding a 'parent_id' column to the tiki_faqs database (for example). This would allow a layout like

*Firewalls
**Checkpoint
**Cisco
**Juniper

Which would make browsing categories and organizing them easier.

The redirect plugin currently lacks the ability to include fragment identifiers, e.g. -+~np~{REDIRECT(page=Foo#some_id)/}~/np~+- does not work; the resulting URL is -+~np~tiki-index.php?page=Foo#some_id&redirectpage=this_page~/np~+- instead of -+~np~tiki-index.php?page=Foo&redirectpage=this_page#some_id.~/np~+-

The trackerfilter wiki-plugin could be enhenced to show/hide fields only for specified groups of users.

Access to RSS modules (incoming feeds) is an all-or-nothing option in v2.0, with just one admin permission available. A beneficial feature for our Tiki would be to enable users to view the RSS module list and add new modules, without having other permissions, such as deleting modules.

{syntax type="tiki" editor="plain"}
On ui.tikiwiki.org, I noticed some issues about the annotation plugin stuff not appearing properly when a page is cached.

I turned off cache for now

{syntax type="tiki" editor="plain"}
On UI.tikiwiki.org, I can add a few annotations to some images, but if I forget to click "Save changes to annotation", I will lose my annotations.

Currently, an administrator of a Tikiwiki installation has to hunt for upgrades, updates, and security related information of his installation. It is often cumbersome and sometimes dangerous, think of the delay in fixing a crucial vulnerability, it has happened elsewhere before. It might also be nice to know that ppl are using current and feature complete software.

A user registered with an apostroph ' in their username (e.g. "Tes't") will not be able to use some feature of TikiWiki.

For example:
They will be able to select a forum, but after that, all that is displayed is the name of the forum, the "new topic" and "list forum" buttons (depending on permissions, of course), and the breadcrumb forum-navigation. The rest of the page (tiki-view_forum.php?forumid=X) is blank, no header/footer or any menus are displayed.

This __is__ dependant on the rights/permissions of the user in question, SubAdmins and Admins will see the full, expected forum page, regardless of apostrophes in their name (at least with my config, YMMV).

Another problem exists in regards to all JavaScript that uses the name of the user, for example the "tiki-my_tiki.php" page of the user, were JavaScript is used to expand Tabs (e.g. clicking "My Infos" will not work). This is due to JS using ' as string-delimeters, and not escaping any ' within the users name.

---

May be that the sole cause of all the problems lies within the JS-string-delimeter, but I'm no expert on the workings of TikiWiki, and the forum page breaks rather spectacularly when compared to the user profile page, which just doesn't work as expected.

Hi!

First: Thanks for this great project!

When you try to translate an article (by clicking on the small globe that is near the edit icon), it sends you to the wiki translation page, and content is empty, ie, it doesn't get the article's content to translate, and off course, even if it did so, the interface is not correct for article translation (it should have the same article interface, with heading and stuff).

I hasn't tried latest trunk, but bug is present on 5.1.

I tried to search for a similar bug already open (because of this forum thread: http://tikiwiki.org/tiki-view_forum_thread.php?forumId=13&comments_parentId=33126), but I found none, thus: I'm opening this open.

Thanks!

Clicking on the title of an article should be like "read more", like for the image. Seems more intuitive to me.

Please see:
http://tikiwiki.org/tiki-view_articles.php

And imagine clicking on the title to be taken to:
http://tikiwiki.org/tiki-read_article.php?articleId=166

This is an easy fix.

No problem at all, but a request for more integration with the wiki and forums.

At this moment (in version 3 (after the bug is corrected)) there is only one forum, which can be used to discuss a wiki page. This is really great.

Using tw.o forums and 2.0 (afaik):

You add a screenshot attachment to a reply in a forum post, and if you click on "preview" first, (as you would do on wiki pages), the image is lost (no tag is inserted on the forum post to help you link the attachment).

However, if you do the same attachment on a post, and click to post it (without previewing it first), the attachment link is shown.

Example at tw.o forums where it recently happened:
[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=29608&thread_sort_mode=commentDate_desc&was_queued=n]

---
according to comment added to this bug report, this issue is still present in branch Tiki5 still (so probably also in trunk)
---
Unbelievable, bug still present in forum posts in 12.x since 1.x! (with forum replies, there is warning, at least, but not yet with brand new posts in the forum and attachment is lost indeed) {sign user="xavi" datetime="2013-11-22T09:45:52+00:00"}

Reproduced here:
http://xavi-9794-1986.show.tikiwiki.org/tiki-view_forum.php?forumId=1
u: admin
p: 12345

It would be nice to add autocomplete for "Find" text boxes for the seach module, header search and advanced seach features.

many x.tw.o sites would benefit from that, for instance...

(I add this request here after Jonnyb explicitly asked me to suggest him places where atuocomplete would be adequate (:biggrin:)
)

Using __Shoutbox__ with __Autolink__ option enabled....

Entering http://www.foo.bar in the shoutbox correctly converts to [[Link], but entering http://foo.bar does not

Cutting and pasting text often involves text which has paragraphs which begin with indented lines. These could be recognized by the editors and converted into paragraphs.

If text area feature "paragraph deindent" is turned on, a line which begins with two or more spaces should be converted into the start of a paragraph. In the normal editor, this text would be moved to the start of the line and a single blank line would appear as a paragraph separator. Note that multiple blank lines before the paragraph should be compressed to a single blank line. Text with indented paragraphs often does not have a blank line between paragraphs, so the code needs to ensure that a paragraph marker exists.

{syntax type="tiki" editor="plain"}
Perhaps this should be user choice?

So user can avoid this step if there is a problem.

This tracker item could not be found

Usability issue, but not so much a bug as feature design:

If the tag cloud is large in tiki-browse_freetags.php, search results are not immediately apparent on the screen. The user has to scroll down past the cloud to see the results, which is not necessarily obvious to new and/or less savvy users.

Ideally, the beginning of the search results should be displayed near the top of the page, but with a portion of the tag cloud still visible for further search filtering. The tag cloud could automatically collapse, with a large obvious control for expanding it again, or it could be positioned side-by-side with the results. Those are the only two solutions coming to mind.

{syntax type="tiki" editor="plain"}
in version 3.2, I would like to add a second calendar (public access television programs - the first calendar is an events calendar. see http://www.progressiveomaha.com/tikidir/tiki-calendar.php ). I would like the user to be able to easily switch between the two or view both as an amalgamated calendar, if they wish.

However, first the user has to click on "visible calendars" which displays a popup window that gives check boxes which gives the option to check one calendar or the other or both with an additional option to "Check/Uncheck All". Once they have made a selection there, the user must then click on "Refresh" to see the calendar or calendars they wanted to see.

People may want to switch back and forth between the calendars several times in one session. Having to go through multiple steps to accomplish that is a disincentive to using the calendar.

Trackers can have many fields.

Multilingual is a way to have multiple values.

Native multi-valued trackers would be useful in certain circumstances.

Another way is to use ((doc:Category Tracker Field)) or ((doc:Items List and Item Link Tracker Fields)) or ((doc:Drop Down - Radio Tracker Field)) with multiple choice option. Probably the best is to build upon the ((doc:Relations Tracker Field)).



We would also want multiple sets.

First Name 1 (field 46)
Last Name 1 (field 47)
Address 1 (field 49)

First Name 2
Last Name 2
Address 2

First Name 3
Last Name 3
Address 3

First Name 4
Last Name 4
Address 4

Could we imagine a new tracker field type "Set of fields":
Fields: List of fields in the set. ex.: 46,47,49
Number of repetitions: ex.: 3

This would create artificial fields (in this case 46-2, 47-2, 49-2, 46-3, 47-3, 49-3, 46-4, 47-4, 49-4)

So these fields could be used independently (ex.: 47-2), but since they are linked, we could have some smarter handling for forms, reports and exports.

We could want the input form to by default indicate only the first set of fields, and via jQuery, show additional set of fields.
We could want a report/export of this "Set of fields" which would aggregate everything in one listing.

{draw id="28"}