Category: 9.x

Collapsible sections are those created by starting a title with "+" or "-". Some of these sections cannot be expanded or collapsed due to a conflict with other collapsible sections shown at the same time but parsed in different contexts.

When such a conflict happens, the div elements of the conflicting sections have identical id attributes (which means the HTML is invalid). Browsers deal with such conflicts by considering that the real element with the duplicate id is the first one. Consequently, when that happens, trying to open/close any of the conflicting sections will open/close the first conflicting section.

It would be difficult to explain exactly when this occurs or not, but this is very simple to reproduce. Suffice to call the FADE plugin twice and to have at least 1 collapsible section in each call's body. Trying to open or close the first section of the second call to FADE will fail.


!! Cause
The identifiers of the section are generated in parse_data_process_maketoc(). The $nb_hdrs variable holds a count of collapsible sections which attempts to avoid such conflicts, but as this is a local variable, when parse_data_process_maketoc() is called several times, conflicts can occur between different contexts. As FADE calls parse_data() to parse its body, a page's immediate content and its content inside a FADE zone are parsed in different contexts.

This affects trunk as of r69061.

!! Example
This is demonstrated on [http://chealer-232-7031.show.tikiwiki.org/tiki-index.php?page=HomePage|this show.tikiwiki.org page].

See 9.x:
https://profiles.tiki.org/Admin

Still a problem in trunk:
http://nextprofiles.tiki.org/Admin

This is the commit that caused it:
https://profiles.tiki.org/tiki-pagehistory.php?page=Admin&compare=Compare&newver=14&oldver=13

Currently what happens is when user clicks on a perpective link (tiki-switch_perspective.php?perspective=8), it will automatically change to http://example.com/tiki-index.php which is the same address for any perspectives by default... which can confuse user when they add the link as bookmark (favorites links) their browser will save the this link http://example.com/tiki-index.php and not http://example.com/tiki-switch_perspective.php?perspective=8

Synchronize a Tiki Forum with a (Mailman) Mailinglist

a) Forum outbound email (Regression)
In Tiki 11 it was observed that Tiki cannot send emails out from a forum post to a mailinglist. This problem might be produced by Zend/composer. This is a regression. It works in Tiki9.5 (not clear about Tiki10). More Info:
https://dev.tiki.org/Regressions+in+11x
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=47927

b) Forum inbound email (Error)
In Tiki 9.5 it was observed that postings from a mailinglist are shown in Forum with wrong author sometimes. Users of Forum and Mailinglist are not necessarily identical. Some users are registered at forum and mailinglist, and they are recognized by Tiki via email address correctly. Every now and then (no clear pattern yet) an inbound email from mailinglist is registered in the forum with wrong username and wrong email, apparently random chosen by someone else who wrote earlier to the list and was listed in the forum with his post.
In addition Tiki Forum breaks threading if the email topic is changed. This might be intentional and due to lack of internal handling of emails' Message-Id header.

c) Tiki Forum header (Wishlist)
Tiki recognizes whether an inbound email was sent by forum or not. This is done by a header. This header should be up to configuration, because it is not possible to connect two different Tiki forums with one mailinglist.

d) Demo and Showcase
Unfortunately it is not possible to construct a showcase easily, because the setup of Tiki plus Mailman is quite complex (spam protection would require an isolated setup which cannot spam real world) and the pattern seems to be dependent on race conditions.

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

tiki-print_pages.php should allow to set the parameter tikiversion at printing time, if Plugin Versions is being used. Example: doc.tw.o of twforsmarties: print documentation for veersion 1.9.x, 2.x or 3.x.
http://doc.tikiwiki.org/tiki-print_pages.php

http://twbasics.keycontent.org/tiki-print_pages.php

Right now, if I want to print the full structure of the documentation, I can't chose version (so that the default is shown)


marclaporte: and the same idea should apply to language. Show me doc in my language, if there is none, fall back to available language.

When a wiki syntax field calls maketoc and the FADE plugin, the table of contents generated may contain bogus entries at the beginning. All the titles in the body of any call to FADE are taken into consideration by maketoc.

This bug is very similar to {wish id=5496}.

! Example

With the following field content, the TOC contains 2 headers, instead of just "Normal header":
{CODE(color="tiki")}
{maketoc}

! Normal header
This is a test page for the FADE plugin.

{FADE(label=Label)}
!! Header which should not be in the TOC
Lorem ipsum...
{FADE}
{CODE}

Since unified searches are done against an index for performance and scalability instead of against the whole content of the database as before, every new or changed content needs to be indexed. When someone imports a bunch of tracker items through the csv import feature, Tiki knows better than to index all at once, and it indexes 10 items and queues the rest for later indexing (10 at a time). There were 592 items in the queue!

When we edit a page and save it afterwards, there is a bug: Tiki forgets to be clever and presumably tries to index the new page content as well as the whole queue on unindexed data. So, it times out with the following message:
Fatal error: Maximum execution time of 90 seconds exceeded in /data/root_www/promusa.alsawiki.com/20140801_www.promusa.org/vendor/bombayworks/zendframework1/library/Zend/Search/Lucene/Search/QueryLexer.php on line 348

Raising Maximum execution time is no solution: it only blows after more time.

The page is actually saved

Going to the admin → Search → Index maintenance → reindex All
empties the queue and aftewards editing wiki pages is possible again.

Admin trackers / <select tracker> / export&import / import items, csv

the tracker has two fields:
1 A text
2 B auto-incrementing itemid

the csv has one column and two rows next to the header:
A
apple
banana

parameters:
as new items not checked (expecting that it will either replace items, or remove them all)

result:
in admin trackers the number of items increases
the items view does not show any new items (even if the tiki cache is emptied) and it shows an unchanged number of items

Sometimes, the pagination generated by the tracker does not work. Here is an example:

#Go to:
+[http://app07.ottawa.ca/smwk/prvacancies/tracker1|http://app07.ottawa.ca/smwk/prvacancies/tracker1]
#Click on closed items
+{img fileId="965" thumb="y" rel="box[g]"}
#Select a filter
+{img fileId="966" thumb="y" rel="box[g]"}
#Scroll to the bottom on the page and click forward arrow to next page
+{img fileId="967" thumb="y" rel="box[g]"}

It auto-generates a “Page 2” link as follows (which gives an error):
[http://app07.ottawa.ca/smwk/prvacancies/tracker1&status=oc&sort_mode=lastModif_asc&filterfield=1&filtervalue%5B10%5D=English&filtervalue%5B11%5D=Aquatics+%2F+Programmes+aquatiques&filtervalue%5B8%5D=Attendant+Recreation+%26+Culture&&filtervalue%5B1%5D=Routhier+CC-172+Guigues?offset=24|http://app07.ottawa.ca/smwk/prvacancies/tracker1&status=oc&sort_mode=lastModif_asc&filterfield=1&filtervalue%5B10%5D=English&filtervalue%5B11%5D=Aquatics+%2F+Programmes+aquatiques&filtervalue%5B8%5D=Attendant+Recreation+%26+Culture&&filtervalue%5B1%5D=Routhier+CC-172+Guigues?offset=24]

What it should do, is generate it as follows (which works):
[http://app07.ottawa.ca/smwk/prvacancies/tracker1?offset=24&status=oc&sort_mode=lastModif_asc&filterfield=1&filtervalue%5B10%5D=English&filtervalue%5B11%5D=Aquatics+%2F+Programmes+aquatiques&filtervalue%5B8%5D=Attendant+Recreation+%26+Culture&&filtervalue%5B1%5D=Routhier+CC-172+Guigues|http://app07.ottawa.ca/smwk/prvacancies/tracker1?offset=24&status=oc&sort_mode=lastModif_asc&filterfield=1&filtervalue%5B10%5D=English&filtervalue%5B11%5D=Aquatics+%2F+Programmes+aquatiques&filtervalue%5B8%5D=Attendant+Recreation+%26+Culture&&filtervalue%5B1%5D=Routhier+CC-172+Guigues]

(only change is that "?offset=24" is at the beginning of the parameter list instead of at the end)

- Imagine you have a record with ten fields, but you only have a 'n' in the last column. It is not easy to select this column.
- Since each field contains a separate field, it suggests that each brings you to some different page.
- If one link of a record is active, the record is not selected.

If the field used for sort_mode is an item link, any initial selected results in zero items returned.

Steps to reproduce:

1) Create trackers:

Tracker "Names", id=1
Text Field "Name", id=1
Values:
"Fitzgerald,F. Scott" id=4
"Follett,Ken" id=5
"Grisham,John" id=6

Tracker "Titles", id=2
Text Field "Title", id=2
Values:
"Great Gatsby, The" id=1
"Dangerous Fortune,A" id=2
"Painted House, A" id=3

Tracker "Books", id=3
Item Link Field (2,2) "Title", id=3
Item Link Field (1,1) "Author", id=4
Values:
"Great Gatsby, The","Fitzgerald,F. Scott" id=7
"Dangerous Fortune,A","Follett,Ken" id=8
"Painted House, A","Grisham,John" id=9

2) Add trackerlist plugins to wiki

{CODE()}{trackerlist (trackerId=1, fields=1, showinitials=y, sort_mode=f_1_asc) /}

{trackerlist (trackerId=2, fields=2, showinitials=y, sort_mode=f_2_asc) /}

{trackerlist (trackerId=3, fields=3:4, showinitials=y, sort_mode=f_3_asc) /}{CODE}

3) Filter on "F" - you will see two authors and no titles or books (expected)
4) Filter on "G" - you will see one author, and one title, but no books. The book should have been listed also.

I did step (2) above on the home page of the show.tiki instance. To rule out interference between the 3 plugin instances on the same page, I also create separate wiki pages "Names", "Titles", and "Books" on the show.tiki instance. The behavior was the same.

You can see another example on our site:
http://www.hrsms.org/home/References

When trying to find a workaround, unexpected behavior was found in TrackerFilter. When the filter is 3/i (intials for title), clicking on a letter results in all titles with the letter anywhere in the string being returned. I would expect only those beginning with that letter. This has been added to the show instance to demonstrate.

You can set a tracker to hold more user information.
On the tiki preferences (tiki-user_preferences.php) it will set a link "User's personal tracker information: View extra information".

With tiki in english the link will go to the user (latin-char or non-latin-char) i'm look at.
If the Tiki is set to multilingual the link is broken and will show my own (admin for example) information.

The functionality to allow comments in wiki pages on a 'per page' basis that was in Tiki 6 has been moved from Wiki admin to Comments admin and is therefore less visible

It should be replicated in Wiki admin as well to make it more visible


Fixed r48529

{syntax type="tiki" editor="plain"}
The plugin section of the wiki help is listing the plugins aplhabetically based on their english name. When it is translated to another language the sorting remains based on the english name, it is quite confusing and looks a bit chaotic in other languages in my opinion. Is there a specific reason why the code here is written this way? If not, can this be fixed for Tiki 4? I dont know how to do it but would appreciate it :)

same as Tracker numeric input.png but with input

screenshot of cursor position in numeric tracker input field

Images uploaded to tracker field image do not respect multitiki paths.

When you upload an image to this type of field, they go to

__img/trackers/__

When you are in a multitiki of, let's say, site1.example.com and site2.example.com, you have a folder for site1 at:

__img/trackers/site1.example.com/__

but your image files don't get uploaded there, but to the general

__img/trackers/__

And the same with all the other multitiki sites.
When you want to backup files, or migate a site to a new server, you are in trouble to know which files belong to which site from the multiki installation.

For consistency with how multitiki works, they should be uploaded to, and used from, the multitiki-aware path:

__img/trackers/site1.example.com/__

^ Related to http://dev.tikiwiki.org/bug1184 . Opened a new one since those comments below are updated of a new trial I made today - Jan. 7th, 2009^
Issues detected while dogfooding "__minimum-clicks for pdf from doc.tw.o/Documentation structure__". An opportunity to improve the current features for production.
Related links:
http://doc.tikiwiki.org/Documentation
and
http://doc.tikiwiki.org/tiki-print_pages.php

Printed to html using SeaMonkey browser 1.1.12 and to pdf CUPS/pdf printer, both under Ubuntu 8.04 GNU/Linux
page numbers refer to a pdf produced today out of there:
[ftp://ftp.ourproject.org/pub/edutiki/090107_doc_tw_o___Tikiwiki_Documentation_SeaMonkey.pdf]
(25Mb)
-----------------------------------------------------------------------------

* Autonumbering of headings is shown on the table of contents, but not on the pages themselves (using the default theme in doc.tw.o, based on thenews.css I guess). I would say that this worked for me a month ago on a 2.1 site using feb12.css with another (shorter) structure of wiki pages ( http://www.iesbarcelona.org/ESSO350/tikiwiki-2.1/tiki-index.php?page=2008+Fall+-+Final+Paper ).

* page 39: .htaccess from dynamic content is not shown in the full page. Can this be modified at printing time so that the full content is shown on the page?

* page 41: a CODE block longer than a single sheet of paper is cut at the end of the page, not showing the rest of the content. Can this be modified at printing time so that the full content is shown on the page?

* Some pages didn't have the title manually displayed. Those ones doesn't show the title of the page (as section of the full pdf)... Maybe the best workaround is to add a setting for the user to select whether he/she wants adding all page names as titles to the pages, or not. For our case, maybe it's easier to remove extra title (easy to identify when you have too title too similar one after the other) than having to figure out where a new page starts... (see plugins pages...). Example: page 127: PluginJS is shown, fine, but not PluginLang, PluginListpages? Plugin Manager?, on the following pages...

* copyright license is needed at the end?

* It would be nice to allow at structure-printing time to select which version among the ones allowed by the PLUGIN VERSIONS (where applicable), had to be selected for printing. Right now, it might be useful for people looking for an updated documentation for their 1.9.x, so that all plugin versions were pre-set to display the content from 1.9.x. Moreover, after April (only some months to go for that) we will have the same issue with people looking for 3.x documentation, or just 2.x. Well, this is just to raise this point for the following months, so that, the better for us for producing our own documentation, the better for other communities producing their documentation using Tiki and coping with their versions also... (Firefox, for instance?)

* when the content is copied and pasted to OpenOffice (using OOo 2.x and 3.x), there are images or tables which are wider than the page size.

* Is it possible to have page breaks added before headings of level X (and let the user select a page break just before a heading level 1, and 2, for instance).
---
Update on Dec 7th, 2012 (Tiki9.x LTS):
* RFE still valid....

In Tiki 2.4 the syntax below work:

~np~{img src="img/wiki_up/cabeçalho" }~/np~

In Tiki 6.4 and trunk it doesn't (I haven't tested with other versions).

The problem is the special character "ç" in the image file name.

This bug was introduced in r22212 (http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=revision&revision=22212). If you remove the call to htmlentities() the problem is solved but I'm assuming this function is there for a reason.

At the end of the installer when launch is run we can get a crash with an exception :

__"Session already opened"__

This has been reported since two years may be six times.

I have not made various test, so may be it depends of the context which is :

#Data upgraded from existing connection
#Run without inhibiting installer

This should not have effect. So I don't understand why others don't seem to observe the problem that I had always.

I need to run again directly index.

{syntax type="tiki" editor="plain"}
Hello,

i've upgrade my site at 8 version.

now when i upload an image and i try to use with img placeholder appear the error "file is not an image"

i read that is couse by Ajax uploader, indeed i've activated this feature recently.
so i 've unactiveted this feature but the uploader is still in Ajax.

can anybody help me?

Hi,
with 8.1 (and before) a __fixedwidth style__ (default 990px) like twist, __when it has to display a list like "wiki pages" overlaps the center column outside the layout of 450px.__

What do you think of this ?
Do any solutions have been studied ?
Do anybody works on this problem ?

The function has "no error bug" but it is not a professional way, a tester said to me whoa !!! you are going to try to propose this...

!!Working on :

Several solutions can be studied and combined :
# __embed these "tables" into tables__ so that they can't overlap but have hscroll (with all fields for selection). This is technically valid but __not at all sufficient because it is unusable__ quite heavy... but can be useful to have studied for later
# Add table with a minimum of 9 cells :
** Title and fields which fits the center column (col2) on span 2 c
** Empty
** second tr :
*** The title of element
*** content table with span 2 c and hscroll
** third tr
*** Footer span 2c (width of col2
*** Empty
# Cut the bottom of middle (col1,2,3) overlapping centered and use 100% width of screen, with automatic hscrool if too large with standard browser zooming
# The same hiding the "middle" (basic col 1,2,3) : needs to display the header with 100% width, and a new content header (enhance all styles to be able with good reliability to hide cols - a good check).
# use solution of "embed table" but with a "button to swap" to full width layout fitting the width of the screen
# option for automatic swap to full width when large tables are displayed
# swap fullscreen for tables described above
~~#090:
!!Waiting for ideas and project, thanks
~~

{syntax type="tiki" editor="plain"}
After a search (general by text) the beginning of text which is displayed is not decoded-re-encode for the context.
On the screenshot joined you can see parts of text with tiki tag (!! for h2), HTML tags, problem of encoding UTF8 probably or old text not re-encoded (not yet checked).

As the title describes :

In the panel of a tracker (Bugs and wishes tracker on dev.tiki.org) the tab title for "comments" don't gives any information if exists comments, while the numbers of uploads of files have the number of uploads.
It should be a progress to see into tabs headers if a tracker have generated and how many comments and with a symbol (stars ?) the volume of comments


This concerns tiki version 8.x and site dev.tiki.org