Category: Feature request

In groups of people you often have the problem to find day/time when all the people have time to meet.

Especially if they are not in the same room.
And even if they are present its difficult to talk about all the pro and cons when is the best time.


http://www.doodle.com/
Is offering an easy solution. Everybody marks the spots when he has time. Doodle comes up with a proposal, when is the best time to meet. No discussions, every vote has the same weight, non-party and you can always reproduce how the decission was formed.

Can we integrate something like this? Especially because the Tiki direction goes more in decision making.
That feature would fit perfectly in.

In addition to EmmArrBee's bug report that TW should not send spoofed mails, I would like to add something on top. Nowadays, admins might want to reassure their users that mails from a Tiki installation really are genuine. There are several ways towards this goal.

I would like to sort them by importance and ease of integration like this:
* DKIM (Domain Key Indentified Mail)
* GPG cryptographic signing
* GPG full encryption

DKIM needs at least some assistance by the ISP, but some parts can be integrated into Tiki. DKIM will soon become necessary for not getting spam-filtered.

Signing and encrypting actually do not need much, because the cryptographic part can be fully outsourced to a pre-existing GPG. It should be checked whether GPG_PATH is set (usually to /opt/gnupg/bin/gpg). A keyring must exist or be created,

The only tricky thing that comes to my mind is the handling of the passphrase. As we cannot ask the admin to enter the passphrase each and every time, we must store it somewhere, which opens a security risk of it getting compromised. So admins should be advised that they create a key and passphrase that can be easily exchanged if compromised. Admins shall be advised to not use their (or someone else's) personal keys for this purpose under ANY circumstance! For comfort, the revoking of the old key could become a Tiki feature somewhere.

I found the other day a chat that looks like is no more on develpment and is used to chat over irc (nice way to chat) is named Eteria IRC and u can find it at sourceforge (http://eirc.sourceforge.net/)

Might this be usefull to change the chat (that in my opinion) that does not work right.

I post this cuz the few times i used the tiki's chat module gave me a few problems with cpu usage and db's saturation

Hope u find this usefull for new vers for the tiki's chat module.

When I first met Tikiwiki, I was looking for only a wiki program. The translating for page (multilingual) feature of Tikiwiki made me to choose it.

But I always wonder: does Tikiwiki really need to have so many features ?

We all know that multi-features software is more complicated for developers as well as users than single-feature software. For example, Tikiwiki has a forum built-in, do you think this forum is better than phpBB3 ? Tikiwiki also has an article feature, do you think this feature is better than Joomla! CMS ?

At present, I have a website built with Joomla, I want to add a new wiki section, but Joomla has no wiki component. In fact, I think we should combine these best softwares together, not re-create the wheel. Joomla doesn't need to build a new wiki component if we can integrate Tikiwiki with it. In fact, this integration only needs at least one function: synchronize the users so they can login in to Tikiwiki without register twice.

I should inform you that Joomla! will be the most popular CMS soon, so I hope the Tikiwiki team take some time to consider this integration suggestion.

Thanks.

We would like to unify the search and find boxes on our site into a single module with a text box and Ajax auto-suggest for Wiki page names. If something that had no auto-suggestions were typed, it would do a full text search.

This is similar to MediaWiki. The current interface confuses even software developers.

We would be open to hiring a consultant and contributing the resulting module back to the TikiWiki project.

http://fotonotes.net/
http://wikifarm.koumbit.net/wikigraphe
http://kryogenix.org/code/browser/annimg/annimg.html



A nice usage example:
http://flickr.com/photos/36381329@N00/2190723280/

Google Maps integration is an excellent feature. It would be helpful to provide [http://openlayers.org/|OpenLayers] as as an alternative.

There's a Gedcom viewer (for Genealogy researchers) that's called PhpGedView (www.phpgedview.net) that looks like a completely awesome online family tree viewer/updater. Looks really well done. There is already a module written for it for PhpNuke, and I think it would be pretty cool if a module was written to interface it with TikiWiki.

((doc:Site identity)) is great because it permits quite a bit of customization without modifying any files. Everything is cleanly kept in the database for easy upgrades.

However, it's not immediately easy to know which zone is for what. Top & bottom bar could have an edit button, so we can edit zones in context.

As an example, ((doc:Interactive translation)) is great because we are in context.

{syntax type="tiki" editor="plain"}
Because if you are good in English, it's not immediately obvious what is translated vs needs to be translated.

Any unstranslated string should be seen in a fraction of a second

This is a feature request for trunk
Edit: {sign user="Bsfez" datetime="2017-03-09T10:08:17+00:00"}
To activate the interactive translation : Admin -> i18n -> enable Multilingual, enable Use database for translation.

In the admin menu: Edit Language -> Toggle interactive translation ON.
Go to a page, at the top of the display you’ll have a switch to turn to start translation.

https://github.com/vasturiano/3d-force-graph is the source of possible 3D directed graphs. It would be interesting to have a plugin that allows tracker data to be represented as a 3D interactive graph.

If we had this, we'd use it on http://dev.tikiwiki.org

The Trac Repository Browser:
http://trac.edgewall.org/wiki/TracBrowser

Let's coordinate here: ((Repository Browser)) and ((Code Review))

There are places Tiki ask to confirm "an" action but the action is not stated.
User should be told "what" is to be confirmed.

Here a video from Calendar, delete event.
{file type="gallery" fileId="1696" showicon="y"}

When inserting an 'internal link' the objects offered are limited to Wiki objects only. (WYSIWYG editor). It would be good to have other objects included also.

{syntax type="tiki" editor="plain"}
At tiki-admin.php?page=login admin can set "CAPTCHA questions and answers".

A question with a single answer.
-+What is the capital of France:Paris+-

However this is fine for ===unique=== language Tikis.
If you use French+English+German you should be able to ask the question and have an answer depending on the language displayed.

When a user is banned in the master site, he should also be banned on slave sites.

This could be an option, but general banning is OK too.

((doc:InterTiki)) permits to share login, preferences and groups between various Tiki sites.

We need the Sister Wiki too!
http://www.wikimatrix.org/wiki/feature:SisterWiki
Continue discussion here: ((Sister Wiki))

((doc:backlinks)) are very cool. But what about backlinks from other sites?

We could use list from:
http://doc.tiki.org/External+Wikis


Related:
[wish2086|Backlinks between trackers and wiki pages (and maybe forums)]
[wish1768|Tracker plugin to get title and make link to tracker item]

After seeing the pitiful state of the German localization, I propose a new feature:

Introduce an upload function on the I18N page (to tiki.org) to upload one's custom.php '''to tiki.org''.

This will create the need of a target on tiki.org that keeps record of uploads, the Tiki versions and language settings the custom.php was created for, and (optionally) contact information or a tiki.org account name.

Intended purpose: Introduce new localization strings for new Tiki features into the language in question's language.php file faster than before, thus reducing the effective "age" of language.php delivered with new version releases. Users (admins) detecting untranslated parts would translate them locally and then share this information with the community.

That will create the need that a list of people is kept with proficiency in that language, because such uploads need to be peer reviewed before consolidating them into a language's language.php file. Important to prevent spam, abuse or illegal or copyrighted content or "edit wars" (groups of people constantly editing back and forth parts that they cannot agree on a translation. Wikipedia is an example of such edit wars...

In tables
tiki_comments, tiki_history, tiki_pages, tiki_tags tiki_user_voting
the column IP is too short (varchar 15) for IPv6 logging

In tables
tiki_actionlog, tiki_download, tiki_logs the column IP is very big (too big ?) varing from 39 to 200 char . In tiki_download the IP cloumn is in UPPERCASE (may be problem with some Mysql installation)

In tables
tiki_banning
the IP is split in three columns . so we can't bann an IPv6

Currently, the Banning System interface (tiki-admin_banning.php) only allows IPv4-format addresses to be specified for matching purposes.

I believe this should be updated when convenient to enable IPv6 addresses to be specified, either as a new field ("IPv6 Regex Matching", with the existing field renamed to "IPv4 Regex Matching") or as a single field that allows both.

It appears from documentation that support for IPv6 in System Administration tables was part of the [https://doc.tiki.org/Tiki8#IPv6|Tiki 8 release]. Assuming I understand that correctly, this request should only require interface changes to be made.

If you try to name a page starting with "tiki wiki" (dash for space) tiki will see this as an action and refuse to comply.

IE: I tried "tiki wiki help" (spaces are replaced by dashes) and got the following error"
~pp~Action not found (help in wiki) (404)~/pp~

That’s a bit... ?

The "Location" item in a calendar event's information accepts only plain text. Since meetings are often online, it would be nice if the location could be a working link. A URL can be input, but it isn't clickable. Being able to use wiki syntax (or Markdown?) would be easiest for the admin.

By the way, the form layout is messed up for this item. The label and information should be inline (side by side) like the other items, but the information is on the next line instead.

It is not possible using the HTML plugin or the wiki syntax to have bootstrap modals as explained at : https://getbootstrap.com/docs/4.0/components/modal/

The page turn black/faded and the modal is displayed below the modal-backdrop (without the modal id).

Note: I have the feeling it was possible in the past (19, 20, 21). May be it is a recent change that has been merged into Tiki 21.

{syntax type="tiki" editor="plain"}
A user with the right perms access to the Wiki list pages (tiki-listpages) and there can "copy" a page to a new page. (it should be called "duplicate" IMO)

The same user should be able to do it from a page itself with an item in the "More" or the "wiki actions bar" dropdown.

{syntax type="tiki" editor="plain"}
As the title says, it should be possible to use the Tiki console (console.php) to empty any tiki logs.
That would ease and even allow automatisation of maintenance operations.