Category: Feature request

A sticky topics would be really nice. When you guys are fixing the errors in the forums, make a change and implement the sticky topic

As you can see in this comment's item, the discussions comes to a point it is hard to read and most of the screen space is wasted.

https://dev.tiki.org/tiki-view_tracker_item.php?itemId=7838&threadId=9696

We should add a new preferences so we can limit indentation on thread reply.
It should be optional
It should be have a threshold field (after 5 replies stop indenting)
It should be set "enable" by default (with 5 replies)
It is important to test with a setting of 2 (after the first post, all replies have the same single step indent)

This happens on comments under or added to another feature, not in forums.

Already possible:
http://profiles.tikiwiki.org/time_sheet

But it would be nicer to have a click on start, click on end to count time for you.

Something integrated to track time spent on ((doc:tasks))

Will be useful for ((project Management))


http://timeclock.sourceforge.net/
http://sourceforge.net/projects/phptimetracker/



Coordination happening at ((Federated Timesheets))

{img src=images/code.png}%%% {CODE(caption=current strikethrough syntax)}
{TAG(tag=>strike)}texte{TAG}
{CODE}

Suggested one for us:
--strike--

As suggested in wikicreole:
http://www.wikicreole.org/wiki/Strike

All wiki engines:
http://www.wikimatrix.org/syntax.php?i=27

This is very useful when using wiki pages for ((project management))

{syntax type="tiki" editor="plain"}
Goal

We want doc.tw.o to generate nice printed documnentation.

Problem
It's too difficult to detect which pages are not in a structure.


A new page may be created but not assigned to a structure and be lost, and not appear in the printer version.

It's ok that some pages are not in structures (notes, redirects, etc) though.


tiki-edit_structure.php -> list at the bottom should only show me pages that are not in current structure, otherwise, I can add the pages at two places in the structure.(feature or bug?) This could useful to move pages though because current system is too cumbersome for large structures like the one on doc.tikiwiki.org


Perhaps, the structure if should appear in list pages. So by sorting, we could find all orphan pages...

Documentation of Tiki (doc.tw.o) needs some help, as well as any other tiki site aiming to produce structured documentatation to be exported as "printer-ready" (.pdf, .odt, ...)

!!- (1). Original idea, as posted in devel list (but improved, and made it easier, below, in (2) )
I include here a copy of the [http://sourceforge.net/mailarchive/forum.php?thread_name=467565F1.9080905%40ub.edu&forum_name=tikiwiki-devel|original post at tiki-devel list]:

{QUOTE()}
[Tikiwiki-devel] New documentation file: Tiki198alpha.pdf
From: Xavier de Pedro Puente <xavier.depedro@ub...> - 2007-06-17 16:44

(...)

There are some issues that, it solved from coders, they would make
easier to produce next documents like the pdf ones:

(1) Page Title is not automatically shown on wiki pages on the server,
and thus, manual header1 was added everywhere (Almost). But when
printing to html, page title is duplicated. => if Show Page Title option
is disabled under "Admin > Wiki", Page title should not be added
automatically at print-to-html time.

(2) to produce the same structure (same level structure of headings) as
in table of contents http://doc.tikiwiki.org/Documentation , some hack
(optional) would be very welcome so that heading 1 in doc.tw.o pages is
not printed as heading 1 in through the multiprint, but as header 2, at
least. (optional).
This is, for instance, what is produced when printing a full structure
from a Workspace - AulaWiki Mod - : a coder could grab the code from
AulaWiki Mod as a reference....
In there, the description of the page is set as the Page title (header
2, I think), and the page title is included below for completeness (in
lower font, and with version number next to it)...

edutwo_ws_print_structure4.png

(3) Numbering of headings: somehow, in Workspaces this is handled
internally, and the user/documenter doesn't need to bother with manual
numbering: it's produced also at print time.
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Example of print structure differences between Tiki's multi-print and
Workspaces print structure:

Print to html "Aula-Wiki Tutorial" from here:
[http://edu.tikiwiki.org/tiki-print_pages.php]

or from here:
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Well, as you could imagine, some changes to the code to make the work of
documenters a bit easier would be very wellcome also... :-)

(...)

{QUOTE}

!! (2) Update July 20th: Easier solution
Easier solution: Get levels for first heading in each wiki page of the structure not from the content of the page.

^__Example__: a page may start with a "! Title of page" (first level heading), and after that, "!! Subtitle of page" (2nd level heading), ...

Imagine that this page corresponded to "2.3.1 Module whatever" as the level in the table of contents of such structure.

The solution would be then that "!Title of page" (in that page "2.3.1 Module whatever"), when sent to (or fetched by) tiki-print_pages.php as a whole structure, was converted to "!!! Title of page"; and "!! Subtitle of page", should be converted to "!!!! Subtitle of page"..., and this way sequentially for all the title headings on each page from the structure...
^

The procedure below should become a 1-click from wiki (structures) to[http://doc.tikiwiki.org/Tiki19beta.pdf|PDF]. Please see:[http://doc.tikiwiki.org/Printing+the+Documentation|How to produce the .pdf out of the .odt]

-----

Dec 13 2008. Update:
Previous problem is fixed. However, I notice that automatic numbering with heading within a page (!!#, !!!#, ...), should be also considered in the global autonumbering.

Plus width of wide images and tables would be better if not that wide when exported to html (maybe an option), for the case when you plan to import it to OpenOFfice, and they are too wide to the document. Should this be another RFE or bug report?

---
REOPENING BUG
update on Jan. 7th, 2009:
See the other bug report: autonumbering didn't work for me with doc.tw.o/Documentation, even if it did a month ago on another site/structure

Related (and newer) bug report/RFE:
[http://dev.tikiwiki.org/bug2255]

On Tiki structure you can have one or several top page and its subset of pages inside the structure.
If you edit your structure "tiki-edit_structure.php" and delete a page ALL the subset of pages will be removed from the structure without a warning.

First a warning should tells the user is about to remove the subset of pages (this can be catastrophic !).
I think a question should be asked about it;
You are removing page of a structure that has a subset of pages:
❑ Remove all the child pages from the structure ?
❑ Keep the page in the structure (they will be moved to the next top page) ?

When you create a new structure you can fill a tree.
This will create subset pages inside the structure.
Below this you can "Categorize" (no more explanations).
As result only the first page will be categorized.

On a Tiki 25 I tried 3 times and I couldn't see any message about the page(s) categorization and only the first page was categorized.

On a fourth attempt (different structure) below the success feedback for the structure creation I could see a feedback about categorization of pages but only the first page was categorized.

On a fifth attempt (different structure) all pages added were categorized.

First, there should be some help the user to understand what will be done about it. (structure and subset of pages will be categorized).

Second... it should work all the time. 🤷🏻‍♂️
I still need to find a way to reproduce...

The icon in the structure action strip are confusing and can be improved.

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

The first one suggest a "search" and/or addition of page while in fact it is to view the page.
The fa-search-plus should be replaced.

As we are using the "eye" icon that is naturally the "View" symbol for Watches we should be creative.
The icon should be without a + sign. Even a hand-point-up will make better sense.

When filling cells with text, you can change color & font of the whole cell, but not single words.
It would be useful to have fully free styling of parts of cell content (to highlight those parts rather than whole cell).

I'd like to send a new blog post (configurable for each blog) to a mail adress (in particular a mailinglist). It is of cause possible to create a new tiki-user for the mailinglist and watch the blog, but we do not want the unwatch-link to appear in the mail, and we do not want to change the template for the blog-watch-mail.

The text in nearly all themes - even Readable - is not pure black (RGB # 00 00 00). This lowers readability. While this may not have a hard effect on accessibility, it certainly reduces reading comfort.

I have compiled the following list of default text color for functional themes (excluding themes with non-white backgrounds) on trunk.

-=000000=-
*Jqui
*Utopias

-=222222=-
*Tikinewt
*Yeti

-=333333=-
*Default Bootstrap
*Cosmo
*Darkshine
*Feb12
*Fivealive
*Fivealive-lite
*Readable
*Strasa
*Thenews
*United

-=363636=-
*Didiem

-=555555=-
*Cerulean
*Lumen

-=515151=-
*Greenvalley

-=666666=-
*Paper
*Spacelab

-=737373=-
*Business

-=777777=-
*Journal
*Simplex

Flatly and Sandstone are slightly special cases, as the text is tinted. The former uses #2c3e50, the latter #3e3f3a.

This problem is developing. Grey fonts have become a fashion, as recently [http://www.telegraph.co.uk/science/2016/10/23/internet-is-becoming-unreadable-because-of-a-trend-towards-light/|reported by The Telegraph]. In Tiki 9, the default color was pure black. In Tiki 15, it has become #333333.

I am not asking for a strictly pure black or pure white interface. I understand that other colors can be aesthetically or functionally better. What am I asking is to increase the contrast for the main content (the context of a wiki page, or of the blog post being viewed, for example).

Currently, Tiki allows you to add users to a newsletter by name, email, or an entire group.

I would like to add users based on last login. For example, I want to send a newsletter to all users who have not logged in for 6+ months.

I request that TikiWiki consider adding a css timer to make the Success on save Notice disappear after ~3-5 seconds.

__Why?__
If one is making many edits to a wiki page it disturbs the task flow to have to dismiss the Success Notice to reclaim some screen real-estate.

__Examples:__
If you click save while editing a word document the application just saves your work you are not left looking at an information bubble telling you your work is saved.

__Coded Example:__
https://jsfiddle.net/swfour/M2B9B/14/

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.

And some cleanup of theses pages would be nice:
http://doc.tikiwiki.org/tiki-index.php?page=Rewrite+Rules
http://tikiwiki.org/TikiWikiRewriteRule

tiki-backup.php was like performing surgery on yourself. It can work but it's risky.

We can't use rating yet (hopefully soon), so at the moment it is just the priority user chooses. From 1-low to 9-high is very subjective and people tend to rate things higher, than they 'objectively' are. I just stumbled across this classification from Bram Molenaar and think that it is a good guideline for rating Items. As long as we use the Priority field, it would be easy to implement, later for Ratings we would have to add something like a legend or so..

--- copied from VIM reference manual TODO List ---
Priority classification:
9 next point release
8 next release
7 as soon as possible
6 soon
5 should be included
4 nice to have
3 consider including
2 maybe not
1 probably not
- unclassified
--- end of copy ---

{syntax type="tiki" editor="plain"}
IMO the switch color mode module should be active by default in new installs. I think users appreciate that feature especially if they have set their browser to request dark mode as a default. The themes have been checked for color contrast (accessibility) issues in light and dark mode so useability should be fine. (A few themes don't have a dark mode because they are dark already.)

I see we have now a "Suggestion box" in Tiki22.

While this is nice I couldn’t find any information at dev or doc about this addition based on "a list of rules" ?
I found a checkbox in feature to disable it.

#While I have no idea what/where it should go, I wonder if this is really a Tiki feature.

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.

!Summaries styles associated to levels in all hierarchical lists

!!Utility
When a hierarchy (summaries particularly) is displayed there is no style associated with the level.

Generally in all documents a different style is associated with level independently of the indentation.

!!the aim, a better readability.

This is en enhancement of style, but it is a very precise detail and a problem of esthetic's independently of the aim, a better readability.

!!constraints
So it should be optional and easy to modify into the style. Asssociated with the style not with the layout.css.

!!What's done
Efficient in my application since 5.3
Easy to enhance for 6.x and more 7.x

!!Changes
*tpl (two ones)
*styles

__Remark : __can be done independently, after the change into tpl, take effect when classes are defined into css
__Optionally :__ size of text by level and by default set in layout, colors or changes in text sizes or text styles into styles.
__Note:__ the name of the style is built automatically with a pattern, used for text and number (if option used), then the developer of style.css can easily add and/or find them for modification

trebly

(ref:B10125-06)

I see that most pages generated by wiki do not supply page last modified information in the HTTP headers.

This information is used by search engines as a factor in re-indexing and also by cashing systems such as cloudflare (which can dramatically decrease server load & speed page loading) or web browsers to determine if the page content can be pulled from cache or if it needs to be re-downloaded. (although granted the rules are not quite that simple)

I request that "last modified" information be included in the HTTP headers of each wiki page, and optimally of other pages such as articles, blogs posts, forum etc.

Initially it could be as simple as supplying "single pages" such as "wiki pages" which already have last modified information stored in the database and its clear that the content on the page belongs to the "wiki page".

I could not find last modified timestamp for blog posts or articles in the database (not to say they are not there) but it may require additional database fields if the information is not already stored.

Pages with multiple content on them (such as a listing of blog posts, or articles, etc.) could display the last modified date of the most recently modified article or blog post, respectively.

I did notice that there was last modified information being supplied for files, so we are partly there already.

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.