Category: Wiki (page view, edit, history, rename, etc)

The 'Show page title:' check box in the Wiki Admin page seems to do nothing.

'Use page description:' toggles both the description and the page title together. Its both or nothing.

Show page title on per page edit, if set to off, turns off page title as well as page category.
One setting effecting two features! It should be normal behaviour to see page category without page title.

Full page mode would be quite important

** Need to evaluate usefulness with Alain Désilets
** LP says it's doable (from back-end perspective)

Coordinate with other work on:
http://wiki-translation.com/

Seen on IRC:
{img src=images/code.png}%%% {CODE(wrap=>1)}
(10:33:47 AM) ***dthacker also wonders if there is a login-timestamp wiki syntax such as mediawiki's ~~~~ that would auto sign with user id and date/time.
{CODE}


Wiki pages are great to produce Neutral Point of View (NPOV) content. If we need to know who added what, we check the edit history.

For debates, discussions, opinions, etc, people will often use Tiki blogs, Tiki forums or comments at the bottom of wiki pages. These are more natural formats and it's clear who thinks what and who said what. Comments & forum threading make it clear who is responding to who/what.

However, in some cases, it is useful to have this type of interaction in wiki pages. The [http://doc.tikiwiki.org/Editorial+Board|TikiWiki documentation Editorial board] has monthly meetings to discuss and make decisions. Members can edit, comment and vote on motions.

The way people add their comments is not standard and if we are not careful, it can get messy. This often happens in wikis.

Some wikis use a special syntax for "signature". This would be a way to associate the name of the user and maybe the date to a specific comment. It would be nice to clearly and visually associate the user to the comment. Maybe the comment & signature are in a same box?

It would be nice also for people to be able to express support to an idea in the wiki page, with a thumbs up (+1) or a thumbs down (-1). Right now, the wiki ratings feature let's us vote only once per wiki page.

These syntaxes should be quicktags to it's easy to add. Maybe some of the less important meta data (ex.: date of comment) would be only visible on mouse-over. (and thus not in printed mode). The mouse over could also contain a link to the user's personal wiki page and some data about the user (his avatar, score, etc).


Ex.:
*click my PluginComment tool (in toolbar)
*Pre-fill text that will be mouse-overed with previously selected text
**add date & signature (with link to userpage)


Everyone: please share your ideas on this and how you have seen it implemented elsewhere.

Thanks!


Related:
{wish id=2102}

This problem was introduced in BRANCH-1-9 and is tough to solve. We need a senior dev on this one.

''Needs more description...''

Here is a weird one:

I edited https://doc.tiki.org/Tiki17 a few times and I got:
504 Gateway Time-out nginx/1.12.0

That is not a big problem, but perhaps a symptom.

Then, when I check the history, I see that 4 revisions are missing (74, 75, 76, 77)
https://doc.tiki.org/tiki-pagehistory.php?page=Tiki17

When I compare, I notice some edits which are mine, and some which are not mine:
https://doc.tiki.org/tiki-pagehistory.php?page=Tiki17&newver=77&oldver=73

It's as if the revisions have been deleted, but I didn't delete them. It's as if the time out saves the data but forgets to put the previous version of the page in the history (or something like this)

I am 99% sure it's a regression, because otherwise, it would have been noticed sooner.

Someone with server access to doc.tiki.org may need to look at the logs...

As seen here: http://themes.tiki.org/tiki-pagehistory.php?page=Sample+page&source=0
This happens only when jQuery UI is set to "None".

Even though global perms allow viewing wiki pages (to Anonymous, for example), assigning an edit perm to another group for a specific wiki page overrides the view perm and Anonymous can't see it anymore unless a specific tiki_p_view perm is assigned to the page for Anonymous.

this is a feature - it is how it works . As soon as you hjave a special perms, you need to redefine all the perm for the page

{syntax type="tiki" editor="plain"}
entering the words "visual studio" in the search_box module causes the following message to be returned in the UI:


An error occured in a database query!

Context:
File tiki-searchresults.php
Url tiki-searchresults.php?highlight=visual+studio&where=pages
Query:
select `data` from `tiki_dynamic_variables` where `name`=?
Values:
0 comspec
Message:
Table 'tikidb.tiki_dynamic_variables' doesn't exist
Built query was probably:
select `data` from `tiki_dynamic_variables` where `name`='comspec'

Check
https://dev.tiki.org/How-to-release

vs

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

With version 21 the wiki pages which are part of a structure seem to be displayed as if the CSS isn't working. It looks like a very simple html page. At first I thought the bandwidth is so low so that the page is presented with the minimum information.

I have an issue where if my sub-headings exceed 9 then the auto-numbering and autoToc is screwed up.

This does not happen on first saved, rather after the next edit and save.

To replicate the issue:

1. Create new wiki page.
2. Add a H1 Heading, e.g. 'Section 1'
3. Add 10+ H2 Headings underneath the 'Section 1' Heading
4. Add another H1 heading, e.g. 'Section 2'
5. Save
6. Edit Wiki page
7. Save again

H2 Headings are OK up unitl section 1.9 and then the system seems to add an additional hard coded 1.x on to the end of the auto number.
An additional hardcoded number is added with each subsequent edit & save.

I received today page modification notification from tiki.org after it was upgraded to Tiki19.

The subject was missing in my Apple Mail application because it was badly encoded.

Raw source before (tiki18):
{CODE()}
To: bsfez@tiki.org
Subject: wiki page "Versions" changed by Marc Laporte
X-PHP-Originating-Script: 33:Sendmail.php
Date: Sat, 03 Nov 2018 20:13:27 +0100
X-Tiki: =?UTF-8?Q?yes?=
From: noreply@tiki.org
Sender: <noreply@tiki.org>{CODE}

The raw source is now (tiki19):
{CODE()}
To: bsfez@tiki.org
Subject: =?UTF-8?Q?=0Awiki=20page=20"201902=20TAG=20Meeting"=20changed=20by=20?= =?UTF-8?Q?Gary=20Cunningham-Lee?=
X-PHP-Originating-Script: 33:Sendmail.php
Date: Sun, 18 Nov 2018 12:05:19 +0100
X-Tiki: =?UTF-8?Q?yes?=
From: noreply@tiki.org
Sender: <noreply@tiki.org>
{CODE}

When you edit a Wiki page, the page gets reloaded, with an additional "success" information for the user, painted in green. This success message includes the version number and a reference to the history feature.

Unfortunately the revision no. given is not the new current version number, but the old one, before the edit was done...

Not a big deal, but could be irritating to non-tech users IMHO, because if you look at the history, which is what the success info encourages, you will not find your edit under the given revision number.

Hello,

Referring to 5.3, when the a selection of page have been made into listpages, after the access to a page there is no else way to go back to the list with is filters than re-run listpage and set again the filter, browse the list often to view and modify the following element.

This is a great lost of operating time.

i suggest, as for the structure, to implement a button which returns to the list and into at the previous position.

Programmatically this needs to :
# - send to page-edit the parameter of the listpage we just have left
# - by the button run again listpages with options :
## - filter
## - current position into the list

This problems is accurate because of the new category features.
when the access rights to a "family of pages" are not the same, the good way is not to use a structure (not designed for this indeed) which access by category is applied to all structure elements, but the category or element access by groups or both.

For my own I use structured categories to access lists of pages. This is the right use, but this list can't at this time be use to browse the selected list.

After checking out in-page navigation outside of Tiki and doing some searching for best practices, I'd like to make a few suggestions for improvement.

First of all, about the current situation of autotoc in master (to be Tiki 27), I came across these bugs, that I think are known already, plus some recommendations:
* Autotoc plugin
** Parameters don't work (bugs):
*** title (nothing displays)
*** levels (only the top level displays)
** The terminology could be improved IMO (suggestions):
*** "inline" should be "sticky-top" or "fixed-top" . I think one of these would be more descriptive; I've always been kind of confused by "inline" here.
*** "activity" should be "active" . This would be a more standard term.

• Autotoc feature itself (suggestions for improvement):
** No need for the page name to be a link as the page name/title is already elsewhere on the page. Presumably the first link of the page content is at the top of the content so the page name isn't needed for clicking in autotoc to get back to the page top.
** Instead, autotoc should have a title like "On this page" to let readers know these aren't links to other pages. (Apparently people sometimes mistake in-page navigation links for links to outside the page.) When the title parameter bug is fixed, the page editor can add "On this page" manually, of course, but maybe it should be default text unless replaced,
** The full list/outline of links should display on page load to give the reader an idea of the page content. I'm recommending this because of articles I came across saying how one main function of in-page navigation is to provide a complete outline of the page content.
** Instead, currently in Tiki 26, only the top-level links display initially, and the display of subsection links seems kind of erratic. Actually I wonder if hiding and displaying lower-level links is needed. Maybe just keep them all visible all the time. See https://getbootstrap.com/docs/5.3/components/scrollspy/
.** If the autotoc is longer than the viewport height, then either make dropdowns for lower-level links like a vertical menu, so there are visual cues (dropdown arrows) that they are there, or put the whole nav in a div with overflow-y:scroll. But actually I think the whole thing should display, and the reader can scroll the page if the toc extends down out of sight.

there should be an option to add a "title" to links in wiki. currently you can only set url and link name (<a href="url">link name</a>) but in many cases title (<a href="url" title="title">link name</a>) comes in handy.

It will be nice to allow the setting of limit of levels to show for maketoc:
{CODE()}
{maketoc maxlevel=2}
{CODE}
will cause only ! and !! headers to be shown, not !!!.

I have an issue where if I add the section heading toggle e.g. !-# or !+#, then they are lost after the next edit.

To replicate:

1. Create a new wiki page with a number of headings, toggle syntax and text. E.g. !-#Section 1, !-Section 2, etc.
2. Save and all is ok.
3. Edit page again.

When i go to source, all toggle tokens are missing from source e.g. + and - are removed from heading code. e.g. !-# is now !#

When you have edit icons enabled for wiki pages and there is PluginInclude, the icon to edit the included page is in PNG format instead of the FontAwesome icon.

{syntax type="tiki" editor="plain"}
On a long wiki page with a lot of Headings (h1, h2, h3, etc) usage the automatic table of content (admin -> Wiki page) use to help navigating on the page as headings were styled.

H1: bigger/bolder than h2 bigger/bolder than H3, etc...

Now they all look the same and it is very hard to use on long pages.

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

{syntax type="tiki" editor="plain"}
When you duplicate a Wiki Page you have 2 additional options:
* Duplicate categories
* Duplicate tags

Both never worked for me as far as I can recall.
When I duplicate a page that are categorized and have tags the new page won't have them.

It should be fixed OR even removed as no one seems to use this (never worked for me since Tiki24 or even more)

It is giving a bad image of Tiki.

{syntax type="tiki" editor="plain"}
On a wiki page, in the page_actions dropdown there is an menu-item "Edit icons".

The menu-items in the dropdown are related to the wiki page (object_id) but not the "Edit icons" that, once enable, will be set enable for all the wiki pages of the website. This is quite annoying as it is also usually breaking the design.

This "page" action/option should affect the page it is toggled only.

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"}
mod-last_modif_pages should not list the sandbox page.
Users could confuse it for real content.