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

{syntax type="tiki" editor="plain"}
in older versions eg. 2.4, it was possible to use wiki page links with ampersands ( &) and also different color in the link text

for instance : "Look & feel" gave the link like <a href=./Look_and_feel> look & feel </a> does

or {CODE()}((Look_and_feel|~~#00F:Look and feel~~)){CODE} gave the link in blue color

Both works with external link syntax {CODE()}[./Look_and_feel|~~#00F:Look and feel~~]{CODE}

most probably it's the same error as describe in bug #3585


if it's helpful : I'm willed to give a bonus to the person who will fix the bug

I tested the wikiplugin author on a fresh Tiki26: https://doc.tiki.org/PluginAuthor

When hovering the text inserted I can see a popup (not very nice) and the popup is unstable.
There are a few similar option in Tiki and using bootstrap.

Using this wikiplugin leaves the impression it has not been improved in time as it should have.

{FADE(label="Previous test on Tiki25")}I tested the wikiplugin author on a fresh Tiki25: https://doc.tiki.org/PluginAuthor

As it is visible on the doc page too, the plugin should display a popup and it is not working.

About the fields, Make Visible is a bit unclear and not documented.
What would be the point to add a plugin and hide it... May be it will be clearer when the plugin work again.{FADE}

It is not possible to add a plugin from the Wiki page help tool. (tested on ff and chrome)

{mediaplayer src="display2067"}

Open Wiki Page, Click on the 'print' button to open the 'print view'.
Top of page is a Title link to the home page of the tikiwiki,
Below that is 'Home'. This should be the name of the wiki page, and/or the description of the page.

In 1.9.8.3...

1. Create a wiki page, including a Description.
2. Change the wiki page and the description.
3. Rollback to the prior version. Although the wiki page content rolls back correctly, the description field did not.

wiki shows no preview in translate edit mode while in normal wiki page edit it's working fine

version: 3.0beta4 SVN
theme: darkroom
browser: FF3

steps to reproduce:
# enable multilingual features
# select translate from dropdown where "English" is
# set the language and pagename for new page serving as translation
# in the editing mode click preview

Wiki simple rating (and not simple rating) is not working.

I want to set a simple rating system for the wiki page.
But as the doc is unclear, I followed step by step : http://doc.tiki.org/Rating and setup an instance.

I’m not sure if I have to use Poll + simple rating to have it.
After setting the first part (poll rating at the top of the wiki page), I tried to vote and get a CSRF error
{img fileId="1428" thumb="box"}

I get on and enabled wiki simple ratings enabled (Preference name: wiki_simple_ratings)
The (ugly) icons are nicely displayed at the bottom of the page.
When I rated as admin Tiki is doing something and back on the page I can’t see any change.

I retried as anonymous on firefox (permission have been set accordingly) and get a Javascript error on the page loading:
{img fileId="1429" thumb="box"}

I refreshed and rated. Same as above page is refreshed no sign of changes.

Back to Admin=>rating, in the user interface I enabled Detailed rating results and Include percentages in the detailed rating results to find a way to see something. No result. (admin or anon)

I rebuild index and refresh caches. Got another error (related to the server setup):

Re rated and revoted with the same results.
I found a "hidden" (experimental presumly) Rating option at the end of Admin=>Wiki=>Page Listings and activated it. No change.

In doubt I use the Preference Search Results for rating to recheck if they were more options. But no. Retried as admin and anon on both systems, same no go. (I don’t have the CSRF error with Firefox as anon).

I think that having a "Was is useful ?", "What is your opinion about this page ?", etc is a must for a Wiki web application. I tried this, I also tried multilikes that doesn’t work neither (for anonymous) and reported. I understand that the alternative could be a tracker form in a module at the bottom of the pages, but on submission, the counters (like, unlike) won’t update nicely and the page will be refreshed. That is not what is expected for such thing.

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

In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.

Wiki syntax parsing for tables is broken

Following two things are supposed to work. These are just copied from the offered quicktags.

||r1c1|r1c2
r2c1|r2c2||

||r1c1|r1c2||r2c1|r2c2||

First one works, but the second ones ends the table at the || and then just prints the text " r2c1|r2c2|| ".

Ok, just saw that Trakcer-Items are Wiki-parsed, too. Good thing! As you can see the effect live! :)

Hmm, everything gets saved, when editing a Tracker except for the feature.... I really have to start working with them.... and search for bugs... sorry for three mails about this, if you are subscribed!

{syntax type="tiki" editor="plain"}
When editing a Wiki page in WYSIWYG mode, pressing the button to insert an external link results in a pop-up appearing to enter the link information.

Entering data into the "Text to display" and "To what URL should this link go?" boxes does not result in the "Insert Link" button becoming active (the button is inactive when the pop-up appears), therefore the link cannot be inserted.

Concerncs the current SVN version of tiki.
If you create a link to another wiki page via ((OtherPage)) it will be linked to tiki-editpage.php?page=OtherPage, whereas it should be tiki-index.php?page=OtherPage

You can see the effect of Wiki-syntax getting parsed differently with the ~np~ ~np~ ~/np~ tag and the~np~ {CODE()} ~/np~ -plugin.

~pp~
~np~text here~/np~ - strips all linebreaks out of "text here" - ~pp~ works

{CODE(caption=>test)}
text here and some enclosed in <these brackets> here
{CODE}

The text between the <>-brackets doesn't get shown at all.
~/pp~

Also, (just in case it's related): tiki-view_blog.php complains to admin user about a division by zero by split plugin (tiki 1.9.2):
* {CODE()}
Warning: Division by zero in /var/lib/gforge/chroot/home/groups/gclub/htdocs/lib/wiki-plugins/wikiplugin_split.php on line 74
{CODE}
* This warning message was not present with 1.9.1. (Xavi - xavidp)

The blogs were htmlspecialchar()ed, too - it looks like fixed in CVS now!

From Tiki26 the slideshow feature default setting have been changed and this breaks previous slideshows using H1 to H3 to create slides.

On a Wiki page by default you have a Wiki top line with location set to top that display on the Wiki page a small menu with "Edit icons" (off by default).
''Most of them look like a little puzzle icon and allow to edit a plugin''

On a Tiki24 after checking it "Edit icons" is off, I set Wiki top line location to "Neither".
No group can see the menu and the "Edit icons" are not displayed.

On a Tiki25 after checking it "Edit icons" is off, I set Wiki top line location to "Neither".
Anonymous and Registered won't see the "Edit icons" however admin is __forced__ to see them.
It is very unfortunate as it often break design of pages in Tiki.

This is a change of behavior.
The only way then to hide them is to go to /tiki-admin.php?page=textarea#contentadmin_textarea-2 and under "Edit plugin icons" disable "Allow plugin-specific edits".

Will be hard for a non power user to know what to do to "counter" this change in Tiki.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

On a wiki page, reviewing each & every change could get tricky because someone could do edit #2 before edit #1 is approved, and then, you end up having branches, which need to be merged.

I have an idea on how it could work but still needs coding: Basically, when a non-editor (someone with lesser permissions) edits the page, the previous version continues to be shown to the public (in any wiki, any previous version is still available to view). Anybody trying to edit the page would be sent to this new "branch" (think of it as a staging area). And the next time an editor (someone with higher permissions) saves the page, it becomes public again. This would avoid the risk of having multiple branches, needing merging. However, the UI would have to clearly show editor #2 that he is not editing the page he just saw.

I could see this being an interesting feature in certain scenarios. For example, using Tiki to generate a corporate website.

When you edit a wiki page, you can indicate what you did. Good.

But if you leave it empty, visitors have no indication of what you did. Maybe we could add some of the ideas of wiki-translation.com (Quantify change size) to have an automatically generated message.

Some examples:
*minor change
*10 words changed
*15% changed

{syntax type="tiki" editor="plain"}
In case we have "Wiki page edit buttons location" set (Preference name: wiki_actions_bar) to "Both" (shows buttons on top and bottom) the bottom "Cancel edit" is not working.

When you try to create a ~np~ {CODE()} {CODE}~/np~ block in the
Wiki which contains $0 somewhere (which is, e.g., quite
common in Unix init scripts), the page won't be
displayed (white screen).

this is easily reproducable by inserting the following
into a Wiki page:
~np~{CODE()}$0 {CODE}~/np~

The bug was not present in previous versions (I
recently upgraded from 1.8.5 to 1.9.0).


And as you can see, it works correctly here in the Tracker:
{CODE()}$0 {CODE}

Wiki pages can have pseudo-buttons, some of which allow to perform actions. For example, a link may allow editing the page. These icons are displayed at the top of the central column, aligned right. In Tiki 12, this region has a height of 19 pixels.

Starting in Tiki 13, this region no longer contains actual images by default, but rather glyphs, which increases the basic height to 20 or 21 pixels. Most importantly, a vertical padding of 12 to 16 pixels (6 px top and 6 px down for Fivealive, 8+8 in Journal) defined for .btn is added. In the end, the region's height is now between 34 and 40 pixels, which makes it more clear than before version 13 that this region uses the full column width, pushing all Wiki content by 34 to 40 pixels down.

This is of course highly inefficient, and IMO ugly. Since multilingual wikis have a language choice widget, this region can show even for unprivileged visitors.

This persists in trunk as of r60089.

In 1.10, there is a "minor" button when you save a wiki page.

When using the wiki for translation, checking minor tells the system that the corresponding translation are __still valid__.

I believe __minor__ also prevents sending notification emails to those watching the page. (why bug them for a corrected typo?)

When a wiki page is renamed, all links in Wiki pages are fixed. Excellent!

However, menu items are not updated. This would be a nice to have. Same thing for wikilinks in forum posts, trackers, etc

I guess it could get tricky because some use links like tiki-index.php?page=blabla, but some just but blabla and use the .htaccess

Please see ((WikiBlame)) and ((WikiTrust))

A user typo whilst creating a structure can create a new page which then isn't (easily) accessed.

Whilst creating a new structure and adding pages with aliases using the "Tree" feature, if hyphen space greater-than rather than simply hyphen greater-than is entered the new page is created without an alias but with a longer that expected page name.

For example
Test_01 -> Page1 creates new page called Test_01 and alias Page1 as expected.
But
Test_02 - > Page2 creates a new page called "Test_02 - > Page2" with no alias.

Accessing this page and removing it is challenging :-))

--(Can't currently create a show instance for you, no database connection available, but I can reproduce this on the demo 18x/system)--

Using the Structures "next page" button from page Test_01 causes a wiki error "Page not found" for "Test_02 - Page2" (sic without greater-than sign).

Likewise wikilink from toc generated on pages within the structure also results in "Page not found".

Adding the plugin listpages with options find="Test_0" to the root of the structure shows the pages as expected.

Note the wikilink URLs generated by toc and listpages are different, but wikilink from listpages also results in the same "Page not found error" for the same page "Test_02----Page2"