Category: Edit interface (UI)

New section edit feature is very useful. Three minor adjustments:

A- There is no way to edit the section preceding the first !,!!,!!! etc
This would be nice as well.

---

B- When getting to the section via an anchor, the edit by section icon is too high. To see what I mean:

1- login to doc.tikiwiki.org

2- go to
http://doc.tikiwiki.org/Editorial+Board+Meeting+2008+05

3- Then click on an anchor like:
http://doc.tikiwiki.org/tiki-index.php?page=Editorial+Board+Meeting+2008+05#2_3_Proposed_changes_to_doc_tw_o_site

Notice how the edit button is not accessible directly? I need to scroll up a bit (not ideal)

---

C- After editing a section, I should be sent back to the anchor of the section I just edited

So I can see what I just edited.

There are some issues with dropdowns and tablesorter data with trackers.
Reproduced in a show.t.o instance (just after the bug item is created):
http://xavi-9794-5607.show.tikiwiki.org/tiki-index.php?page=Wants
u: admin
p: 12345


(1) Tracker item status displayed in a PluginTrackerList as dropdown has no values (this is fixed in Tiki14.x, it seems). Fixing in 12.x LTS will be appreciated.

Response: This is not backportable to 12x unfortunately. This ability sort and filter based on the image title wasn't added until tablersorter version 2.17.5 and Tiki 12 uses 2.14.4. But I have fixed as much as possible and it is now possible to filter using o, p or c in 12x

(2) Dropdown field. An item has no value for that field. How do you select those records with empty value? Could some filter like "empty/not empty" be added to the fitlers?

Response: I don't see an easy way to do this. Would suggest using the sorting to sort empties to the top, or in some cases setting dropdowns or range properly could capture empties (e.g., if they actually have a 0 value). Will ask the tablesorter developer for a fix.

(3) when the order of the fields in the plugin trackerlist doesn't match the order of the fields in the tracker definition, the results are unexpected: it seems to overrule the order in the trackerdefinition.

Response: after further discussion this is not an issue - the sort parameter needs to be set to y for columns to follow the order of the field parameter.

Thanks in advanced!

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

2 issues:
#The side-by-side translation feature is ugly.
#After

!To reproduce
#Install fresh Tiki15
#Install internationalization profile
#Watch page ''Instructions for the Multilingual Wiki'', see i18n icon
#→click ''Translate''
→Choose a language under "Translate this page to a new language", enter a page title, click ''Create translation''

See ugly side-by-side (see snapshot in attachment). That's __issue 1__

After translation is done, click on ''Full translation''
→ One ends up viewing the english page instead of the new translation page __issue 2__.

But the translated page is well created and the first time it is viewed, it has the info box saying it's new.

Seen on IRC:
{img src=images/code.png}%%% {CODE(wrap=>1)}
(10:33:47 AM) ***dthacker also wonders if there is a login-timestamp wiki syntax such as mediawiki's ~~~~ that would auto sign with user id and date/time.
{CODE}


Wiki pages are great to produce Neutral Point of View (NPOV) content. If we need to know who added what, we check the edit history.

For debates, discussions, opinions, etc, people will often use Tiki blogs, Tiki forums or comments at the bottom of wiki pages. These are more natural formats and it's clear who thinks what and who said what. Comments & forum threading make it clear who is responding to who/what.

However, in some cases, it is useful to have this type of interaction in wiki pages. The [http://doc.tikiwiki.org/Editorial+Board|TikiWiki documentation Editorial board] has monthly meetings to discuss and make decisions. Members can edit, comment and vote on motions.

The way people add their comments is not standard and if we are not careful, it can get messy. This often happens in wikis.

Some wikis use a special syntax for "signature". This would be a way to associate the name of the user and maybe the date to a specific comment. It would be nice to clearly and visually associate the user to the comment. Maybe the comment & signature are in a same box?

It would be nice also for people to be able to express support to an idea in the wiki page, with a thumbs up (+1) or a thumbs down (-1). Right now, the wiki ratings feature let's us vote only once per wiki page.

These syntaxes should be quicktags to it's easy to add. Maybe some of the less important meta data (ex.: date of comment) would be only visible on mouse-over. (and thus not in printed mode). The mouse over could also contain a link to the user's personal wiki page and some data about the user (his avatar, score, etc).


Ex.:
*click my PluginComment tool (in toolbar)
*Pre-fill text that will be mouse-overed with previously selected text
**add date & signature (with link to userpage)


Everyone: please share your ideas on this and how you have seen it implemented elsewhere.

Thanks!


Related:
{wish id=2102}

Since 14.x displayList=y broken in Plugin TrackerFilter, and therefore, featured Collab Community profile broken

Tested with trunk r52418

To reproduce:
# apply Collaborative_Community_12x profile.
# Go to the registered users homepage. You'll see an almost WSOD with just the table header (of the trackerplugin) at the top.
# Edit the TrackerFilter plugin params to set displayList=n and everything will display correctly (but no list of items pre-displayed)

Error message in the show.t.o instance where has been reproduced:
http://xavi-9794-5447.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage

^ Fatal error: Call to undefined function smarty_modifier_escape() in /var/www/xavi-9794-5447/lib/core/Tiki/Render/Editable.php on line 55
^

{syntax type="tiki" editor="plain"}
Since Tiki27 the tracker field text area shows an edit and a preview tab.

This addition should have been made optional for trackers text area or per features and for modal use.
The tracker interface turn to be a confusing and crowded area when editing an item (in a modal 😱).

Site timezone is not respected when using Plugin Convene

E.g.: site default is UTC-2. You choose your time in the convene plugin, as UTC (even if you have no indication of the timezone, it seems), for instance, and the stored time is shown 2 hours before the time you selected in your choice.

Reproduced using Tiki 13.x here:
https://tiki.org/Admins+Team+Meetings

However, I can't reproduce it in an associated show instance in trunk. Maybe it has something to do with the timezone set in php settings, and not just the setting in Tiki?
I kept the tiki set as "Admin home > General > Date and time > Displayed Time zone: Use site default".

www.mozilla.com is automatically turned into a link. (great)

but support.mozilla.com is not.

So I must do:

{img src=images/code.png}%%% {CODE()}
[http://support.mozilla.com|support.mozilla.com]
{CODE}

If automatic detection of support.mozilla.com is too risky, maybe the following:
{img src=images/code.png}%%% {CODE()}
[support.mozilla.com]
{CODE}

should be smart enough to know that I meant:
http://support.mozilla.com

and not:
http://dev.tikiwiki.org/support.mozilla.com

Like Ricks99's great work:
http://tikiwiki.org/tiki-view_blog_post.php?blogId=26&postId=302

current plugin (from mods)
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/mods/trunk/wiki-plugins/submit/wiki-plugins/wikiplugin_submit.php?view=markup

Ex:
http://www.stumbleupon.com/tag/tikiwiki/

Please see:
http://www.addthis.com/

Wiki Syntax for special characters seems to fail in 1.10 (I can get it in WYSIWYG). Thus, ~np~~169~~/np~ no longer shows the copyright symbol.

The problem appears to lie in TikiLib - parse_data
if (!$simple_wiki and $prefs['feature_wysiwyg'] == 'n') {
$this->parse_htmlchar($data);

Here's this issue - I have WYSIWYG set to Y, but NOT showing by default. It seems that the test should be whether WYSIWYG is actually showing - I have no idea what the variable is.

While selecting the status when editing a tracker item in the modal (feature Chosen enabled), the icons do not display properly.

Expected behaviour: the same status icons used everywhere else should show there, instead of coloured square boxes.

See attached image for details.

{img src=images/code.png}%%% {CODE(caption=current strikethrough syntax)}
{TAG(tag=>strike)}texte{TAG}
{CODE}

Suggested one for us:
--strike--

As suggested in wikicreole:
http://www.wikicreole.org/wiki/Strike

All wiki engines:
http://www.wikimatrix.org/syntax.php?i=27

This is very useful when using wiki pages for ((project management))

Please go to "Syntax Examples" here:
http://www.wikimatrix.org/compare/TikiWiki-CMS-Groupware+MediaWiki

Please also see:
http://meta.wikimedia.org/wiki/Help:Wikitext_examples

Some syntax could be supported as it doesn't really conflict with the existing.

__Basic formatting markup__
{img src=images/code.png}%%% {CODE()}
You can ''italicize text'' by putting 2 apostrophes on each side.

3 apostrophes will '''embolden the text'''.

5 apostrophes will '''embolden''' and ''italicize''
'''''the text'''''.
{CODE}


__Signature/timestamp__
{img src=images/code.png}%%% {CODE()} You should "sign" your comments
on talk pages:
- Three tildes gives your
signature: ~~~
- Four tildes give your
signature plus date/time: ~~~~
- Five tildes gives the
date/time alone: ~~~~~ {CODE}

__Section headings__
{img src=images/code.png}%%% {CODE()} == Section headings ==

''Headings'' organize your writing into
sections.
The ''Wiki'' <u>ab</u>
##software can automatically
generate a [[table of contents]] from them.

=== Subsection ===
Using more "equals" (=) signs creates a subsection.

==== A smaller subsection ====

Don't skip levels,
like from two to four equals signs.

Start with 2 equals signs not 1
because 1 creates H1 tags
which should be reserved for page title. {CODE}


However, links & images could be more problematic.

Related:
*[wish1531|Wiki markup for icons]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]
*[wish1220|MediaWiki import script]

tiki.org (11.x): many pages shows as anonymous (or registered) with left column overlapping central column. And the icon to flip left column is unclickable. See screenshot (from http://tiki.org/Translation+Server ).

This was visited with Chromium (Versió 28.0.1500.71 Ubuntu 13.04).
Using firefox everything is displayed properly

{sign user="pascalstjean" datetime="2013-08-26T01:52:24+00:00"}
* Chromium is no longer webkit. It is now Blink http://techcrunch.com/2013/04/03/google-forks-webkit-and-launches-blink-its-own-rendering-engine-that-will-soon-power-chrome-and-chromeos/
* Also tried to reproduce using http://browsershots.org/ I ran all browsers and couldn't find a screenshot that seemed broken

{sign user="xavi" datetime="2013-08-29T19:29:30+00:00"}
* Other user reports in irc.t.o a similar issue in t.o with Firefox browser:
+ [http://irc.tiki.org/irclogger_log/tikiwiki?date=2013-08-29,Thu&sel=72#l68]

https://tiki.org/calendar has gone mad, and self-refreshes indefinitely.

I wanted to reproduce a bug in the calendar using our own calendar there, but I could'nt and noticed this issue.

Coming from custom rewrite rules? Bug in recent 15.x code?

This used to work in the past at some point with some Tiki 12.x, according to the documentation written by lindon.
But it fails for me as soon as I set "server=y" in the params of Plugin TrackerList.

I've set up (modified) the profile Barter_Market so that the nice Tablesorter feature can be demonstrated (with server=n so far, of course) for the list of available wants.

This also allows to easily reproduce a failing environment (replace it to be server=y, etc). It has also been reproduced in a show.t.o instance attached to this bug report.

http://xavi-9794-5606.show.tikiwiki.org/tiki-index.php?page=Wants
u: admin
p: 12345

Filter for antything, and it won't work. Change param server=y to server=n and it will work again (except for the filtering on a tracker field "items_list": tracker_wants_offers_same_user).

In Tiki 12.x, you can filter for the field items_list tracker_wants_offers_same_user with no problems (provided server=n of course), but you can't filter on the status (which does work nicely in 14.x).

This tablesorter thing looks promising indeed! Thanks lindon!!!

Tablesorter: dropdowns in tsfilters and shown as text filters (most of them) when server=y

Reproduced at the show instance from this related report:
https://dev.tiki.org/item6200

http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6202
u: admin
p: 12345

edit the page, and you will see that many of the filters where set as dropdowns, However, they are shown as text filters.

Tags: Add a modern beautiful and advanced filtering with HTML5 and jQuery, such as Filtrify
https://github.com/luis-almeida/filtrify
http://luis-almeida.github.io/filtrify/
MIT Licensed

We would use it to let users browse more easily Profiles from https://profiles.tiki.org

Demos:
* Multiple categories: http://luis-almeida.github.io/filtrify/movies.html
* Load images with Lazy Load: http://luis-almeida.github.io/filtrify/lazyload.html
* Add pagination with jPages: http://luis-almeida.github.io/filtrify/jpages.html

When you have edit icons enabled for wiki pages and there is PluginInclude, the icon to edit the included page is in PNG format instead of the FontAwesome icon.

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).

Tracker field 'Date and Time (Date Picker)' gets current time as default value in mobile mode (12.x) even if set pref to 'None'.

This implies that if users only saves a few fields of the tracker form, and doesn't plan to set value for the date and time (date picker) fields, they will get stored current date value, even if that can be a wrong value (it should be empty).

Reproduced here:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

See field 14, in standard desktop-computer mode, and compare with Mobile mode (siwtch with link in module in left column)

Tracker field 'Dropdown with other' does not display the other field.
See it reproduced in trunk after applying the profile "Voting System" and attempting to add an item (cast a vote) using the other field.

To reproduce: login as
u: user1
p: user1
(plain registered user)

And go to

http://duqtape-11783-5792.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

where you will be able to insert new items,

You can admin the site with:
u: admin
p: 12345

Tracker field with Multiple selection list cannot be displayed in mobile mode, in 12.x

(untested in 14.x)

See it reproduced in:
http://xavi-9794-5642.show.tikiwiki.org/tiki-index.php
u: admin
p: 12345

# Switch to mobile mode (see link at the bottom on central column of page).
# choose "case A", and then,
# try to see the values for the field: "Case A. Multiple Selection List". Only one is shown.

Tracker fields of Radio buttons and multiple selection pre-select value 0 when it's one of the options even if not manually set as default

Set as options for that tracker field: 1,2,3,4, and no value is pre-selected (expected behavior)

Set as options for that tracker field: 0,1,2,3,4, and value 0 is pre-selected (wrong behavior; no value should be preselected, since no value is repeated twice)

Workaround (for radio buttons): 0,1,2,3,4, ,
(note that a space is set as option, twice, after value 4).

For multiple selections this workaround is not valid, since value 0 is also pre-selected.

Reproduced here:
http://xavi-9794-5599.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=1&cookietab=2

u: admin
p: 12345

See fields 5 (radio button) and 6 (multiple select)
---
{BOX()}
Update: {sign user="xavi" datetime="2015-03-26T09:37:35+00:00"}
Bug still alive, it seems jonny. I svn-up'ed to Thursday March 26, 2015 09:25:10 CET - REV 54744, and new items from your new tracker show a default value of "0" preseleected for the radio button, even if no value should be pre-selected according to the configuration.
See:
http://xavi-9794-5599.show.tikiwiki.org/tiki-ajax_services.php?controller=tracker&action=insert_item&trackerId=2&modal=1

And the radio button field definition ([http://xavi-9794-5599.show.tikiwiki.org/tiki-ajax_services.php?trackerId=2&fieldId=9&controller=tracker&action=edit_field]) still has as options: "0,1,2,3,4", so no pre-selection is expected, but "0" is pre-selected.
{BOX}