Category: Feature request

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

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

At https://dev.tiki.org/item8530-Server-check-is-raising-false-alarms-about-Tiki-requirements I used the wikiplugin img to display an image from anywhere on the internet.

The plugin display a broken image.
If I check the code and the url of the src it is correct and display the image.

Update: The img plugin insert action will automatically select the mediaplayer plugin if a video is detected. (not well documented)
---
Still:
It is possible using the plugins img or files to select or upload directly a file from the Tiki File Galleries. It would be nice in 2023 to have also this select functionality in the media player plugins.

Using the wiki plugins mediaplayer, webdocviewer or googleDoc we can display PDF and documents from many sources.
Almost everything BUT not PDF document stored on a google drive.

We need to add an option in one of our plugins to allow user to do so.

Currently there is no wikiplugin to place 1 or more blogposts on a wikipage (showing title and content of the blog).

The functionality should be similar to the wikiplugin_articles, so that the amount of posts and the blogId can be specified.

Using a wikiplugin instead of the module plugin or RSS gives the advantage that you can show entire blogposts and that you can include a permissions check, so that users that should not be able to see the post don't get it on the screen.

In WikiPluginTracker the confirmation message should have an option to send to any URL. That way, insted of having a confirmation message when the user click on send, he is send to another wiki page, etc where you can put the confirmation message you want. Because confirmation message may be more than one sentence, it may be very useful; and it open to the possibility to have another WikiPluginTracker on the second page... So you can have a tracker on multiple page.

__french__
Dans WikiPluginTracker, exemple la fonction qui permet d'afficher un texte comme message de confirmation devrait avoir une option de renvoyer vers une URL. De cette façon, l'utilisateur a plus de latitude sur la forme du message de confirmation. Surtout, il peut étaler un formulaire sur plusieurs pages wiki !

ex.:
TRACKER(trackerId=>4,fields=>13:14:15:16:17:18:19:20,url=>http://www.google.com)}{TRACKER

A tracker has been categorized (using admin category add cat to the tracker). (16 = 2019)
The same tracker has a category field for the same category selection. (16 =2019 or 17 = 2020, radio button or dropdown)

On the item level, in the field category the tracker category is forced ''displayed'' even if it is not select in the field. While it make sense on the code/configuration level, it is pretty weird visually for the admin or the user.

In the screenshot below, all the items are categorized (17) 2020
But they show on the list both category (the one from the tracker (16) 2019, the one from the item field category (17) 2020.
{img fileId="1446" thumb="box"}

In Tiki25 (PHP7.4) there is no message helping the admin to understand that the PHP version of the server is not correct (PHP8 or ...).

Such message would help to quickly fix issues and give a new admin the impression Tiki is more friendly. ;-)

On file gallery you have a slideshow option (admin => listing).
Once enabled it will display a slideshow button at the top of gallery pages.
In browse mode you can navigate from page to page: http://bsfez-11581-7931.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=4


When clicking it start a slideshow that display images ===from the first file in the gallery.===

When you have several pages this is not user friendly and is bad UX. (imagine you have hundreds of pictures)

To demonstrate:
*In the edit gallery Iisting setting I set 2 image per pages (row) to have several pages
* I used small images but bigger images or on mobile the image will cover all the screen (you won't see the screen below the slideshow like in my screenshot)

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

ADDITIONAL INFORMATION;
Seems that the URL and the slideshow should use an offset parameter but it is not working.
Exemple: http://bsfez-11581-7931.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=4&offset=4

On a multilingual Tiki 22 with "Prevent special characters in page names" enabled and "Wiki link format" set to relaxed. (multilingual is important factor here, it is because you have many languages with accent or non-latin characters)

This is working ((Tiki and Virtualmin interop))
This is not working ((Tiki, Virtualmin intérop and more and m’ore and זה או זה))
''On dev "Wiki link format" is set to complete" so it is correctly displayed'' ?

{img fileId="1470" thumb="box"}
{img fileId="1471" thumb="box"}

Having a comma or a quote in the title of a page will break future usage of the page name as link. (wiki link)
The user has no warning about this and it gives a very bad user experience.

# Warning on edit/rebname
When renaming or naming (edit) a page the editor should be warned: "you are about to save this name for the page and it contains xxxx those character(s) may forbid..."
# Warning on using wiki link syntax
It should be forbidden (or at least a warning) for an editor to create a wiki link in a page that contain such characters to prevent breakeage and bad user experience.

On Tiki23 when using a since last visit module the category filter is not applied.
If I set a module since last visit to display only items from category 125 I will see many more object than expected.


For exemple, there are only 13 items (no child) for the category "communication_(public)" at : https://tiki.org/categories
At : https://tiki.org/Bernard_tests I set a module I this:
{CODE()} {module module="since_last_visit_new" category="125"}{CODE}

I see MUCH MORE than 13 objects, including object for whom it is not possible to categorise them (users?).

---

While the documentation doesn't mention a category parameter, a user can apply it the most natural way for users, see the video:
{file type="gallery" fileId="1698" showicon="y"}

Seems that “Advanced” parameters are in fact parameters applied to the outer modules functionalities (module visibility and appearance) and not the specific module functionalities (what the module do)

On a Tiki24 I set a tracker with "Restrict non admins to wiki page access only".

Doing so, the item content is visible through plugins (like list and customSearch) for users with corresponding permissions.

However if I use the Tiki search (tiki-searchindex.php) in the results and in the Search control panel, search Items to display in search results, Default where, Entire site is enable anywone can see parts of the trackeritem content for this tracker.

Tiki Search is not a Wiki page, therefore it shouldn't display the items in a tracker where Restrict non admins to wiki page access only" is enable

A list of "small" improvements to improve Tiki surveys;

# The multiple-choice options length are too limited.
+Above 6 or 8 option is not possible.
# The heading field is not easy to use and can be enhanced.
##The page option should be placed at the end (if doesn’t exist then newpage=n). Should be better to have a radio button set to "no" by default.
## It should be possible to use it for plain text (not only header)
## It should be possible use formatting tools (bold, underline, ...)
## It should be possible to use a link (open a _blank page)

{syntax type="tiki" editor="plain"}
On a Tiki25, I create a tracker with a username selector to be the owner of the items.

In the tracker properties, I set "User can see his own items".
^
User can see his own items
The tracker needs a user field with the item-owner activated. No extra permission is needed at the tracker permissions level to allow a user to see just his own items through Plugin TrackerList with the param view=user
^

And so, user can see his items and I can unassigned any tracker global permission.

I also set Restrict non admins to wiki page access only
^
Restrict non admins to wiki page access only
Only users with admin tracker permission (tiki_p_admin_trackers) can use the built-in tracker interfaces (tiki-view_tracker.php and tiki-view_tracker_item.php). This is useful if you want the users of these trackers to only access them via wiki pages, where you can use the various tracker plugins to embed forms and reports.
^

So I understand that only Admins can use the tracker interface.

And it is working fine.

However, if I need user to update their existing items using a modal in a plugin List (tracker-update) or inline-editing format the user see a permission denied.

I have to assign to the group the permission can change item (tiki_p_modify_tracker_items) and this allows users to edit his items on a plugin list.

But now;
* Restrict non admins to wiki page access only as no more effect. (user sees the tracker interface (/trackers | list, the tracker content | /tiki-view_tracker.php?trackerId=xx and /itemxx | the tracker item)
* They can edit any items (other users)

Which is pretty bad because it just cancelled:
# User can see his own items
# Restrict non admins to wiki page access only

There may be more with the tracker field additional permissions and other workaround, but this is just digging deeper and deeper.

In my point of view, it should be possible for an admin to set that user cannot see the tracker interface and can see/edit only their own items quickly (in the tracker properties) without risking display to one user items of another.

I would like to be able to filter searches by Category ''names''. This would improve usability across a Tiki site.

I'm aware that when search filtering by Category, there is a popup on the search page that allows a user to select a Category (or Categories) which will then appear in the Category filter box in a way the search filters can understand. This is handy, but it would be handier to be able to directly type a Category name (or part of a Category name) into the filter box.

The Category selection box also does not help when composing {LIST()} blocks from PluginList with {filter} blocks. At the moment, {filter} blocks must be composed with prior knowledge of the Category ID number. One must use {filter categories="12 AND 38"} instead of, for example, {filter category-names="Czech Novels of the 1900s AND Polish Novels of the 1900s"}. This makes it harder for people to approach writing wiki pages when they want to include lists of objects in Categories.

I imagine a version of this feature would be easy to write for someone familiar with the codebase, because methods for searching by Category ID have already been built and there is already a function get_category_id($name) in lib/categories/categlib.php.

on dev.tikiwiki.org, we have a custom syntax ~np~{wish id=1234}~/np~ to get information about a wish.

This shows the description of the wish, with a hyperlink.

This uses ((doc:PluginTrackerItemField)). If you are a Tiki admin, you can see the config here:
http://dev.tikiwiki.org/tiki-admin.php?page=textarea&plugin_alias=wish

This is very very useful.

How, how could we indicate that a bug is solved? (ex.: on ((Tiki4))

If bug is solved, could it have a relevant class (ex.: special color, crossed out, etc.)?


http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2009-09-25,Fri&sel=291#l287

I would like to be able to encrypt the text of pages before writing them to the database, and decrypt for searches or display to the user.
It would be cool if the same function could be applied to the text of tags, categories, articles, or other features, but being able to use it for wiki articles is my main concern.

---

Update 31 May 2018: I found out how to encrypt entire databases through the MariaDB documentation. https://mariadb.com/kb/en/library/encryption-key-management/

With this in mind, I would like to propose a page be created in Tiki documentation that briefly overviews encryption options for Tiki installations (For example, by linking to that MariaDB article if one is using MariaDB). Perhaps a process to automate the commands required to encrypt a database could be added at some future point (?), that users could opt into when installing Tiki?

Font Awesome (and maybe others?) supports rotating the icon, and some of the icon instances in Tiki are rotated (like the "sitemap" icon is used for Tiki's categories feature, rotated 270 degrees). So a PluginIcon parameter like ''rotate="270"'' would be a great addition.

Many news sites and blogs use a large image above the article content (see stories at vox.com, dailybeast.com, mic.com, www.bucketlistly.blog, etc. for example), whereas Tiki is by default limited to a small image to the side of the content. It would be great to have an option in the editor to choose either big image above the content or smaller image to the side of the content. For articles this would be the topic image. For blog posts and other cases it would be the featured image.

Infinite scroll automatically loads more articles or posts as the user scrolls down the page, so it isn't necessary to click to retrieve the next article/post. This is a popular feature used at many news and other websites, and would be a nice enhancement for Tiki sites.

One possibility (maybe leading contender, though others could be evaluated) is https://infiniteajaxscroll.com. For open source projects this is available under the MIT license (so ok for Tiki). It's also listed at packagist.org (https://packagist.org/packages/webcreate/jquery-ias).

Wish: integrate 'Terms of Service, Didn't read' options https://tosdr.org into our Terms and Conditions feature

Maybe some options to let the tiki admin choose (radio button?) which of the policies from "Terms of Service, Didn't read" they have in their tiki site.

^From https://tosdr.org
__Terms of Service, Didn't read__
We are a user rights initiative to rate and label website terms & privacy policies, from very good Class A to very bad Class E.

Terms of service are often too long to read, but it's important to understand what's in them. Your rights online depend on them. We hope that our ratings can help you get informed about your rights. Do not hesitate to click on a service below, to have more details! You can also get the ratings directly in your browser by installing our web browser add-on:
^

Our feature:
http://doc.tiki.org/Terms+and+Conditions

When a fixed-top navbar is used, the page needs top padding of the same height as the navbar to prevent the navbar from obscuring the page content. Also, when an in-page TOC is used, and a link is clicked to go down the page to the relevant heading, the heading will be positioned at the browser window top, and under the navbar, unless there is an offset (such as margin/padding on the target heading).

Currently there is default pagetop padding for layouts using fixed-top navbars, but there isn't a fix yet in the Tiki stylesheets for the TOC problem (the Tiki project sites have a custom CSS rule as a fix). However, the height of the padding may not be right for all sites because the navbar height can vary depending on navbar content, font size, and so on.

Being able to specify the navbar height would ensure having the right px value for the site. (If there is a JavaScript solution instead that could be automatic and solve the problem, that would also be an acceptable solution, as far as I know.)