Category: Feature request

The login settings page should be refactored to eliminate the presentation of unneeded configuration options.

These regex expressions could be shared in a wiki page.

Ex.: ZIP code, Postal Code, Phone number, etc

Idea by Fernando Galandrini

In Tiki 3, the feature_category_reinforce allowed Tiki to evaluate category permissions with AND operator, to determine if a user can view an object in the category.

This __"Permission to all (not just any) of an object's categories is required for access"__ option was removed in Tiki 4 & 5. Now Tiki always evaluates category permission conflicts with OR operator.

I would like the feature_category_reinforce option re-instated for Tiki 5 & 6.

When we have the ability to close repetitive remarksboxes and save some user space it would be nice to allow users to tick a checkbox and opt-out to not show that remarksbox up on next page reload again...

Perhaps par of Notifications Revamp:

Some examples:

Every year, we need to do: {wish id=4730}. It would be good to have a reminder.

Same idea for
* Application for a non-profit booth for OSCON
* Domain name renewals
* SSL renewals
* A BBB meeting room could send a reminder link 20 minutes before the meeting
* etc

Ideally, these reminders could be visualized in a calendar view.


Example:
{CODE()}A tracker field type "reminder" "deadline" or something (An extension of the time/date field type). If status is X, by date Y, send out a reminder e-mail every week until it's solved. (ex.: Pete of the security list). If status is X by date Z, send a reminder to a different email (escalation) (security@){CODE}


--------

+1 {sign user="pascalstjean" datetime="2013-09-10T19:27:51+00:00"}

The scoring system is untranslatable as a whole.

It relies on labels written in English, and unlike some module parameters, where translators can mock the interface by rendering the translation in the explanation of the parameter, that won't be possible here, so that scoring cannot be translated, and to admins who do not speak English this entire feature/module becomes unusable, because it will be incomprehensible.

My proposal for rebuild with the least amount of work needed is: Prefill with IDs and have the current text be a mere label, but rendered through tra().

--Tiki 18.x no longer needs mods.tiki.org-- It would have been nice to delete mods before 18.0 but it's somewhat late now...

Ref: https://tiki.org/forumthread67983

Presumably, we shut down mods.tiki.org in April 2021, at the end of the support period for 15.x?
https://doc.tiki.org/Tiki15

The "Allow HTML" button is a PITA.

because it is default unchecked EACH TIME you open the edit screen. therefore if anyone puts html in a page it is by default not parsed the next time somebody edits.

Using the tiki-mailin feature (for Wiki-Put or Article-Put), I consistently see right after the body tag, a PHP message showing me the array being populated. This happens whether or not there's an error in the posting itself.

Can someone explain why this is happening?

Source of example is attached. (@@@ indicates prvate information). Thanks.

Is it possible to give a checkbox or setting to turn this off?

This feature has never worked well. There is no active development on it. Should be moved to mods or just removed.

But there is not unanimity on this yet :-)
http://dev.tikiwiki.org/Endangered+features

Although I ''don't'' get reports about my own changes to wiki files, I ''do'' get reports about the attachments I myself make to wiki pages. I'd rather those not be sent out.

We have two calendar interfaces in Tiki. The newer ((doc:FullCalendar)) and the legacy code. This is more work to maintain, etc.

* Upgrade FullCalendar to latest version. Decide if we use
** latest version http://blog.arshaw.com/1/post/2013/09/fullcalendar-news.html
** or stick with the one we use now FullCalendarResourceViews, which is needed for the ((doc:PluginTrackerCalendar)), its development gets in sync every now and then with the original FullCalendar, and allows to do ressource planning: https://github.com/jarnokurlin/fullcalendar
* Review any FullCalendar issues such as:
** https://dev.tiki.org/item4248 https://doc.tiki.org/FullCalendar
** https://dev.tiki.org/item4993 - FullCalendar doesn't show in Mobile mode in 12.x LTS
* Remove legacy code and put FullCalendar as the always on default way to show calendars
* And then, [http://themes.tiki.org/item67|Make FullCalendar use Bootstrap classes and be responsive]

On the banner feature there is still mention (and certainly strains of code) of Flash. (flash is dead)

See: http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php

The parameters and the strains of code should be removed.

{syntax type="tiki" editor="plain"}
In order to make show*.t.o servers more sustainable (in terms of disk-space consumed by show*.t.o instances), a suggestion was fired in the [https://tiki.org/Roundtable-Meeting-2020-09|TRM of September 2020]]: once a bug report is closed, then "the system" could delete the tiki file tree linked to that bug report. Mysql db could be kept, but the many hundreds of Mb in current tiki versions from the file tree on disk could be removed to respect disk resources & availability for new show*.t.o instances.

Example: show2.t.o currently consumes something like 10 new Gb per month, due to the instances being created by users.

using www.domain.com vs domain.com and it will not keep you logged in.

Plus, having www is no longer relevant nowadays


http://www.fabianlim.name/redirecting-non-www-domain-to-www-using-htaccess
http://arjaneising.nl/wp-content/uploads/htaccess-www.txt

{CODE(caption="Jonny says")}Finally - Marc, did you crack the www url problem? As you said, it would be nice to have as a pref in Tiki and i think the only way to do it for all cases (subdomains, subdirectories etc) is in PHP. For now we could just add it to local.php - stuff like:

if (strpos($_SERVER['HTTP_HOST'], 'www') === 0) {
// do stuff...{CODE}



Related:
{wish id=1611}

https://blog.mozilla.org/labs/2013/09/reintroducing-togetherjs-formerly-known-as-towtruck/

If you rename a page, the old page name is still in the index.

Reorganising the Control panel Print Settings (tiki-admin.php?page=print) as follow:

Title : Print and PDF settings
Subtitle : Settings and features for print and pdf document generation
Tabs : General | Print settings | PDF settings


!!General
!!!Content
* --Show Page title-- => Insert Page title
* --Print wiki authors-- => Insert wiki authors
* --Print original wiki URL-- => Insert original URL
* --Print modules-- => Not here, we should use module parameter (added recently) Modules selection (print, screen, mobile, desktop, etc))
!!!Table of content
* Table of contents
* TOC heading
* TOC levels
!!! Document settings
* --PDF Orientation-- => Page orientation
* --PDF page size-- => Page size
* --Print Friendly PDF -- => Print Friendly
* Left margin
* Right margin
* Top margin
* Bottom margin
* Page background color
* Page background image
!!! Watermark and Additional content
* Watermark text
* Watermark Image URL
* CoverPage text settings
* Coverpage image URL
!! Print settings
* Print Wiki
* Print articles
* Print original tracker item URL
* Print original forum post URL
* MultiPrint
* Number of columns

!!PDF settings
* --PDF from URL-- => PDF generator engine
* PDF header text
* PDF footer text
* Header margin from top of document
* Footer margin from bottom of document
* PDF password for viewing

* Hyperlink behaviour in PDF
* PDF Bookmarks
* Link TOC with content
* Slideshow (reveal.js) PDF export
* Print indexed

* Printing to PDF memory limit
* Printing to PDF time limit

The Dynamic Content items are great show data at one set time, but why not have them repeatable so that you could have reminders appear on your tiki pages to tell you to review one of your business process every Friday etc. I know there is a calendar but jumping into calendar breaks your work flow.

{syntax type="tiki" editor="plain"}
During the early site configuration, before the admin user selects an avatar image, there is "AD" text placeholder where the admin avatar normally appears. The "AD" text placeholder, in my opinion, looks jarring and could be open to misinterpretation. Although it only appears until the admin specifies an actual avatar image, until then, it looks to me like an ad banner placeholder or something and doesn't contribute to a good first impression of Tiki by the new admin. If possible, I think it would be much better to have a default admin icon or image that actually looks like it represents the administrator account, rather than text that could easily be misinterpreted.

__My response to Landry's question__ (comments don't seem to be working now - Oct. 9):
My choice is the first icon, the person with the suit and tie.

Here is documentation about emoticons / smileys: https://doc.tiki.org/Smileys

I suggest replacing current emoticons in tiki with the natively supported emoji. The emoticons currently displayed in tiki currently look dated. The menu may be best replaced by a basic emoji menu, and have the unicode inserted directly into tiki pages.

The feature that replaces text emoticon representations with the picture based emoticons could also be changed to output the unicode emoji.

Replacing with emoji not only brings a facelift to tiki, but also has the potential of reducing tiki parser reliance-time, allows people to use emoji they are use to, and will help to optimize page load time.

Emoji is now supported in every browser we support with the exception of IE 9. ( currently holding 0.3% of popular use) http://caniuse.com/usage-table

All modern browsers/ OS's support color emoji. Legacy browsers (like IE 10 @ 0.27% usage) support non-colour emoji.

Presuming we are talking about Emoji support as outlined in Unicode 6, excluding the flag implementation, support is very good.

There are libraries available that use js or php to replace the unicode emoji with a standard svg library, such as http://emojione.com/developers/, but with such good support already it may not be worth implementing this, as long as we stick to Unicode 6 emoji.

I furthermore suggest that the emoji button on the edit page be removed altogether on mobile devices in favor of the built in emoji support. Desktop emoji still requires a tiki emoji menu IMHO.

This all of course hinges on the emoji bug: https://dev.tiki.org/tiki-view_tracker_item.php?itemId=6189 being fixed.

Some desktop applications have a way to report errors. This would help us know which bugs happen the most often. For example, we could check for sql errors or hard php errors.

Of course, this would be totally optional. Even better would be for people to be able to share their Tiki configuration (anonymously) at the same time so maybe we could detect that bug X only happens with a specific combination of on/off settings.

Firefox talkback:
http://www.mozilla.org/support/firefox/faq#talkback

Of course, knowing about all the bugs doesn't automagically fix them. However, some are super easy to fix if we notice them, like this one:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1399

The same way TikiWiki community members can vote on bugs and feature request, the "crowdsourcing" of error reporting will make it easier to distinguish the most common issues. It would also be a hint that some very rarely reported issues are probably related to a rare server configuration.

The same way I invest to address the most voted on features/bugs, I would do the same here. Specifically, I would like to see reports of the top-10 Postgres-related errors. I am sure these are easy to fix and could make TikiWiki more useful to Postgres users. I would like to use Tiki on Postgres eventually.

http://yro.slashdot.org/article.pl?sid=09/01/24/1938224

I would like TikiWiki's search engine to return results with links to matching sections within pages.

A Wikipedia example of this would be a search for "Life and career." It brings up an entry for John R. Brinkley that has links to the entire article on John R. Brinkley (http://en.wikipedia.org/wiki/John_R._Brinkley) and another for the "Political career" section of that page (http://en.wikipedia.org/wiki/John_R._Brinkley#Political_career).

If I tried to do this in TikiWiki, I would get a search result with a link like the following:

http://mywiki/tiki-index.php?Page=John_R._Brinkley&highlight=Political%20career

That might help if I were searching for this in Google, but it doesn't do what the wiki content creators at my company want. If there is a workaround, I'd love to hear it.

I'm requesting that Tiki project team consider the following:

A Tracker can automatically create a new item of its own type (same list of fields).
A Tracker can automatically set "open status" on new item.
A Tracker can automatically set "close/pending status" on another item .
The above automation is triggered from a date/time calculation using Mathematical Calculation.

Use case:1 Agile Project Management
You have organised your project into time-boxed parcels of work.
Each parcel has an associated tracker item with meta-data on the parcel and what needs to be done.
You have set key-dates for parcels of work to be complete.
If you "miss the boat", tough luck, you have to role in with the next time-boxed parcel of work.

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.