Loading...
 

Category: WYSIWYCA (What You See is What You Can Access)

WYSIWYCA (What You See is What You Can Access)
Show subcategories objects

Name Type
"Submitted by" at dev.tw.o/tracker5 forgets username after 2nd edit => user can't edit his items.
To reproduce:
* As a user with non admin rights insert a tracker item to dev.tw.o/tracker5
* edit it again, and change something (add some text to a text areas, etc.) And save
* you are not able to edit that item any more because the "Submitted by" field has lost the record.
* edit that item as a user with admin rights, adn manually provide again the username of the poster.
* the poster can edit it one more time. But after that, he loses the ability again.

...

Example:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2885
---
testing this bug
---
2nd edit
tracker item
1.10: "view extra infomration" link fails in User Prefs screen if user hasn't default group defined
Using 1.10cvs from mid June 2007.

This problem is on at: http://moviments.net/intercanvis

User tracker is on, it's created and working (at registration time everything is ok and working, user sets new data for the user tracker info before ending registration, etc.). Well, at least for Registered users.

This morning I went (as a user with admin privileges) to User Preferences screen > Personal information > Your personal tracker information: "View extra information" (link to [http://www.moviments.net/intercanvis/tiki-view_tracker_item.php?view=+user] ),

but at that link I get this message:

^
-=ERROR=-
No tracker indicated
Go back
...
^
This user belongs to Admins, Editors and Registered groups, but has no one defined as default.
When defined a default group (Registered, the only one with user tracker defined), the link worked.
tracker item
Caldrac
Contributors
tracker item
jonnybradley
Contributors
tracker item
Search within a category
Categories are amazing for a large site. It makes it easier to manage. Next step is to add an option in search which can be filtered by category.
tracker item
5.0: anonymous shouldn't see "watch" icons when browsing category tree
Using Tiki 5.0: anonymous shouldn't see "watch" icons when browsing category tree.
And they can.
Reproduced here, for instance:
http://intercanvis.net/tiki-browse_categories.php
tracker item
Admin modules does not display available modules or provide easy method for selecting unused modules
Bugs & Wish list
tracker item
All actions should check if page exists
Logged in, go to:
http://profiles.tiki.org/tiki-pagehistory.php?page=Tiki+Transforming

You will see a bunch of action (Source, Permissions, History, Export, etc). These actions should be WYSIWYCA
tracker item
Allow Tracker item rating to be seen or voted through PluginTracker and PluginTrackerList
Nowadays, Tracker item rating cannot be seen nor selected if using either ((doc:PluginTracker)) or ((doc:PluginTrackerList)). However, it can be seen (for anons) and voted for registered again, after some recent fixes by Sylvie! (thanks Sylvie :-)

I tested that here in dev.tw.o (for instance):

http://dev.tikiwiki.org/Calendar

(not showing ratings even if they exist; check [tracker5])


2007-08-13 ML: But this will conflict with wiki page cache. (because value of my last vote is shown, and likely different than yours).

2007-08-13 Xavi: If cache is the problem for this feature request, why not forcing/advising the user to avoid using cache (at least in this page) if he/she wants this tracker field correctly show on the page? (in case this feature is considered interesting enough). I leave to consideration by coders... It was just a suggestion which I would find useful.

2007-12-09 ML: Fixed in BRANCH-1-9 by Kerrnel22. You need to add tracker field ID to trackerlist plugin.

__Wiki page cache with trackerlist ratings needs to be tested to see what the real issues (if any)__
tracker item
Blog options WYSIWYCA (especially trackbacks)
In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.

tracker item
Do not display [comment] link, when no perm to post comments and no comments posted yet
for users with tiki_p_wiki_view_comments perm only, it displays the ~np~[comment]~/np~ link on the wiki page bar even when no comments there yet to read, so clicking it does literally nothing...
tracker item
Edit page warning sometimes stays active even when you cancel.
Can someone give more details on this one?

I believe the problem occurs when someone goes to edit a page then uses the browser buttons, links or types a new URL without clicking either the svae or cancel buttons. -- mdavey

A related issue is that the lock is checked /before/ all the permissions checks have been done. The result is that one can try to edit a page as anonymous, get an error warning, login, try again only to be told that 'Anonymous' is editing the page. -- mdavey

obs: waiting for cvs to unlock to commit
tracker item
fix sheets created directly from wiki SHEET plugin within wiki pages for managing tables visually
Spreadsheets can be created directly through wiki SHEET plugin directly within wiki pages. this allows managing big tables visually, as well as having the data ready for producing graphs, etc. (see documentation for tikisheets at doc.tw.o, if needed)

However, when you create a sheet through a call to the SHEET plugin from the wiki page itself, there are 3 issues which need to be fixed:
# you need to know the id you want to assign it to,
# after that, tiki-sheets.php doesn't list it (even if the sheet is really created, and you can import data to it, and show it at the wiki pages, etc.).
# the sheet is not shown with the right css

Even if we have wysiwyg option available, I still think that is worth improving tiki sheets usability to be used directly from wiki pages, once those 3 previous issues are fixed.
---
Updated on Feb. 2, 2011, using trunk (7svn)
# Steps to reproduce the first issue
## Edit a wiki page
## Use the plugin helper to create a new sheet in that page. And since it's a new sheet, it doesn't have a sheetId yet, so that you leave all fields empty in the plugin helper for the pluginsheet
++ this will add this type of code in your wiki page:
++ {CODE()}{sheet}{CODE}
## Save the wiki page
++ you will see an empty sheet shown in place at that wiki page, with the button at the bottom to allow the user to "edit it" (so far, so good)
## Once you click in the edit sheet button, you end up in some url like this one:
++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=&parse=edit
++ which produces a WSOD (blank page).
*** In my case, I guess that this url should have been:
+++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit
+++ since I had only one sheet previously created, with sheetId 1, so that the next one should be 2. However, this new url is still producing WSOD for me. (tiki caches cleared, just in case, repeated this step, and same WSOD)

The expected behavior is that the user is the user would be editing a blank new sheet with the url:
http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit

and when the user saves that sheet, the new sheetId 2 exists, and the user is either sent back to the wiki page where he clicked at the button "edit sheet" (preferable option) or either sent to the corresponding tiki view sheet 2.
tracker item
WYSIWYG & Mobile: check if browser is supported and provide relevant error message
Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)
tracker item
WYSIWYG doesn't save the new content in wiki pages
Editing a simple wiki page, converted into wysiwyg, added new content, saved page, and nothing of the new content is saved (old content is shown at save time and when visiting the page again)
tracker item
list gallery in tiki-browse_gallery.php
To reproduce, go to:
http://tikiwiki.org/tiki-browse_gallery.php?galleryId=18

and, as an anonymous user, click on "list gallery", you will be sent here:
http://tikiwiki.org/tiki-list_gallery.php?galleryId=18
"Permission denied you cannot access this gallery"


Should tiki-list_gallery.php use the same perms as tiki-browse_gallery.php? Right now, it seems to be only for admins.




tracker item
listing file gallery contents broken in Catalan Language since 1.9.8beta???
Mmmm, file gallery contents cannot be viewed if anonymous and language selected is catalan. Example:

[http://gclub.ub.es/file6]

Change language to english or any other, and the contents will be shown.

I'm not sure but I would say that this didn't happen before I updated to 1.9.8beta (yesterday)

----
May be related to that older bug report?:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1204&trackerId=5|Listing a file gal. in CATALAN returns smarty error for admins, and blank page for reg. users]
tracker item
Login module should include some info text when Intertiki is on
When Intertiki is on, mod-login_box.tpl should show some info on the login box reporting where to register in order to log into that site. Example: edu.tw.o., with tw.o registration.
I've done this by hand:

^Intertiki is enabled. Log in with your account at <a href="http://tikiwiki.org">http://tikiwiki.org</a>. <br><b>New?</b>: <a href="http://tikiwiki.org/tiki-register.php">register at tw.o</a> and come back to log in here.
^
{CODE(wrap=>1)}
Intertiki is enabled. Log in with your account at <a href="http://tikiwiki.org">http://tikiwiki.org</a>. <br><b>New?</b>: <a href="http://tikiwiki.org/tiki-register.php">register at tw.o</a> and come back to log in here.
{CODE}

But this could be added more general on tiki, so that it checks whether intertiki feature is on, and get's the name of the intertiki server from some value at your tiki isntallation, and then, the message is customized on the login box.
tracker item
luci
Contributors
tracker item
Mark blog entry as private doesn't work
Blog post edit page (tiki-blog_post.php) has a "Mark entry as private" check box, to restrict viewing to the author. But it doesn't work; any user can read the post.



Needs to be fixed or the option removed from tiki-blog_post.php in time for 1.10.0
tracker item
menus are not shown any more to anonymous, at least
Since some weeks ago, afaik (April 2008, or so), menus and menu options cannot be seen for anonymous on several sites that I admin, including edu.tikiwiki.org, if you select some themes. Example: moreneat.css

On others, like http://moviments.net/ilp (using nornia.css), the menu on a module assigned to anonymous and registered, was shown when you logged in. Right now I've just assigned thatmodule to admins only, and used menupage module, which works fine. But I can re-set the previous config. is somebody wants to reproduce the missworking.
tracker item
module freetags_morelikethis is not WYSIWYCA
The module freetags_morelikethis shows links a user has no permission to view.

I have to introduce a knowledge management system in our company and am convinced that TikiWiki is the solution to go.

The problem is:
- lots of data is classified (categorized)
- Tags are required to build a network of the knowledge
- the users will not accept a system that leads often to "permission denied"

Without this module being WYSIWYCA I cannot suggest TikiWiki to the management.

tracker item
module users_rank has a link to list users even when feature is off
obs: waiting for cvs to unlock to commit
tracker item
#2115
Bugs & Wish list
tracker item
Modules: if a feature is turned off, it should be hidden or somehow filtered + other ideas
Tiki 1.9.8 ships with 94 modules. (excellent)


Need a "module manager"

Module should come with a screenshot or preview.

A page listing all modules with descriptions and parameters- grouped by feature.


currently, the "user modules" and "assigned modules" titles are very non-intuitive. Should say "custom modules" and "active modules"




However, all modules are listed at all times. Module listing should check for features which are activated. It would be easier on new Tiki admins. For example, if articles are deactivated, don't show me last_articles in tiki-admin_modules.php



Admin modules does not display titles of available modules or provide easy method for selecting unused modules, such as with a listbox. The missing information is not available unless a Tiki admin has system admin permissions.



Also, all possible parameters for the current module should be listed (or picked from a drop-down)
See:
[http://doc.tikiwiki.org/Module]



Related:
Plugins admin interface
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=502
tracker item
Need Forums to Display per Group - Nevermind
Our community needs some forums for the administrators only so that we can pass messages back and forth. However, there's no way to make any of this private. Any registered user can read and post what need to be private forums. In many cases you don't even have to be registered to read.
tracker item
New module: search page name, search text, edit page
In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}
tracker item
permission "minor" seems useless on doc.tw.o: registered can't use it even if granted to them
permissions "minor" seems useless on doc.tw.o: registered can't use it even if granted to them
Check it live on: http://doc.tikiwiki.org
Login as admin to check that tiki_p_minor is granted to registered. Logout and login again as plain registered user, edit a page, and you don't see the "minor" button.

Registered users need it since it is a part of the interface needed for best interaction with new translation features on 1.10 (minor changes are not counted as new content to a page is being translated; if no minor, then a minor change to an outdated page reports to the up-to-date pages that new content has been added on other pages, and thus, lots of noise is introduced in the community)
tracker item
Permissions on individual galleries for tiki-galleries.php and tiki-list_gallery.php
Anonymous can view this gallery:
http://www.marclaporte.com/gallery1
And there is a list to the galleries:
Put I can't list the available galleries (available to anonymous)
http://www.marclaporte.com/tiki-galleries.php


There is a related problem with tiki-list_gallery.php where a :

if ($tiki_p_admin_galleries != 'y')

which prevents all individual image gallery permission checks
tracker item
Polls can be seen by anonymous even though they are not allowed to vote.
Anonymous users can see can view polls even though they don't have tiki_p_vote_poll

These files need to be checked:
tiki-old_polls.php
tiki-poll_results.php
tiki-poll_form.php

Setting that anon can vote in polls needs to be cheked too.
tiki-admin.php?page=polls

Sorry not to have a clearer bug report. Short version is that permissions for polls don't work as expected in 1.9.0

Please also see tracker #278
tracker item
recurrence rules in calendars are broken to me
Three issues with recurrence rules in 3.0 (tested in 3.0beta1, at the http://tikiwiki.org/TikiLiveCD 0.5a)

# When you hit preview event (before adding the new event to the calendar), the recurrence rule data is lost.
# -- A recurrence rule conflicts with something else. I get "~~red:Events cannot end before they start~~", but the settings are not to produce this warning/error message. The event canot be posted to the calendar. See image attached to this bug report.--
# If admin has not set the default calendar to be viewed by default (I didn't even know about that new setting in 3.0), events are not shown in the calendar for each user until that single user clicks on "Visible Calendars", and select the calendar (even if only one!), in order to view the events he/she has just added. Another user has to do the same process.
---
updated May 4th 2009: the second bug report from the list of three can't be reproduced anymore, at least with tiki3rc1.
The third, seems fixed in a quick trial I?ve just made (I read days ago that nyloth fixed that).

The first one about the preview is still applicable.
tracker item
Remove requirement of global tiki_p_view wiki pages in order to allow to manage one local structure
tracker item
Saving in WYSIWIG removes Edit Section buttons; saving in Wiki restores them; Wiki edit option disappears when doing a section edit
If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:))

Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors.

This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages:
*Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page.
*If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing.
tracker item
section edit in non-editable menupage (from module) possible when page in central column is editable
section edit icons in non-editable menupage (from module) are shown when page in central column is editable.
(Ajax enabled, in case it matters)

The links in section edit icons open the central column page for editting, not the menupage one, but anyway, confusion is added to users... (plus icons non-WYSIWYCA on the menu page)

It should be easily reproducible on dev.tw.o.

Using Tiki 4.1.
tracker item
since_last_visit_new module links to new users in not WYSIWYCA
New users are linking to:

tiki-assignuser.php?assign_user=


It should be:

tiki-user_information.php?view_user=

for users that don't have tiki_p_admin_users
tracker item
Standard permissions for features per groups
Every time a new object gets created (wiki page, blog entry etc) the item recieves only global permissions.

It would help a lot if the admin could define 'standard permissions' for each group for specific features.
(needs to be integrated with improvements to "permissions by category" introduced in 1.9 - which provides a coherent approach for "object" based permissions to compliment user based perms.)

To keep wiki pages inside the group, the admin would assign the read right only to that group, and a member of that group posting a new item would not have to worry about security as much.

Am not sure what to do when user is member of multiple groups... maybe she can select in a drop-down which is the one that wins, or maybe the admin determins that when creating the user?

Reccomendation: Inherit permissions. (particularly for wiki)
The default behavior for a new object should be to inherit permissions from the page it was created from (global if none). Particularly in a wiki, this would facilitate the use of "private areas" - key feature for tikiwiki as groupware so committees. groups, etc. can operate in privacy, if so desired. Whoever create the page should be able to disable this inheriting, but it should be on by default. Admins can then create private wiki spaces by customizing perms on one page (the group home page).
tracker item
Structures section at object permissions table not shown
tracker item
tiki-lastchanges.php content should be WYSIWYCA
Should not show IP, source, history, etc. if the features are off.
tracker item
tiki-list_trackers.php should be WYSIWYCA
Users have a link (list trackers) to tiki-list_trackers.php on tiki-view_tracker_item.php and tiki-view_tracker.php

However, if some of the trackers are restricted, users get an error message instead of getting the list of trackers to which they have access.
tracker item
tiki-mobile.php -> normal integration in Tiki
tiki-mobile.php should appear in the menu when activated

BUG: It is possible to surf blogs in mobile mode even when deactivated.

WYSIWYCA: tiki-list_articles.php?mode=mobile and link to articles in tiki-mobile.php should only show when it user can see articles. Make sure to check topic permissions too.
tracker item
toc plugin lists all the downstream pages in a Structure even if some are not permitted to user
Using Structures to assemble Wiki pages into a book is a very powerful way to manage sets of pages in a holistic manner.

A common usage requirement however is to be able to restrict access to some selected pages within a Structure, which works fine from an access control point of view, BUT when the toc function is used ALL the pages will be listed within the Structure no matter what Category permissions the individual user has. This means that users have visibility of some pages that they cannot access - which may be very undesirable!! and conflicts with the WYSIWYCA principle.

It would be extremely useful to be able to filter the resultant list from the toc function, to just the pages/links that the individual user's categorisation permission allow them to see. In this way the categorised pages would not be visible at all in the same way as they are treated in many other functions e.g. List pages etc.

Still does this in 3.0b4

FIXED
tracker item
Trackers: WYSIWYCA for List trackers, View this tracker items, Monitor, etc
On these two pages:
tiki-view_tracker_item.php
tiki-view_tracker.php

Reminder: a user could have permissions to view a specific tracker without having general tracker permission.

Related tracker:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=505
tracker item
v3.0 Freetag search displays wrong item count when categorised content search listing is multi-page
A previously reported bug with searching Freetags (#2235), where there was a WYSIWYCA problem has been fixed and this bug item is closed.

But there is still a small glitch when you search categorised content with the number of items 'count' when the listing of the items goes over several pages.

What happens is that the number of items that are 'found' is only decreased from the total by the number of items in the current page listing that cannot be viewed because of categorisation (ie WYSIWYCA).

For example if the listing per page is set to 25 items and there are 55 total items but 6 are excluded for WYSIWYCA reasons (4 excluded in the first 25, and 2 in the second 25) then the first listing page only shows 21 items and says there are 51 in total; the second page shows 23 items and says there are 53 in total and the 3rd page shows 5 items and says there are 55 in total.

So whilst WYSIWYCA integrity is correctly preserved, the number count varying every time you scroll through the pages is obviously very confusing.


Aug 15 - closed this item as its so old and may no longer be an issue
tracker item
When using articles, no horizontal menu is shown (thenews.css based theme)
When using articles on a tiki 5 site, using a thenews.css-based theme style, we don't see the horizontal menu at the top bar.
On all the other tiki features, that menu is shown as expected.
You can reproduce that here:
http://intercanvis.net

versus


http://intercanvis.net/articles
tracker item
WYSIWYCA & default settings for inter user messages
When I click a user, I am offered to send him a message. But then I get:

User XYZ can not receive messages
ERROR: No valid users to send the message

1: WYSIWYCA: I should not be offered to send a message if the user has disabled that. (frustrating to write such a message for nothing)

2: tiki-user_preferences.php: "Allow messages from other users" default should be yes

3: tiki-user_preferences.php: "Send me an email for messages with priority equal or greater than:" default should be "3"

tiki-admin.php?page=login
3- Users accept internal messages by default: default should be yes -> $allowmsg_by_default

4- Users can opt-out internal messages: default should be yes -> $allowmsg_is_optional


All these should be the default settings (most logical) if a Tiki site admin choose to activate inter user messages.

Related:
Easier Inter-user message management for Tiki admins:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=959

Also related:
Should sender email be disclosed when receiver gets notification via email? goals: balance privacy & facilitate communication/collaboration
tracker item
WYSIWYCA for all permissions : feature_check in Table: users_permissions
Started in 3.0, needs to be used in tiki-admingroups.php and propagated to various places where permissions are set.


Also on wish list: A way to put more emphasis on more important permissions.

Either basic vs advanced or an ordinal column (top put more important stuff at the top)

So for a wiki page, view, edit and history should be at the top or in basic while tiki_p_use_as_template and tiki_p_export_wiki should be in advanced
tracker item
WYSIWYCA for Wiki Links
Wouldn't it be great if a wiki link (the standard [] syntax) would check whether the current user has rights to the page that it links to? THat way we could turn off the hyperlink if the user cannot open the page anyway...THat would add some processing overhead, but I am sure that would be manageable.

Don't know where to begin, though, I do not really understand the wiki processing in Tiki...
tracker item
WYSIWYCA in polls broken in BRANCH-1-9
If I add a poll in a module, a registered user can see it even though he can't vote.
tracker item
WYSIWYCA needed for since_last_visit_new module
It is currently possible to see links to tracker items we are not supposed to see. (clicking gives error message)
tracker item
WYSIWYCA on Inline Tracker edit
tracker item

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools