Category: Feature request

This is for internal groups within a wiki, a bit like ((workspace))s.

Some pages have special perms. We'd need a way that new pages created from these inherit permissions.

It could be possible to do via category permissions but..

{syntax type="tiki" editor="plain"}
When printing a wiki page (or viewing the printer-pretty version) that has links, it would be nice if links actually showed the full URL.

For example

((http://yourtiki/foo|Foo)) would display as Foo (http://yourtiki/foo)

((http://yourtiki/foo|Bar)) would display as Bar (http://yourtiki/foo)

[http://foo.com|Bar] would display as Bar (http://foo.com)

When the system (in this case was a Linux box) runs out of disk space, a Tiki user cannot login. Basically, the user is sent back to the home page. In other words, it looks like the user has authenticated, but is not logged in. So it looks like a PHP session issue. It could well be.

If the user enters a wrong password, a wrong password message is seen.

It would be nice if Tiki could detect that the disk space is low and alert admin users, especially during install. Low priority of course, but still nice to have.

MoinMoin example:
{THUMB(id=29, url="tiki-browse_image.php?imageId=29")}{THUMB}

When you use re captcha the Privacy Terms panel overlap (right) element of the page.
You can always scroll to see what is under unless you are at the bottom of the page where the footer and bottom_modules elements are under it.

When recaptcha is enable we should add a margin-bottom so it is always possible to see the footer content.

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

See yourself by creating a structure and making a page with {toc} in the source code. That creates a Table of Contents of the structure. This table of contents isn't considered by the Wiki 3D browser. So you are forced to enter links manually to be able to browse the structure with the Java Applet.

At https://doc.tiki.org/Wiki-Argument-Variables we have a list of the available wiki Argument Variables.

We have a permanent variable for pageid and itemId (wiki pages and trackers) and we can use it to dynamically populate plugins for exemple (like the plugin list)

However we have other object types like __files__ for which we don't have a permanent variable.
While I wonder if it is not hidden somewhere, it will be nice to have a fielId variable.

By extension wouldn't be possible to have simply objectId ?

With MediaWiki, before you save, you can review changes. It shows what you __will__ change (if you click save), in wiki diff format.

This is very nice.

Sometimes, we have done several edits, and we are not sure exactly what we changed (supposing we are multitasking or interrupted). It is nice to be able to review this and fill out the edit description accordingly

Useful for translation as well:
http://wiki-translation.com/tiki-view_tracker_item.php?itemId=51


Related:
*{wish id=2102}
*{wish id=1843}
*{wish id=1220}

In addition to smilies and text formatting like bold, add syntaxes for commonly uses markers in text.

Please see some nice examples here:
http://wikifeatures.wiki.taoriver.net/TextFormattingRules

Which are inspired by :
[http://moinmo.in/HelpOnSmileys|MoinMoin]

I like:
/!\ warning
(./) check
{OK} thumbs up
{i} information
{1} {2} {3} for nice numbering

We currently use images at doc.tikiwiki.org and it's cumbersome.


From #wiki (freenode)

(11:20:53) TheSheep: marclaporte: btw, if you need some icons, there are some I drew at http://sheep.art.pl/Icons
(11:21:10) TheSheep: marclaporte: especially the hand icons can be... uhm... handy
(12:16:35) marclaporte: hehe
(12:17:52) marclaporte: for icons: is license compatible with LGPL?
(12:18:15) marclaporte: I wish we had a license compatibility grid for CC vs GNU
(12:19:58) TheSheep: marclaporte: I can relicense it for you
(12:20:17) TheSheep: marclaporte: although using gpl for something that's not software is weird for me
(12:33:22) marclaporte: yes, but icons have to in the app, no?
(12:42:45) TheSheep: marclaporte: but icons are also distributed when somebody merely uses the web app
(12:43:00) TheSheep: marclaporte: would you want to force them to provide the source code?
(12:44:49) marclaporte: I just don't want any trouble
(12:45:02) marclaporte: and to respect author's wishes
(12:45:51) TheSheep: marclaporte: I can promise I won't give you any trouble, just tell me what you need to use them :)
(12:46:01) marclaporte: hehe
(12:46:13) TheSheep: marclaporte: it will also help me to release my future works in a way that is friendly for developers
(12:46:22) ***marclaporte is adding on todo list

{syntax type="tiki" editor="plain"}
When attaching a document to a wiki-page, for example an MS-Word file, this attachment seems not to be indexed. There's also no option to indicate which handlers for different mime-types to use. This option is available when using file-galery, but not for page attachments.
As a result the file will never show up in any search results.
Furthermore: it would be convenient to be able to indicate that the indexing of attachments should be logged. This would ease system debugging in the case mentioned.

{syntax type="tiki" editor="plain"}
The initial report is kept for the record. (see below)

Feature request based on the comments. (see the comments section)

It should be possible to group changes per page (accordion ?) so it is possible at first to see all the pages that have been changed. When toggling the view it should show all "this" page changes.

Minor changes shouldn't be displayed.

---
Previous:

I have the feeling this is a recent change.

At https://tiki.org/tiki-lastchanges.php is display ANY editing of the pages they were saved meaning when 20 editing where done on a page, it will show 20 rows for the same page. With you can have a page displaying only changes on a single page. It turn the feature as unusable as the user is busy playing with the navigation and can’t see the essential information instantly (last page that were changed).

Beside once on a specific page history is working so the details of the changes that were made are available.

Obviously the purpose of this feature is to show last-update-date not ALL-update-date
---
feature_lastChanges (https://doc.tiki.org/item849?highlight=last+change)
description
Enable users (with permission) to see the sortable, searchable list of wiki pages (tiki-lastchanges.php) organized by ===last-updated date===. Use the Configuration area to specify which items to display..
---
https://doc.tiki.org/Using-Wiki-Pages?highlight=last+change#Displaying_Last_Changes

!!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))]

{syntax type="tiki" editor="plain"}
In edit mode, if I do

{CODE()}
((
{CODE}


(and maybe a few letters), an auto-complete should appear, like the quick_edit module. This list should be WYSIWYCA.


This would also be useful in some plugins, when a parameter is wiki=

The most important is ((doc:PluginInclude)), because the main goal of the plugin is to include other pages, which you may not know the exact name.

When in plugin edit mode, an auto-complete could be done with jQuery (ask LPH for details)

Related:
{wish id=480}

When you edit a very long content and or you want to test your editing preview is not always as handy as opening the page in a second tab or a second browser.

In both case, being able to save (as you go) while staying in editing mode would be a great option.

May be there is such option somewhere (I recall something in the WYSIWYG toolbar) but, it is not available out of the box from the main button bar (Preview, Save, cancel).

That would really help people with the "timeout" and loss of content when they are editing a very long page with a lot of content.

I could be nice to have a kind-of "History Flow" application, or feature, integrated in the Wiki.
Such as the "History Flow" ([http://researchweb.watson.ibm.com/history/]) developed by people from MIT and owned by IBM (afaik)

I'm not skilled on CVS, but I wonder if this is already developed for CVs applications. (gCVS, for instance, for GN/Linux Gnome)

And from thepoint of view of Tiki, I know there is the option "export all" tiki versions of a page, at wiki page edit time. Could this be used to see more easily all the changes that a user has made to a document, etc.?

(I'm thinking in the educational scenarios where as teachers we have to review a user contribution to a collective document, and grade it, etc.).

A page can be renamed but there is no log of the change anywhere... No one will know this page was renamed.

The action of renaming a page should be logged in the page history (auto dated description: The page "mypage" was renamed "mynicepage")
I wonder if there is a notification sent for such change ?

Content Templates are an easy and comfortable way to change the look and content of wiki pages. It would be nice to be able to define such a template as your default for wiki pages, instead of having to choose it every single time you create a new wiki page, or changing the template of wiki pages in general.

It is rather difficult to write plugins that embed other plugins. The reason is the wiki syntax of the plugins not expressing if it is a beginning or an ending clause. The default is the "{X} body {X}" syntax.
Instead, {X} body {/X} should be used.
While this latter syntax as well as the {X /} are accepted by $tikilib->parse_data, it does not process the embedded calls. E.g {X} {X /} {/X} does not work. It returns an empty body instead of {X /} or the result of {X /}.

Typical plugins we'll want to use:

https://doc.tiki.org/PluginInclude
https://doc.tiki.org/PluginTracker
https://doc.tiki.org/PluginTrackerList

Using Plugin Web Doc Viewer (https://doc.tiki.org/PluginWebDocViewer) I can embed in a Wiki page a PDF from a Tiki file gallery or an external URL (if it end with .PDF from my test) or a Google doc file (documents, spreadsheet, etc) from a Google drive.

Using the plugin Plugin Google Doc (https://doc.tiki.org/PluginGoogleDoc) I can embed a Google doc file (documents, spreadsheet, etc) on a Wiki page.

However I couldn't find a way to embed on a Wiki page a PDF file stored on a Google drive.
It just failed.

This would permit more parameters.

Ex.: make invisible

{CODE()}
{alias page=oldpagename visible=no}
{CODE}

There should be a conversion script so every time Tiki detects the old syntax, it converts to the new one.



Related: {wish id=wish2450}

A plugin like this:
{img src=images/code.png}%%% {CODE()}
{BACK()}{BACK}
{CODE}

Thats does this:
{img src=images/code.png}%%% {CODE()}
<input type=button value="Back" inhibited_Click="history.go(-1)">
{CODE}

{syntax type="tiki" editor="plain"}
It would be great feature I think if you could quickly mention someone in the wiki pages and anywhere else using syntax like -+@johndoe+- and after page is saved it would make a link to their user info and send a notification to them that they were mentioned on the object.

It should also respect the "show realName" preference when enabled.

Requirements:
* Needs to check if the @ is at the beginning of line, or surrounded by whitespace to not catch regular e-mail addresses
* Needs to match only one @ followed immediately by the username (login name)
* Optionally it would be nice if it matched also mentions in common parenthesis like -+(@username)+- without need to surround them by space

See also ((Freeform Relationships)) with the idea of @@group

The capability to include (recursively) with parameters is probably the most powerful and content factorizing feature of our best competitor MediaWiki.

It make not only produce content much faster and in a much more modularised way.

The references :
* [http://en.wikipedia.org/wiki/Transclusion]
* [http://www.mediawiki.org/wiki/Help:Templates]
* [http://doc.tikiwiki.org/PluginInclude]

{syntax type="tiki" editor="plain"}
On a Tiki23, I can activate the "Revision approval" feature for Wiki Pages at -+tiki-admin.php?page=wiki#contentadmin_wiki-3+-
Admin => Wiki page => Flagged Revision => Revision approval

This function then requires the user to select the categories that will be governed by this feature using the field "Revision approval categories".

This is workable if you have a few categories (like 10 or 20). However, if you have many categories and subcategories, it becomes very complicated and hard to understand how to manage them.

To add to the confusion, there is an "invisible" limit on the number of categories that will be displayed. By default, you will see only 50 category results because of the setting:
Look&Feel => Navigation => Limits => Maximum number of records in listings: 50

It is very hard to understand why you don't see all the categories if you are not a super power user.

{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))