Category: 1.8.x

when an new user installs tiki in a browser he does not see the progress of his installation it can cause him to cancel or start the installation again despite the fact that the installation is well done

Although the RFC (for example, [http://www.robotstxt.org/wc/norobots-rfc.html]) doesn't explicitly require a leading slash (/) before the page name, I have found that, as of late Oct, 2005, many 'bots, including Googlebots, have started requiring them.

For example, before the change,

Disallow: tiki-pagehistory.php

would prevent well-behaved 'bots from trying to index tiki-pagehistory.php. However, after the change, I had to have:

Disallow: /tiki-pagehistory.php

in robots.txt, or else all my page history would be indexed! I verified this using my server log, and also by doing google searches against my site for phrases that only appeared in page history. I have every reason to believe this is a problem for all other TikiWiki-based sites.

Others have noticed this. There is discussion in the forums at:
* [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=13666&forumId=4|Googlebot ignoring robots.txt] -- includes a __graph of my bandwidth usage before and after__.
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=12342|Adding <meta name="robots" content="noindex,nofollow"> to History pages]
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=15004|Yahoo search indexes Print pages instead of Read pages]

The robots.txt in the current distro (1.9.x Sirius) contains

Disallow: tiki-print.php

Should it not also contain

Disallow: tiki-print_article.php
Disallow: tiki-print_blog_post.php
Disallow: tiki-print_multi_pages.php
Disallow: tiki-print_pages.php

When users submitt data to a TikiWiki site, there is now workflow included. However this results in active management of a TikiWiki site, for different data entered.

Editors, may receive updates to the site, when you use the notification mechanism, however, there is now way for an editor/administrator to get notifiied by e-mail about other changes to the site, or even worse: notification which need approval, like new links and FAQ entries.

There should definitly be notifications for any submitted data to the site which requires approval to be displayed.

When a user fills the e-mail address field at tiki-send_blog_post.php?postId=XX with non-email-string, an e-mail per sentence is tried to send from the server.

A simple check for a well written e-mail adress in the field should prevent silly mistakes from novice users in tiki, but very annoying for the server mailing efficiency and sys admin annoyance redirecting mal-formed e-mail...

It happens in 1.8.5, and also in 1.9.0.

In 1.8.5, the mailin feature doesn't work properly. It may work for some combination of mail systems, but not for others. And it does not properly handle multiple mailed-in messages when a page load is attempted.

Specifically, some combination of mail client and mail server caused the email address extraction to leave a newline on the end, which should be trimmed.

Also, in determining the type of message, a case-sensitive string comparison is done against "text/html", which won't match for upper or mixed-case.

Finally, there's a bug (probably a minor design flaw) in the way the histlib object is created in lib/tikilib.php, such that if the code is executed twice in the same session, it will fail the second time because the $histlib object isn't created.

Last but not least, after parsing the message, if there are no parts found, the loop that attempts to process them assumes that $output->parts exists, which it may not.

Today button on date pickers not using time as well does nothing

{syntax type="tiki" editor="plain"}
This is an ongoing task.

It will never be finished as we are always adding more features :-)

Info:
on tw.org the naming convention is to use a ,xx suffix where xx is the lang code. For example "Home" is linked to "Home,fr"

The capability to include (recursively) with parameters is probably the most powerful and content factorizing feature of our best competitor MediaWiki.

It make not only produce content much faster and in a much more modularised way.

The references :
* [http://en.wikipedia.org/wiki/Transclusion]
* [http://www.mediawiki.org/wiki/Help:Templates]
* [http://doc.tikiwiki.org/PluginInclude]

I would like to be able to filter searches by Category ''names''. This would improve usability across a Tiki site.

I'm aware that when search filtering by Category, there is a popup on the search page that allows a user to select a Category (or Categories) which will then appear in the Category filter box in a way the search filters can understand. This is handy, but it would be handier to be able to directly type a Category name (or part of a Category name) into the filter box.

The Category selection box also does not help when composing {LIST()} blocks from PluginList with {filter} blocks. At the moment, {filter} blocks must be composed with prior knowledge of the Category ID number. One must use {filter categories="12 AND 38"} instead of, for example, {filter category-names="Czech Novels of the 1900s AND Polish Novels of the 1900s"}. This makes it harder for people to approach writing wiki pages when they want to include lists of objects in Categories.

I imagine a version of this feature would be easy to write for someone familiar with the codebase, because methods for searching by Category ID have already been built and there is already a function get_category_id($name) in lib/categories/categlib.php.