Category: Wiki Structure (book & table of content)

^ 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....

I do not know how to contribute code, but have developed the following "fix" that works to create TOCs when using the >Print Current Document feature in TW. This fixes the problem with the TOC growing to enormous length on a large page with each new section TOC being appended to the previous section's TOC. This fix has worked across many major versions.

File: [tikiwiki]/lib/parser/parserlib.php
Insertion point: in 12.0 line 2814; in 12.2 line 2967

Insert IMMEDIATELY BEFORE the following existing code:
{CODE()}
if (!empty($maketoc)) {
$maketoc = $maketoc_header.$maketoc.$maketoc_footer;
}
{CODE}

Inserted code:
{CODE(ln="1")}
//=====larryg -- beginning of custom code to make TOC and MAKETOC work properly in tandem
global $TOC_newstring, $TOC_oldstring ;

$TOC_newstring = $maketoc ; //===== get a copy of the newest TOC before we do anything to it
if ( strpos($maketoc, $TOC_oldstring) ) // larryg - if this MAKETOC contains previous chapter's TOC entries, remove that portion of the string
{
$maketoc = substr($maketoc, 0 , strpos($maketoc, $TOC_oldstring)).substr($maketoc, strpos($maketoc, $TOC_oldstring)+ strlen($TOC_oldstring)) ;
}

//prepare this chapter's TOC entry to be compared with the next chapter's string]
$head_string = '<li><a href=' ;
$tail_string = '<!--toc-->' ;
if ( strpos($TOC_newstring, $head_string ) && strpos($TOC_newstring, $tail_string) ) {
$TOC_newstring = substr($TOC_newstring, strpos($TOC_newstring, $head_string) ) ; // trim unwanted stuff from the beginning of the string
// $maketoc_header = 'PRESTRINGFOUND'.$maketoc_header ;
$TOC_newstring = substr($TOC_newstring, 0, (strpos($TOC_newstring, $tail_string) -5)) ; // trim the stuff from the tail of the string </ul></li></ul>
// $maketoc_footer = 'POSTRINGFOUND' ;
$TOC_oldstring = $TOC_newstring ;
}
//=====larryg -- end of custom code for TOC and MAKETOC
{CODE}
Please feel free to apply/use as you see appropriate,

-larryg

---
{BOX()}
See comments to this item.
In addition, a show.t.o instance has been created where the issue is reproduced:

http://larryg-10847-5405.show.tikiwiki.org/tiki-print_multi_pages.php?printstructures=%255B%25221%2522%255D&find=&print=Print

u: admin
p: 12345

As you can see, the table of contents in Chapter 2 ("3.2" in the numbering of the single html) shows the issue.
After applying your patch, I get the same issue still in this example.

You can test locally if you want by means of downloading a snapshot of the show instance.
{sign user="xavi" datetime="2014-08-08T09:05:34+00:00"}
{BOX}

How about an infobox that will appear in the right column connected not only to wiki pages but to tabs within the wikipage. the info box would be able to be edited separately from the wiki page but be connected to the wiki page . the info box should be able to include video,maps,graphs,.

here is an example of an infobox that I am working on but this one is not in the right column but withing the page its self.

http://wiki.mousecentral.com/tiki-index.php?page=Splash+Mountain#contentSplash_MountainTab-2

Categories have assosiated privileges. Tiki would be more secure if categories where inherited when a new child page is created in a structure.

When I first met Tikiwiki, I was looking for only a wiki program. The translating for page (multilingual) feature of Tikiwiki made me to choose it.

But I always wonder: does Tikiwiki really need to have so many features ?

We all know that multi-features software is more complicated for developers as well as users than single-feature software. For example, Tikiwiki has a forum built-in, do you think this forum is better than phpBB3 ? Tikiwiki also has an article feature, do you think this feature is better than Joomla! CMS ?

At present, I have a website built with Joomla, I want to add a new wiki section, but Joomla has no wiki component. In fact, I think we should combine these best softwares together, not re-create the wheel. Joomla doesn't need to build a new wiki component if we can integrate Tikiwiki with it. In fact, this integration only needs at least one function: synchronize the users so they can login in to Tikiwiki without register twice.

I should inform you that Joomla! will be the most popular CMS soon, so I hope the Tikiwiki team take some time to consider this integration suggestion.

Thanks.

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

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

For multipage wikis the display of the "table of content" using __maketoc__ isn't ideal as this statement requires to be placed on every page otherwise it wouldn't be visible for other pages.
Usually this "table of content" is used for quick navigation purposes. Therefore an alternate to the __maketoc__ statement should be provided which should allow to specify the wikipage which shall be outline. Such a statement can then be used in a module nearby the original wikipage.

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

!!!This problems concerns quite all table and forms (in tables or not) with fixedwidth themes.
This is the reason while it appear in so many functions.

!!!As for most of tables in many functions, with "twist" (no other style tested) the tables of the middle (C2) either overlap C3 or are behind C3 and sometimes C2. They just have a little part outside the 990px large (in twist as the width is written into css it can't be changed by prefs).

__~~#F00:The corresponding functions are then completely unusable.
~~__

Here I write this for the example elementary function "add an element to a structure" givin in screenshots joined documents

Three scrennshots proposed are :
#What a user see
#The limit of the div as shown by firebug
#The whole div zone hidden

{syntax type="tiki" editor="plain"}
When creating a list of pages for a new structure with the Tree list. The Tiki stalls out and does not create the pages but dies randomly half way or three quarters of the way through the list. I then created a VM environment to test against that same version 9.1LTS and same symptom.
The problem is not there under 6.3LTS. I can create the structure just fine. Then export the structure and import it into 9.1LTS. Not exactly the workaround I want.

For future versions 11 ? 12 ?

Hi,

There are several main marked up languages that we know well.

I think that it will be useful to be able to exchange (import, export) documents with other selected marked up languages.

!!I particularly think to two categories :

!!!1- The task and documents managers used by development tools : Eclipse-Mylin Aptana environment and Bugzilla

Remark :
About this category, I redact documents using textile to describe the developments integrated into projects and bugzilla.
This because I have near fifty elementary project developed since 4.0, stabilized at 8.3 and that I am preparing for 10.x. (They remain for most of them available and someones must be adapted - galleries particularly)

!!!2- The wikies
The problem is to exchange data with users of main wiki.

The need is to use the large capabilities of tikiwiki to hold projects management and documentation. But as it is not specialized it cannot be directly used.

!!There are several ways, this is completely opened :
1- Be compatible i/O with textile which is very closed from basic tiki marked up language. This for basic articles.
2- Develop a plugin using tikiwiki as marked up language for Mylin
3- Look farther with a full XSL XSL-Fo (note that with eclipse all marked up supported languages can be exported as XSL-

!!On the way, proposal
1- First : list of major marked up languages for wiki and task managers
2- Links import export existing from one to another
3- Choose the optimum
!!
Aim :
- Prepare use of tikiwiki in project management
- Be compatible with environments as Eclipse to with other project management tools

!!Reason(s)
- Tiki provides a lot of coherent and very useful tools to manage the content of projects (documents and detailed task management, studies) and groupware life and management which is the core of project management (the classical tools for planning are only in my mind a little part). __But it cannot be connected with specialized existing tools and information systems in various businesses. The problem and aim is to prune efficiently tikiwiki into these organizations.
__
Trebly

Using Tiki 6.x (proposals) and Tiki 7 (trunk)

I have a wiki page that belongs to multiple structures.

I have the "open page as structure" option enabled.


If I open the page directly, Tiki does not know which structure to use, so it opens the page __with no__ structure.

This means that the generated TOC is empty. The only way the end-user knows that the page is __supposed__ to be in a structure is by selecting a specific item from the __Structure__ drop list.

But the end-user may not have any understanding of what a "wiki structure" actually is.

There should be a way to set the default structure for a page.

Many people use the wiki without structures. It should be optional, like the rest.

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

It is not possible to set a multilevel menu using the default implementation of bootstrap in Tiki.

The result of trying using Tiki tools is a weird behavior that doesn't fit the available tools and the user choice (sublevel are omitted and missing).

They were debate among the dev community on early bootstrap v3 days about having or not multilevel menu and multilevel dropdown.

As per today, there are already plenty of solutions for v3 and v4 including multilevel menu;
[https://www.google.com/search?q=bootstrap+v4+multilevel+menu&rlz=1C5CHFA_enIL504IL504&oq=bootstrap+v4+multilevel+menu&aqs=chrome..69i57.8999j0j4&sourceid=chrome&{google:instantExtendedEnabledParameter}ie=UTF-8|Goole search]

Implementing one of those solution in our Tiki menu (that include multilevel menu tools) will avoid revamping it from the ground and having to distinct interface (bootstrap menu __vs__ suckerfish/legacy tiki menu).

Using (or not) structure to create a menu, the first item (top menu item) i not clickable anymore.

Check : http://bsfez-11581-6514.show.tikiwiki.org/tiki-index.php

When changing a wiki structure with drag and drop in tiki-edit_structure.php, the 'save' button doesn't appear as it does in Tiki 18/19.
It's keeps being hidden by css with display:none, beside that it also doesn't work; it will not save the changes.

Please see as showed here, it's possible to drag a new page in to the structure but there is no save button.
http://wobow-11900-7179.show2.tikiwiki.org/tiki-edit_structure.php?page_ref_id=1

I'm creating a Tiki site with several small reusable bits of content (as Wiki pages). Cell phone users are my primary audience, so I'm relying on HAWHAW and HAWIKI. I'd like to use INCLUDE module or structures to reuse the content. Tiki handles it fine, but my mobile tiki doesn't support either INCLUDES or Structures. The INCLUDE lines pass right thru unparsed.

1. Is there an easy way for me to get INCLUDE to work?
2. Is it planned for support in a later release?
3. Are there plans for support for Structures?

Thanks for HAWHAW, it's great!

Rob

{syntax type="tiki" editor="plain"}
If you change the language via the switch language module it also changes the language of a multilingual structure to the same language, even though the option 'Changing the page language also changes the site language' is NOT set.

If you want to translate the page into another language it would be helpful to have those two seperate and don't have to switch language for the menu, and then you have to switch the language of the structure again - thats one step too many if 'Changing the page language also changes the site language' is NOT set.

The method
{CODE()}public function move_to_structure($page_ref_id, $structure_id, $begin=true){CODE}
changes the moved node's structure_id, but not the children's structure_id. The target structure will still show the children, but will not allow them to be moved. (Pressing save will have no effect, basically causing a read-only structure, with no warnings or errors ouptut)

---

Here's your fix:

{CODE(wrap="0" colors="php")}public function move_to_structure($page_ref_id, $structure_id, $begin=true)
{
$page_info = $this->s_get_page_info($page_ref_id);
$query = "update `tiki_structures` set `pos`=`pos`-1 where `pos`>? and `parent_id`=?";
$this->query($query, array((int) $page_info["pos"], (int) $page_info["parent_id"]));
if ($begin) {
$query = "update `tiki_structures` set `pos`=`pos`+1 where `parent_id`=?";
$this->query($query, array($structure_id));
$pos = 1;
$query = "update `tiki_structures` set `structure_id`=?, `parent_id`=?, `pos`=? where `page_ref_id`=?";
$this->query($query, array($structure_id, $structure_id, $pos+1, $page_ref_id));
} else {
$query = "select max(`pos`) from `tiki_structures` where `parent_id`=?";
$pos = $this->getOne($query, array($structure_id));
$query = "update `tiki_structures` set `structure_id`=?, `parent_id`=?, `pos`=? where `page_ref_id`=?";
$this->query($query, array($structure_id, $structure_id, $pos+1, $page_ref_id));
}
// get the page_ref_ids of all child pages of the moved page
$child_ref_ids = array();
$result = $this->query("select child.page_ref_id from tiki_structures p inner join tiki_structures child on child.parent_id = p.page_ref_id where p.page_ref_id=" . $page_ref_id);
while ($row = $result->fetchRow()){
array_push($child_ref_ids, $row['page_ref_id']);
}
// update the structure ids of the child pages
$this->query("update tiki_structures set structure_id=" . $structure_id . " where page_ref_id in (" . implode(',',$child_ref_ids) . ")");
}{CODE}

Moving nodes in structures moves to wrong places in some cases (!): weird behavior in tiki 2.3.

If someone wants to track this bug down, I can provide a db backup of the site where this can be reproduced.

Printing a structure with mpdf, some things are not printed properly:
* Footer (or header) {PAGETITLE}
A wiki page itself can be printed to a PDF, and {PAGETITLE} __in the footer __ will be translated correctly to the footer. But once the same page is printed as part of a structure, {PAGETITLE} in the footer will only produce a void.

* Plugin Last Modification
A wiki page itself is printed to PDF correctly showing the value for {lastmod}. If the same page is printed as part of a structure, {lastmod} will not be translated.

Working in wiki page alone:
{img fileId="1440" thumb="box"}

Bug in structure:
{img fileId="1439" thumb="box"}

When trying to remove an item from a Structure, the page refreshes and there are 2 options at the top of the page that aren't very obvious to the user.

This is inconsistent with our typical Tiki UI. Usually we either have a Popup with a request for action OR a page that requests Confirmation.

I would like to see a Popup with request for action

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))