Category: Feature request

Currently (2.x), admins can configure new registrations to select specific groups during registration. I would like to request the following enhancments:

# Specify a default group. Currently, there is no default. I want to be able to configure a default group (i.e., adding checked="checked"...)
#Allow admins to confirm group requests. For example, I want to allow users to ''request'' to join an admin-level group upon registration, but I want the current admin to be able to verify this, before the user gets admin access.

Plugin TrackerIf doesn't seem to accept nesting so far, and we need it to allow customization of the interface to edit data with Pretty Trackers.

*If field_1 is A
** if field_2 is not empty, display value of field_2
** if field_3 is not empty, display value of field_3
** if field_4 is not empty, display value of field_4
** ...
* if field_1 is B
** if field_10 is not empty, display value of field_10
** if field_11 is not empty, display value of field_11
** if field_12 is not empty, display value of field_12
** ...

{CODE(ln="1")}
{TRACKERIF(test="(f_1='A')", ignore='n')}
{TRACKERIF(test="(f_2 ='')", ignore='n')} {ELSE} {$f_2|output} {TRACKERIF}
{TRACKERIF(test="(f_3 ='')", ignore='n')} {ELSE} {$f_3|output} {TRACKERIF}
{TRACKERIF(test="(f_4 ='')", ignore='n')} {ELSE} {$f_4|output} {TRACKERIF}
{TRACKERIF}
{TRACKERIF(test="(f_1='B')", ignore='n')}
{TRACKERIF(test="(f_10 ='')", ignore='n')} {ELSE} {$f_10|output} {TRACKERIF}
{TRACKERIF(test="(f_11 ='')", ignore='n')} {ELSE} {$f_11|output} {TRACKERIF}
{TRACKERIF(test="(f_12 ='')", ignore='n')} {ELSE} {$f_12|output} {TRACKERIF}
{TRACKERIF}
{CODE}

When using a user tracker to collect additional information per user during registration process, it would be great if you could specify to include that information in the user popup/mouseover.

The profile feature of Tiki is a really powerful tool, but it could be more flexible in processing user input before applying profiles.
Right now, it is only possible to request string (Input Text) data from the user during applying a profile .
I'm planning to do a really customizable profile, that can be configured via the user request form.
It should be possible to have more supported controls like checkboxes, radio buttons and (single/multi) dropdown selections.
Then these input data should also be used within a condition (IF/ELSE statements) to react on these user input during processing the profile apply.

__Example:__

Show a list of predefined groups an a offer to the admin user.
He can select, what groups are needed and which are then automatically set up by the profile:

[[ ] Group Sales
[[ ] Group Marketing
[[ ] Group Administration

Visuals possibly like:
* list of checkbox (multiple selection)
* radio button group (single selection)
* dropdown (Bootstrap) which can be used with single and multi selection

__Important:__
By having such controls available it is mandatory to be able to use them with conditions (IF/ELSE IF/ELSE) within the YAML code to be able to switch processing on the given selection.

__Further profile related ideas:__
* Secured profile repositories (password required, profile user which can be permitted)
>> Option to hide profile content to public and registered users

This may be 2 bugs:

When you select Admin - External feeds and create a new feed, a blank page is presented after clicking "Save." It appears as though the external feed is saved, though.

Created feeds are not being updated on a schedule, nor are they being updated when the "Refresh" option is clicked. Clicking "Refresh" results in a blank page being displayed.

This has been ((http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=37418&topics_offset=23&topics_sort_mode=lastPost_desc&forumId=4|reported on the forum.))

In tikilib.php, the external link icon is hardcoded:
{CODE(wrap="1",colors="php")} if ($prefs['feature_wiki_ext_icon'] == 'y' && !$options['suppress_icons']) {
$ext_icon = "<img border=\"0\" class=\"externallink\" src=\"img/icons/external_link.gif\" alt=\" (external link)\" />";
}{CODE}

That is not good if you want that icon to be different.
You have to overwrite img/icons/external_link.gif with your own, and remember to re-overwrite it when updated to a new Tiki.

It would be better to either allow the user/admin to give a link to an alternative icon, or even better: put it in CSS, so that it can be overwritten in themes.

A quick fix would be to change line 5806 and line 6245 from this:
{CODE(wrap="1",colors="php")}$ext_icon = "<img border=\"0\" class=\"externallink\" src=\"img/icons/external_link.gif\" alt=\" (external link)\" />";{CODE}
to this:
{CODE(wrap="1",colors="php")}$ext_icon = "<span class=\"externallink\">   </span>";
{CODE}
And then put a CSS class in design.css or other appropriate css file, so that it can be overridden by theme css:
{CODE(wrap="1",colors="css")}.externallink
{
background: url(img/icons/external_link.gif) no-repeat;
}{CODE}

The title for External wiki links in not parsed, for instance
~pp~ ((wp:Link|Title)) ~/pp~
will display __Link__ instead of __Title__

We need this for *.tikiwiki.org as well
{img src=images/code.png}%%% {CODE()}
((dev:EditUIRevamp|Improve the content editing interface))
((dev:AdminUIRevamp|Improve the admin interface))
{CODE}

Say I need to make a link such as:
{img src=images/code.png}%%% {CODE()}
[http://en.wikipedia.org/wiki/Argument_map|Argument map]
{CODE}

I could use an ((doc:external wiki)) link which is like this:

{img src=images/code.png}%%% {CODE()}
((wp:Argument map))
{CODE}

Even nicer would be an image (instead of {img src=img/icons/external_link.gif}) so the visitor knows he'll be sent to Wikipedia.

Also, would need:
*optional title: to explain what this site is about. (ex.: this is a sister community)
*option to open new window
these would be set centrally and you could override.


Perhaps the direction to take is to build with ((doc:plugin alias))

This feature ((doc:External-Wikis)) is very hard to find from the admin control panels and its name doesn't tells what it really does.

It allows to use aliases for external websites set by the admin that will be used and displayed as wiki links.

However, beside the obscure name"External Wikis"... ??‍♂️;

It is not to be found in the Wiki panel tabs.
It is not to be found in the results of the search preferences filter.

You can find it under the admin menu item "Tools"... something this is not IMO.

It is also in the Settings menu (but you don't have access to this menu from the admin area)

---
The setting page displays 2 additional fields compared to the documentation. The inline help doesn't really help to understand the simple mortals what they do:
* Index, [prefix]main, such as tiki_main
* Search as, Leave blank to search using currently active groups.

Someone with knowledge should tell what they are doing.


__In summary, another gem buried in the Tiki preferences that deserves better visibility and documentation.__

In many cases, have extra structured fields in wiki pages would come in handy. Ex.: a glossary of terms may need a field for noun, adjective, etc.

Categories and tags are not in the version history, and it would be clunky anyway.

((doc:Pretty trackers)) are awesome when it's a data centric context. But when the structure emerges from the wiki, it's better to have extra fields to wiki pages.

Please see:
http://developers.facebook.com/connect.php
http://www.sociable.es/en/facebook-connect/

There are many pages within t.o that have spaces. On the other hand, the WikiSyntax historically uses WikiWords. I also see that tiki supports aliases for pages. This led me to the following suggestion:

- Propose to render WikiWords as "Wiki Words" in the page. This makes it easier to read. Obviously this mean one control more ...
- When parsing a page, and there is no page for a specific WikiWord, look for the page 'Wiki Word' (adding a space before each capital).

Advantage : this would allow people coming from other wikis to make links with WikiWords, even for pages like ((Wiki Plugins)), without the need for clumsy parenthesis everywhere.

New fade plugin is cool.
http://doc.tikiwiki.org/PluginFade

#If body is empty, plugin should not be clickable
#However, if there are line breaks in the body, the are no longer in the fade.
#Also, should have a setting, default to y for little icons:
{img src=images/code.png}%%% {CODE()}
[-] [+]
{CODE}

There is some failure to get geolocation from searching an address either manually typing address through tracker field location ui or in the backend with params to get address from other tracker field.
No point selected for that address, even for simple cases that used to work in previous tiki versions.

I failed to produce this with fancytable:
||Item|Amount|Price per item|Total
Apple|3|1|3
Banana|2|3|6
|sum| | 9||

It's a common usecase, Excel solves this with SumProduct.

Or is it actually possible to solve this with the current implementation??

{syntax type="tiki" editor="plain"}
It would be good if modules with the nobox="y" parameter set would automatically be given a "nobox" class, for the benefit of themes that want to style them specifically such as assigning text and link colors. The "no-decorations" parameter already does this, so it might be a model for the changes needed for the "no-box" class. Of couse it's possible for the admin to add the class using the "top class" or other module parameter, but it would be nice if it was automatic.

This is the use case: a Tiki site creates a lot of similar documents (which end up as PDF files) in the form of wiki pages assembled from a combination of included pages and text that is copied from "template" pages and customized. When the pasted section of text is edited for improvement, it would be good to be able to see where that section was copied from in order to improve that page (the base or "template" page) as well.

Maybe this could be done if there was a feature called "CopiedFrom" that, when activated, would print comments before and after the pasted text such as

-+Copied from "Template Page A" start+-
''The copied/pasted content is here.''
-+Copied from "Template Page B" end+-

These comments could be ~np~ ~t c~wiki comments~/t c~ or <!-- HTML comments --> or mPDF {DIV(class="d-print-none")}{DIV} comments ~/np~, depending on the site requirements. I don't know if the comment type needs to be selectable per instance or global at the site.

As this is kind of a rare use case, maybe it could be implemented as a Vue.js widget (just a thought). It would have to have the ability to get the page name or URL where text is selected and copied and print it as indicated where the paste is made.

I have a FAQ with many questions with no organization which can make it difficult to find a particular question (and therefore related answer).

It would be good to be able to prevent wiki pages in a specified category from being listed by this module (last_modif_pages). For example, at the *.tiki.org sites, there are "Archived" and "Retired" categories for wiki pages that have old content, etc. and so are for admin users or registered users only. When a page is edited to be categorized in one of these categories, it is then listed in the module, but this isn't a change that needs to be, or should be, publicized, since the page is being removed from access.

There should be a field in the module parameters like "Don't list pages in these categories", where category names or ids could be input and pages in these categories wouldn't be listed in the module.

{syntax type="tiki" editor="plain"}
As CSS and browsers have gotten more powerful, a page refresh shouldn't be needed to turn on and off fullscreen mode. Compare with the new color mode switch: the change is instant as the browser changes CSS variable values in real time. I think the same could be done to switch the visibility of the peripheral page sections.

Currently, Tiki does not have a feature to lock a specific user account.

Such locks can be essential. E.g. when you created a user account, but the user doesn't use it. For security reasons, you must lock it after a certain grace period. Either automatically or, as a fallback, manually.

Deleting is not a way to do this, because then you delete all preferences, so in order to preserve user preferences, but secure the site, a lock feature is IMHO essential. Admins should have the ability to lock user accounts. Actually this should be a perm of its own "Can lock user accounts", given by default only to members of the Admin group.

As a workaround, an Admin can create a new password (only known by him/her), but I believe a locking mechanism is more elegant. Also it removes the necessity for the user to re-establish his/her password after the lock gets lifted.

In a more sophisticated version, Tiki could inform members of the Admin group if a user that has a lock imposed on his/her account tries to login, that a login attempt was made.

There was a question in the forum (by freeman57) about how to let users use their webcams to record a video to insert in a wiki page, etc. After checking around, I came across a plugin for Wordpress that does this, using Kultura: [http://wordpress.org/extend/plugins/all-in-one-video-pack/]. It would be great if someone could do a Tiki version, or equivalent, of this plugin. There doesn't seem to be any installation needed in the server except for the plugin files.

Actually I think just a subset of what's in the Wordpress plugin would be needed. That plugin includes other video and audio display options along with a TinyMCE install, which wouldn't be needed for Tiki.

This would be a nice additional feature for sites and users and would tie in well with Kultura integration.

When certain high-level events occur where the internet community wants to express protest, switching a website to show it's content on black is an often used measure.

Most of the time, some message will be displayed additional to the content (or instead of the content).

Therefore I like to propose the following be added to the banner feature: Turn the Tiki black.

It involves much labour to rebuild a CSS to reflect this. This could be automated. So flicking a switch on the banner feature might compile the previous CSS to one temporal CSS in which each and every colour gets inverted.

As most Tikis will render text mainly as mostly black letters on (kind of) white, such a colour reversal would automatically yield white on black, and even let contrast unchanged, so no areas that become hard to read will spring up.

And the deactivation is even easier to implement, simply go back to the original CSS.

Caches should be cleared after CSS manipulation, of course.

This should be optional, like the rest.

But beware of:
[wish1697|permission "minor" seems useless on doc.tw.o: registered can't use it even if granted to them]

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.