Category: Wiki Structure (book & table of content)

A link to remove permissions from structure should be visible when editing permissions for a page that is in a structure.
In version 1.9.8.3, the version that I use, that link don't appears for any page.
I have detected the problem is a programming error in line 14 of file templates/tiki-pagepermissions.tpl. There is a test of variable $isStructure when the correct would be to test $inStructure that is the variable that is assigned in line 89 of file tiki-pagepermissions.php

{syntax type="tiki" editor="plain"}
When you have a table of content and a menu element, the menu should open OVER the table of content and menu link useable.

Actually it is a weird mix with broken display and the menu link are not accessible.
Happen also when you set a menu at the bottom that dropup over the table of content.

Visible at: https://doc.tiki.org/Tiki27

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

When giving a group the permission

tiki_p_admin_wiki

it is not enough to add a page to a structure. The corresponding input field on tiki-index.php just doesn't appear.

2015-03-10 EDIT: SOLVED! Thx LPH and Gezza.

WikiStructure administration:

The "Save" button is not appearing ...
... and not working

* not if made displayed via "inspect element"
* nor if hardcoded visibility (ex: tiki-edit_structure.php -> button save - > display:none for ajax=n)

Maybe a problem with AJAX in Tiki pre-13 / trunk??

in tiki-edit_structure.php following is not working:

add filtered wikipages to the structure AND SAVE

move pages in the structure to different positions AND SAVE

delete wikipages out of the structure AND SAVE

So all functionality is there, but just "saving" is not possible.

I did not make a show instance here, but please check out [http://dev.tiki.org/item5093],
where I will document and add more pre-13 related bugs to the show instance:

__[http://torsten-11143-5093.show.tikiwiki.org/tiki-index.php?page=wikistructure_example&structure=wikistructure_example&page_ref_id=1|see the structure]__

__[http://torsten-11143-5093.show.tikiwiki.org/tiki-edit_structure.php?page=wikistructure_example&page_ref_id=1|try to alter the structure]__

Server login: show/show
Tiki login: admin/12345

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.

This tracker item could not be found

Various tools are able to built a structured documentation form internet exploration.
A good example is ZOTERO.
The product can get urls, html pages content, manage a hierarchical structure, set marks etc...
The product is able to export XML files with various basic patterns :
1. Zotero RDF
2. MODS
3. RIS
4. Refer/BibIX
5. Unqualified Dublin Core RDF
6. WikiPedia Citation templates
7. BibTeX

These structured informations can be imported to a wiki structure.
he interest of Zotero RDF (but I had not the time to the Unqualified Dublin Core RDF have the advantage of containing the structure definition the link to external url and if the html page has been captured the component html page with the elementary component has images.
This model his the closest of wiki structures.

Too the Wikipedia Citation templates is close but from the url refs;

I have not found where are the text and synthesis objectives for "import" and data shared (XML files as RDF Zotero structures), and multiwiki, in 4.x and 5.x

I am interested in participating to these developments.

Best regards to everybody

Implement something like the special page [http://en.wikipedia.org/wiki/Special:Book|Wikipedia Book] to generate some revenue from community assets

The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever

I am a new Tikiwiki admin/user, and although DELIGHTED with the product, must confess to being disappointed with structures, TOCs and MAKETOCs functionality. See my posting in >Forum >Documentation for details of these issues.

Using Structures to assemble Wiki pages into a book is a very powerful way to manage sets of pages in a holistic manner.

A common usage requirement however is to be able to restrict access to some selected pages within a Structure, which works fine from an access control point of view, BUT when the toc function is used ALL the pages will be listed within the Structure no matter what Category permissions the individual user has. This means that users have visibility of some pages that they cannot access - which may be very undesirable!! and conflicts with the WYSIWYCA principle.

It would be extremely useful to be able to filter the resultant list from the toc function, to just the pages/links that the individual user's categorisation permission allow them to see. In this way the categorised pages would not be visible at all in the same way as they are treated in many other functions e.g. List pages etc.

Still does this in 3.0b4

FIXED

https://dev.tiki.org/How-to-release?structure=Developer+Documentation
vs
https://dev.tiki.org/How-to-release


See image

{syntax type="tiki" editor="plain"}
I will report 2 bugs as they appear to be related:

1. If I create a structure in english, create a wiki-top-of-structure, then i translate it in spanish... when spanish users browse the wiki they will see the translated page in spanish but with English title.
see it on http://mi.solcentral.org/tiki-index.php?page=Sobre+Sol+Central

2. Also Tiki will not let the user to change from Spanish to English (if accessing with a Spanish configured browser), since the drop down list of languages appears disabled. These happends with many other wikis created in structures.

General Settings:

Tiki 6.0 fresh install.


Settings in Multilingual:

Detect browser language ON
Show pages in user's preferred language ON
Requires User Preferences Screen (OK)
Users can change site language ON
Display available translations ON
Multilingual structures ON
Requires Structures (OK)
Requires Multilingual (OK)



Settings in Structures:

Open page as structure OFF

{syntax type="tiki" editor="plain"}
Hotword processing needs to be turned off for the text expansion of the built-in macro __toc__: {CODE()}{toc}{CODE}

If a page name in a structure has spaces, and a defined __hotword__ appears as a name in the page, then the __toc__ expansion is corrupted by the __hotword__ processing. For example, if the page name in a structure is __xxx yyy zzz ddd__ and __zzz__ is a defined __hotword__, then the resulting link out of the __toc__ expansion is the equivalent of: {CODE()}((xxx yyy zzz ddd|xxx yyy)) ((zzz)) ddd{CODE}
Note how the trailing portion of the page name is not linked at all now.

This may apply to expanding the built-in macro __maketoc__, especially when aliases are shown, as well.

Verified on the opensourcecms.org installation as requested.

{syntax type="tiki" editor="plain"}
Verified using Tiki 6.1:

I attempted to create a new page within a structure, by using the structure navigation bar (add page). Tiki creates the page, but does not place it within the structure. Using the "add as child" option makes no difference.

This worked correctly in 5.3

{syntax type="tiki" editor="plain"}
When creating a new structure, Tiki will automaticlly create the strucutre's wiki pages. However, Tiki does not assign a language to the page. Tiki defaults to __Unknown__. This means that the user must still manually open/edit __every__ created page to set the language properly.

It would be nice if Tiki used the ''__site's default language__'' instead of Unknown

{syntax type="tiki" editor="plain"}
I defined a category Helpdesk and assigned it to a structure Helpdesk FAQ.
Also i defined a group Helpdeskadmin, which useres should be able to add new pages to the structure.
Now if a helpdeskadmin try to Add a page to the structure (with the button on the top of the wikipage with the toc), he must have global permission tiki_p_edit, not only for that categorie.



My analysis:

In tiki-editpage.php there are to permission tests:

First:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

Second:

//Is new page to be inserted into structure?
if (isset($_REQUEST["current_page_id"])) {
[...]
$structure_info = $structlib->s_get_structure_info($_REQUEST['current_page_id']);
if ( ($tiki_p_edit != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit')) || (($tiki_p_edit_structures != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit_structures')) ) ) {
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

The first one is the problem becaus it asks only for globel permission, i think.

It appears that from v18.10 to v18.11 the path to "jquery.ui.nestedSortable.js" changed from:
vendor_bundled/vendor/jquery/plugins/nestedsortable/jquery.ui.nestedSortable.js
to:
vendor_bundled/vendor/jquery-plugins/nestedsortable/jquery.ui.nestedSortable.js
(Note the sub-folder vs. the dash "jquery-plugins")

But the code is still looking for it in the old location.

In the Admin Structures interface, this results as a 404 error on the js console and breaks the feature. It's impossible to drag any items in the Structure or page list in the Admin Structures interface.

When on a wiki page on my tiki, I have the options available to watch the specific page or to "Monitor the sub-structure". When clicking on the latter, I am redirected to a permission denied page and the watch for the sub-structure is not set.

Even admin is being denied the permission to set a sub-structure watch on a wiki page.

Setting a watch on a sub-structure inside the structure-admin menu works fine for any permitted, though.

{syntax type="tiki" editor="plain"}
When you move a part of a structure to another or new structure, the structure_id will not be updated.

!!Problems

__Pretty Much Resolved by the wiki ALIAS function__ - so closed.

Redirect plugin
*is not included by default in TikiWiki because it could be used for bad things
*creates redundancy (in search results, page listings, etc) - maybe redirected pages should not appear in list?

Renamed pages
*do not automatically redirect - creates broken links.


!!Proposed solution:

!!!renamed pages
*When a page is renamed the user must choose "hard or soft redirect" perhaps better known as "redirect or refer from old page?"
**hard redirect places redirect plugin on pagename-old to pagename-new.
**soft redirect puts something at top of page like
^This page has been renamed: pagename^


!!!Add synonyms/aliases to a page

suggestion (mlp): adding aliases to a page should automatically create pages with hard or soft redirects to pagename. Note that the adding of alias pages must not destroy data if page already exists.

Ex.:
dev.tikiwiki.org/Tracker
dev.tikiwiki.org/Trackers
dev.tikiwiki.org/Bug tracker

would be aliases. It would avoid the pollution we have here: http://dev.tikiwiki.org/tiki-orphan_pages.php


doc.tikiwiki.org/Install
doc.tikiwiki.org/Installation
doc.tikiwiki.org/Installer

Each wiki page should be able to put one or many aliases. These aliases would work in search. All the aliases should have an important weight in the internal search engine.

We could use this instead of renaming pages. Also, when we do rename a page, we could have an option to have the old page name to be an alias of the new one. Thus, better for external search engines.

Theses aliases could even be used as meta tag for this page.

Putting aliases to non wiki pages (ex.: tiki-forums.php) would make ((doc:structures)) more useful. Now, using structures for site navigation only makes sense if you only have wiki pages. And who ''only'' wants to have wiki pages with all the great features offered by TikiWiki? :-)

It also help to use cleaner page links in sentences. If my Wiki page is called Install, I have to do the following now:

{img src=images/code.png}%%% {CODE()}
For more information about ((Install|Installation))
{CODE}

With aliases, I could do:
{img src=images/code.png}%%% {CODE()}
For more information about ((Installation))
{CODE}

Page aliases - and hard redirects - should permit to set status "Moved Permanently" for robots to send traffic to main page.

What would we do with page renames? (which correct links in wiki pages). Needs some thought. We don't want some unwanted changing of text in existing wiki pages.


Do we need?
Redirect to internal or external http is ok because a special permission is needed to use. -> tiki_p_wiki_alias . In security admin, warm that giving tiki_p_wiki_alias to untrusted people is a security risk.


Related:
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

Creating a new page (e.g. -+Foo+- through the form in the wiki structure top bar produces a missleading error message:
{CODE()}
Error. TikiLib::create_page: Cannot create page "Foo", it already exists.)
{CODE}

In addition, another remarksbox is shown below saying:
{CODE()}
Success
Page Foo saved (version 1).
{CODE}

However, the page is created indeed, and within the structure also.

You can reproduce it here:
http://xavi-9794-7136.show2.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

Create a page called foobar (or any other name for a new page inside the structure) and you will see the issue reproduced.
{img fileId="1314" thumb="box"}

If a wiki page is included in a structure, Tiki lists the page when viewing the structure (or when listing TOC) -- even if the user does not have permission (tiki_p_view) to actually view the page. This presents an invalid structure to the use -- they are seeing pages that they do not have permission to view. Tiki should only show pages (in a structure) that you can actually view.

Alternative impelentaion (proposed by luciash):
To have an option "restricted pages in this structure will be ommited from the list" or "will be shown but marked as restricted"

Confirmed in 1.9.8 and 1.10.1

As explained and demonstrated on the show instance (trunk): http://bsfez-11581-8389.show2.tiki.org/tiki-index.php?page=HomePage

Even if permissions are set correctly (tiki_p_edit) (tiki_p_edit_structures) not all groups will see the structure "Add page" field on the top of the page.

For example, registered (group that exist by default in Tiki) will see the field. A group I create, and with the correct permissions won't see the same "Add page" field.

---

I tried to create a Tiki24 show instance. It fails with errors in the log.
{FADE(label="log" icon="y")}
###########################################################################################

== TIM Thu Apr 27 07:04:19 UTC 2023 : TIM command: CREATE
###########################################################################################


== TIM Thu Apr 27 07:04:19 UTC 2023 : Starting instance creation

== TIM Thu Apr 27 07:04:19 UTC 2023 : Unpacking tarball
tar (child): /usr/local/src/tiki/24.x.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

== TIM Thu Apr 27 07:04:19 UTC 2023 : Chown-ing everything to TIM user and group

== TIM Thu Apr 27 07:04:19 UTC 2023 : Running setup.sh
sh: 0: Can't open setup.sh

== TIM Thu Apr 27 07:04:19 UTC 2023 : Creating database

== TIM Thu Apr 27 07:04:20 UTC 2023 : Setting GRANTs on database

== TIM Thu Apr 27 07:04:31 UTC 2023 : Creating local.php
/usr/local/sbin//tim-create: line 155: /var/www/bsfez-11581-8389/db/local.php: No such file or directory
chown: cannot access '/var/www/bsfez-11581-8389/db/local.php': No such file or directory

== TIM Thu Apr 27 07:04:31 UTC 2023 : Old Tiki - populating database via tiki.sql
/usr/local/sbin//tim-create: line 184: /var/www/bsfez-11581-8389/db/tiki.sql: No such file or directory
touch: cannot touch 'db/lock': No such file or directory

== TIM Thu Apr 27 07:04:31 UTC 2023 : Starting extra steps special to show instances. Anything done below is not part of a standard Tiki installation.
svn: E155007: '/var/www/bsfez-11581-8389' is not a working copy
Creating file http://bsfez-11581-8389.show.tikiwiki.org/info.txt with extra info for developers
CREATION END - results in http://bsfez-11581-8389.show.tikiwiki.org/install_log.txt (available after a delay)
{FADE}

On a Tiki24 freshly updated it is possible to create pages with an illegal name as set on Tiki:

^
Invalid page name
The page name specified contains unallowed characters. It will not be possible to save the page until those are removed: /?#[]@$&+;=<>
^

Using Structure to create a page bypass the check and once created the page exist but is not viewable or editable and structure cannot be modified (impossible to move the elements in the structure).

Reproduced in the show instance, check the last page name of this structure.

http://bsfez-11581-8198.show2.tiki.org/tiki-edit_structure.php?page_ref_id=159