Category: Feature request

I think what's needed is a Gallery of "Tiki Sites in a Box". In other words, Tiki sites that are preconfigured to meet a particular kind of needs. The needs should be defined not in terms of features, but in terms of GOALS of the end user or organisation.

This could be a list of descriptions like this:

- I want a site to enable collaboration inside my organisation.
- I want a site to broadcast my ideas to the world and allow people to add to them and comment on them.
- I want a site that will act as an open knowledge base on a particular topic.
- etc...

Each of these could point to an example which would be a "fake" site that could act as a sandbox. People could go to this fake site, play around with it (but not reconfigure it), to see if it's what they are looking for.

This would allow easy single click configuration of Tiki. The user would simply click on one of the items in the Gallery, and the Tiki site would be configured accordingly.

One issue is: what happens if the user choose wrong and later wants to switch to a different model? I guess if no content has been created in the site it's fine, but what if content has already been created and that content is somewhat incompatible with the new model that the user is choosing?


Related:
*[tiki-view_tracker_item.php?itemId=1513|OpenSourceCMS type demo to test/develop and show off profiles]
*[http://info.tikiwiki.org/Use+Cases|Use Cases]

__Moving discussion of this wish to ((Profile Manager))__

The survey interface has been left behind and should be upgraded to bootstrap 4 standards.
https://surveyjs.io/Examples/Library/?id=bootstrap-material-theme&platform=jQuery&theme=modern
https://webdesignerwall.com/wdw-snippet/bootstrap-survey
http://www.prepbootstrap.com/bootstrap-template/bootstrap-survey

Tiki tabs are a nifty feature to make a page cleaner / simpler.

For example for trackers, we have:

View / Comments / Attachments/ Edit

However, I want to be able to link directly to "edit" so someone could be invited to edit their user tracker or add a bug or add a calendar item.

I would like something like this:
tiki-view_tracker_item.php?trackerId=5&itemId=978#view
tiki-view_tracker_item.php?trackerId=5&itemId=978#edit


There seems to be the start of something:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=980&show=edit

Tiki offers a data type "email adress". This does basic syntax checking. Actually, it is VERY basic. It only checks is there is an at sign (@) in the string. A little bit more might be wished for, in order to reduce spam and clutter from anonymous users.

IMHO it should also be checked if a domain name is entered. So it should be detected whether there is a full stop after the at sign, and at minimum one letter before and after the full stop.

Now Tiki accepts a@b, IMHO it should at least check whether it is a@b.c (I would not recommend to check acutal TLDs, because they change too often nowadays.

Tiki trackers are great for a bug tracker, as we are dogfooding here.

But what about for a "help desk" setting? -> Private requests from many customers to one company.

Imagine a hosting company. They may have public forums & trackers. But they also have a place where customers can ask direct support requests. And only the customer and the company can follow this tracker.

There is a way for people to just modify their own tracker. But this is more for a user profile, than a series of support requests.
http://doc.tikiwiki.org/tiki-index.php?page_ref_id=3204

You can also give permission to add a tracker item but not view. But they can't modify existing tracker items. (like sending in a black hole)

If we want people to submit many tracker items, but only see/edit their own, what should we do?

Currently, there is and option "Item creator can modify his items?" at tiki-admin_trackers.php

Maybe we need one: Only item creator can view his items?" Of course, staff working for the company would be admins and could see the trackers for all companies.

Or there could be login drop-down, and only that user can see. Even nicer would be that it's possible for people of the same group to see.

Maybe this possible with the current feature set. In which case, just documentation is necessary.

Some things to experiment:
"My items" in tiki-my_tiki.php

Current workaround is to make a tracker for each customer.

Please see: ((Issue Tracker))

---
Related:
Trackers need "tiki_p_trackers_view_own" permission to view own items only
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=211

I upgraded a Tiki from 24 to 25 after completing the installation I landed on the homepage with errors displayed :
-+Field searchable does not exist in the current index. If this is a tracker field, the proper syntax is tracker_field_searchable.+-
And many -+No results for query.+-

While this is normal, as I didn't ran the index:rebuild command, this is not very elegant and can be improved;

First, in such case a message with a link should be displayed about completing an action and not a page full of errors as that doesn't look good.

When the unified-index doesn't exist a modal warning over the page "Tiki detected that..." with an invitation to action "for your Tiki to work properly you must run rebuild command". If you have a small database you can run it from here else please use console.php.
A option to close the modal (admin choice to continue) and display the page.

Ideally the installer should automatically do such operation.
One difficulty is that we don't want run from the HTML the index:rebuild command to run on a large database as there are chances of timeout.

Tiki could suggest at the end of the installation process;
"You upgraded, before entering your new/upgraded Tiki you must run the index:rebuild command"

If possible a database size detection and offering suggestion;
"The Tiki installer script detected that your database size is: nnn"
We recommend:
* Small database => rebuild the index now
* Medium database => rebuild the index now
* Large database => rebuild the index using console.php

If the database size detection is not possible or too complicate (it may depend of server OS ?) we can simply give recommendation and offer to run the command for the user or suggest him to do it using console.php.

On a Tiki21 created using git go at : tiki-admin.php?page=general
It shows : 21.0svn (InnoDB)
It should show information about Git.

^My Git detail module: GIT 21.x:ba642 Wednesday February 19, 2020 20:08:06 IST^

This tracker item could not be found

Use case:
*Manage many sites/domains with one Tiki installation
*"Park" all the domains on top of each other and get Tiki to send people to the right page depending on the domain.
*Common user base & permissions
*Theme control to provide different theme per section/category/page
*Could be different domain per language

Ideas
*Maybe domains could be links to categories. Put a page in a category and it gets its theme from theme control center
*Modules per domain
*If on page for domain X, force/rewrite URL to that domain
For example
^www.musicband1.com/introband1
www.musicband2.com/introband2
www.musicband3.com/introband3

So if I go to:
www.musicband1.com/introband2
I am redirected to
www.musicband1.com/introband1^


Limitation:
*pagename collision. Ex: domain1.com/intro = domain2.com/intro
*Single shared search engine
*Meta-tags will be shared

Also need to think about the Use Case where different workgroups want different domains. (A bit like *tikiwiki.org sites)

With new Tiki4 Workspaces, we could associate the domain as a preference.

What happens if a wiki page is in many categories, and they have different domain names. How would the priority work? Random? An order? Same idea as default group?



Related:
((WikiFarm))
((TRIM))
((Workspace))

Hello,

Tiki is fantastic piece of software providing (almost) everything one can think of CMS and I would not have difficult time to switch to it all of my web sites...except, there is one, imho, quite important thing which I do miss a lot - it's TIki's __import-export__ capabilities.

For instance, at the moment I?m responsible for one non-profit organization's web site and Tiki would be perfect match for it, but currently there are ~250 posts available and there is no option to import it into Tiki. (:cry:)

These days static-site-generators (e.g. [https://gohugo.io/|Hugo]) and/or flat-file CMS.-es (e.g.[https://getgrav.org/|Grav]) are becoming popular by eliminating need for database usage, but, provide some kind of support to migrate from popular blog engines like WordPress. Moreover, since the content is no longer stored within database, but it is written down in some standard markup (markdown, asciidoc, rst,...) and stored in regular filesystem, it is very easy to change one's platform.

Otoh, there is, afaik, nothing like that available for Tiki so in order to move to it, one practically has to start from the scratch and there is also no way out. (:eek:)

Recently, someone added support for Tiki markup to the [https://pandoc.org/|Pandoc] due to the need to migrate one's content from the Tiki, so we can say there is kind of 'way out' for those wanting to change from Tiki to something else, at least, for blog posts, articles etc.

However, there is none support to convert to Tiki, although there is an open [https://github.com/jgm/pandoc/issues/4825|issue] in regard.

So, my proposal it to take this issue more seriously (there is similar [https://dev.tiki.org/item6697-Markdown-support|issue] to make Tiki more friendly citizen for those wanting to move to/away from it.

Lastly, I'm also thinking that by having good support for Pandoc, I'd certainly take advantage to write some longer articles/posts using my preferred editor which provides helpers for the markup (e.g. rst), syntax highlighting etc., all while being offline and then just convert to Tiki Wiki markup.

It's a pity that Tiki does provide so many things, inherently missing in static-site-generators which have to be plugged via some 3rd party apps/services out, out of the box, but it lacks in import-export features.

There was also [https://github.com/wikiLingo/wikiLingo|wikiLingo] initiative, but it seems that it is stalled and/or [https://tiki.org/item6607-6607?highlight=robert%20plummer|Robert] is no longer around?

As of Tiki 1.9.7, only Tiki admins (full admins) can manage Tiki menus. Yet, this is often something we may want to delegate to editors.

tiki_p_admin_menu would be very useful

tiki_p_watch_trackers exists.

But there should be a general watch permission. For a registration website, we want people to have accounts, but not necessarily to watch pages. Thus, now, we need to deactivate watches altogether.

If user watches activated (for all), any user is able to "watch" a tracker, so that he/she will receive an e-mail message with all the information from the tracker item, even if some field were declared as "hidden"... (sensitive info).

I already reported this at sf.net for 1.8 trackers. And I seem to see the same problem nowadays with Tiki 1.9....
This should be fixed for privacy of sensitive information collected through Trackers/forms

tiki_p_read_comments & tiki_p_post_comments exist in general permissions, but post is missing from specific wiki page override:

{img src=show_image.php?id=8}

The field "name" in the tiki_preferences is currently limited to 40 characters.

This may be appropriate for English speakers, as soon as you start developing german-language Wiki Plugins, it becomes awfully little. For Example:

You are trying to write a plugin named

__ inventarisierung_details (this string has 24 characters).

As soon as you try to configure this, it becomes

__ wikiplugininline_inventarisierung_details (this one has 41 characters)

and fails horribly.

When you activate the 'Advanced' settings via the slider at the top, this gets constantly reset to 'Basic', (unless you save the preference in an additional step) so whenever you do something you have to set it back to 'Advanced', which is a nuisance.

Thanks
hman

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

There are some settings to
#force a user to validate an email addresses by clikcing a link
#for admins to need to click a link in an email to approve a new account.

But what if emails aren't getting through or to go faster?

An admin should be able to validate an account manually








__Duplicate__
{wish id=1710}

Some users may never receive the validation email (ex.: spam filter) and the tiki admin nevers knows their status.

Tiki admin should be able to manually validate an account.

The canonical is:
<link rel="canonical" href="https://nextthemes.tiki.org/tiki-all_languages.php?page=CSS">

But should be
<link rel="canonical" href="https://nextthemes.tiki.org/CSS">

Say I want to follow all the action on a Tiki site, I have to register to several RSS feeds.

5 RSS feeds just on:
http://tikiwiki.org/tiki-index.php

And if a site activates a new RSS feed, I may not find out right away.

I would like a tiki-all_rss.php which combines all RSS feeds which I am allowed to see.

Insert a new item into the calendar and click preview - the preview only shows the description of the calendar item - it should show the title also.

Use case 1:
* Customer has his own hosting (ex: dedicated or shared hosting)
* There is not just Tiki on that hosting
* Tiki consultant doesn't really control the hosting. They may change config to suit another app or in an upgrade.
* Tiki consultant sets up everything just nice thanks to Tiki Check
* Several months go by, all is well. Tiki Consultant is a hero.
* Hosting company (or someone else working on another app on the same server) proceeds to an upgrade/change without telling anyone
* Several months go by, problems appear, there is dissatisfaction
* Customer considers this as within the warranty and expects the Consultant to fix without extra charge
* Tiki consultant feels: "hey, it worked when I left it"
* Tiki consultant doesn't remember / have data on the previous config so can't explain the cause of the issues.
* Customer thinks Tiki was perhaps not such a good idea, as it's not supporting data load and there are all kinds of quirks
* Customer gets told, "why didn't you use system XYZ instead?"

In an alternate reality, Tiki Consultant sets up a Nagios/Icinga/Shinken instance to track all Tiki sites he has been associated with. Data is logged quietly in the background.

When an issue is reported, he can look at historical data and see what changed and have a clue. As a bonus, he can indicate to the customer that hosting company made changes to the server without advising anyone. Tiki Consultant is a hero (and can bill that time), and hosting company is not. If Nagios/Icinga/Shinken could alert the Tiki Consultant of changes, it would permit Tiki Consultant to review changes and to evaluate if there are any risks of issues.

Use case 2: run on all *.tiki.org sites to help reliability.

Use case 3: run on pre-dogfood servers and if we notice something went awry (ex: requires more RAM), we have a clear indication of which day the commit came in.
We have 50+ beautiful checks in tiki-check.php Surely it can't be hard to make them accessible to an outside monitoring system?

{syntax type="tiki" editor="plain"}
tiki-contact.php is an "incomplete feature"

To be useful, it would need

A- An optional "from" field for visitor's email (some people leave comments and ask for a reply but they forget to leave their email. A specific field for email would help so people don't forget.

B- An option for the visitor to receive a copy of the message.

C- Subject should be used in title of internal message. Assuming the subject is "Question about forums"

Current:
New message arrived from tikiwiki.org

Proposed:
New message arrived from tikiwiki.org (Question about forums)


It is possible to do all this with trackers. So is worth improving this feature or better to document trackers? Related: ((Trackers Examples))

There is text in tiki-install.php that is in english without tag or option to translate it.

{CODE()} $title = 'Tiki Installer Security Precaution';
$content = '
<p style="margin-top: 24px;">You are attempting to run the Tiki Installer. For your protection, this installer can be used only by a site administrator.</p>
<p>To verify that you are a site administrator, enter your <strong><em>database</em></strong> credentials (database username and password) here.</p>
<p>If you have forgotten your database credentials, find the directory where you have unpacked your Tiki and have a look inside the <strong><code>db</code></strong> folder into the <strong><code>local.php</code></strong> file.</p>
{CODE}

Would be nice to have this working as the rest of Tiki