Category: Tags

Freetags would be very nice on other Tiki objects, specially Tracker items, in order to make Tiki more 2.0 compliant... (and since trackers are used by users, which not always find their natural cateogries in the pre-fixed categories by an admin system in Tiki (through categories feature)

Contributors

On the Admin: Freetags page, the "Number of Tags to show in Cloud:" field controls the number of tags to display in the tag cloud (such as on the tiki-browse_freetags page).

I would like a way to tell Tiki to show __all__ the tags.

For example, I would like to enter Number of Tags to show in Cloud = 0 to have Tiki show all tags.

Bugs & Wish list

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.

I would like Tiki to display each item's freetags when display the search results. This would help end-users determine the relevancy of each item.

I would like Tiki to display each item's freetags when display the search results. This would help end-users determine the relevancy of each item.

As Admin, when I create new Topic Post in a Forum, and add Tags and post... if I edit the former post tags, adding more tags, they are not saved. The former tags remain.


General Settings:

Tiki 6.0 fresh install.

Problem solved in 6.2

In many cases, have extra structured fields in wiki pages would come in handy. Ex.: a glossary of terms may need a field for noun, adjective, etc.

Categories and tags are not in the version history, and it would be clunky anyway.

((doc:Pretty trackers)) are awesome when it's a data centric context. But when the structure emerges from the wiki, it's better to have extra fields to wiki pages.

Right now, users always make too many variations of tags. One way to solve the problem is to have Flickr style auto-complete of tags when entering them.

===v2.2===

When an item has a Freetag added and the Freetag menu looks for content with a designated tag it will list ALL content - even if some pages are Categorized and the particular user doing the search does not have permission to access the page.

Obviously the user cannot actually access the page but being able to see it makes them think it is available to them and just knowing a particular page exists may create difficulties.

Need to filter the objects being listed (presumably in tiki-browse_freetags.php in a similar way that tiki-listpages.php does this) so that only objects that the individual user is allowed to see are listed.

Using 1.10cvs from mid june 2007.

Created a tiki from scratch (basic enabled profile). change features, and make sure freetags are enabled.
Added freetags to a wiki page.like this:
{CODE()}
help ayuda ajuda cómo com howto
{CODE}

After that, I can see the list of words on top of the page. When we click on any of the freetags, it goes to : http://yourdomain/subdir/tiki-browse_freetags.php?tag=help

Ann nothing is displayed there in the table of tagged content:

^
Browse related tags


Tots Planes Wiki Galeries d'imatges Imatges Galeries d'arxius Formularis Trackers Items
Troba:
type name href description










[[ant] Pàgina: 1/ [prop
^

Btw, it's a multitiki installation, on subdirectories (not virtual hosting)

Categorisation is a social problem - different people have different words for the "same" category.

Use Google-like tags (check schtuff.com for a nice example) - this would make lots of wiki pages easier to find, IMHO.

In tables
tiki_comments, tiki_history, tiki_pages, tiki_tags tiki_user_voting
the column IP is too short (varchar 15) for IPv6 logging

In tables
tiki_actionlog, tiki_download, tiki_logs the column IP is very big (too big ?) varing from 39 to 200 char . In tiki_download the IP cloumn is in UPPERCASE (may be problem with some Mysql installation)

In tables
tiki_banning
the IP is split in three columns . so we can't bann an IPv6

Contributors

To reproduce: tag something with an apostrophe, like "l'apostrophe".

get to tiki-browse_freetags.php
This tag is displayed as "l\'apostrophe" instead of "l'apostrophe"

Note: it still works for searches, so fixing the display of the freetag should not break the search feature.

We already have categories, etc.

a) There is no way of displaying __all__ available tags.
b) There is no way to sort the available tags in alphabetical order when editing a wiki article -> properties.
c) The list of tags from case b) is hardly readable because the formatting leaves something to desire
d) There is no way to influence the sorting when displaying the freetags using the module Most Popular Tags.

The module freetags should have an option to disable the display it as a menu item in the main menu.

I feel the need for a tag description field (that could be) associated to each freetag. That'd allow to place a definition (what does this tag mean ? what should it be used for ?) to make it as clear as possible for users to use the tags and know what they mean.

Not sure wether it was possible or not, I posted a message on the forum : http://tiki.org/tiki-view_forum_thread.php?comments_parentId=44367&forumId=4

Before limiting freetags to "Alphanumeric ASCII characters only (No accents or special characters.)" in the Admin - Freetags settings, a user tagger w wiki page with brf+.

It seems the special sign "+" is not well managed when removing the association.
The Remove seems working fine but nothing happens.

Features Classification

Contributors

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.

Semantic link relationships seem until now only browsable by admins.
Since there is - besides the admin view - no other way to get the semantic relations listed, no one else can get advantage of semantic links and will make no efforts in setting semantic relations.
Concidering the importance of semantics in wikis a plugin seems highly necessary to get the feature of semantic links in tiki started.

__Request:__
Likewise to the Plugin ((Backlinks)) all pages that link to a specific page in a specific semantic relationship.

__So far:__
The semantic_links module is supposed to enable views on semantic relationships.
And indeed, when selecting a semantic type and push the button "show usage", the result shown is exactly what I need.
However this view is only possible for admins.
But since that view for admins is already existing, I would estimate the efforts to implement a plugin as low.

__Plugin idea:__
Relating to the example shown in the documentation of ((SemanticAdmin)) dogs and cats are subsets of animals.
We want the page "animals" to list all subsets by a plugin likewise to

{SEMANTICLINKS (semantictype=subset, page=animals, info=hits|user, noheader=1}
{SEMANTICLINKS}

The result would be:
- dogs
- cats


__Insufficient workarounds:__
Until now the above shown results have to be specified manually as invert relations.
For automatic listing, existing plugins ((PluginShowpages)) / ((PluginListpages)) / ((PluginSearchtitles)) do not work.
So the only workaround without the requested plugin I could image would be to tag the pages "dogs" and "cats" with the a tag "subset-animal" and than use freetags plugin for a listing dogs and cats in the animal wikipage - likewise to the status tags in this tiki. However, that sounds like a bad abuse of tags, since we already got that information saved in our semantic links relationship - we just need to get it readable.

__Related pages:__
Relating to forum discussion with marclaporte:
[http://tiki.org/tiki-view_forum_thread.php?topics_offset=20&topics_sort_mode=lastPost_desc&forumId=4&comments_parentId=38751]

See ((Social Bookmarking Within Tiki)).

When creating a page, include quick tags in the Folksonomy Tags box. They show up in the Most popular tags module, but when clicked on in the cloud none of the tags entered on a Blog page can be found. Tags from gallery and wiki pages are found and listed, but nothing from any Blog page.

This is consistent across three Tikiwiki sites. Although they are all hosted on the same server.

Have tried it with Linux & Windows, Firefox, IE, Opera & W3M.

Tiki version: 3.1
PHP Version: 5.2.9
Apache version: 2.2.13 (Unix)
MySQL version: 4.1.22-standard

It is possible to enter tags made from more than one word by entering them between "". Since 3.0, the system seems to still recognize those tags (they are rendered correctly in the "Most popular tags" module, but clicking on such a tag comes up with "0 results found". The same applies for the Folksonomy module, which shows correctly, but comes up with 0 results for such tags. It does not matter if the tagged object is a blog post or a wiki entry.

It is possible to enter tags made from more than one word by entering them between "". Since 3.0, the system seems to still recognize those tags (they are rendered correctly in the "Most popular tags" module, but clicking on such a tag comes up with "0 results found". The same applies for the Folksonomy module, which shows correctly, but comes up with 0 results for such tags. It does not matter if the tagged object is a blog post or a wiki entry.

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

Contributors