Category: Feature request

Provide example for jquery regex url that validates the condition in tracker field: positive number with or without decimals

I followed the example from here: http://www.sitepoint.com/jquery-basic-regex-selector-examples/ (plus from many other internet sites suggesting regex's for that condition with no luck) :-(

It seems to work in Tiki14 with this validation regex:
{CODE()}
^\+?[0-9]*\.?[0-9]+$
{CODE}

But it didn't work for me in Tiki12. I'll try to reproduce again in a Tiki 12 show.t.o instance.
to reproduce, come here:
http://xavi-9794-5641.show.tikiwiki.org/tiki-index.php?page=Bug_Tracker

and type 12 at the field Number: you'll get "Provide a positive number with or without decimals" and you shouldn't

provide some button for users to save their choices (or cancel) other than the edit button they clicked on to display the options to choose from to make it more consistent with the rest of tiki

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09

There may be cases when an article type doesn't call for the publication date to be displayed. But then the publication date input isn't on the edit screen. Then there is no way to control the display order of articles other than in the order they are created. For maximum editorial flexibility, the editor screen should allow publication date input even if the date isn't going to be displayed.

Sometimes, we end up with some strange characters in pages names (accents, punctuation, etc). While it generally works, people should keep URLs with simple characters (like in emails) for nice readable URLS.

For example:
((I know this is all wrong, but fear it might be right - Alain Désilets))

{syntax type="tiki" editor="plain"}
Quiz does not show correct answers and immediate feedback after submitting quiz even though these options are checked in the quiz admin.

Maybe these problems are not priorities? I haven't seen the Quiz Admin doc page updated since 2008.

There is no posibility to ask questions with more than one correct answer.

I would like to have to ask multiple choice questions with more than _one_ correct answer.

Add a feature to limit amount of space used by users (quota).

Add a status panek to allow the user to see the space used (on disk and database) by Tiki. Maybe also display the amount of space for each feature (filegals, wiki, ...).

An additionnal option could be to send a mail to the admin (or a specific user) when users data occupies nearly 90% of the specified quota.

It could be interesting to specify quotas separately for each features.

At the moment the forums in tikiwiki have only a very basic functionality unfortunatelly. Please add a few things to make them more usable especially for people who are plain users and not developers.
Second issue with quote: In case you have a more complex discussion going you often need to quote several people in one reply. It is very bad for normal users (!) to have to learn and write code. Thus a button "quote" that enters the code automatically into the eply box and only needs to be filled with name and content would be a very good improvement.

At the moment the forums in tikiwiki have only a very basic functionality unfortunatelly. Please add a few things to make them more usable especially for people who are plain users and not developers.
First one: Quote function is not citing (or allows no addition manually) whose post is cited. That is a forum standard feature, please add it! People at our page ask for it, we just launched and have already 50 users and will grow fast with a lot of complex discussions. That is absolutelly necessary.

Presently Tikiwiki gives the possibility to quote always or to quote never.

Obviously the quote or not quote should be left at the appreciation of the user, depending on the previous post.

The plugin list need a real "random" sort option to display trackeritem randomly in a list.
It will help to use it in many place.

For example at https://tiki.org/consultants
We use {CODE()} {sort mode="randommode" modes="tracker_field_tikiConsultantsUsername_asc, tracker_field_tikiConsultantsItemID_ndesc, tracker_field_tikiConsultantsItemID_asc, tracker_field_tikiConsultantsSorting_asc,tracker_field_tikiConsultantsName_asc, modification_date_asc, tracker_field_tikiConsultantsName_desc"}{CODE}

With all this parameters it even couldn't get the illusion it is random. Refresh 4 or 5 times the page and you will see that the list is permutation of the same order.

The action log is almost unusable so it needs a major revamp.

Ideally the log data should be indexed in the unified search index (or maybe a separate one like the prefs?) and the search should be something like a custom search page where you can filter by date range, user, category (section) etc.

Might be good for a medium-newbie dev as it couldn't really be much worse!

Also, the log calendar needs reinstating, probably (was disabled as became totally broken after full-calendar took over)

Rebuilding index now reports:
{CODE()}ssh-w00ec615@dd29038:/www/htdocs/w00ec615/12x$ php console.php index:rebuild
Started rebuilding index...
Indexation
wiki page: 2
file: 0
trackeritem: 2
sheet: 1
comment: 0
Rebuilding index done
{CODE}

This was always in the web interface and recently added to the command line in http://sourceforge.net/p/tikiwiki/code/48172/
Great!

What would be even more useful is to have the same stats that are provided by the "Server Load" module from tiki-admin_modules.php, which provides Execution time, Memory usage and number of Queries

So then, we can get an idea when it's getting too long or using too much RAM.

We'd want this both in web & command line. This could be added to the ((Monitoring)) system and we could monitor system health.

Thanks!

Google ReCaptcha is displayed in english only.
This is wrong, it should use the selected language by the page (tiki) and be displayed in the corresponding language.

https://developers.google.com/recaptcha/docs/language

You can test and check at : http://bsfez-11581-6186.show.tikiwiki.org/tiki-register.php
Change the language, the recaptcha stays in english.

Record Calendar-related actions at the Action log

It's currently now possible through the ((doc:Action Log)) to display ((doc:Calendar)) actions, since they seem not to be recorded.

Calendar is buggy in some edge cases, and recods in the action log would help to find out when the issues happen.

If you want a tiki with calendars and action log setup already for your, see this:
http://xavi-9794-5877.show.tikiwiki.org/tiki-admin_actionlog.php
u: admin
p: 12345

Mail-in should have an option to record events in the action log. Events could e.g. be "New email", "Email routed to structure" or "Error no anonymous access"

should have Recurring events feature on calendar, that will be great...

Currently, one must list the parentID of ONE category for the category field. It would be nice if there were a "recurse" option that would show ALL the categories and subcategories for one parent. That would make setting up categorized trackers much easier.

It would be nice when deleting (or renaming) a wiki page, if Tiki asked for a redirect (via the REDIRECT page). This would help visitors how have bookmarked the original page.

Use case:
#As admin, you select to DELETE (or RENAME) a wiki page.
#When Tiki prompts for confirmation, there could be a checkbox & text field asking for a redirect page.
+You should be able to enter ''either'' an existing wiki page or a fully qualified URL.
#If you select the checkbox (and enter a new page), Tiki does not ''delete'' the page. Instead Tiki edits the page to replace all existing content with a REDIRECT plugin.


There should be an option to have "301" headers so search engines know to update their DB.


There is a new page Alias feature in 3.0 Renamed pages could keep old URL as an alias. This could be done by appending an invisible page alias.

See attached images for UI example from MediaWiki

Related:
[wish1489|Wiki page name Alias]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

Related:
[wish1489|Wiki page name Alias]
[wish1119|Better handling of page renaming]
[wish1292|Plural WikiWords when using ((WikiWord))]

After looking through the CSS for TikiWiki, one quickly find several redundancies and inconsistencies (modules are not consistently using CSS in the same way, just take a look at the login box with different renderings to see what I mean). On top of that, some CSS classes requested by the code are actually not existing in some CSS... (separatorline etc in some menus)

SO, should we not rethink the styles system?

What I am thinking of is less of a local (modul-driven) approach but rather a context/mode-driven approach.

For example, we could structure the class names so they properly represent the place of usage: header,main, left, middle, right, bottom as pre-fixes, and the usage as the tag, and a qualifier as the postfix.

Example:
A Menu item would be [location]_menuitem_[qualifier]
A Menu item on the left side would be left_menuitem_[qualifier].
A Menu Option on the left side would be left_menuitem_option

SMARTY knows precisely where it is rendering. So we could generate a standard variable in smarty called $CSS_LOCATION, which smarty maintains. All css requests are parsed through a smarty function that assembles the propper prefix.

The [qualifier] is there to make writing CSS a little easier. We can simply create a DIV as an envelope around a structure, assigning the class [location]_[usage] to that. All elements inside would then automatically inherit those characteristics, and the CSS part would only have to deal with the diviation. Those should be clustered together in the CSS to give a clear view on what happens in this particular usage...

I know that this is most probably a &%$&-load of nitty-gritty work, but once done, we should be able to then write a little app that makes developing CSS much easier (maybe even inside TikiWiki) Biggest problem: how to we manage the transition to the new approach, how to maintain backwards compatibility, and how to get alignment on the structure itself...

COMMENTS are very welcome.

J

I would like to see a way to control how often I receive watch emails.

Situation 1 - DIGEST mode:
I would like to receive a single email each day that identifies every watched item that changed.

Situation 2 - TIMEFRAME mode:
If a page is changed by the same user within a preset timeframe, I only want to receive a single watch email. To avoid the "lost edit" issue, many users SAVE their wiki pages frequently (sometimes several times per hour). If I'm watching the page, I'll get TONS of emails. I'd rather get 1 email per user change per hour, for example.

Session expiration is producing some losts on forum posts (in a similar way it was happening on wiki edits...). That solution by ricks99 was very smart on wiki edits. Could it be added also (or similar behavior) to forum posts?

---
update: Do the same on trackers!!! (show some popup if you are going to loose your session on that site)
I had lost that information because I my session (apparently) expired... (maybe there was a conflict of cookies with the ones on other 1.9.9 tiki sites I was loging in and working in right now)...

Please see
http://doc.tikiwiki.org/Lost+edit


{FLASH(movie=files/FeatureRequest_BetterHandlingOfBackButtonWhileEditing.swf,width=>811,height=>708,quality=>high)}{FLASH}

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.