Category: Edit interface (UI)

Plugin Slider interferes with expected behavior of ui for anon in homepages.

To see it reproduced, visit this site (with a plugin slider),
http://seeda4c.org

And try to switch language que the correspinding module.

Something similar can be reproduced applying one of the featured profiles. (Company Intranet, afair)

Plugin TrackerToggle doesn't display the hidden field if attempting to change value in a previously saved itemId

I followed the documentation found here:
https://doc.tiki.org/PluginTrackerToggle
with this type of syntax in a pretty tracker page:
{CODE()}{TRACKER(trackerId="1" fields="2:5:10:11" showtitle="n" showdesc="n" showfieldsdesc="y" showmandatory="y" showstatus="y" wiki="Template1")}{TRACKER}

{trackertoggle fieldId="5" value=1 visible="y" id="condiv"}
{CODE}

And the wiki page Template1 contains:
{CODE()}
Field 2: {$f_2}
Field 5: {$f_5}
{DIV(id=condiv)}Field 10: {$f_10}{DIV}
Field11: {$f_11}
{CODE}

and the field is hidden by default, however it doesn't get displayed when the radio button gets the value "1" (yes) when visiting a previously saved item; e.g., with the url like:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3

(please note that this itemId3 has field5 stored with value 0 (case A). That's why even if you click (at item edition time) to the second value of the radio button (value 1 - case B), nothing is shown (because field5 has value 0 stored or in the session or something).

---

See it reproduced here:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3
u: admin
p: 12345

Plugin Convene should suggest by default the username of the user viewing the page as the one to be added.

With long lists of users, like in t.o, browser becomes slow due to the building of the long users list. It' would be way easier for most use cases if your own username was provided there as a suggestion (for logged in users) so that user just needed to click at "+" button.

PluginFade shows nothing in 16.x. It works as expected in 15.x, and in trunk, a new param has been added (bootstrap=y) which allows the plugin to at least show up.

Workaround? backport that ENH of param to fix PluginFade so that at least there is a way to make it work in 16.x

I create a demo on the instance {sign user="Bsfez" datetime="2016-12-31T06:54:06+00:00"}

((doc:PluginSlider)) lost start/stop control after upgrade from 12.x to 15.x

See the problem reproduced in doc.t.o, where the param to build Start/stop is set (buildstartstop="y" ), but nothing is shown:
https://doc.tiki.org/PluginSlider#Example

(compare with the screenshots from Tiki9/Tiki12 sites in the doc page)

Wasn't that fixed already in 15.x+?

see https://www.evernote.com/shard/s37/sh/682b16c7-5296-41d2-ab70-829d1bbf7b29/e0db8c152d5513bfa729ba484646e10c

The tiki popups have transparent background

While dealing with tracker data, the preference "Sortable Chosen Multi-selects" seems to not work at all. The jquery seems fine, in that I can drag and drop items, but when I go to save the tracker, it ignores the order in which the fields were sorted in.

I have noticed this predominately while editing a tracker item.

Editing a page with "CODE()] ... {CODE}", hitting preview produces a different visual output than the resulting page when hitting save: the code is boxed, but a different font is used.

DOM inspector says for the preview:
pre {
font-family: Menlo, Monaco, Consolas, "Courier New", monospace;
}

DOM for final page:
textarea {
font-family: inherit;
font-size: inherit;
line-height: inherit;
}

Maybe related to https://dev.tiki.org/item6214

{syntax type="tiki" editor="plain"}
Since Tiki27 (may be in tiki26 also) enabling the option "Preview Edits" on the "Editing and Plugins" panel at tiki-admin.php?page=textarea also add a "Preview" tab when you edit a text area field on a trackeritem.

This is pretty annoying as it is not optional and add more on an already crowded modal.

The help text and option on the "Editing and Plugins" doesn't says a lot about this.

I suggest that we keep the "Preview Edits" as parent checkbox and add subset of checkboxes:
* Preview Edits
** Wiki pages (enable by default)
** Trackers (disable by default)
** ...
''(There may be other features where it applies, Articles, Blogs, Forums, Calendar, etc)''

The label option could be clarified, something like; Preview Edits Tabs

when an new user installs tiki in a browser he does not see the progress of his installation it can cause him to cancel or start the installation again despite the fact that the installation is well done

[https://doc.tiki.org/Trackers | Trackers] in Tiki are [https://tikitrackers.org | touted] as an easy, convenient way to rapidly build databases and simple web interfaces for them, essentially simple knowledge management applications for all types of organizations. However, creating the interfaces to view them and integrate them into wiki pages is harder and more confusing than it should be, because it expects you to magically know the exact raw values to be used, instead of offering you choices of valid values based on the current combination of filters.

Let's say I want to quickly make a nice table showing a sortable and searcheable list of items from a Tiki tracker; to my understanding, I am supposed to use PluginList to do that (instead of TrackerList ..?), however when I try to use [https://doc.tiki.org/PluginList---Graphical-User-Interface | the GUI] to do it (as of Tiki 24 and older, this means clicking the "?" button on the right of the page content's editor toolbar, then clicking "Plugin Help", then searching for "List", then clicking the little icon on the left of the "List" name), I get a GUI that can help write the syntax... however, even if I somehow figure out that I need to add filters for:

* type="trackeritem"
* field="tracker_id" content="some number"
* field="some_other_variable" contents="something else"

...it's not really easy nor efficient, because it expects you to magically know and input the exact value needed, instead of offering you choices of valid values. This is annoying when editing an existing List, but it's even more annoying and intimidating when creating a new one, because you're facing a blank page and have no idea what to add where.

Ideally, whenever and wherever possible, it should provide a "picker" widget that lets you select among valid values. For example, in the case of tracker_id, it should show me a list of trackers with their names (i.e. some dropdown combobox widget that has not just the ID numbers, but also the nicknames of those trackers). Same with tracker_status, and various other fields; particularly for fields that have multiple choices (instead of raw strings that could be anything), it would make a lot of sense to present those choices to pick from.

I understand that Trackers are a power user tool, but certainly there would be areas in the GUI where Tiki could present "choices" and presets that accelerate the workflow and productivity, instead of requiring the user to memorize a bunch of numbers and raw values (and not make any mistakes) or have a big amount of browser windows open side by side to try to find the information in one window and input the information in the other. It would just be so much faster if the software could assist and speed up the human in this task; after all, that's what we have computers for!

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

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

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

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}

According the docs ([https://doc.tiki.org/Content-Templates#Use_it]) and past experience, there was an edit textarea on the content templates page (tiki-admin_content_templates.php) but, at tiki.org, the edit tab only allows editing of content template details, not the body of the template.

Maybe as a workaround, a wiki page can be specified for the template's content, but this is supposed to be just an alternative to composing on the content template admin page, not the only way to do it.

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.

When we have a textarea in non wysiwyg mode, the textarea can be resized by moving the bottom right corner.
The mouse changes its style as illustrated on the attached snapshot.

This works fine for FireFox but not for Mac-chrome or linux-chromimum.

The textarea can be resized, but the bug is, there is no hint about it so people miss the information because the mouse does not change shape.

You can reproduce on this very textarea using chrome (no need for a show instance :-) )

branch 12.x nowadays uses codemirror 3.16 (3.x is supposed to be right-to-left language ready).

I tried with hebrew, and the editor shows an extra scrollbar on the right of the screen, which hides the firsts letters of each sentence starting on the right margin.

Tested on Tiki 11 release (no svn) with page editing in mode wysiwyg.

If a second user (with proper perm) come to edit a wiki page (overrinding) he will see nothing in the editor bloc as he was getting into an empty page.

To reproduce on the show instance:
Open in one browser.
Log as editor1/12345.
Edit and let open in editing mode the homepage.

Open in a second browser.
Log as editor2/12345.
Edit the homepage, when warned the page is already edited by editor1, override.
You'll get an empty page.

Used to work.

Long overdue feature in TikiWiki:

http://en.wikipedia.org/wiki/Help:Section#Section_editing

[http://sourceforge.net/mailarchive/message.php?msg_name=435AF64C.1050106%40marclaporte.com|2005-10 discussion on the developer's mailing list.]

If "edit by section"=Y as a wiki feature, all H2 should create a bookmark and a section that can be edited individually. As an option, all heading levels could become sections.

Section edit should be optional and there should be a syntax to override (either way)

More explanation from our friends at WikiMatrix:
http://www.wikimatrix.org/wiki/feature:section_editing

12.x - 15.x: Tracker: filter items is broken when radio button with labels set (0=No,1=Yes,2=Dunno).

No matches are found when there are some items which met the intended criteria.

--It'll be-- reproduced in an attached intance --in short. Stay tuned!-- :-) {sign user="xavi" datetime="2016-02-09T12:21:27+00:00"}
Login in here:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
u: admin
p: 12345

You will see the field TestRaduio, with some values (0, 1 and 2; their labels, in fact)

Try to filter by that field:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=f__asc&filterfield=8&filtervalue%5B1%5D=&filtervalue%5B2%5D=&filtervalue_other=&filtervalue%5B3%5D=5+%28high%29&filtervalue%5B8%5D=0%3DNo&filter=Filter#
---
__Update:__ {sign user="xavi" datetime="2016-02-10T10:42:06+00:00"}
the problem is also found (and still unsolved) at teh trackerfilter level. Sorry, I tried for one hour, but I couldn't get the right syntax to port this type of fix there also. :-/
To reproduce, see it here:
http://xavi-9794-5810.show.tikiwiki.org/tiki-index.php?page=HomePage

__The issue is reproduced also for dropdown fields when labels are set, etc. See it reproduced with field "Priority" (Dropdown). __

__Reproduced also with "Dropdown with other" (field __Location__) in the tracker itself, but it works as expceted through Plugin TrackerFilter.__
Does work:
http://xavi-9794-5810.show.tikiwiki.org/tiki-index.php?page=HomePage

Doesn't work:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=f__asc&filterfield=2&filtervalue%5B1%5D=&filtervalue%5B2%5D=0%3Droom+1.1+%2855+seats%29&filtervalue_other=&filtervalue%5B3%5D=5%3Dhighest&filtervalue%5B9%5D=y&filtervalue%5B10%5D%5B%5D=1&filter=Filter#

Multiselect seems to work well, as expected, in both tracker itself and plugin trackerfilter.