Category: Edit interface (UI)

Please see: ((tw:CMS Landscape)) and ((tw:Wiki landscape)) and try to edit those pages without getting lost.

Now you understand what we need :-)

Also: https://doc.tiki.org/Unified+Index

This looks cool:
http://twiki.org/cgi-bin/view/Plugins/EditTablePlugin

CSS... Themes...

http://www.horde.org/imp/docs/?f=CHANGES.html

[cjh] When a user's session times out while they are composing a message, give them a special login screen which displays the message and allows them to log in again to resume their message with all data intact.


[jan] Show timeout warning if session is about to expire.


Similar: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1094

I just tried making a button in master and this is the result:

{CODE()}{button plugin_edit_row="((Homepage))" plugin_edit_row="Go to Homepage" plugin_edit_row="smile" plugin_edit_row="50px"}{CODE}

The parameter names are incorrect, obviously.

Update: I checked the articles plugin also and it shows the same broken behavior, so maybe this is true for all plugins. I added blocker status to this bug.

Can not edit Wiki Pages in Tiki 13.0 using Chrome or Netscape. IE10 is working fine.

Details: I upgraded my Server from Tiki 7.0, PHP 5.2, MySql 5.1 to Tiki 13.0, PHP 5.6, MySql 5.5.

I needed to do the Datebase Upgrade with the console.php. Otherwise tiki-install.php stuck with an error in Perms/Context get_user_xxx:

Then I did choose Unified Search and upgraded and rebuild the index with the console.php.

After this I can edit Wiki pages using the IE10 10.0.20 x32 or x64 Browser just fine!

But Chome and Netscape Browser on Windows and Linux both x32 and x64 versions are have all the same error: They do not allow to put the cursor into the edit pane and there seems to be somthing that blocks the mouse and cursor to get to the edit textarea.

Can someone verify this behavior?

Has someone a solution for this?

Now the details of the used browsers:

Working: => Wiki page edit pane is functional and I can edit the content and save it successfull!
*Internet Exporer IE10 Version IE 10.0.9200.17088 x32 Win 8.0 x64
*Internet Exporer IE10 Version IE 10.0.9200.17088 x64 Win 8.0 x64


Failing: => Wiki page edit pane locked. Can not enter or change anything of the content.
*Google Chrome - Version 37.0.2062.124 m (64-bit) Windows 8.0 x64
*Google Chrome - Version 37.0.2062.120 (64-bit) Linux/Debian 7.6 x64
*Mozilla Firefox 32.0.3 x32 Windows 8.0 x64
*Mozilla Firefox 32.0.3 (64-bit) Linux/Debian 7.6 x64

Info: There are no difference if I try to edit a new wiki page or an existing one.

I tried to add my name to the schedule created with plugin convene in ((Tiki11)) and clicking at the "Add user" button (or Add date) did nothing when I was visiting the page with mobile interface. Same with the button to edit choices.

Same issue with Chrome or Firefox on Android.

---

To reproduce:
http://xavi-9794-4778.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage

u: admin
p: 12345

Change to mobile (link in module in the right column)
Click at "Add user" button (or Add date)
Nothing happens

Hi:
For some reason I can't get login popup to *.t.o sites from android smartphone.
* t.o/forums: I can't see the "Log in" part on the top horizontal bar of the site, that I see using a desktop computer.
* dev.t.o: I can see indeed the "Log in" part on the top horizontal bar of the site, but clicking on it does nothing (apparently) for me.
* dev.t.o: clicking on the icon to display the contents of the top horizontal bar of the site does nothing for me.

:-/

We need improvements to that *.t.o site-bootstrapification maybe?

Xavi

can't upload an image to a file gallery in doc.t.o with elfinder (default UI) since 16.x

To reproduce:
#I'm logged in as user "xavi" (with no admin perms, I mean)
#I edit one page, e.g. ((doc:Tiki17))
#place the cursor somewhere in the text.
#Click at the button from the toolbar to "Choose or upload images"
#The elFinder UI popup is shown with no contents, and I?m not able to click anywhere (browser non.-responsive), while I can't only get access to use the browser again when the wiki pedit page is automatically refreshed with the elFinder automatically disappearing.
#Reproduced also after clearing my Browser cache, and Tiki caches, with Chromium and Firefox.

{syntax type="tiki" editor="plain"}
Filtering by category in trackers yields zero results. However, there are tracker items in the category, and they appear if you browse the category. Other filtering appears to work properly.

The URL appears to be malformed:


Note the extra bracket after filtervalue[33] parameter.
http://www.casesofinterest.com/tiki/tiki-view_tracker.php?trackerId=7&status=o&sort_mode=lastModif_desc&filterfield=33&filtervalue[31]=&filtervalue[32]=&filtervalue[49]=&filtervalue[47]=&filtervalue[41]=&filtervalue_other=&filtervalue[35]=&filtervalue[33][]=102&filtervalue[40]=&filtervalue[34]=&filtervalue[45]=&filter=Filter

However, manually removing the extra bracket also fails:
http://www.casesofinterest.com/tiki/tiki-view_tracker.php?trackerId=7&status=o&sort_mode=lastModif_desc&filterfield=33&filtervalue[31]=&filtervalue[32]=&filtervalue[49]=&filtervalue[47]=&filtervalue[41]=&filtervalue_other=&filtervalue[35]=&filtervalue[33][]=102&filtervalue[40]=&filtervalue[34]=&filtervalue[45]=&filter=Filter

chosen lib prevents changing the sorted order display of fields from an items-list tracker field with the translation smarty system

Workaround: disable chosen lib temporarily, make your changes to the selection of fields to be displayed, and/or the sort order, save (and reindex if necessary), and you can enable chosen lib again later on.
At least this worked for me so far.

See show instance and screenshot

When typing a text in a rather regular mode, the CKEditor loses some keystrokes, so that the text has to be reviewed.
Whereas in V12 it would happen randomically, in V13 it happens at regular intervals, as if the editor would make an auto-save, and would stop being responsive for that time lapse.

Make 1.9.11 and 1.10 consistant
Remove less used quicktags and add some in the spirit of ((EditUIRevamp))

Clicking on icon after file upload from text area through toolbar icons fails for me to add the right syntax for that file

Reproduced in https://adup.cat (in case theme style matters, etc)

The code that got inserted said something like "cat" or "file" with no number or fileId, etc.

See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

{img fileId="1397" thumb="box"}

Dev.t.o has the Syntax highlighter enabled, with theme as: "Off (but switchable)"

I'm editing this page:
http://dev.tiki.org/tiki-editpage.php?page=Tiki12

as user xavi, with Chrome, and I can't see the button to switch the highlighter on.
---
Weird: after a while, the button is shown again. {sign user="xavi" datetime="2013-11-04T18:50:52+00:00"}
---
I can't reproduce it anymore. Who knows... Closing item.

Codemirror does not respect off-bs-by-default in L&F & extra white space & false scroll

To reproduce for the time being, see
http://demo.tiki.org/12x/tiki-admin.php?page=look&cookietab=6

Codemirror set to "__Off (but switchable)__".

!!! Issue 1: Codemirror does not respect off-but switchable by-default in the admin panel Look & Feel

Custom css text area respects the codemirror default setting, but Custom HTML head does not (and neither they do custom bottom code nor custom javascript, which show codemirror on by default)

{img fileId="679"}

!!! Issue 2: Codemirror shows extra white space & false scroll

See custom code before the closing body tag

{img fileId="680"}

Notice the big space at the bottom, and the scrolling bar indicating that there is more content at the bottom (but it's not shown in the white space below).

When you scroll down a bit, you see that there some some more code indeed:

{img fileId="681"}

But that should be shown using all the available space in the textarea in the first instance.

----
Issue Still present on 06 February, 2014 15:02:50 CET- REV 49772. {sign user="xavi" datetime="2014-02-07T09:19:46+00:00"}

Codemirror: button to switch it on is hidden when first the editor is set to fullscreen

This was working in Tiki9.

To reproduce:
* Set codemirror feature to on, and mode to "Off (but switchable)"
* edit one wiki page with the plain text editor
+ notice that the button to "switch highlighter" is shown below the textarea. Do not click on it yet.
* click at full screen icon in the toolbar
+ notice that the button to "switch highlighter" is gone from the textarea surroundings

{flash type="url" movie="display683" width="778" height="654"}

----
Issue Still present on 06 February, 2014 15:02:50 CET- REV 49772. {sign user="xavi" datetime="2014-02-07T09:21:05+00:00"}

The foreground color picker ({img src="img/icons/palette.png"}) in the edit toolbar for a wiki page displays a blank white rectangle instead of the grid of available colors.

This doesn't seem to be an issue for a tracker edit toolbar (e.g., the toolbar for this description field).

To see an example, just open up the edit area for any wiki page on this site or any of the tiki.org sites that are on Tiki12, and then click the {img src="img/icons/palette.png"} icon in the toolbar.

{img fileId="676"}

Colorbox in mobile 12.x LTS doesn't show up properly (empty black screen with a encircled cross in the middle)

To reproduce, see show.t.o instance:
u: admin
p: 12345

Load the homepage, switch to mobile, and click at the link in the homepage: "wiki syntax"

When the Strasa theme is selected, the tiki edit structure page is unusable. The Page Alias box(es) background is the same color as the text within. Making the text invisible on the screen and thus impossible to edit / update / review.

Consolidate menu types as just Bootstrap menus. That is, remove suckerfish and legacy - neither Bootstrap nor suckerfish - menus. Then add Smartmenus ([https://www.smartmenus.org/]) to enhance/extend Bootstrap menus to regain features lost by the removal of suckerfish menus.

UPDATE: Smartmenus feature has been added to branch 19 and trunk and will be configured and bug-fixed hopefully before the release of Tiki 19, or soon thereafter. The feature is optional of course and is marked as experimental for now.

TODO: resolve any issues in Smartmenus integration in Tiki. Longer term, evaluate removing CSS menus (suckerfish/superfish menus) when it's determined that Smartmenus makes them redundant.

It should be at the very least possible to add content templates where the cursor is, like ((quicktags)).

This was working in previous versions of Tiki (maybe oldish ones: 6.x, etc, afaik). I couldn't check when the regression was introduced.

Default Duration length in calendar events misscalculated (2h while times were from 18h to 19h)

See it reproduced:
http://xavi-9794-5901.show.tikiwiki.org/tiki-calendar_edit_item.php
u: admin
p: 12345

At posting time, the times where shown (depending on where you click to add the event) either as from 0:00 to 1:00, from 18 to 19h, or from (in my last case) 10:41 to 11:41h.
But you you click at "Show Duration", they display 2h in both cases, even if they should display 1h.

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.