Category: Feature request

Currently, the $page and $description variables are available only for content displayed as Wiki Pages. Coding modules to extract similar information from other pages that may be displayed has to be done on a case by case basis.

Actually to have the plugin listExecute action initiate by a cron job you have to use curl, send user (admin) credentials and use http(s) authentification which is not very safe.

{CODE()}curl -u admin:adminpassword "http://yourtiki.com/YourActionPage" --form "list_action=ActionName" --form "objects~0=ALL" {CODE}

It would be nice to to have a console task being able to execute listexecute actions on a particular page avoiding unsafe communications.

In the console.php translation:getstrings it is possible to use the "basedir" argument to set the directory from where you want to get the string (or so it seems). However you can only use it inside a Tiki root directory or at least a directory that contain a /lang/yourtargetlanguage directory. (ie: lang/en/)

See: lib/language/GetStrings.php
Line 171 ~pp~if (! file_exists($this->baseDir . '/lang/' . $lang)) {~/pp~

Else it throw an error "Invalid language code."

There should be a better documentation for this or a mechanism to ask if the user want to create the "missing" directory in the basedir.
(use case: getting strings of smarty template in themes/templates or inside a specific theme: themes/Bernard/templates)

It is rare that editors are able to edit and save a single session to create, improve or edit a Wiki page.

In some case you even start something and add relevant information for the session (Describe the change you made) or you forgot to add it. :)

It would be useful to:
# To able to edit the history session description
# To have a way to consolidate editing sessions (grouping them)
## Be able to name and edit the sessions (group) description independently with the single session description

Beside the basic we can have a bit of improvement (permissions + options) that would
* Allow super users (Admin or Editors) to use the new feature on all sessions.
* Allow the contributors to use the feature only on his own sessions.
* Contributors can edit history sessions for the same day/time duration sessions.

Consolidate menu types as just Bootstrap menus. That is, remove suckerfish and legacy - neither Bootstrap nor suckerfish - menus. Then add Smartmenus ([https://www.smartmenus.org/]) to enhance/extend Bootstrap menus to regain features lost by the removal of suckerfish menus.

UPDATE: Smartmenus feature has been added to branch 19 and trunk and will be configured and bug-fixed hopefully before the release of Tiki 19, or soon thereafter. The feature is optional of course and is marked as experimental for now.

TODO: resolve any issues in Smartmenus integration in Tiki. Longer term, evaluate removing CSS menus (suckerfish/superfish menus) when it's determined that Smartmenus makes them redundant.

If the content of a remarksbox __which is part of a list wiki syntax__ contains a line (carriage return) the part below it is displayed outside the remarksbox.

{img type="fileId" fileId="1257" thumb="box" desc="Plugin content"}

{img fileId="1258" thumb="box" desc="Plugin display"}

To use Tiki as a real content management system where people can add or change wiki pages securely, it will be a feature, if they (compared to mediawiki or wikipedia) first can store changes or new wiki pages as a draft. A chief editor checks it before it will be published. If it is possible to add this feature, I promise there is no reason left to choose mediawiki as a software.

The process could be:
1. somebody changes content in a wiki page or adds a new wiki page. Chenges will not be visible to everybody but the admin and the chef editor.
2. admin and chief editor will be informed about changes automatically
3. admin or chief editor check the content
4. if admin or chief edito agree they will publish the changes
5. if admin or chief editor do not agree they will not publish it and contact the editopr.

I am creating a huge portal with tiki as an alternative to wikipedia. Unfortunately I found out too late that this feature is missing. I can imagine the usability of tiki will be increased tremendously if this feature will bne available.

Let's follow the progress on this:
http://intranetblog.blogware.com/blog/_archives/2008/9/25/3900479.html

See also: ((CMIS))

Let's follow the progress on this:
http://intranetblog.blogware.com/blog/_archives/2008/9/25/3900479.html

See also: ((CMIS))

It should be at the very least possible to add content templates where the cursor is, like ((quicktags)).

On our Tiki Roundtable Meeting page there is a lot of redundancy task to manage the information.

One of them, at https://tiki.org/Roundtable-Meeting-2020-05 we have the convene plugin (people that voted to decide the time of a meeting based on their availability) and we have a list of confirmed people.

While it is not 100% the same, it would be nice and look alike most of the similar tools to have the "confirmed" list directly populated from the convene list.

This would be optional (a plugin parameter) to have it displayed.

We could extend it (like most calendar tools, including Tiki calendar) to have 3 options:
Coming, Interested, Not coming. (each one being displayable or not).

convene plugin: prevent the user to add default info (Add or Add user string) instead of the real username or a different string

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09

The cookie consent mechanism has this bold claim:

__"Complies with EU Privacy and Electronic Communications Regulations."__

First of all, let me express my thanks that someone has undertaken the task of creating a feature that at least tries to adhere to laws and regulations. Many IT systems do not even have that.

But the bold claim is only partially fulfilled. You ''can'' make cookie consent compliant with regulations, but it does not tell you how. And some defaults are ''not'' compliant.

To elaborate:
There is an option "Cookie consent disabled" with description
"Do not give the option to refuse cookies but still inform the user about cookie usage.". Enabling this would be a clear breach of regulations. In the European Union every user must be given the right to deny setting cookies. Luckily this one is default off.

This also implies that the setting "Cookie consent alert" with description "Sorry, cookie consent required" and hint "Alert displayed when user tries to access or use a feature requiring cookies." is non-compliant. The user has a right to refuse, and you cannot block his/her access upon that. It is okay if functionality is reduced (like remembering sessions), but you cannot block access.

There is a "Cookie consent question", "Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." with this default text: "I accept cookies from this site.". That's not a question, that's an answer :-)

"Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." Hm, no checkbox? Ask a clear question, one that users can answer binary "Yes" or "No".

The default label for consent is "Continue", which is not compliant. The label must clearly tell an medium level informed user what it does. Therefore it cannot be labelled "Continue". It can be changed, but this is the default.

Also, any kind of consent checkbox must not be preset!

So, I see the spirit of the devs to help admins be compliant, but this needs some brushing up to really enable admins to be on the right side of the law :-)

I see that for some areas outside the EU one might want to be less adherent to EU laws and therefore might want to force users to accept cookies. But a GUI of a function that claims compliance should not encourage that. So either claim this and offer only compliant options or display advice or even alerts when admins click on settings that would make them breach compliance... Or have one checkbox "compliant settings only" or something like that.

Also, inform admins that by law, site admins must inform their users about what kind of personal data is stored, where it is stored, and for how long. Commercial sites must also tell which persons are to be contacted if users want to get a copy of all that data, or who is to be contacted is someone wants that deleted.

I suggest adding country Tanzania and language Swahili.

Will be happy to supply information needed - and the flag graphic.

Create a bash or php script which will convert the old type Tracker rating field to the new one for upgraders (people who upgrade) using this field.
---
We would benefit in the Tiki Community itself since we would re-use all the information added by users over the years to indicate which bugs in the bug tracker are more important to them. It could be a way to review the list of pending bugs by priority according to user's opinion expressed in that rating option. Thanks luci for filling this wish report {sign user="xavi" datetime="2014-09-21T07:04:05+00:00"}

Any robust forum software must have the flexibility to be able to create sub-forums (i.e. a forum within a forum) if needed.

For example, if I wanted to have a general Wiki forum that lists all the PHP-based Wiki software, that would look like so (example screenshot created in phpBB to illustrate):
{img fileId="1333" thumb="box"}

Under __Wiki software__ (which is a forum in its own right), you can see that there are other sub-forums. The sub-forums are for specific discussions about those technologies, but the more general __Wiki software__ is to discuss

* Wiki software in general
* anything not to do with the specific Wiki technologies listed, or
* a Wiki technology that has not been listed (such as, for example, an emerging one)


So that, by clicking on the __Wiki software__ forum, I would be presented with the underlying Wiki forums, but I would also see a list of topics associated with the general __Wiki software__ forum as described above.

===__Why is it needed?__===
Without this functionality forum administrators using Tiki for their forum are forced to use workarounds such as having to add another forum called "Other" that is meant to be a catch-all for anything that is not defined by the existing forums, such as this
{img fileId="1332" thumb="box"}

and if you had multiple forums, it would result in each forum having an "Other" entry, which is not very pretty.


This has been discussed with Marc Laporte and work should begin shortly.

Please create a new language for Tiki, a pseudo language which I would call "generic". Pseudo because it doesn't contain real language, but a "dummy" translation that gets automatically created by tools like I have introduced in the "Create a tool to" request, which extracts everything in tra() etc. clauses found in .php, .tpl or .js source code, thrown into an associative array to be used as language.php + language.js.

The keys would be the original English text, as it would be on a "real" translation, the values would be an indicator ("##") - so strings can easily be searched, the file name where the string was found and the line number. Examples can be found in the above mentioned request. This gets structured by single line comments that indicate the full (relative) path to the particular file.

Having this as a "regular" language brings the advantage that every Tiki installation will automatically bear a copy of this generic "translation" readily waiting to be translated by future translators.

These could translate line by line, occasionally looking up the source code as indicated in the value part of the associative array, to understand the context.

Translators could also easily do partial-only translations, and when later on untranslated text pops up, that text, although looking really ugly, auto-identifies itself.

Of course the problem remains that sometimes there have to be different translations depending on context, but at the moment Tiki's tra() is completely blind for context, but rectifying this is a bigger project of its own.

Create a profile for an improved Issue Tracker (with linked trackers) using the latest improvements in 14x

See this discussion:
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2015-03-17,Tue&sel=180#l176]

As reported in the ((cc)) page, luci joined the team adding a profile to use his enhancements for social networking, so that they can be used in the use case of Barter networks. ( http://intercanvis.net , etc.)

Tiki Wiki is a content management system. And it can be used to distribute text (but also images, music etc.) to the world.

In Germany, there is no copyright as it exists in the US. Instead, authors have inalienable rights to their works (which cannot be sold or transferred) and for the usage royalties apply.

There is a system of collecting those royalties like VG Wort. If a publishing house reprints text that are declared by the author, publishers pay to VG Wort, they pool all those royalties and pay their members on the basis of the amount published by an author.

For several years now, VG Wort has a system for online texts (METIS). In order to participate, web sites must include "count marks" together with the texts. The author requests (personal) count pixels from VG Wort, and the website must be programmed so that it deliveres those pixels.

In essence, such a count pixel is just an img loaded from VG Wort's servers, a transparent GIF with 1x1 pixels in size. The author gets them in form of HTML lines like this, for example:

{CODE(Colors="TikI")}
<img src="http://vg08.met.vgwort.de/na/e1c16c290fc545d8809d5990b2295aa6" width="1" height="1" alt="">
{CODE}

There is one specific pixel per text, not per author.

It would make things vastly easier if Tiki could automate the process. Pixels get handed out to authors either als a PDF or as a spreadsheet table (CSV...).

A system could be devised where a Tiki user would upload such a CSV, and a plugin could be integrated into a content page (article or wiki). Less sophisticated, the user would indicate a "text ID" to identify the text. A more sophisticated system would, when the plugin gets called, look up if the calling content already has a pixel assigned, and if not, assign one and track the relationship of pixels with contents and then playout the respective pixel alongside with the content.

This system could also inform the user if the amount of pixels is less than the amount needed by current online content and create nice reports :-)

Systems for collecting royalties ("copyright collectives") exist in every country, so this would not only be useful for German Tiki users, but for practically everyone that shells out copyrighted texts larger than 2K...

https://en.wikipedia.org/wiki/Copyright_collective

Creating a translation of Tiki Wiki is a really arduous task, more like a project (I have spent more than half a month already, almost fulltime).

No one will want to do this more than once, at least I don't. The problem is, that in order to render a good translation, you have to see a text in it's context. The task is so tremendously labour intensive, because you have to backtrack clicking everything, activating everything, then deactivating everything, trying to provoke all errors etc. pp. et. al.

Now comes the problem of Tiki improvements. With every new release of Tiki, from the smallest bugfix to the biggest new release of a LTS possibly comes new text. And even correcting a single character that was part of a typo immediately leads to the translation vanishing into thin air because the pattern matching of tra() won't catch it any longer. The translation remains in the language file, but is never displayed again.

So everything will have to be re-checked., time and again.

Since Tiki Wiki does not have one file of text that resides in constants, you cannot simply generate a diff to see what has changed, and thus needs new (or altered) translations.

Therefore a tool would be necessary that extracts all text to be displayed. That tool could then also look up if there are pre-existing translations of those strings, and present them, too. As a side effect, such a tool could help developers to guard their code against strings NOT passed into tra() or tr (which makes translating them impossible).

In the first stage, such a tool could simply produce one file as output, in later development could be interactive. Such a tool would be a necessry prerequiste for version advancement of Tiki, because without it, all (!) translations are rendered into "status unknown" with any change of code.

Side remark: Such a tool does not necessarily have to be part of Tiki. It could make development easier it at first it would be stand-alone.

{syntax type="tiki" editor="plain"}
I propose that a Tracker field type UUID is introduced. This field would - similar to the autoincrement field - create a universally unique identifier (UUID) https://en.wikipedia.org/wiki/Universally_unique_identifier for every item while it is created or imported and will not change after creation.

With this field it will be easier to connect Tiki Trackers to other systems to exchange data (e.g. be able to push changed data sets from external databases). UUIDs are also common in systems that use calendars and contacts (CalDAV, CardDAV) to be able to identify data sets and avoid data duplication.

php: https://www.php.net/manual/en/function.uniqid.php

In my tiki installation I'have eabled i18n plugin in order to be able to handle gracefully translations; however, since in my enterprise there is a main language and all new pages will surely be created in that very language, I'd like to avoid to have to select the page language every time I create a new page (it is considered a waste of time).

In particular I think an option could be added that, If enabled, causes new pages to have the user's language as page language.

Thank you for your attenction

I have stumbled upon a problem when a feature (especially Hotwords) is enabled it creates lot of issues incorrectly parsing the content of Wiki pages and other parts of Tiki where wiki or smarty syntax is involved resulting in links inside rendered HTML attributes or WSODs. So here is my wish:

It would be super useful to have a plugin which would prevent some enabled features auto-parsing or allow parsing of its body depending on params, something like:

__The next example would prevent (ignore) parsing of the Hotwords and CamelCase WikiWords in the plugin body.__

{CODE()}
{PARSE(ignore="feature_hotwords:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

__The next example would allow only parsing of Wiki syntax and WikiWords and nothing else in the plugin body.__

{CODE()}
{PARSE(only="wiki_syntax:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

Other candidates for the "ignore" and "only" params:
feature_wiki_allowhtml
feature_autolinks
feature_wiki_argvariable
feature_wiki_paragraph_formatting
smarty_syntax
wiki_plugins (meaning all wiki plugins)
wikiplugin_div (meaning specified wikiplugin)
etc.

I think it would be useful also for the LTS versions.

Anybody takes the challenge ?

{sign user="luci" datetime="2013-12-12T20:48:49+00:00"}

If permission is granted to view a tracker then tracker history can be seen (through category or direct permission)

History should be a kind of "editors / admins" privilege.
Creating a tiki_view_tracker_history permission would give more flexibility and I believe it is not big task.