Category: 2.x

When you are watching an item, the email is sent in the language of the site visitor, not your own chosen language.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Tested with 1.10b1...

When generating webhelp from a wiki structure, Tiki creates the ../pages/img/wiki_up/ folder, but does not populate the folder. This results in missing images when viewing the generated HTML files.

Tested with 1.10b1...

When generating webhelp for a wiki structure, if the wiki page contains {TOC} or {MAKETOC} plugins (that generate a list of child pages/headings), the list is not included in the generated webhelp HTML.

Tested with 1.10b1 from SVN (not sure about prior releases).

When generating webhelp from a wiki structure, if a wiki pagename or page description includes a " (quote), the webhelp will fail.

Workaround:
After Tiki generates the the files, you must manually edit the following file:

../webhelp/YOUR STRUCTURE NAME/menu/menuNodes.js

Look for the entry that contains the " (quote). It may be similar to:

insDoc(foldersTreeAAA,gLnk("R","Your page title with "quotes" here","pages/Your page name.html"));

You will need to "escape" the quotes as follows:

insDoc(foldersTreeAAA,gLnk("R","Your page title with \"quotes\" here","pages/Your page name.html"));

The webhelp will now function properly.

The webmail currently only supports POP. IMAP support like IMP, Squirrelmail, Roundcube, etc would be much better. It could rely on PHP's imap support like IMP does. People who will want IMAP would have to have it in their PHP, which is in an acceptable requirement.

To reproduce:

1) Log in as admin.
2) Go to Groups Admin
3) Assign tiki_p_search permissions to a group with no administrative ("tiki" type) permissions.
4) When page refreshes, you will see that all Admin permissions have been assigned to the group, and the Administrative links have been added to the Application Menu module.
---
Confirmed by dthacker

{THUMB(id=44, url="tiki-browse_image.php?imageId=44")}{THUMB}

A user belonging to this group also gets admin menu after logging in.

(This bug has been tested and verified on clean installs of TW 1.10b1 , 1.9.11 and on opensourcecsm.com)

When someone starts to create a new article (submit/edit/new) and chooses a different article type from the menu "Type", the field "Body" disappears (even if the heading_only property of the field is NOT set).

The problem seems only to exist on clean installs with empty databases which fill up the default values with null instead of 'n' for the different type settings.

In turn, the conditional in the function chgArtType() in the file /lib/tiki-js.js does not do a proper checking of the null values creating a situation where it interprets that the heading_only property for all article types is active (or so I gather). Thus it disables the Body field every time regardless of what the property of the article type says.

When clicking a link to answer (re) a comment (at least on blog), the comment section colaps.

Answear a comment on a blog, and all text magically disapair as the comment area colaps.

under admin permissions:
If you edit a wiki page with a wiki rating, the old poll is deslected and a new poll is made with the generic name 'rate it'.

This means the scores are reset to zero and the admin has to edit the page again and reselect the old poll.

under registered permissions:
If you edit a wiki page with a wiki rating, the old poll is deslected and the page doesn't have a rating anymore.

Wiki ratings is a very nice feature, but this is a showstopping bug.. I hope it isn't too hard to fix ;).

With version 2.2, normal and OpenID login enabled, and the modules "since_last_visit" and "since_last_visit_new", they don't reset when using OpenID login. When loging in with the normal login, those since last visit changes are reset.

{syntax type="tiki" editor="plain"}
When printing a wiki page (or viewing the printer-pretty version) that has links, it would be nice if links actually showed the full URL.

For example

((http://yourtiki/foo|Foo)) would display as Foo (http://yourtiki/foo)

((http://yourtiki/foo|Bar)) would display as Bar (http://yourtiki/foo)

[http://foo.com|Bar] would display as Bar (http://foo.com)

When reporting that a categ. mandatory field is missing, another mandatory category multiple checkboxes loose their previous selection.

You can try that here:
http://moviments.net/cursos/Inscripcions+2008

Fill all mandatory fields except the last mandatory one. Submit. User gets the message that the last field is missing, which is true, but then, the selections made in the first mandatory field (category multiple check boxes) are lost. So if user only clicks on last missing mandatory field, he gets a message again that the first is missing, but the last is missing again then, etc.





Same behavior when using the tracker directly (instead of tracker plugin)

When the system (in this case was a Linux box) runs out of disk space, a Tiki user cannot login. Basically, the user is sent back to the home page. In other words, it looks like the user has authenticated, but is not logged in. So it looks like a PHP session issue. It could well be.

If the user enters a wrong password, a wrong password message is seen.

It would be nice if Tiki could detect that the disk space is low and alert admin users, especially during install. Low priority of course, but still nice to have.

MoinMoin example:
{THUMB(id=29, url="tiki-browse_image.php?imageId=29")}{THUMB}

{syntax type="tiki" editor="plain"}
Confirmed on clean install of 2.4. Testing on opensourcecms.org, it does not appear this bug carried into 3.0. Have not found this reported in the forums nor bug tracker.

Since upgrading to 2.4 (sorry, only have Fantastico), there is a bug introduced with the permission level assignment capability (level configuration at bottom of tiki-assignpermission.php page). If used once as expected / described, then any further "update" to permissions in that same group will ''Null'' out the whole "Level" column in the __users_permission__ table.

Go to __groups__, __admin a group__, __admin its permissions__. Click "level configuration: show" way at the bottom. Do an assign of a level to that group and hit update. Once done, simply hit the normal "update" button in the "assign permissions" section. Does not matter if you change a permission or not. Now if you try to "level configuration: show" again, the level fields for every permission are nulled out and no levels appear in the "assign" list at the bottom of the page. Browsing the table in PHPMyAdmin confirms this behavior.

Note that you do not have to do a level assign a second time. Simply trying to change the inclusion of any individual permission (or making no changes but simply clicking the update button in assign permissions) will cause this to occur. Also, it does not matter whether "level configurations" are shown or hidden.

Wiki "((doc:edit by section))": Nice feature added, thanks heaps to those who made that possible! :-)

BTW, I found that it doesn't allow concurrent edition of different wiki sections of the same wiki page.
Tried on doc.tw.o on June 8th 2008, using Mittwoch and also Tikinewt.css (After clearing tiki cache) , and it didn't work for me on any of both cases.

doc.tw.o page needs to be updated once fixed.
http://doc.tikiwiki.org/edit+by+section

In 1.9.x, Side-by-side diff is the default

Sometime in the history of 1.10 (around when WYSIWYG editor arrived I think), HTML diff became the default.

This appears to be more of an accident than a conscience choice.

Side-by-side should re-become the default.

Ever better, the admin should should what the site default it.

Even better, each user could override this value in their preferences.

{syntax type="tiki" editor="plain"}
We installed Tiki with version 1.9 and we quickly installed the PluginInclude and starting making extensive use of it. This week, we upgraded to 2.2 and some of the includes stopped working.

After some trial and error, it appears to be the 3rd to 4th include on a page (all pages have the same permissions via categories) that fails. It works for admin, but not the average user.

I took a look at the plugin and found the line

// $text="<b>User $user has no permission to access $page</b><br />";

and uncommented it. The user received the message that they did not have permission.

In addition to smilies and text formatting like bold, add syntaxes for commonly uses markers in text.

Please see some nice examples here:
http://wikifeatures.wiki.taoriver.net/TextFormattingRules

Which are inspired by :
[http://moinmo.in/HelpOnSmileys|MoinMoin]

I like:
/!\ warning
(./) check
{OK} thumbs up
{i} information
{1} {2} {3} for nice numbering

We currently use images at doc.tikiwiki.org and it's cumbersome.


From #wiki (freenode)

(11:20:53) TheSheep: marclaporte: btw, if you need some icons, there are some I drew at http://sheep.art.pl/Icons
(11:21:10) TheSheep: marclaporte: especially the hand icons can be... uhm... handy
(12:16:35) marclaporte: hehe
(12:17:52) marclaporte: for icons: is license compatible with LGPL?
(12:18:15) marclaporte: I wish we had a license compatibility grid for CC vs GNU
(12:19:58) TheSheep: marclaporte: I can relicense it for you
(12:20:17) TheSheep: marclaporte: although using gpl for something that's not software is weird for me
(12:33:22) marclaporte: yes, but icons have to in the app, no?
(12:42:45) TheSheep: marclaporte: but icons are also distributed when somebody merely uses the web app
(12:43:00) TheSheep: marclaporte: would you want to force them to provide the source code?
(12:44:49) marclaporte: I just don't want any trouble
(12:45:02) marclaporte: and to respect author's wishes
(12:45:51) TheSheep: marclaporte: I can promise I won't give you any trouble, just tell me what you need to use them :)
(12:46:01) marclaporte: hehe
(12:46:13) TheSheep: marclaporte: it will also help me to release my future works in a way that is friendly for developers
(12:46:22) ***marclaporte is adding on todo list

If an upload fails here: tiki-list_file_gallery.php?galleryId=1, I get a descriptive error message (ex: file too big).

The same would be useful for wiki page attachments.

When viewing wiki page history, default two versions to compare should be last two. Bug introduced in January 2008 on BRANCH-1-10

{THUMB(id=18,url="show_image.php?id=18")}{THUMB}

!!Problems

__Pretty Much Resolved by the wiki ALIAS function__ - so closed.

Redirect plugin
*is not included by default in TikiWiki because it could be used for bad things
*creates redundancy (in search results, page listings, etc) - maybe redirected pages should not appear in list?

Renamed pages
*do not automatically redirect - creates broken links.


!!Proposed solution:

!!!renamed pages
*When a page is renamed the user must choose "hard or soft redirect" perhaps better known as "redirect or refer from old page?"
**hard redirect places redirect plugin on pagename-old to pagename-new.
**soft redirect puts something at top of page like
^This page has been renamed: pagename^


!!!Add synonyms/aliases to a page

suggestion (mlp): adding aliases to a page should automatically create pages with hard or soft redirects to pagename. Note that the adding of alias pages must not destroy data if page already exists.

Ex.:
dev.tikiwiki.org/Tracker
dev.tikiwiki.org/Trackers
dev.tikiwiki.org/Bug tracker

would be aliases. It would avoid the pollution we have here: http://dev.tikiwiki.org/tiki-orphan_pages.php


doc.tikiwiki.org/Install
doc.tikiwiki.org/Installation
doc.tikiwiki.org/Installer

Each wiki page should be able to put one or many aliases. These aliases would work in search. All the aliases should have an important weight in the internal search engine.

We could use this instead of renaming pages. Also, when we do rename a page, we could have an option to have the old page name to be an alias of the new one. Thus, better for external search engines.

Theses aliases could even be used as meta tag for this page.

Putting aliases to non wiki pages (ex.: tiki-forums.php) would make ((doc:structures)) more useful. Now, using structures for site navigation only makes sense if you only have wiki pages. And who ''only'' wants to have wiki pages with all the great features offered by TikiWiki? :-)

It also help to use cleaner page links in sentences. If my Wiki page is called Install, I have to do the following now:

{img src=images/code.png}%%% {CODE()}
For more information about ((Install|Installation))
{CODE}

With aliases, I could do:
{img src=images/code.png}%%% {CODE()}
For more information about ((Installation))
{CODE}

Page aliases - and hard redirects - should permit to set status "Moved Permanently" for robots to send traffic to main page.

What would we do with page renames? (which correct links in wiki pages). Needs some thought. We don't want some unwanted changing of text in existing wiki pages.


Do we need?
Redirect to internal or external http is ok because a special permission is needed to use. -> tiki_p_wiki_alias . In security admin, warm that giving tiki_p_wiki_alias to untrusted people is a security risk.


Related:
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

Under 1.9.5 and under two different themes, I could not create a wiki page that had quotes in it. I received an error like this:

Invalid variable value : page = asdfasdf "foo"

That would be only a minor annoyance. But it gets worse. You can rename a page to have a name with quotes in it; however, having done so, you cannot then view or edit that page. You receive the same error when attempting to access the renamed page.

http://dev.tikiwiki.org/Add+to+WishList simulates the wiki page "add to WishList"


But
{CODE()}
((Add to WishList))
{CODE}

does not simulate
{CODE()}
((Add+to+WishList))
{CODE}

Should it?

Should plus(+) and space ( ) be freely interchangeable, the same was "A" and "a" are?

This is best explained with an example:

~pp~
Paragraphs are parsed

just fine here

{TAG(tag=ul)}foo{TAG}

but now

paragraphs and

line breaks aren't working!
~/pp~

This only happens for tag=ul, not even for tag=ol.

This happens regardless whether wiki paragraph formatting is enabled and regardless of whatever is inside the ~np~{TAG(tag=ul)}~/np~, even ~np~{TAG(tag=li)}~/np~'s.