Category: Feature request
Request to add a totally new feature or to enhance an existing feature. Also called Request for Enhancement (RFE)
Show subcategories objects
| Name | Type |
|---|---|
| create tracker_changed_notification_subject.tpl | tracker item |
|
Creation of wiki page: enter description and wiki page name is suggested (but editable)
Goal: Making is easy to use description field without needing to duplicate data entry Say I use Tiki for terminology. If I use the wiki page name for terms, I will end up with many weird characters in the URL. If I use the description for the term, I still need to enter a cleaner/shorter wiki page name. This is an unnecessary step. Create wiki page could be full term, and accents and special characters are suggested (but overrideable) |
tracker item |
|
Cron option for when it's not possible to have a real cron job (like Poormanscron)
Like: https://drupal.org/project/poormanscron Useful for ((Update notifier)), Newsletter throttling, etc. ------------------- {sign user="pascalstjean" datetime="2013-09-10T19:31:34+00:00"} This will be important in order to make Unified Index default in Tiki (reindexing of the site every week or so) |
tracker item |
|
Cron-job map-generation
The tw.o-maps are mostly out of date - due to a human-bug (messed up longitude and latitude) I live in Somalia since I enter my geographic data on tw.o some months ago. I can understand, that the admins got other things to do than re-generate the maps. And I can't think of any other needed cron job in tw.o, but never the less it would be cool to have some cron-table to execute certain PHP-function (at least I guess map-generation is some kind of PHP-function). |
tracker item |
|
Current page in structures breadcrumb should not be a link
There's no point in the current page in a structure "breadcrumbs" being a link, because you're already on that page, and it's even kind of misleading because it might give the impression that, because it's a link, it refers to the ''next'' page in the structure, not the current page. |
tracker item |
|
Custom CSS values which overrides chosen CSS (and are kept in database to be future-proof)
I pick one of the themes included in Tiki (Codex.css for example). It is almost perfect for my needs. I would like to make a few modifications, which are not appropriate to share with the Tiki project. A- If I edit the styles/codex.css, I will have to redo my change again at each upgrade. B- If I duplicate styles/codex.css to styles/mycustomtheme.css, I will not be taking advantage of any future enhancements to the theme. It is not possible to put CSS information as Custom code in Site Identity. The other benefit is to distribute css adjustments via profiles, like: http://profiles.tikiwiki.org/site_width 1- Smarty doesn't like the curly brackets used in CSS. {literal} bla bla {/literal} could be used to get around this 2- It is not in <head> </head> I jsut tested by putting the code below as Custom code in Site Identity and it works :-) {img src=images/code.png}%%% {CODE()} {literal} <style type="text/css"> body { background-color: blue; } p { color: yellow; } </style> {/literal} {CODE} Entering CSS "as-is" with curly brackets in Site Identity and having it render as internal CSS could be a solution. http://www.tizag.com/cssT/internal.php or maybe a custom.css should be maintained, and cached from this data. Related: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1014 http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1178 |
tracker item |
|
Custom fields in User preferences
Users should be able to add their own data in custom fields in tiki-user_preferences.php Users could publish their phone number, their ICQ address, etc |
tracker item |
|
Custom javascript: a future-proof way to handle
Tiki has a lot of features. But sometime, we have to hack it up with various things that we can't share back to the project. So we want to modify Tiki, yet, keep upgrades easy. It is already possible to add custom language strings. It is possible to override Smarty .tpl files with our own It will soon be possible to add custom CSS strings It would be nice to have this for javascript as well. A custom.js somewhere. If it can be kept in the database, it makes site migration and backup even easier Or it could be in styles/*/custom.js It would be nice to have the option of putting towards the top or towards the bottom. Maybe Site Identity custom areas already permit this? |
tracker item |
|
Custom language translation
Sometimes, we want to change a few language strings from the original Tiki. It could be because of regional or community expressions. Currently, we need to change language.php and/or the template (tpl) files. It would be better to have a custom language file which would override default text. (Like we do for tpl files). Therefore upgrades would be smoother. Even better if we could edit this language file via the GUI. |
tracker item |
|
Custom language translations in the database and administered via web interface
This will make upgrades easier as people won't have to worry about overwriting their enhancements, Multilingual categories need translations and doing by FTP is not fun. Related: [tiki-view_tracker_item.php?itemId=485] -> This is suboptimal Support.mozilla.com has need for this as well. https://bugzilla.mozilla.org/show_bug.cgi?id=488728 In 3.0, language/*/custom.php can be managed by the web interface. Next step is to have this in a wiki page |
tracker item |
|
D3.js support in Tiki
See: https://tiki.org/forumthread51287 --- Addendum: Make a plugin in Tiki to display the basic d3.js-based charts already developed in the past (in through PluginChart or other means) Related: https://dev.tiki.org/item6263 - Make PluginChart optionally reuse some other lib already in Tiki to make js-based charts (raphaeljs, chartjs, d3.js, etc) See: https://dev.tiki.org/Data+Visualization#d3.js Basic d3.js-based charts already made in Tiki: http://marclaporte-11197-5155.show.tikiwiki.org/ u: admin p: 12345 |
tracker item |
|
Danger with Watches and PluginGroup
When writing a particular wiki page, and being set this page to be watched to a group (let say Registered users). Then if the page has plugingroup to hide particular peaces of special text that is not intended to be known by certain users. Then every time this page changes, a notification email is sent to all Registered users (this is ok), but in the content of this email all the source code is revealed to EVERY user on the Registered group, regardless if they have the right to see Source of wikis. Don´t know how this could survive the testing and dogfood of this community. May be there is another way to let the Registered group to be acknowledged of a change in a wiki, without compromising content. Please enlight me on how to do this much of the work done on our live tiki portal uses plugingroup to restrict snippets of text to certain groups and other snippets has to shown, in the same wiki. There should be an option to configure a watch to be sent in a way that only alerts the user that a particular page has changed without showing all source, in respect to a particular right to see or no to see the source. I have checked on the proper user rights and object perms to avoid them to receive this notifications in the proper way, but tiki doesn´t seem to take it. Using Tiki 6.2 |
tracker item |
|
Dates format in all GUI
Hi, Because of partial translations of pages, I use French or English GUI translated and sometimes Spanish, Italian or German. Because I Have defined complementary of elements of GUI dictionary, it is not so evident to take care the whole time with which language you are working and more the associated date format. It is the reason, while, after, some errors in input dates in a wrong format that I do believe that the current format to input a date should be always repeated into display tpl or input title (displayed). This is a long and progressive but useful job in my opinion. Each time I can do it, I do. |
tracker item |
|
DB Manager from within the admin dashboard (maintenance)
The idea is a basic DB management panel from within the Admin. Same stuff exist for Wordpress and they come very handy to perform maintenance task and even auto-maintenance task. Should do: *Green checklist (db exist, db version, host, path to backup folder, last backup, etc) *Table list (name, number records, data usage, etc) *Optimise/Repair (one by one, all) *Backup DB (manual, auto, where [folder, email... maybe dropbox ?], duplicating ?) *Restore DB (folder listing, delete old, same as original, different name [same user/pass]) *An option page (path to backup folder, etc) I believe there is also some stuff we can add if we look for a wider "maintenance panel". As we'll have a scheduling system, we can have automatic backup + optimise tables + optimise search index + flush caches, etc. As long as we don't introduce danger (like get the system stuck waiting for a question) would be great for Tiki to perform better. Wordpress has something very similar: http://wordpress.org/plugins/wp-dbmanager/screenshots/ {sign user="pascalstjean" datetime="2013-08-18T18:11:45+00:00"} After brainstorming, it was also suggested that maybe packaging Adminer would be a potential way to accomplish this feature request http://www.adminer.org/ |
tracker item |
|
Missing Tracker Item #1266
This tracker item could not be found |
tracker item |
|
Dealing with forgotten usernames
Sometimes, users forget their usernames and end up creating duplicate accounts. Here are two things which would help: 1- Users should be able to have a password reset/reminder while only knowing their email. __fixed in 1.10__ 2- In tiki-adminusers.php, the search box should work for emails also (not just usernames) __fixed in 1.10__ Related: [tiki-view_tracker_item.php?itemId=1069] Also, in 1.9.x, usernames are CaSe SenSitive. __fixed in 1.10__ |
tracker item |
|
Dealing with high-volumes of data (drop-down lists become search boxes)
TikiWiki often has drop-down menus with many choices. Ex.: drop-down list of users, or wiki pages, etc That is ok for a few hundred. But what if you have 300 000 users or 300 000 wiki pages? There should be a setting where beyond a certain number, the drop-down become a search box. |
tracker item |
|
Default path for file upload in blogs property dialog (general properties)
Uploading of all files and pictures in file gallery root is the default for adding files to blogs. This tends to lead to a real messed up gallery. And leaving the user alone with navigation towards a special folder starting with gallery root every time will not work - nor did ever :-/. Wouldn't it be nice to have the possibility to predefine a default folder for some functions - i.e. "Default folder for files and images of this blog" in every blogs "General options" tab? Giving there a path will lead to (or create, if not present) a subfolder into file gallery that will become the default path of every upload dialog in this blog. In similar ways, default paths could be imagined to be added to a number of other functions. ''__To Do:__'' • Add a new property "DefaultFilePath" to blogs. • Add a new input filed of type text/file path to general setting in blogs. Save into DefaultFilePath of blog • "Save to…" file picker of "choose or upload images" or "choose or upload files" (which in fact is the same function) in blog editor will use this value as preset path. • Tidy up: Reduce blog editors menu entries "choose or upload images" and "choose or upload files" to a single "upload image or file" |
tracker item |
|
Default sort for Trackers by date
In tiki-admin_trackers you can only use fields explicitly belonging to the tracker for default sort - it would be good to have the possibility to sort by default by Created or Modified, too. Should be possible to even default sort by Comments, Attachments, Downloads etc. UPDATE: Even TrackerId would be interesting. This occured to me, when trying to make bugs duplicate - that wasn't possible by TrackerId or other standard fields. So problem has been rephrased: Opened up a New Trackeritem for this and marked THIS one DUPLICATE of http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=256 |
tracker item |
|
DefaultSettingsChanges in 1.10
We need to decide about ((tw:DefaultSettingsChanges)) in 1.10 Some of the new features are much better than previous ones (ex new diff engine). People upgrading their Tiki could conserve their setting. However, new installs should take advantage of the new features. A note should be added in tiki-install.php This must be low maintenance for Tiki dev team. |
tracker item |
|
Defaut user wiki page name should be based on realname instead of e-mail
In 1.10 now we can set to login as e-mail and display realname wherever possible. But the user wiki page by default is set to 'UserCreate<e-mail>. We should still allow user to create his page with 'UserCreate<username/real name>'. The recommended behaviour should be if user chooses e-mail to be private or it could be if admin sets to disaply realname wherever possible, then it should use 'UserCreate<realname>' other cases it can be based on e-mail. |
tracker item |
|
Deploy watch category to tiki-browse_categories.php (and everywhere relevant)
It is too difficult now to watch categories (but the feature works well). Please see: ((Category Watch DogFood)) on ((SUMO)): [https://bugzilla.mozilla.org/show_bug.cgi?id=498001|Improve UI and feedback for watching categories to say you'll be e-mailed and offer easy way to turn off] |
tracker item |
|
Detect BOM in a Tiki health check and in release process
Discussion here: ((BOM)) |
tracker item |
|
Detect language in a comment and offer a "Translate this" link
Similar what FB does below posts which are in a different language than yours. |
tracker item |
|
Detecting if CAPS LOCK is on
suggested by r1 on #tikiwiki http://24ways.org/2007/capturing-caps-lock |
tracker item |
I would change default from:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org
to:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org by Jean-Paul