Category: Feature request

At this moment in version 3, forums are as they are, flat forums with category.

Let us create child pages, so we can maintain nice URLs.

site1.com/game1/FAQ
site1.com/game2/FAQ

Foswiki's webs is a great example. Very organized and clean looking URLs.
http://foswiki.org/System/ManagingWebs

If that's not possible to do, maybe consider making structures look less messy, or changing this :

http://doc.tiki.org/Tiki+Administrator+Guide?structure=HomePage+AdminGuide
http://doc.tiki.org/Article+Details?structure=HomePage+AdminGuide

To something like this :

http://doc.tiki.org/HomePage+AdminGuide/Tiki+Administrator+Guide
http://doc.tiki.org/HomePage+AdminGuide/Article+Details

Going to http://doc.tiki.org/HomePage+AdminGuide should take you to the main structure page.

Integrating a Simple Classifieds System with Categories and Subcategories would be nice. Each ad should be attached to the user that submitted it and possibly integrated with the user's "my page" so they can keep track of their ads, how many replies they've received and so forth. Nothing too complicated to start with...but it would be a fantastic addition to the software.


ML: Should this be a new feature or done with trackers? If done with trackers, it could distributed via the ((Profile Manager))

Make 1.9.11 and 1.10 consistant
Remove less used quicktags and add some in the spirit of ((EditUIRevamp))

It'd be nice to have an option which would open a new browser or window when clicking a URL in the shoutbox.

{syntax type="tiki" editor="plain"}
At https://nextdoc.tiki.org/tiki-browse_freetags.php you can see the list of all the tags.
When you click on a tag it add the term to the search field and wait for further action from the user.

When I click on the search button the term will stay in the search field and other terms will be added.

This is a bit wonky and bad for UX.

Clicking on a tag should do the job, initiate the search for the object with this tag.

Viewing this video from the file gallery is not working (anymore) download the file: https://dev.tiki.org/dl1629

Media player's way:
{mediaplayer src="display1629"}

Update and clarification {sign user="Bsfez" datetime="2021-11-30T08:44:36+00:00"}
At https://doc.tiki.org/tiki-browse_freetags.php I used 2 tags (that have results, they are displayed in bigger font size): configuration articles

All selected = 0 results (what ?)
{img type="fileId" fileId="1653" thumb="box"}
{img type="fileId" fileId="1652" thumb="box"}
---
One selected = results (not sure what was searched... look like both)
{img type="fileId" fileId="1657" thumb="box"}
{img type="fileId" fileId="1656" thumb="box"}
---
Last selected = results that seems to be articles (Good)
{img type="fileId" fileId="1654" thumb="box"}
{img type="fileId" fileId="1655" thumb="box"}

Not only the UI is not great but if this is what was intended it very confusing and look broken.
In comparison with "all selected" and "last selected" and the results displayed I don't know what a user is supposed to understand. The options descriptions are also adding confusion, terms in a input (search) field are not "selected" while terms clicked on should be considered as selected (mobile era).

See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

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

When page content is too large, the browser is way too large or some content is truncated/hidden:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=Hello%20World&preview=73

This is the good behavior in Firefox but not IE6:
http://www.wikicreole.org/wiki/TikiWikiCMSGroupware

Maybe CODE plugin should have wrap=1 by default, but with the horizontal scroll, it'll be OK.

Tiki mode is now part of CodeMirror:
https://github.com/marijnh/CodeMirror/tree/master/mode/tiki
http://codemirror.net/mode/tiki/

Be we also have a duplicate in Tiki code:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/lib/codemirror_tiki/mode/tiki/tiki.js

Say I want to use several RSS feeds in Tiki, I need to make a module for each. Or to add several calls in a wiki page. However, if I have some very active sites (like tikiwiki.org, and some not so active (like mobile.tikiwiki.org), the slow news sites is taking up precious screen space.

Now:
{CODE()}
{rss id=1 max=10}
{CODE}

Nicer:
{CODE()}
{rss id=1+2+5 max=10}
{CODE}

php console.php index:rebuild works well

However, it doesn't give any feedback.

The web interface reports:

wiki page: 2850
blog post: 4
article: 1708
file: 4321
trackeritem: 6988
comment: 13

Execution time: 510.07 secs
Memory usage: 116.50MB
Queries: 245172 in 163. secs
Last update from SVN (12.0svn): Friday 02 of August, 2013 11:11:40 EDT- REV 46958

Comments added on a tracker item are not noticed on tab (color, number, ...)

For instance: [http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=97&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=26&filtervalue[26]=check|this tracker item] has at least one comment, but when viewing tracker detailed information, there is not information on the "comments" tab of the tracker item (not any pinky color, and/or number of comments on that specific tracker item...), so that it's difficult for a reader to notice that there where comments added....

There should be a setting to allow comments to be editable, by user and/or admin.

It is now possible to comment a file gallery. However, it would be more useful to be able to comment an individual file.

For example, someone uploads an audio or videoclip, others could comment.

suggestion by Yannick Boily

It is now possible to comment an image gallery. However, it would be more useful to be able to comment an individual image.

For example, to identify who are the people on the photo.

suggestion by luciash d' being aka Lukáš Mašek

At https://dev.tiki.org/item8242-Comments-I-replied-to-a-comment-and-tiki-showed-another-user-as-the-author I create a ticket for a bug but after it happens to me again I'm trying to re-think and re-evaluate. Obviously, I'm doing something wrong (sorry) and I revisited the user interface to understand why I could have been confused.

I'm more and more working on mobile screen also so placement and size with touch screen can be more tricky than with a desktop sized screen.

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

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

I suggest:

* The danger colour shouldn't be the same as secondary
* The destructive actions should be separated from the others (same line start - end ?)
** Reply and Post a new comment together (not the same color)
** Edit, Delete (or cancel) together
* Edit, Delete (or cancel), the editing actions may be small buttons to emphasis the difference between editing actions vs adding content

---

With the above in mind, this also can be improved.

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

10 possible actions:
* 2 primary - Scarlet (light red)
* 7 secondary - Bordeaux (dark red)
* 1... Danger (very light soft-pink) ? ?

In my mind would should have distinction between
* Adding content often used tools (Edit)
* Adding content secondary tools (Comments, Files)
* Collaborative / User tools (comments)
* Editing tools (Rename, History, Source)
* Helpers/Admins tools (Translation, Permission, Remove)

''Translation can be seen as an adding content tool or editing tool (not 100% sure about this one, I would say that the dropdown is fine as we have it usually somewhere else)''

Distinction can be Made with colors, position (start - end) size (btn - btn-sm), design (outlined) and semi-hidden (dropdown)
https://doc.tiki.org/Documentation is different and offer a 4th (or 5th) color which help a bit.

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

For wiki pages, we have this option. It would be nice to port to comments so we could open our blogs to anonymous comments without getting spammed.

Since this is vast project, we'll use a wiki page: ((CRM))

We have a nice comparison for wiki, spreadsheet, etc. but not yet something nice for images.

DokuWiki has a nice "Shine-through" and "Swipe" diff views of images
{flash type="url" movie="display303" width="344" height="551"}


See also:
https://github.com/zurb/twentytwenty

Once MediAlchemyst will be in Tiki18, we can add something like https://packagist.org/packages/caxy/php-htmldiff to compare the evolution of a file


See also: ((History)) for some potential code we could re-use

I wish the wonderful multilingual features that the Wiki side of
TikiWiki has were available/applied consistently throughout the Tiki package.

So, it works really well to view wiki pages in your own languages,
translate into others and keep these in sync collaboratively.

While you stay in the Wiki side of things.

As soon as you leave to use files, forums and FAQs etc. etc. multilingual is patchy at best.

I'd like to be confident that whatever feature I enable, its possible
for all content in that feature to be truly multilingual.

composer.lock needs to updated
* when composer.json is updated
* to get updates on any of our 100+ dependencies

Tiki developers sometimes waste time with this. Let's automate.

It should be ran with the right version of PHP (the lowest supported for that Tiki version)

Also, each branch needs to be run independently (you should't merge the results of one branch in another). So this should be excluded from the script at ((Semi-automatic merging period))

We need a robot SourceForge user name. Ex: tikicibot


One example: (up for discussion):
# Check all changes on composer.json and update immediately composer.lock (because a dev working on something likely wants to see immediate results)
# Update composer.lock every 10 days on supported branches. So we get somewhat frequent updates. Since composer.json is set for semantic versioning, it should not cause regressions.

Also, there is some weirdness where the composer.tiki.org URLs are changed to the external sources like Github.
http://sourceforge.net/p/tikiwiki/code/68089
This automation should keep everything on composer.tiki.org

This should also be done by the release script

Some examples:
http://conf.phpquebec.com/en/horaire
http://code.google.com/events/io/sessions.html

{syntax type="tiki" editor="plain"}
Prefs that should be handled differently for:

* ((Redactor))
* ((Connect))
* Some prefs if you copy a site elsewhere and try to run like ((tw:Pre-Dogfood Server))
*** Elastic Search
*** CDN
*** memcache?

It Tiki we can use Smarty or Wiki templates (wiki pages).

For the Wiki pages there no consistency between tools in Tiki.

-=The template parameter=-
For customSearch plugin the parameter is "wiki=" - https://doc.tiki.org/PluginCustomSearch
For the List plugin the parameter is "tplwiki=" - https://doc.tiki.org/PluginList-output-control-block
For the Plugin IncludeTpl the parameter is "filename="wiki:" - https://doc.tiki.org/PluginIncludeTpl
... There could be more...

All the parameter to call a template from a wiki page the parameter should be the same anywhere.
"tplwiki=" seems to me to most understandable and precise.

-=The Wiki syntax require to use the template=-
* Plugin List: a wiki template can be use as is (you just paste your HTML)
* Plugin customSearch: your html need to be enclosed between literal tags ({literal} HTML {/literal}

It should be just consistent for the end user (not power user) experience.