Category: Edit interface (UI)

Tracker inline editing & Dynamic items list: Options in 2nd field are not updated when the first field is changed.

To be reproduced in a show.t.o instance.
u: admin
p: 12345

http://xavi-9794-5033.show.tikiwiki.org/tiki-view_tracker.php?trackerId=2

Change Product Name "PostgreSQL" to "Oracle DB". Therefore, Product Version should be changeable to "10.2.0.5", but it's not.
It doesn't even show in this show.t.o instance. In an intranet with other data, it shows, but witht the old values, not the new ones to be offered (10.2.0.5 in this case, for instance).

--Tracker inline editing: 2nd field in Dynamic items list cannot be edited (empty dropdown)--
Update {sign user="xavi" datetime="2013-12-04T11:20:22+00:00"}:
* This has been either fixed partially, or it was not properly reported.
* In either case, the real issue as of r48534, is that when Jquery chosen is enabled, the second field in a dynamic items list (the 2nd drop down) doesn't get the appropriate width to display the labels longer than just one or two characters. The labels seems to be there, and the right options seem to be chosable. The problem is that they are not displayed in full with, and user cannot read the options.

Reproduced in the associated show.t.o instance:
u: admin
p: 12345

http://xavi-9794-4942.show.tikiwiki.org/tiki-view_tracker.php?trackerId=2

Log in as admin, and click on the Product Version "10.2.0.5" on the row for "ERP | Oracle Database"

The dropdown just shows 10., instead of the full label 10.2.0.5.
The same happens without tracker inline editing, i.e., editing the item, such as:
xavi-9794-4942.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=6&show=mod

Instead of this:
{img src=images/code.png}%%% {CODE()}
*[tiki-view_tracker_item.php?itemId=909|Integrating fotonotes or wikigraphe or DOM Image annotation to the Image gallery]
{CODE}

I should be able to indicate something like:
{img src=images/code.png}%%% {CODE()}
*{bug909}
{CODE}

and have the nice link generated. And if the title of the bug changes, I am OK. Having some more info about the bug in a mouse over would be a nice bonus!

Having a drop down menu or bug picker would be sweet too!

Maybe even some backlinks detection!

You can see an nice example here that even has a bug icon
http://winscp.net/eng/docs/history

FYI, the implementation of Plugin TrackerCalendar in trunk (with the new lib installed through packages) doesn't allow the user any more to move an item from the row corresponding to one resource towards the row corresponding of another resource.
Tested with the "Collaborative Community" profile.

I tested today the plugin helper ui to select fields in plugin trackerlist, but I had no way to get my typing stored/saved in the page for the "fields" param: numbers got lost when clicking elsewhere, and text (field names) didn't make any matxh in the dropdown.
This used to work with no problems in the past (Tiki15 LTS at least).
Editing by hand in the wiki textarea (aside of the plugin popup helper ui) worked as expected for the param "fields" in plugin trackerlist, but new users got confused aboput why that text input/dropdown for "fields" in plugin trackerlist didn't work in the popup helper.

Right now, translating a page is a 2-step process and it's not super easy.

When editing new wiki page (normal edit mode) and trying to insert a wiki plugin from the Help plugins icon it does nothing when finding the plugin you want and clicking the plugin icon.

!Impossibility to modify and save item
I'm a registered user with minimum functionality "Registered user" in the "Video" group.

In trying to modify my Consultant profile, I encountered several difficulties.

The main difficulty is that I am unable to modify the content. Let alone my img, I want to modify my description.

!My consultant profile
Here is the url of my consultant description: https://tiki.org/item6579

!Unable to save
Here is the screen capture showing that once I completed my modification, I'm unable to save. It looks like the saving button becomes idle but never finishes.
::{img fileId="1252" thumb="box"}::

If someone with admin access can replace the text for the one below in the meantime this bug that was discovered, it would greatly help me get this new contract I'm working on getting so that the prospects looking at my profile can say: Oh, Daniel and his TelePartout can help me resolve problems I have with my business development and he can refer me to the correct resource.

!-Here is the replacement text
{CODE(caption="Here is the replacement text",wrap="1")}
-=Intermediate Super User - Business Development consultant and Social Media specialist =-
Daniel is [http://tiki.org/UserPagedaniam|a member] of the Tiki community since 2011. His company [http://telepartout.com|TelePartout.com] is a 360 sales development company.

::~~#C00:A service bureau offering the help __you need!~~__::

Per example, get pages created, calendars, forums, blogs looked after with content that makes sense, etc.

[http://tiki.org/UserPagedaniam|Daniel] does translation and transcription too: English, French and Spanish.

And yes, [http://telepartout.com/BSNE|TelePartout loves to see what's coming up on your nearest screen] . If you need help, it's possible. See one of the ((Video Clips|video)) page Daniel maintain.
{CODE}

Firstly, this bug is being submitted assuming I am operating the editing interface correctly.
The main issue is, when configuring the editor tool bar at tiki-admin_toolbars.php there is a drop down menu for Global, Admin, Articles, Wiki Pages.
I have always assumed that when for example, I choose "Admin" from the drop down menu and I click on load to load the admin tool bar, while the "View Mode" is set to "Wiki and Wysiwgy" and if I assign specific tools to the editing tool bar while in the "Admin" preview, and click on save, then I should be able to see a different tool bar other than what a "Global" user would see in both the Wiki and Wysiwyg toolbar.
This would allow me as an Admin to have the ability to use the "code" or source feature, but on the Global tool bar, the "code" or source feature would not be available to non admin users.
Assuming I am correct in how I see this should work:

After customizing the tool bars for Global, and Admin while in "View Mode" for Wiki and Wysiwyg, and when I go to edit a page as an Admin using the syntax tool bar, I do not see the Admin tool bar, I can only see the Global assigned tool bar. Since Tiki15 (I never used Tiki12) I have never been able to have the option of using different tool bars as assigned at tiki-admin_toolbars.php

A show instance will be created to demo this bug.

Please see:
http://universaleditbutton.org/

Related:
*[wish1781|Support for the Wiki creole markup (syntax)]


In testing now on:
http://wiki-translation.com

Commit:
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=rev&revision=13295

I don't know how to fix this one myself.

Icons are defined in the sql schema. therefore the logic to display the icon needs to be adapted to use
{CODE()}
{icon name="foo"}
{CODE}

instead of the img html tag.


See it reproduced here:
--http://xavidp-1553-5651.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=43&offset=0&sort_mode=position_asc&optionId=195&maxRecords=25#contentadmin_menu_options-2 --
u: admin
p: 12345

----
Confirmed issues still exists in Tiki18.0 {sign user="xavi" datetime="2018-02-05T19:39:10+00:00"}
---
Re-reproduced in 18.2svn {sign user="xavi" datetime="2018-04-03T16:08:42+00:00"} in a new show.t.o instance (even if the issue is more easily shown when upgrading a previous tiki site where those settings where more easily ticked):
Login as admin here:
http://xavi-9794-5783.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=42
u: admin
p: 12345

You need to ensure that the menu is not using bootstrap but css, plus the setting enabled to use icons for menus (done already in the show.t.o instance)

Cheers

Update PluginVersions to Bootstrap classes (missing tabbed-like display). Tab titles show up as if they were plain text. However, if you click on them, links do work indeed. It¡s just a question of missing css classes, I guess, to restore the intuitive display.

See:
https://doc.tiki.org/PluginVersions#Basic_example

And compare it with:
https://doc.tiki.org/pluginTabs#Example

These plugin was used in doc.t.o pages. It looks like a standard Plugin Tabs, but the difference is that when you click on a tab title, all sections with plugin tabs siwtch to that version, so that you can print a long page (ideally, a whole wiki structure) with the sections related to that version of the software set to display its contents in place.

Something like these css properties might be missing at __./themes/default/css/default.css__ in trunk:
{CODE(colors="css" ln="1")}
/* Versions plugin */
.versionav {
padding: 0;
border: 1;
margin-bottom: -1px;
border-color: #eeeeee #eeeeee #dddddd;
border-bottom: 1px solid #dddddd;
}

.versionav .button {
margin-bottom: -1px;
}

.highlight {
background-color: #f5f5f5;
color: #262626;
margin-bottom: -1px;
border-top: 1px solid #e2e2e2;
border-left: 1px solid #e2e2e2;
border-right: 1px solid #e2e2e2;
}
{CODE}

{syntax type="tiki" editor="plain"}
{maketoc}
!Problem Summary
The dialog structure for uploading a file and adding a link to it in wiki page is much better than it was, thanks to the introduction of the __File__ icon in the toolbar of the wiki editor. But it is still cumbersome and error prone. Here is the process below and the usability issues that I found at various spots.

# Click on the __File__ icon
# Pick __File Gallery/Archive__ in __Type__
# Click on __Pick a file__ link
# Click on the __Upload File__
# Click on the __Browse__ button
# Click on __Upload__ button
# Browse the file system and pick the file.
# Once the file is uploaded, click on its name.
# Click on __Insert__ button

Besides the fact that this is long, there are many places where it is misleading to the user (details later). I had to try this more than a dozen times, clicking on different items, to figure out how it works. And I had help from some experts on the mailing list!

Fortunately, there are a number of very small fixes that we could implement to address those issues. See below for a discussion of the various issues and proposed fixes.

!Issue 1: __Type__ should have a reasonable default
Currently, the type is set to empty. It really should be set to either __File Gallery/Archive__ or __Attachment__ by default. Personally, I would favour __File Gallery/Archive__, because I think it's generally a bad idea to attach files to a wiki page, because it limits your ability to link to those files from other pages. But the point is: the value should default to what users most commonly use.

In some cases, the picklist only has one option in it anyways (ex: if the feature for attaching files to wiki pages is off). In those cases, then the picklist should DEFINITELY default to that single value.

^Fix: Set the __Type__ to a sensible default... I vote for _File Gallery/Archive__^

!Issue 2: __Pick a file__ link looks more like a caption than something you can click on
I never realized that I could click on it to choose the file. Someone had to actually point that out to me. Others on the mailing list have said that they need to point this out to users all the time.

^Fix: Change the link to a button^

!Issue 3: Too easy to miss the __Upload__ button
Once you click on __pick a file__ link, you are presented with the general screen for navigating and managing the File Gallery. But at this point in time, you are only intersted in uploading or choosing a file from the gallery, and seeing this complex dialog is very disorienting. In my case, I managed to miss the fac that there was an __Upload__ button on that screen, and I thought I had mad a mistake and someone pressed the wrong button or link in the previous screen. I had to go back to the previous screen several times and click on different things, and finally come back to clicking __pick a file__, and then I saw the __Upload__ button.

^Fix: Instead of having a single __Pick a file__ link (well, button, if we implement the fix to Issue 2), we should have two buttons: __Upload__ and __Choose from Server__. Or something like that (I can't think of a good workding). The __Upload__ button will take you directly to the place you currently get to after clicking on the __Upload__ button in the File Gallery screen. The __Choose from Server__ button will still take you to the __File Gallery__ navigation and management menu.^

!Issue 4: Not clear that you have to click on the file name after uploading
In Step 8, there is nothing that tells you you need to click on the file name after you uploaded it. I went through the whole process several times and it never occured to me that I had to do this until someone from the mailing list told me.

Note that there is a message to that effec that appears if you hover the mouse over the file's name. That message really should be visible at all times, not just when you hover over the file name.

^Fix 1: Make it so you don't need to click on the file name altogether.

Fix2: If that's not possible, at least put a very prominent messages saying that the user needs to click on the file name^

!Issue 5: Insert button is not clear.
In Step 9, you are back at the original pop up, and you need to click on the __Insert__ button, otherwise the link to the uploaded file does not get inserted.

Again, I had to do the process several times before realizing I had to do this. My natural tendancy was to close the popup, either by Xing it or clicking on the __Close__ button. The result is that the file does not get inserted on the page.

I think the problem is that the two buttons at the bottom say:

__Close__ __Insert__

And you naturally tend to click on the first of these two, i.e. __Close__.

^Fix: Change the order and caption of the two buttons as follows:

__Insert link__ | __Cancel__

Also, if the user clicks on the X to close the window, the link should be inserted (in other words, __Insert link__ should be the default). The reason is that it's easier to recuperate from that error (you just need to erase the link) than to recuperate from the other error (you have to start again from the beginning, to insert the link).
^

{syntax type="tiki" editor="plain"}
On a Tiki29.x (tested before and after Tiki29.1 release) when I use the Wiki page, Action, Edit icons nothing happens.

On a Tiki Wiki 29, when I try to edit a plugin using the plugin edit icon it doesn't open the dialog.

In the console I see it create a 500.

I see in the PHP error logs:
{CODE()}
[Sun Feb 08 20:34:34.809307 2026] [proxy_fcgi:error] [pid 3852014:tid 140443887073024] [client 127.0.0.1:53564] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function TikiLib::safeFileExistsInPath(), 1 passed in /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Edit/PluginController.php on line 273 and exactly 2 expected in /var/www/vhosts/mydomain.org/httpdocs/lib/tikilib.php:7314\nStack trace:\n#0 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Edit/PluginController.php(273): TikiLib->safeFileExistsInPath()\n#1 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Broker.php(140): Services_Edit_PluginController->action_edit()\n#2 /var/www/vhosts/mydomain.org/httpdocs/lib/core/Services/Broker.php(27): Services_Broker->attemptProcess()\n#3 /var/www/vhosts/mydomain.org/httpdocs/tiki-ajax_services.php(53): Services_Broker->process()\n#4 /var/www/vhosts/mydomain.org/httpdocs/route.php(400): include('...')\n#5 {main}\n thrown in /var/www/vhosts/mydomain.org/httpdocs/lib/tikilib.php on line 7314', referer: https://mydomain.org/Mypage
{CODE}

I checked PluginController.php, safeFileExistsInPath.

The function safeFileExistsInPath() requires two parameters: the file and the directory to check it against. But in PluginController.php, it's only being called with one parameter.

{syntax type="tiki" editor="plain"}
This isn't so much WYSIWYG as the wiki editor but see no such feature checkbox.

Anyway if you click a wiki editor button twice, like bold, I expect it to undo the action, like the WYSIWYG editor. Instead it tries to make the text doubly bold, which is apparently not possible.

Also if you use a button and drop focus from the editor, I expect the preview Ajax to update as usual, but it does not.

The problem: Say I am multi-tasking.

1- I start editing a wiki page
2- I check my thunderbird email.
3- I click a link in my email
4- That link could take over my browser and I lose what I was editing. Not fun.


This is what we need:
http://marclaporte.com/tiki/FeatureRequest_BetterHandlingOfBackButtonWhileEditing.swf.html

And that solution also works when you are clicking a link in an email. (not just back button)


other causes of ((doc:lost edit)) are listed in documentation.


similar: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=971

Wiki "((doc:edit by section))": Nice feature added, thanks heaps to those who made that possible! :-)

BTW, I found that it doesn't allow concurrent edition of different wiki sections of the same wiki page.
Tried on doc.tw.o on June 8th 2008, using Mittwoch and also Tikinewt.css (After clearing tiki cache) , and it didn't work for me on any of both cases.

doc.tw.o page needs to be updated once fixed.
http://doc.tikiwiki.org/edit+by+section

I've upgraded today to latest 20.x (to r71082, from svn code from 1-2 months ago or so) and attempting to insert wiki code to display a file in a wiki page (just after file upload) fails: not the full syntax is written, just "file", and no fileId either.
File seems to get uploaded successfully indeed, but the popup helper (open through the toolbar icon to upload files) fails to display the information that the file was uploaded successfully, not to insert the right syntax to that file.

{img fileId="1329"}

Reproduced with updated Firefox and Chrome, on Ubuntu GNU/Linux 64 bits (in case it matters)
And reproduced in dev.t.o also (provided that the tool -+tikifile+- has been added to the editor toolbar.{sign user="xavi" datetime="2019-09-27T11:06:15+00:00"}

Using standard file gal interface (not elfinder), and standard wiki editor toolbar, and using toolbar icon -+tikifile+-.
Same process to upload images works as usual, as expected.

With MediaWiki, before you save, you can review changes. It shows what you __will__ change (if you click save), in wiki diff format.

This is very nice.

Sometimes, we have done several edits, and we are not sure exactly what we changed (supposing we are multitasking or interrupted). It is nice to be able to review this and fill out the edit description accordingly

Useful for translation as well:
http://wiki-translation.com/tiki-view_tracker_item.php?itemId=51


Related:
*{wish id=2102}
*{wish id=1843}
*{wish id=1220}

In Opera (9.6), the wiki edit page only displays as far as the quicktags (these show), then the page display hangs and nothing else loads. This is with the normal editor.

Since I upgraded some site to Tiki 18.x (svn), I can't edit properly wiki pages through the mobile phone (using Chrome on Android, in case it matters).

Once the page is open for edition, copy & pasting some url from elsewhere (for example) get your url appended with some extra text each time you click elsewhere in the same edit, or even if you just hit at the save button afterwards.

If you disable codemirror highlighter for the time being in that edition, then no extra text is prepended and you can save as expected.
---
Similar issue still present in 20.x{sign user="xavi" datetime="2019-07-06T17:58:57+00:00"}

Reproduced with an android based device (using chrome) in:
http://xavi-9794-6662.show2.tikiwiki.org/tiki-index.php?page=HomePage
visit with mobile device, enable codemirror highlighter, and attempt to edit the text.

In addition to smilies and text formatting like bold, add syntaxes for commonly uses markers in text.

Please see some nice examples here:
http://wikifeatures.wiki.taoriver.net/TextFormattingRules

Which are inspired by :
[http://moinmo.in/HelpOnSmileys|MoinMoin]

I like:
/!\ warning
(./) check
{OK} thumbs up
{i} information
{1} {2} {3} for nice numbering

We currently use images at doc.tikiwiki.org and it's cumbersome.


From #wiki (freenode)

(11:20:53) TheSheep: marclaporte: btw, if you need some icons, there are some I drew at http://sheep.art.pl/Icons
(11:21:10) TheSheep: marclaporte: especially the hand icons can be... uhm... handy
(12:16:35) marclaporte: hehe
(12:17:52) marclaporte: for icons: is license compatible with LGPL?
(12:18:15) marclaporte: I wish we had a license compatibility grid for CC vs GNU
(12:19:58) TheSheep: marclaporte: I can relicense it for you
(12:20:17) TheSheep: marclaporte: although using gpl for something that's not software is weird for me
(12:33:22) marclaporte: yes, but icons have to in the app, no?
(12:42:45) TheSheep: marclaporte: but icons are also distributed when somebody merely uses the web app
(12:43:00) TheSheep: marclaporte: would you want to force them to provide the source code?
(12:44:49) marclaporte: I just don't want any trouble
(12:45:02) marclaporte: and to respect author's wishes
(12:45:51) TheSheep: marclaporte: I can promise I won't give you any trouble, just tell me what you need to use them :)
(12:46:01) marclaporte: hehe
(12:46:13) TheSheep: marclaporte: it will also help me to release my future works in a way that is friendly for developers
(12:46:22) ***marclaporte is adding on todo list

After using the fullscreen icon while editing a wiki page and then going back to normal mode it breaks the whole usability of the form; textarea is too wide (some icons out of viewport), some b0rked parts appear. (Wrong forced CSS caused by wrong jQuery usage?)

Last time I saw it working correctly was in Tiki 9.

{syntax type="tiki" editor="plain"}
In edit mode, if I do

{CODE()}
((
{CODE}


(and maybe a few letters), an auto-complete should appear, like the quick_edit module. This list should be WYSIWYCA.


This would also be useful in some plugins, when a parameter is wiki=

The most important is ((doc:PluginInclude)), because the main goal of the plugin is to include other pages, which you may not know the exact name.

When in plugin edit mode, an auto-complete could be done with jQuery (ask LPH for details)

Related:
{wish id=480}

In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.