Category: Wiki Structure (book & table of content)

I'm a bit surprised that this hasn't been picked up by other international users as it seems to be quite broken to me, so maybe I'm missing something.

Multilingual structures only work for detected browser language and for registered user preference. If you try and change the page language using the language drop down box it browses to the new url, but the delivered page does not change.

I think this is classed a bug, as it renders the language dropdown box useless.

It also makes it impossible to edit translations as whenver you visit a page to translate it reverts to the page that is in your default language.

Edit: I've just realised this only happens when open page as structure" (feature_wiki_open_as_structure) is on. That setting is very useful however...

Edit: Even then, the language of the root page in the structure cannot be changed. Unless feature_sync_language is enabled and you go to a sub page, change the language and then go back to the root.

When a structure is printed using multiple print, then the page aliases are ignored.
The TOC shows numbering and aliases correctly.
But the page within the print output shows numbering and page name instead of alias.

This is not only inconsistent, but a major problem:

All pages in TikiWiki must have a unique name. So, in case you need to create similar structures multiple times, you'd need to define some prefix for the page names to keep them unique.
This results in rather ugly page names.

Example:
A section "Client Overview" is mandatory in the structure.

The structure is created for some module "Module A" and some module "Module B".
You'd now prefix the pages, resulting in page names "ModA_client_overview" and "ModB_client_overview". That works okay, no problem, you can simple create aliases "Client Overview" for the pages.

The TOC then prints "1.1 Client Overview". That's correct.

But why does "1.1 ModA_client_overview" appear in the printout of the page instead?!

~~#F00:__EDIT: Could not Reproduce in Show! I try to fix with an upgrade. Reducing the importance of this bug report for now.__~~

__Setup:__

* Wiki Structure: on
* Namespaces: on
** seperator: __~__
** tested also with: __:__
* Hide namespace indicator in structure path: ticked (on)
* Hide namespace indicator in page title: ticked (on)
* Force all non-namespace page links to the same namespace: both settings (on/off)

* Create a wiki page with a namespace name example:
+ __example~startstructure__
* Make a Structure from it
* Create a new page __mywikipage__ into the structure
+ page gets correctly named __example~mywikipage__

__Problem:__

When in default settings the ''__Wiki URL scheme__'' is ''__URL encode (Tiki classic)__'' in /tiki-admin.php?page=wiki.
Then the Namespace rewrite does not work and the links / urls are __example+startstructure__ instead of __example~startstructure__, why Tiki does not find the page and either gives an error message or a create page notice or a redirect to the HomePage, depending on further configurations.

__Workaround:__

When the ''__Wiki URL scheme__'' is set to ''__Replace Spaces with dashes__'' in /tiki-admin.php?page=wiki, the links / urls are still wrongly rewritten , but with dash instead of plus: __example-startstructure__ and they do correctly redirect to __example~startstructure__ .

__Additional remarks:__

I think, that the rewrite of the structures feature (wiki structure breadcrumb menu AND plugin toc) from the seperator to the dash (or otherwise the plus) is still wrong.
When I create a page __example-mywikipage__, then I can access the original page with following URLs / Links:
* __example~mywikipage?structure=example~startstructure__
* __example~mywikipage__
* __example-mywikipage?structure=example~startstructure__
* __example-mywikipage-2__

Where __example-mywikipage-2__ is somehow defined as alternative URL from Tiki (18.x) without creating that page at all.
Only __example-mywikipage__ directs to the new page!
__example-mywikipage?structure=example~startstructure__ directs to the old page!

The wiki structure feature uses __example-mywikipage?structure=example~startstructure__ as URL for __example~mywikipage__ respectively instead of __example~mywikipage?structure=example~startstructure__

I'll try to reproduce with a show instance.

Users should be able to edit existing structures without being able to create new ones or destroy existing ones.

In 1.10, the page position is shown on the structure nav for page. It works perfectly for new pages, because of the fix applied in http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=889

However, structure pages created in 1.9 may have pos in db that remains non-contiguous. It will be better to have a way to clean this up.

This tracker has no category for bugs related to the structures option of tikiwiki.

If you use the "add page" on the structure navbar (on a page that's in a structure), pick the language if necessary, then save the new page, two contradictory feedback messages appear, one saying ~~#900:"TikiLib::create_page: Cannot create page "Your New Page Name", it already exists.)"~~ the other saying ~~#090:"Page ''Your New Page Name'' saved (version 1)."~~

The page seems to be save ok though.

{img fileId="1352"}
(I have a screen shot but can't insert it into here from the toolbar - another bug (:frown:) - manually added)

demonstrating, will update after demonstration

invalide - duplicate, closing

In 1.9.2, the ability to create PDF files from structures is fixed (which is great). All files in the structure are now automatically added to the include list when the PDF icon is clicked while in an active structure.

However, the resulting file is badly named. For example, in a structure consisting of:

test structure [view |edit]

* 1 numbers [x] [view |edit]
o 1.1 one [x] [view |edit]
o 1.2 two [x] [view |edit]
* 2 colors [x] [view |edit]
o 2.1 blue [x] [view |edit]
o 2.2 green [x] [view |edit]

(http://gaeacoop.org/tiki/tiki-index.php?page_ref_id=1)

the resulting PDF file is named "green" rather than "test_structure.pdf" or "test structure.pdf". Not only is this generally confusing (naming the pdf file for the last page in the structure is pretty counter-intuitive), but the lack of the PDF extension prevents the browser from automatically opening the file. I was able to force the file to open with Acrobat Reader 5.0 for Macintosh on OSX 1.3, but only after setting the file filter to "all files." Many less experienced users would have stalled before this.

The PDF generation should default to the name of the structure plus the ".pdf" extension, and probably should also allow this file name to be manually changed before the PDF is generated.

Dear all,
I have a problem that at least started for version 2.0 RC4 and 2.0 final. In fact those are 3 problems, but I believe linked to the same issues

* I created a group "editors" which has more permissions than registrer.
* I gave the requested permission to the group, which "works well"


but those features does not work

List pages -> return no page
multiple print -> shows no strucuture and no page
Structure -> does not show strucuture.

For all of them the feature works if logged as admin.

I see no missing permission that sounds like related.

Any idea ?

Many thanks in advance!

See also http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=29889

Permission from category are not applied for tiki_p_edit (Can edit/create pages) even if group "Default category assigned to uncategorized object edited by a user with this default group" is set.
Unless GLOBAL permission for tiki_p_edit is set (which is wrong as user of this group will be now able to create and edit any page anywhere without being locked in their category:structure).

Real life case:
I have a tiki with several section (shop, store, marketing).
I create a category for each section.
For each section i also create group of user so each each group can edit is own section only.
I set 3 structures so user can also create page in his structure/category/section.

In group preference, i set each group to have "Default category assigned to uncategorized object edited by a user with this default group" with the relevant category (group_shop to category_shop, etc).

As things should work.
If a member of group_shop create a (child) page from a page in structure_shop having tiki_p_edit checked for category_shop, tiki should understand that the new page should inherit from the same category permission (category_shop) and create/edit the page.

But this is not happening. Tiki see the new page to be create has "non-categorised" yet therefor doesn't allow the creation for a usergroup with tiki_p_edit uncheck in global permissions.

Summary: When creating a new page, tiki should check user group category permission and apply them prior the page exist (applying inheritance on a create state page - not saved yet).

I have a set of translations:

page_id=14 - EN - is an element of a structure "A"
page_id=15 - DE - is an element of a structure "B"
page_id=16 - FR - is not an element of any structure

wiki option "Open page as structure:" is enabled...



When I try to use reference like this:
"tiki-index.php?page_id=14&bl"

the reference works as it would be following:
"tiki-index.php?page_id=14". (it does not open pages in languages DE & FR)

When I try to use reference like this:
"tiki-index.php?page_id=16&bl"
Everything works excellent!!!




the same thing with wiki-syntax references.

When pluginSharethis is used on a page, the following maps are blank

1) map displayed using pluginMap
2) map displayed using showMap option with pluginTrackerlist or pluginTrackerfilter
3) location fields displayed with pluginTrackerlist or pluginTrackerfilter

This has been demonstrated on a show.tiki instance

On Tiki23 I created a structure and added child page.
After a few page they start to behave awkward in there placement and relation.

There is no way to fix that. All the pages look on the same level on the admin structure interface while on the display side and if I check dump tree the structure is not the same;

{img fileId="1595" thumb="box"}


This is the export tree:

{CODE()}
Home Page Content
HomePage_banner_en
HomePage_banner_fr
HomePage_banner_he
HomePage_classes_en
HomePage_classes_fr
HomePage_classes_he
HomePage_values_en
HomePage_values_fr
HomePage_values_he
{CODE}

This is the display page
{img fileId="1596" thumb="box"}

{syntax type="tiki" editor="plain"}
If one has a structure (s1) that is restricted (in terms of extening) to ordinary users and a second structure (s2) that can be extended by everyone, everything works as expected. if one links s2 into s1 by adding the page to s1 ordinary users are unable to add pages to s2 using the navigationbar when navigating from s1 to s2 although they can if they use the structure admin panel tiki-index.php page= s2&structure=s2&page_ref_id=2

i've been recognizing this in tiki 4.1 in 4.0 this was not a problem at all (as far as i remember)

A new profile handler for wiki structures would be very handy to promote the use of structures in many uses cases (learning environments, project management, TEAMS, workspaces in general, ...)

http://profiles.tiki.org/Structured+Master+Documents

I created a profile to demostrate the use of wiki structures to new wiki admins, but it's missing the change to create the structure directly from the profile, which would be needed to enhance other more advanced profiles (Learning Center, etc)

Quick sensation in a production site of mine:

A new page in a wiki structure doesn't inherit categ perms from structure parent but only object perms (unexpected for intranet type of sections of wiki structures)

It does inherit permissions from the parent when local permissions are applied to the parent wiki page. However, in my opinion, category permissions (when there are no object permissions but category permissions) should be either applied by default to the new child page from the parent in the structure, or at least offer/warn the user about it with a checkbox for the user to select to copy categ. permissions also.

To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

And see the same page as user:
u: user1
p: user1
which has been granted local permission to view and edit that page, and global permission to edit structures. If you attempt to go to edit the structure,
http://xavi-9794-5464.show.tikiwiki.org/tiki-edit_structure.php?page=D1+Cover&page_ref_id=1

you get:
{QUOTE()}
Error: You do not have permission to use this feature: tiki_p_view
{QUOTE}

Potential Workaround:
Comment out the check for the permission to display any part of the edit strcutures interface. Line 22 from tiki-edit_structure.php should become:
{CODE()}
//$access->check_permission('tiki_p_view');
{CODE}

And line 123 from templates/tiki-edit_structure.tpl should change from:
{CODE()}
{if $editable == 'y'}
{CODE}
to
{CODE()}
{if $editable == 'y' && $tiki_p_edit == 'y'}
{CODE}

Should that be enough?

I couldn't test properly due to the interference of this other bug which prevents assigning object permissions:
https://dev.tiki.org/item5916

Some documents will have too much content to be fetching from the server multiples times, so I have documents spread across a few pages. It would be nice it you could link the pages so their section numbering is contigious across all the pages as listed below:
Page 1
1.1 Section
1.2 Section
Page 2
2.1 Section
2.1 Section
Page 3
3.1 Section
3.2 Section

Hi Devs, I need one show.t.o instance to show all (or most) of the bugs, which I find for Tiki pre-13.

I have a few smaller websites in production with pre-13 trunk to have a productive testing environment.

The bugs will be reported individually and refer mainly to this show instance instead of individual instances, where it makes sense (at least in my mind).

In case of questions or comments to this tracker item / show instances / bugs, you may write to torsten@tiki.org

Should the site map be generated from the wiki structure? from the menu?


https://www.google.com/webmasters/tools/docs/en/protocol.html#sitemapOverview
http://www.sitemaps.org/

At https://doc.tiki.org/PluginToc#Only_second_level_and_sorted_from_A_to_Z it show:

__D__ocumentation Lifecycle
__F__eature Page Template
__d__elete
__e__rrors
help
in progress
merge
...

It should be ordered from A to Z
(OR some importance is given to CAPS vs notCAPS ?)

~~#F00:__EDIT__~~ : I created an instance to reproduce and I couldn’t so it may be something with Tiki.org
http://bsfez-11581-6285.show.tikiwiki.org

Hi

When doing ~np~{toc sortalpha=alpha}~/np~, the sorting does appear to be not Unicode-aware. The order for pages with German umlauts in their names isn't correct. (They get placed at the end.)

Bye

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