Category: Feature request

There already is a Wiki that imports GEDCON files into the website.
Since this is open source - could this also be added to Tiki please.

If the content of a issue in the wishlist is big it may hide the title link in the dev dashboard: https://dev.tiki.org/Developer-Dashboard

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

Should not be possible... (truncate ?)

{syntax type="tiki" editor="plain"}
On a wiki page, in the page_actions dropdown there is an menu-item "Edit icons".

The menu-items in the dropdown are related to the wiki page (object_id) but not the "Edit icons" that, once enable, will be set enable for all the wiki pages of the website. This is quite annoying as it is also usually breaking the design.

This "page" action/option should affect the page it is toggled only.

After 20 years no one has a real idea of who is using Tiki and where and users are not effieciently converted into members. Some even struggles to get in contact with other members of the community and it is an active action and sometimes time consuming.

We have no idea of the areas, country or continent where Tiki is used or popular and who, among the power users or consultant will be able to better provide support.

The Tiki ecosystem critically need to regroup, understand where it stand, help its users to find support when needed and be kept in the loop of information.

While we don't want to be intrusive, it is fairly possible to include at the installation process (the page where we talk about the Community) an __optional__ automatic registration on the user (admin email address) to tiki.org. This should include some way to have an area or country information

This will provide better way to be informed about our software popularity, inform our users about Tiki (news, progress, event and updates) as well as help the dozen of users fighting to be registered (or simply moving away) from being new member of the community.


While completing this bug report I found out the following (another proof there are things we are not very good at and we should improve by using such automation):
* https://dev.tiki.org/item8589-Registering-to-tiki-org-register-option-is-barely-visible-at-t-o-on-the-login-box-popup
* https://dev.tiki.org/item8590-Registration-should-be-brought-forward-at-tiki-org-get-involved-page

Subject says it all.

Some great men(women) said great things - and I can't enter their name in addition to their quote!! ;(

Give credit, where credit's due! And I take that very seriously!

{syntax type="tiki" editor="plain"}
The template tiki-print_blog_post.tpl uses the classes posthead for div and span which are not defined...

This is not ended it is good for an alpha version. Not a publish release.

The title or the blog post is then displayed are small...

The title of the blog is not at all displayed
The site name is not at all displayed
The subcomment of the blog at all displayed

__Even Copyright is activated nothing is defined.__

__This print function can't be used.

If you can't print the text of post of a blog which under Copyright the blogs themselves are not usable.__

__The admin of such a site is then not in good conditions when this function is used.__

!The specialization of categories in profiles : major consequence

!!Nature of the problem

Everybody who have developed tikiwiki application that during data structuring and at the end of development (if it exist, not in project management) any category can't be applied to any object.

So if we try an interpretation of this fact it is because the development of categories is a way to structure either a metabase or an implicit complement of database on the objects of tiki.

In project management we will have to connect to new objects and sometimes to create links with external objects (can be defined by URLs). This because the object that are managed into a project can be separated into two classes :
*the objects that are tiki objects and
*the objects that are external (as CAD draw, all physical objects and their definitions managed externally): these object must have an "image" into tiki like a map and his corresponding land, mainly a wiki text with the definition of the object. But in fact others objects can be associated to these external object. So they can be simply a category with a link to a new objects for tiki (see UMLAP meta model that I presents). This new objects is simply able to reference an external object (quite like an URL).

So either in simple tikiwiki application or with project management, categories are in fact quickly linked to some types of objects.

A category will define a way to hierarchically organize blogs or forums, it will be only associated to the corresponding object.
Another for example with a root "Subjects" can classify structures, wiki pages, blogs, calendars etc...

The development of the application or profile then will be associated with a specialization of categories.

!!What's to do to implement this new feature ?
*Add to the definition of a category a multi-select box which allows to define the objects classes to which the category can be linked
*Link a category to a specialized wiki structure which contains the definitions of the categories (the wiki structure is automatically a replication of the category structure)
*For the display of the panel used to define the classification of an object into the categories, the displayed categories must be associated with the class of the object.
*Quite automatically when the list of objects which are associated to the same category is displayed it will contain only the classes associated to the category.

It is not very load as development but I do believe a great enhancement to clarify categories management and use.

Trebly

Maybe some of you will think of this as a "marketinhg" thing, but let's face it : for most users on the Web "wiki" is synonym with "MediaWiki-powered sites that look like wikipedia".

What I propose is to create the theme and tools to facilitate migration of mediawiki powered sites to tikiwiki the (very) easy way : fill a form during install that points to the Mediawiki database, and extract all the info to automagically populate the Tiki. I'm willing to participate, but I do not feel I have the required knowledge at this moment to be able to do something useful in the coding part : I know little to no PHP or MySQL stuff, I even wasn't able to install Tiki properly here (shame on me).

Right now you can set theme control by many type of objects, but not trackers.
For forms to get information from new users, it might be useful to allow using some different and customized theme for them.
A possible solution is using wiki pages (which allow theme control by object), and tracker plugins inside; however this does not work for all tracker fields, so the option to set trackers at theme control by object is still desireable (imo)

You want a Tiki-powered site but none of the bundled themes fit with the look & feel you want for a project? You would like an easy way to generate a style? Me too!

I have a (crazy?) idea for a Tiki CSS generator. Before I explain it, please visit the StrangeBanana:
http://www.strangebanana.com/

Ideal end result would be: 1- submit logo or picture, 2- a corresponding CSS is generated, 3- result can be visualized from demo site and 4- then just use the custom css on your site!


http://themes.tiki.org/TikiThemeGenerator

When users submitt data to a TikiWiki site, there is now workflow included. However this results in active management of a TikiWiki site, for different data entered.

Editors, may receive updates to the site, when you use the notification mechanism, however, there is now way for an editor/administrator to get notifiied by e-mail about other changes to the site, or even worse: notification which need approval, like new links and FAQ entries.

There should definitly be notifications for any submitted data to the site which requires approval to be displayed.

Topic says it all

We have a way of synchronizing the RealName with fields in the ''user tracker''.

It would make a lot of sense to have a similar option for synchronizing the users avatars with a ''file type field'' in the ''user tracker''.

Currently, one can ask for an image of the user at registration or later in the user tracker but if the user's avatar needs to be provided by the user himself/herself.
That's cumbersome and not intuitive.

Example real life use case: The user tracker is used as a company directory, filled by the users' ''official'' photos. Lacking user avatars or asking the users to update their avatar makes no sense since all the work was done already.

The comments sort order has been not great for a long time, possibly ever, i think we default to listing by comment date, but that breaks down if someone replies to an old comment, that one might be in page 2 so we miss new content.

I’ve been reading Reddit for a while now and I think they sort the threads by number of replies, which generally equates to the most interesting and popular ones rising to the top.

Shouldn’t be to hard to add (optionally of course), any volunteers? ?

Image Gallery does not have Tiff support, let alone raw formats! A revamp should include some tool to insert/use metadata from the imaga files.

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

The Changes Wizard shows no mention of Tiki 22.x
Instead the first thing it shows is "__New in Tiki 18 (LTS)__".
A bit embarrassing we have nothing new in Tiki 22.x to show there... (:redface:)

Release Blocker or not? You decide! (:wink:)

It is frequent you have to set a Tiki in a single language that is not english.

However due to the nature of the documentation and the way the information is shared among tiki users it is way much easier to perform admin in english.

Activating multilingual may answer some issues (there are still a few when you are using a non latin language) but it brings a lot of unwanted behavior like displaying to the other users translation information or tools on the wiki page they shouldn’t see.

It would be nice to have a simple option to set language = english for the Administration interface (based on Admins or other Super Users or feature Admin) without activating the multilingual feature.

When a new admin start setting up his Tiki he will likely put his own logo.

However there 0 control on the page or in the code code to limit the logo size but the 1170px width for the first container.
So if the admin pick a high resolution logo, it can use the 1170px width.

Result is not what is expected.
Having the "non power user" user in a situation he have to resize the logo and reupload it is "passé".
We should have some logical limit. (optional, changeable, whatever)

The ((tw:Roundtable Meetings|Tiki Roundtable Meetings)) are to be held __monthly every 3rd Thursday at 14h UTC__. Please make it possible to be able to do this in Tiki.

This should work with recurring events. So people in different time zones will see the event in their time, depending on daylight saving time (DST)

A form anonymous can fill is still very common and used in many website (tracker items, registration and contact form).
We are used to it for so many years that we don't see it, but for others, this is not a good image for Tiki.

On mobile and desktop it really look like unfinished work.
# The buttons colours are wrong:
* Submit should be primary
* Refresh captcha should be secondary
# Width and field should match.

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

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

See: ((Database Redact))

Although it would be nice, this doesn't need to be automatic on a cron job like {wish id=4665}

Amette explained that he copies data to a new database and that he executes various operations on this database.

So in essence, a cloning command is necessary for this. And a clone and upgrade is needed for show.tiki.org

If clone and redact was available on the command line, as a cron job, it could be an extra parameter to a clone command. See: ((Command-line tool|#console.php_clone))

And when we'd become quite confident with our script, we could even make the backups available to the public, like Wikipedia does. This is one more reason why fully automated would be nice.

http://en.wikipedia.org/wiki/Sanitization_(classified_information)

1st use of this new process is to supply redacted copies of tiki.org, doc.tiki.org and dev.tiki.org to Matthieu Hermet to work on NLP with ElasticSearch.

Please see:
http://phplayersmenu.sourceforge.net/example-treemenu.php

With a view source, you will notice
class="phplmselected"


How can we add this to Tiki?


Menu tree built from categories?

Or if the menu compares with current URL? and puts class="phplmselected" if it's a match?

In Tiki we can filter a large quantity of data but our output is limited to screen.
So in some cases the users are displaying a lot of row only to copy them into a different editor or programs.

IE: Someone perform a search, select annually lines with the mouse, copy and paste into Excel.

We discussed during the January 2022 TRM of an idea of an option to export the results of a customSearch into a CSV file or a PDF or to print it (without the pagination of course). We have something similar for the plugin List table output : https://doc.tiki.org/PluginList-output-control-block#Download_CSV_of_Table_Results

We need this for the customSearch plugin and eventually "outside" the table template.

{syntax type="tiki" editor="plain"}
Elasticsearch enhanced version supports 30+ languages including:
European: English, German, French, Spanish, Italian, Portuguese, Dutch, Russian, Norwegian, Swedish, Finnish, Danish
Middle Eastern: Arabic, Turkish, Persian
Asian: Chinese, Japanese, Korean, Thai
Eastern European: Bulgarian, Czech, Hungarian, Romanian, Lithuanian, Latvian

Tiki search using Elasticsearch engine work with English stemmer.
See private function getIndexDefinition() at : lib/core/Search/Elastic/Index.php

Due to this, search results for Tiki Wiki website using other languages like German doesn't output expected results.
With an item title "Diplomatie"
"Diplomat" or "Diplomatie " (with an extra space) are found while "Diplomatie" is not found.

Tiki should be able to use the correct stemmer based on the language content.
There should be an automatic language detection to select the relevant stemmer using the $prefs['language'] (the current site language) with a manual override using a new pref in the Search control Panel : $prefs['unified_search_language'] (if you want search language different from site language)

Fallback: Defaults to English if nothing is set

For Multilingual Sites we may need to detect language per document.