Category: Feature request

On a Tiki26 I searched for "payments" and this is the results displayed.

The feature payment is not yet activated (default).
Enabling the payment feature (Payment payment, features advanced) is the first step and a quite important step in the process (if not enabled, all the rest is not relevant)
However this preference is not the top result but buried somewhere in the middle of the results.

This is one example and I guess there may be worst case.

My results should have displayed the __Payment payment, features advanced__ checkbox at the top of the results.

---

Many too big "un-needed" warning are displayed and this added to the preference type (advanced in my screenshot) add confusion to the already dense Tiki preferences and admin options.

I mean, what is good for a big warning about "Exchange rate for types of credit to use" if the user won't use "Tiki user credits" and even "Payment" ?
If there were one warning from time to time on a page it would look important and relevant.
As there are too many warning displayed, it is just noise and people tend to skip them.

I'm not sure what should be the right solution, but I'd like something like a more discreet warning, the yellow warning icon - Requirements not met, and ONLY upon user action (mouseover, click, tooltip reveal, etc) to see the complete message. That way, the user is not submerged with warnings he doesn't need, and only when he need to see the verbose got the exact warning.

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

After editing and saving a certain section of a wiki page, it would be very helpful, if TikiWiki would scroll down to this section again, when reloading the page.

Many other Wikis like Mediawiki or Dokuwiki handle section editing this way and it is indeed very convenient.

Imagine you edit a section of a very long wiki page and you have always to scroll down manually, when you have saved the page but have to review it.

There are no universal products....

I do think so, that each is specialized, even so open as tikiwiki, any user of products try will to connect with others specialized products.

In fact the connection between systems takes a long, long time because, a product uses an implicit meta-vue of real, so there is a core of meta-model of datas which is progressively developped and connection are more and more simple, they become an element of culture of a community more and more large. This take decennies. This begin to exists for
*text calendar and tasks with ics files structure (but there is a confusion betteween taskd and event which generates a lot of bugs),

*text with ldap models for address management etc...
*text various contexts

About this my proposal is about calendar, task, and workflow is to have a bi-directionnal connection of the calendar and tasks.

Why bi-directionnal, because tikiwiki is an information generator that can be hold with ics shared files, and these must be easily connected with coherent others tasks and events that can be managed by specialized tools.

The main tikiwiki purpose is production of text and documents, may be it can go to GED (management of electronics documents), but technical documents have too specialized tools for technical documetns production etc...

But I don't se any (many but that can be solved) reason not to link a tiki event linked with a date held by Gannttproject (xml clear structure) and/or ics.

You will find the same with links with thunderbird calendard (oriented mail communication), SUGARCMR (relation and commercial action) yet connected with thunderbird and tikiwiki.
The main tools are ics and xml (complex structures for ganttProject)

This is future, this must be well thought because in these domain an error can generate year of delays.

I hope to have launched some ideas able to identify axis.

These are ways of work

This is an alternative to full WYSIWYG.

Wiki parser does some things. To get Javascript WYSIWYG, you would have to rewrite and maintain in javascript.

It re-uses existing features and has less chance of What you Saw Was Not What You Got.

Clicking Preview is a great way to see what you will get. But it's slow and it makes you loose your cursor position.

How about having a button to open a second browser window which refresh every 5 seconds (configurable) the content of the wiki edit box?

Lots of people now have large screens so they could put this side-by-side (or however they want it)

With the option HTMLdiff, you could in quasi real time not just see what you will get, but also see the colored diff. (cool!) So before you save, you know what you are about to delete.

((WYSIWYG-ish wiki))

Trackers are great in Tiki, it provides a way to build quick and easy register solutions.
When used in any context related to monitoring, it would be nice to have a way to associate a record with one or more events in time. For instance you would like to receive an email at the time the issue related to the task should be controlled and/or be resolved.

Thinking on it as a feature, the following could be considered in the solution:
*It could exist more than one "timer" in the tracker record,
*It should be added like any other tracker field to the record definition,
*It could have different ways to alert: email, rss, ... (maybe only one choice when instance),
*It could have rules, like auto disable when the record is closed (or other condition),
*It could be (as an option) reprogrammed,

and also
*Maybe a user wants to know about all his/her pending "timers".
*Maybe timer implementation could be independent objects that are linked to (special fields in) tracker records (or other objects), so global management is possible.

I guess that a good part of above functionality is already in Tiki in some form.

((doc:Alert)) brings some cool new stuff, but it just works for file galleries.

There should be one feature which works everywhere which permits to inform all kinds of people/websites/computers about something. (via email, IM, etc.

All over Tiki, there are contextual links the relevant page on http://doc.tikiwiki.org/Keywords

This is pretty good for end users because they get access to info about the feature and the opportunity to improve it.

Now, it would be good for Tiki admins to see links to http://dev.tikiwiki.org/Keywords as well so they know what bugs have been reported and they get the opportunity to learn, share and participate.

Related:
((Viral TikiWiki))

When we have many admins on a site, it's hard to keep track of who changed what.

One admin may turn on a feature, and a second turns it off. This should be logged.


So when a change is done on tiki-admin.php, the old & new value should be available in the logs.

This will permit a "manual restore" after applying a profile.

{syntax type="tiki" editor="plain"}
If Tiki is going to have System Menu item icons by default in new installations, probably all menu items should have one. Why only "Categories" in the system menu dropdown?

The same items in the admin pages aside menu have icons, so it should be just a matter of adding them to the system menu. Note: be sure these are added in a vendor-neutral way so that if the admin switches from Font Awesome to Bootstrap icons (or another icon set), they will still display.

When I was testing various CMS/Wikis for a project, I ran across a module for another (Joomla or Drupal, can't remember which) CMS which allowed a user role or group to automatically generate a personal page, an image gallery, a weblog and any type of content page. It would be extremely useful for my project, but one of the few things missing from Tikiwiki (which is why I am implementing Tikiwiki, it has all of the other features I need in one install).

In 3.2, one can create a personal page in MyTiki and use an Avatar (I see from the Community it wasn't always available & I appreciate the feature), but I would like an Administrative feature that could turn these off while still allowing users to access their Preference Screen, especially for changing their password and email address.

User pages and avatars could take up a great deal of space if there are a lot of users. I'd like to turn off the ability of users to have user-pages and avatars. If there's a way to do that now, please let me know, because I've looked everywhere for a way to do that (and there's a note not to edit templates unless you really know what you're doing and I somewhat know, but I'm afraid of creating a problem).

Currently, the length of the search result snippet is hard-coded to 250 characters (in searchlib.php). it would be nice if this could be defined by the admin as part of the search preferences.

Currently, Tiki allows anonymous visitors to subscribe to a newsletter (via the "subscribe any address" feature. It would be nice if anonymous visitors could "watch" items simply by adding their email address.

When using the Mail-In feature with Articles, Tiki places the entire email in the article's Header. I would like a way to specify portions of the email to placed in the article's header, the rest in the Article body. Perhaps by some sort of text marker?

When you view an article, the URL simply includes the id# of the article. On wiki pages, however, the URL lists the article title.

{syntax type="tiki" editor="plain"}
The Manticore server doesn't find words of length 2, when used by Tiki. It looks very much like only words of length 3 (or even 4) are indexed.

This depends on the configuration used when the __tables are created__ inside of Manticore. It looks like Tiki specifies the "min_word_len" setting to be 3 (or even 4) when creating the "tiki_main_..." table inside Manticore. The SQL command in question is "CREATE TABLE tiki_main_... (...) min_word_len='3';"

I've searched the Tiki settings in the "Search" Control panel and couldn't find a setting for the minimum word length of Manticore.

The minimum __can't__ be configured in manticore.conf, because it is set (so it seems) at table creation time, which is the time when Tiki rebuilds the search index.

This isn't about stopwords. I've tried with 2-letter-word which aren't.

When performing a search which only includes one 2-letter-word, I get the following error message:
{INDENT()}Malformed search query: SQLSTATE[42000]: Syntax error or access violation: 1064 table tiki_main_69a052d856213: P08: syntax error, unexpected ')' near ' ) | (@title )'{INDENT}

Currently, Tiki creates a single RSS feed per feature (e.g., wiki, articles, etc.).

For features that support i18n, this means that end-users will subscribe to a feed that contains items that they cannot read.

It would be nice if Tiki could create language-specific feeds each feature.

You can see this on info.t.o; we issue articles in English and French and Tiki includes both languages in a single feed: http://info.tiki.org/tiki-articles_rss.php?ver=2

Allow direct file placement in the file gallery upload folder and have it index the files/add them to the file gallery...similar to the photo gallery which simply index all files with an image extension (ie. jpg, gif, bmp) and displays them in the batch upload area, this feature needs to be integrated into the file gallery so you can add/ftp files into the file gallery stipulated upload folder and them show up in a file gallery.

When adding a new item to the directory, it would be great if I could upload an image for the link.

It would be nice to allow a user to select an image from a image gallery of the same tiki site when he/she needs to provide an image for a tracker.


Imagine something like "offers" and "demands" trackers, or hand-made articles, etc. You could assign an image from a gallery as image in that tracker item (like article topic in articles feature nowadays), or insert your own image for that tracker item (as in articles nowadays).

Moreover, Tiki could provide a bunch of pre-defined images in such a gallery from Openclipart.com (public domain licensed in there), to make it easier to staart using images in trackers, or article types, etc.....

Yahoo Weather (and, I assume other feeds) rss feed dumps neat html into the description field of the first item rather than the title. I've modified function.rss.php to accomodate this and allow users to continue to use the regular module creation interface. Basically, I added a new parameter "desc" such that if you use {rss id=1 max=1 desc=1} the resulting output will use the description field instead of the title field. Skipped items will still be skipped.

Sorry, but I'm very new to Tikiwiki and may not conform to regular documentation standards...please correct me as neceesary.

To allow for greater styling, it would be great to allow HTML coding and/or wiki syntax in the __Site Title__ and __Subtitle__ fields on Admin: L&F.

It would be nice if visitors to info.tikiwiki.org could search all of the tw.o domains at once. What I envision:
1. A user goes to info.tw.o and searches for "WYSIWYG"
2. Tiki searches all of the *.tw.o domains and presents the results to the user, breaking the results by domain (e.g., all of the doc pages, dev pages, etc.)

Currently, the search results page will provide a box for users to extend their search to other tw.o domains, but (IMHO) it really needs to be automatic. See http://info.tikiwiki.org/tiki-searchindex.php?highlight=wysiwyg&where=pages&search=go for an example.

Maybe this could be expanded to fetch search results from other, non-Tiki search engines, too.

{syntax type="tiki" editor="plain"}
It would be really useful to be able to override the smarty templates used for email notifications (currently in -+templates/mail+- and -+templates/activity+-)

Probably a new pref -+mail_template_wiki_pages+- to look for pages "named exactly like the template files" (maybe starting with -+mail_+-?) with the correct -+tiki_p_use_as_template+- permission and if found, use that as a tplwiki resource instead of the tpl file.

Hopefully to be backported to 21.x when tested.

You cannot assign meta tags to individual pages. If you use the universal meta tags, that is not the best way to optimize for search engines.