Category: Feature request

Please add a (small) timeout to the popup box that is launched on mouseover that contains user info, avatar etc.

Or add a mouseout that kills the popup, which would even be better IMHO.

Reason: If you navigate "classic style", i.e. with a mouse, over sites like dev.tiki.org, you constantly mouseover peoples' user info, and this means you have to stop in your mouse movement and go back to the info that caused the popup, which in long lists might take a while, and not before you found the source will it go away... So this behaviour blocks you in your tracks...

Thanks alot!

The list of MIME types that Tiki supports is missing text/x-uri and text/uri-list (RFC 2483 Section 5).

x-uri could also be opened (in a new window), if a user clicks on such a file (basically a text file, which is why currently it gets classified as text/plain.

Whoever designed the classic colorful pseudo-3D icons for the control panel, could you please add those icons that by now are missing and therefore fall back to the flat and b/w icons? Those are user prefs, printing (that seems to exist already, just not embedded correctly?), packets and RTC.

Thanks alot!
Hman

There are several ways how a visitor of a Tiki could pay for goods and/or services, but Tiki supports almost none of them (Paypal is the only internationally accepted solution offered).

Besides credit cards, which Tiki does not support, several national solutions exist (that Tiki doesn't support either). Most of them are proprietary API, every bank has it's own. From the European Payment Initiative Council comes a new standard: SEPA request to pay.

It's a standardized way that streamlines the process. The user doesn't have to transfer money by having to open up his/her online banking, entering the very long (and thus error prone) IBAN, and the Tiki doesn't have to deal with differing APIs for different banks.

SEPA request to pay works like this: When the shop requests payment, this is being transferred via SEPA request to pay to the user's bank, which adds the request to the homebanking of that user, so the user can confirm the payment within the trusted environment of his/her homebanking, an error free and trusted way to deal with payments. From the Tiki point of view, the unified specification is a big plus: Only one code base needed...

The standard can be found at this [https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2018-05/EPC069-12%20v2.1%20Quick%20Response%20Code%20-%20Guidelines%20to%20Enable%20the%20Data%20Capture%20for%20the%20Initiation%20of%20a%20SCT.pdf|link], the homepage of SEPA request is [https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/sepa-request-pay-scheme].

Please add a feature to Tiki to automatically sort marked content. And please use it on tiki-admin.php, because due to the translation, the list of plugins is__totally__ ill-sorted, making the use much harder than necessary. The same goes for permissions...

Only an automated sorting would automatically apply to every translation, and would not have to be redone after changes....

Thanks

When you display articles using the module articles (http://doc.tiki.org/Module-articles) the output gets alphabetically sorted by topic.

For several use cases it would be desirable if more control over the output be possible, like sorting by alternative fields (date/time of publication or expiry), or reverse sorting order, or some other even deeper sorting options.

To give an example:
When you use articles to show hints for upcoming TV shows, you will have date, time, channel and program name in the topic. Unless you are in Japan sorting alphabetically by a field starting with a date will NOT yield the desired sorting order.

In continental Europe dates start with the tens of the day of month, leading to the ones, then go on with the tens of the month itself, and so on. This will lead to a first of July being before a February 28th..

In Japan, dates begin with millenia, followed by centuries, and so on, thereby providing correct order through alphabetical sorting. But in UK and USA you run into the same problem once your dates start with spelled out months (resulting in April being the first).

As my corrected, amended, updated version of the German localization steadily grows, the need arises that subcategories of German get their own I18N branches, so that they - when they edit their very own custom.php and might propose this to the community - do not change wordings of what is called "High German", in ISO terms "de.de".

The most common subcategories of German are Austrian German and Swiss German, in ISO: de.at and de.ch. Especially Swiss German really needs its sub-category, because Swiss German greatly differs in the spelling of many words, because Swiss German is lacking one letter of the alphabet, the ligature of 's' and 'z', which is 'ß'. Some US developers have called it the "B looking character", and its glyph resembles a greek beta, but it isn't. Called an "Eszett" or "sharp S", and pronounced as IPA: [ˈʃaɐ̯fəs ˈʔɛs], [ˈʃaːfəs ˈʔɛs], in HTML it is {CODE(Colors="Tiki")}ß{CODE}.

Regardless of how you call it, the Swiss don't have it. It simply doesn't exist in Swiss German, therefore all words containing it have a different spelling in Swiss German. https://en.wikipedia.org/wiki/%C3%9F
"ß was encoded by ECMA-94 (1985) at position 223 (hexadecimal DF), inherited by Latin-1 and Unicode (U+00DF ß LATIN SMALL LETTER SHARP S).[6] The HTML entity ß was introduced with HTML 2.0 (1995). The capital variant (U+1E9E ẞ LATIN CAPITAL LETTER SHARP S) was introduced by ISO 10646 in 2008."

Several Tiki syntax plugins declare a body, for example the REMARKSBOX plugin. The plugin call edition windows offer to fill or modify that body, but do not offer toolbars to assist in doing so.

It would help editors to add toolbars for plugins which declare a body which takes text that is parsed by Tiki.

{syntax type="tiki" editor="plain"}
Please rename the start button of the wizards.

The reason is that the translation function tra() is completely ignorant of context. And at least in German the problem arises that the imperative of starting, that "start" means, is different from the noun that marks the beginning of a calendar event. In English both are "start", but not in German.

In German that is "Beginn" (as with all nouns with upper case 'b'), while the imperative of starting would be "beginne" (as with all verbs with lower case 'b'), or in the preferred more professional looking passive construction "beginnen". The verb "starten" also exists, with that it would either be "starten" or "starte", but this arises the problem that if I rename one, I must as a consequence also rename the other. It is not possible to correctly translate both!

Because tra() is igorant of context... So I have to make a decision which wrong translation does lesser damage... So please find a different string for "Start". Preferrably, since it might take aeons before tra() becomes context sensitive, one that carries the context inside the string itself, like "start wizard". This should be a recommendation FOR ALL STRINGS throughout Tiki...

While searching for a string that I did not find in Tiki's source code, I came across /lib/wiki-plugins/wikiplugin_registermemberpayment.php. It does contain Javascript! And quite a lot. Almost half of the file is after the statement
{CODE(Colors="Tiki")}
$headerlib->add_jq_onready(<<<JS
{CODE}

My request for the devs would be: If you have full-fledged Javascript programs, please separate them off into their own .js files. The reason is that PHP's tokenizer will not parse Javascript behind a <<< statement, which is token T_START_HEREDOC (which is eventually ended in a T_END_HEREDOC), and a call to tr() will be inside a huge block of T_ENCAPSED_AND_WHITESPACE, and not in one T_STRING (with the string to be translated in a T_CONSTANT_ENCAPSED_STRING)...

Thanks from your fellow translator
hman

Plugin Add to Cart is used in conjunction with a tracker item (the product).

In the tracker item we already have price and description however the Plugin Add to Cart need those field to be set manually. Extra maintenance and... dull :)

The Plugin Add to Cart should be able to use the product information.

A few missing utilities from plugin alias management:
* Rename alias
* Clone / duplicate alias
* Export / import aliases

Also, the edit interface could be nicer:
* Move it to a separate tiki-admin_pluginaliases.php file
* Group all parts of parameters together, e.g.
** documentation
** Simple arguments (or)
** Body arguments (or)
** Composed arguments

Here's a little plugin that allows to easily integrate [https://flattr.com|Flattr] with the wiki. Since this is my first attempt to write a plugin it would be great to review the code (especially since I'm no expert for php).
One thing that would be nice to solve would be the inclusion of the javascript part which should be added into the head-element when the rendered page contains a flattr plugin. I just did that while using a simple switch. Really ugly but it works for me.

Bye

See the 3 slides starting here at minute 16' 48'':
http://recordings.blindsidenetworks.com/bigbluebutton/a71a9df7c98b845ae41553a527a5e7c03a69fe27-1431112418160/presentation/index.html?t=16m48s

New params are added to the api, that could be exposed to tiki, so that they are shown at the description list of the bbb meetings recorded for that channel, etc.

((Plugin alias)) which I am considering renaming __Plugin builder__ permits some amazing things.

((Backlinks)) can be cool for dynamic & efficient information organization.


How can we have the two together?

Perhaps an alias of the REDIRECT plugin which includes semantic wiki link "alias" between the two pages...

More on this later...

I suggest a plugin/mod configuration tool, where Admins can specify the __name of a plugin__ and a __list of parameters__ to be provided to the plugin. There is no way for Administrators to configure plugins. Every incantation of a plugin must specify all needed information. A configuration tool would allow control over all invocations of a plugin, or specifying non-public configuration details.

I believe that at present adding configuration options for a plugin requires the plugin to include code for admin pages. This tool would be available for use with any plugin with chooses to look for the passed parameters.

For example, a SHOWIMAGE plugin's configuration parameters could specify the default (or mandatory) image source to use, the default image size, and decoration options. By altering the configuration parameters the appearance of all invocations would be changed.

Add a new param for how long to extend the voting time if there's a tie - would have to make sure it's before the first possible time by "a bit"

The new plugin editor in v3 is cool

It makes it easier to fill in the blanks.

It would be nice to know which choices are the defaults, so I know that I don't need to fill in if it's what I want.

Ex.: Iframe plugin has Scrolling options of yes|no|auto

But which is the default?

Adding a option to quick upload a file in the LIST plugin

This would allow low tech people to easily add a file to a galery

TW5.0beta1
http://dev.tikiwiki.org/Hello+World#To_create_a_new_plugin seems to be outdated. the plugin cannot be installed i the prescribed way.
By the time a php plugin file with a "wikiplugin_" prefix is saved to the lib/wiki-plugins folder, the Administration/Editing, plugins gives an empty pages. So do all the pages containing the new wiki plugin. Nothing is listed as a plug-in to be installed.

Two smaller corrections
* The sample code containing an extra '}' (last but one in wikiplugin_helloworld_info())
* The name to save the plugin must be lib/wiki-plugins/wikiplugin_helloworld.php instead of lib/wiki-plugins/wikiplugin-helloworld.php.

Once a tracker field is set as title, it turns to be a link to the tracker item.

In certain (but several) condition when using a plugin List, ListExecute or the plugin Map this field(link) will be inserted into another link and then the display will be broken and it will show code instead of item link. (a link within a link is bad)
Check the instance.

First problem: There is nothing that can tells you from where come the issue and only after several experience and Jonny’s help we found out what it was. Anyone else (and new comers) won't have any idea why the display is broken.

Second problem: __It is a pain !__

Workaround are messy; you have to duplicate fields (Name and Title), title has to be set to a different field (like Id) and start confusion or worst, previous setting that were ok turn to be broken.

Would it be possible to have some kind of strip there ?
(if the value is already a link, strip <a ...). There is a smarty function for that "Strip" couldn't it be easily set ?

If the admin setup a plugin List (ListExecute, CsutomSearch) with a Wiki Variable (IE: {filter field="tracker_field_userUsername" content="{{user}}"}) BUT "Wiki Argument Variables" is not enabled he will see : No results for query.

The admin should be warned he is trying to use a feature that is not enabled when saving the page.

It is not possible to use the plugin ListExecute to send an email that contain a tracker field type file. If you do so it will send different kind of un-useable code.

There is a debate about inserting a file in an email and maybe this will be fixed/changed one day. In the meantime it will be cleaner to display proper error or warning something like "it is not possible..."

The ultimate feature of Amazon and all the e-commerce shopcart systems is the one known as "Customers who bought this item also bought .." or "were also interessted in ..".
The feature would show objects or items that were viewed or bought by previous users in conjunction with the actual item or object.

Idea:
Applied for tiki a new plugin "Relation By Views" would allow to list related wiki pages (or even other objects) in a page likewise to existing backlinks and alias plugins as well as semantic links.
Though, the information is based on previous view counts / his of wiki pages (or other objects) that have been hit by users wihtin the same session as the actual wiki page / object.

The enhancement is obvious: we would make a step further to get implicit relations between pages / objects based on user behaviour.
Just as the advantage in ecommerce is crossselling, we would provide cross-links and encourage readers to have a look to further pages / objects.
In regard to enhancements of the basic shopping cart feature in Tiki 5, this plugin could even be used as a real "customers were also interessted in" feature.

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.