Category: 3.x

Currently there is only one (two) methods to come from blog view (tiki-view_blog.php?blogId=<int>) to the view blog post page: Clicking on the small "Permalink" or "Comments" Link at the bottom of the post.
I find it more intuitive (or I'm just familiarized to this by the other blogging solutions out there ;-) ) to click on the title of the specific post to view it with its comments.

Everytime I use the maketoc inside a wiki page on a fresh tikiwiki 3.2 install the whole page content is duplicated every time I hit "save". Even if I delete all the content but one version and hit save the whole PREVIOUS page is duplicated again. Like I hit save: two times the page content. I delete all but one time the content, I hit save: three times the page content. I delete all but one time ... save ... four times the page content.
Only removing the maketoc makes it possible to get rid of the problem.
That was done with Opera browser on a page with 4 h1 headings but I doubt it is a browser problem. :)

This tracker item could not be found

A small collection of related issues with maketoc:

^{maketoc} -=Maketoc issues=-^
!!! ''TOC and heading type sizes''
* This is an issue that seems to crop up repeatedly on tw.o. Users would like to be able to easily control type size of both the TOC itself and headings created by maketoc. Type size for both seems to be theme-dependent now, with many themes using very large type size for headings, some with a type size for TOC entries that is too small for users with only slight vision loss. It would be a Good Thing if TOC and heading type sizes could easily be set globally, per object type, and by category, with switches available to vary those settings on a per page or object basis.
!!! TOC and heading character attributes
* It would help reduce inconsisistencies in TOC and heading character attributes (as in this tracker item) if the attributes could be set globally, per object type, and by category, with TOC switches available to vary those settings on a per page or object basis. However, the ability to manipulate emphasis within a single TOC/heading entry should be retained, so that for example, a single word could be italicized in a TOC/heading entry.
!!! Vertical linespacing between headings and text
* Under some themes, vertical linespacing between text and headings is too much for taste, or as in the theme affecting this tracker item, too small for taste. This is another setting that should be unleashed from the themes and made easily selectable by a Tiki admin through global, category, and object type settings, with switches for per page or object variation.
!!! ''Backlinks from headings.''
* Links from the TOC to headings are now 1-way. For larger pages, maketoc would be much more user friendly for those viewing pages if clicking on a heading would take you back to the TOC.
!!! Outline numbering.
* TOC formatting and heading formatting would be friendlier to the eye if both could be assigned numbering schemes such as 1., 1.1, 1.1.1, 1.2 or I., A., 1., a., II, etc. Settings might be implemented as described for ''TOC and heading formatting.'' If developed, this might be implemented for lists as well.
!!! Headings indentation.
* Many power users in the word processing and outliners worlds expect headings to inherit the indentations of the corresponding TOC entry. This would help break up the visual clutter that happens when many headings are close together vertically as a result of short text elements separating them, as in this tracker item (but it is far worse when there are subtopics and corresponding subheadings). Settings might be implemented as described for ''TOC and heading formatting.''
!!! Text indentation
* Many people used to word processors' outlining or stand-alone outliners expect text to be left-indented one tab more than its heading. Relevant settings might be implemented as described for ''TOC and heading formatting.''
!!! Associated features
* Display current settings in editor, change current settings from editor. Make changes to settings made from the editor apply only to the object being edited, so that users do not accidentally apply per object settings to other objects. Admins should have option to disable deviations from admin-set settings.
* maketoc is commonly used in conjunction with list features. Any changes to maketoc should not unintentionally impact the list feature and ''vice versa.''
* Need to ensure that all enhancements suggested render correctly when Tiki objects are exported as PDF.
!!! Future options
* Future options might be kept open by maintaining compatability between Tiki objects containing maketoc elements and various formats used by outliners such as OPML, XOXO, OML, or OpenDocument XML. (See corresponding Wikipedia articles.) E.g., it might be feasible at some point to directly export an outline file to Tiki where it is imported as a wiki or blog page and ''vice versa.''

__The message below was edited.__ {sign user="Chealer9" datetime="2018-06-08T15:57:21+00:00"}

We are running into an issue of maketoc appending onto itself if more than one maketoc appear per page. for starters, our server is TikiWiki 3.2, Windows Server 2003, apache 2.2.13, mysql 5.1.39, php 5.3.0, Multiwiki setup.

We are seeing this in ((doc:Multiprint)). What I am seeing is that if I have Tikipage A with a ~np~{maketoc}~/np~ at the VERY top and headings 1, 2, 3 and Tikipage B with a ~np~{maketoc}~/np~ at the VERY top and headings 4, 5. When I Multiprint using the Pages selector (both Tikipage A and B) there will be 2 TOCs displayed in the resulting print page. The first TOC will show 1,2,3 and further down the page will be 1,2,3,4,5 (when I expected only 4,5). We are trying to Mulitprint hundreds of pages (and most have their own maketoc) so the very last TOC takes up 15 pages itself (after accumulating TOCS over 100s of wiki pages). Big problem for us as our nurses need to have a hardcopy/offline copy on hand in case our systems go down.



So it is the parsing of the maketoc that is causing the appending of subsequent TOCs. I found a bug by "larryg" where he tries to fix a similar issue (cf {wish id=2781} and [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=2&comments_parentId=34791]) but his fix did not work for me. I think that he is on the right track. Does anyone know of a fix? Has anyone experienced this? Is it fixed in 4.x?

Thanks in advance,

Tim

{syntax type="tiki" editor="plain"}
Nothing happens
http://doc.tikiwiki.org/tiki-mindmap.php
http://dev.tikiwiki.org/tiki-mindmap.php

On at least two sites, running respectively 3.x and 4.x:

- jiamcatt.ourwiki.net (3.x)
- terminology.tikiwiki.org (4.x)

I noticed that if I change a wiki page and save it as a minor edit, email notifications are still being sent.

I think that this only happens when the user is part of a group for which a Group Watch has been set. When I tested on the 3.x site, that's the conclusion I had come to (this AM, UK time). But this PM (UK time), I tested on the 4.x site, and it seems that the minor edit is causing notification even if a user-defiined watch (i.e. as opposed to a group watch) is set.

BTW: This bug caused a minor incident on the JIAMCATT site. Someone did about 30 minor edits to a page that was being monitored by a large number of people, because he was a newbie and was trying to master the syntax for referencing a section inside a page. As a result, 30 notifications got sent to a hundred people, and some of them got pretty pissed off, and almost walked out on the site. One person asked to be "taken off this infernal web site".

So, if the bug can be fixed quickly, I can go back to this community and tell them that something was done to prevent that sort of problem in the future, which might diffuse the crisis.

Here:
http://tikiwiki.org/TikiCopyrights

I just got:
{img src=images/code.png}%%% {CODE()} WARNING: No such module CVS! copyright.txt {CODE}

Similar to orphans pages and wanted pages, it would nice to have a way to have a list of used plugins (how many times used) from which we know how many are broken.


This happens if someone attempts to use a plugin which isn't activated. This can happen on upgrade for example or if a plugin was de-activated.

We need a way to know how many times each plugin is being used. So we can deactivate without causing issues.

Also, __approval of plugin security__ conflicts with wiki cache. When approving, cache should be cleared. Please test.


** Would need to watch this list
** Rick asks for a [http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2009-05-01,Fri&sel=120#l116|mass approve]

When viewing the list of messages, no matter how many messages have been chosen to display, the system displays at the bottom

Page: 1/1

With no prev/next links

There is no way for users to access the rest of their messages. Sorting works, so they can reverse-sort the date etc... but this is hardly equivalent and anyway once they have more than 2x the display list size, the remaining messages are out of reach entirely.

With any Theme selected.

Contrary to TikiWiki documentation (and contrary to TikiWiki common sense) it is NOT possible in a 3.0 wiki (specifically http://jiamcatt.ourwiki.net) to assign any permissions to Newsletters. This means that NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

JIAMCATT is the community of IT-oriented managers of language (translation and interpretation) services of major International organizations and European multilateral bodies. After a slow start about a year ago this community has now agreed to try to use a TikiWiki-based system. Within the past month (since several of the TikiWiki team participated in the JIAMCATT annual meeting in Ottawa, Canada early May 2009) close to 200 users have joined up.
One key aspect of the work of JIAMCATT are Working Groups. One of these has just started work. It’s tools include wiki pages in the two working languages (En + Fr), a discussion forum (consisting already of 13 topics), and – last but NOT least – a Newsletter to keep everyone abreast of developments. This feature, it now turns out doesn’t work in a very bad way: NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

I expect this should be a simple fix for a TikiWiki insider (the feature existed at the time the documentation was written); albeit impossible for someone not intimate with the insides of this system.

Screen shots are attached. The first – now shows as the last – called “ButtonsAvail-inJiamcatt-ourwiki-net-Newsletter-admin.gif” shows the buttons seen by an Admin user when trying to do “Admin Newsletters”. The second, called “MissingButton-from-doc-tikiwiki-org.gif” shows the buttons in doc.tikiwiki.org in the http://doc.tikiwiki.org/Newsletters section in the http://doc.tikiwiki.org/tiki-index.php?page=Newsletter+Admin&bl=y page, under the segment titled “Changing Existing Newsletters”. The third screen shows you what a non-Admin user who should have access to view newsletters and archives of this Working Group, sees (file: “Empty list of newsletters for (nonAdmin) WG members.gif”).

Unless someone can provide a fix quickly, this group will abandon TikiWiki as its working tool.

omstefanov

{syntax type="tiki" editor="plain"}
When you add the module last_files, the tikiwiki can't be started anymore! Everything is blocked and that is it. The server load goes up to the maximum

Forbidden 303 error when trying to save a blog, caused by mod-security

{syntax type="tiki" editor="plain"}
Assign the module ''events'' on the left, and you get a weird looking of the left menu, and a disappering content on the right side.
Assign it to the right side results just in wrong textcolors for the left menu.
In both cases the bottom bar will be shown in the menu (on the corresponding side where the events module is assigned).
Tested with all stadard themes, for all the same result.

And it doesn't show a calendar with events, so it's useless at all.

Tested with firefox 2 and 3 under linux.

Btw: Module calendar also shows no calendar, but at least it doesn't break the themes.

module calendar is only showing one letter for the week days. However, some languages (such as Catalan, at least) have all week days starting with the same letter, which produces a useless letter on the top (if you take into account whtat it might be showing sunday in the first place instead of monday, which is the first day in the whole spain, Andorra and other Catalan speaking countrees.

example of useless calendar week days:
http://moviments.net

or maybe just add a popup (overlib?) tip with the full name of the week day when the mouse pointer is over the letter?

Clicking on the module controls (up, down, across, remove) does nothing. Also (the easy to fix part), the module flipping icon overlaps the right-hand end of the module control icon.

{syntax type="tiki" editor="plain"}
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.

Say I use 3 structures to hold wiki pages on a site.
The 3 structures are used for very different subjects or interest for users.
I am using the last_modif_pages in the Homepage wiki page, but everything from the 3 structures is mixed.
I would quite like passing the structure Id as a parameter so only its pages would be listed.
I would then probably use 2 or 3 times the module in the homepage, one for each structure, so that I could show modified pages in distinct areas of the homepage.

there seems to be a bug around module last_tracker_items , here in dev.tw.o
To reproduce: submit a bug report through:
http://dev.tikiwiki.org/Report+a+Bug

once submitted, you are redirected to:
http://dev.tikiwiki.org/your+wish+has+been+cast

but there is no item shown in the box
^ __Last Items__
^

The item, however, has been successfully created at the tracker.

I have set feature_comment_moderation=y, so new comments are invisible until approval, but they are shown as new comments on the since_last_visit_new module. So if user clicks on this link they come to the page where the comment was made (currently only tested with blog comment, but should be the same with other comments), and don't see this new comment.
I've no idea if this also affects coming version 4, only working with v3.2

{syntax type="tiki" editor="plain"}
In recent trunk installs, no module windowshading/flipping icons appear. I noticed a new check for a javascript pref in module.tpl. Is there an admin option for this?

The module mod-since_last_visit_new.php does not currently check to see if a parameter has been set to set the title. As a result, the current code always displays "Since your last visit...".

The desired effect is to allow an authorized user to set the module title using the 'title=my custom title' parameter.

This tracker item could not be found

Typically, mouseover is to show more text over a small snippet. To save screen real estate.

So the data in the mouseover will typically be much large than the text. Plus, I may want wiki syntax parsing in the mouse over part.

It is now:
{img src=images/code.png}%%% {CODE()}
{MOUSEOVER(text=text that goes to mouseover)}
snippet that is moused-over
{MOUSEOVER}
{CODE}

It should be :
{img src=images/code.png}%%% {CODE()}
{MOUSEOVER(label=snippet that is moused-over)}
text that goes to mouseover
{MOUSEOVER}
{CODE}


Plus, this is a very cool plugin. It should be in main code base, like the THUMB plugin.

{syntax type="tiki" editor="plain"}
Plugin Mouseover in 3.0 now uses label= in the options to specify rollover text (Create a mouseover feature on some text). Text works fine but in previous versions you could use an image instead of text. Now the image displays (if you use "{img src=...}", "<img src=...>" does not work even if you have "allow html"), but no roll over text is displayed when you mouseover the image.

Note: The mouseover plugin only appears to work only if MooTools UI Enhancements is selected. Maybe this needs to be added to the Mouseover plugin documentation.

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"}