Category: Edit interface (UI)

Using the Footnote UI while editing, I can enter a footnote the first time only during a single editing session. If I try to use the Footnote UI a second time during the same editing session, the UI fails to open.
I have to save the first edit completely, then edit again, and use the Footnote UI to add an additional footnote.

So, the UI will only open once, per editing session.
Bug will be shown on "show instance".

{syntax type="tiki" editor="plain"}
When trying to add a new module in ADMIN MODULES>EDIT MODULE TAB> GROUPS
Select list the module is visible to.
I can click on an item such as Admin, Editors etc...
BUT
The item does not get selected and set/saved.

Forum editor (wysiwyg?) can't be loaded in mobile device (tested with chrome on android smartphone).

Example url:
https://next.tiki.org/tiki-view_forum_thread.php?comments_parentId=52179

If it can't be properly fixed, at least wysiwyg editir shoukd be disabled when in mobile devices?
---
^ __Update as of March 16th 2015 __
Bug still present in next.t.o (sorry, I can't see the revision number any more at "Settings > Control Panels > General > General Preferences").
I did clear the ./temp/public/ cache folder, reloaded the url indicated in the bug report in a browser at the computer (wysiwyg shown), and then something equivalent on Chrome on Android smartphone, and still can't see the textarea to type.

So please, don't close a bug report unless you tested the fix with the described steps to reproduce it, even if some other bugs are fixed that "should" or "might" also fix the reported bug, etc. At the most, change status to "pending" while requesting to the bug poster to "Please retest". And thanks wolfgang for all you efforts to improve Tiki: they are very welcome!
{sign user="xavi" datetime="2015-03-16T08:43:49+00:00"}

In addition, no editor shown at the show.t.o instance attached to this bug report with Chome on GNU/Linux PC, using 14x r54428, either:
http://xavi-9794-5559.show.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=1
u: admin
p: admin
^

The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.

The FullCalendar UI doesn't load in Mobile mode, neither in the Calendar nor in the ((doc:PluginTrackerCalendar)) features.
Therefore, nothing is hsown at all for the user.

Potential Solution/Workaround: at least use the former calendar UI as a fallback?

Reproduced in the show.t.o instance:
http://xavi-9794-4993.show.tikiwiki.org/tiki-calendar.php

u: admin
p: 12345

when you switch back to use the former calendar UI (you disable full calendar: http://xavi-9794-4993.show.tikiwiki.org/tiki-admin.php?page=calendar > "Use FullCalendar to display calendars"), then the standard Tiki Calendar ( http://xavi-9794-4993.show.tikiwiki.org/tiki-calendar.php ) is shown.

The PluginTrackerCalendar uses only FullCalendar, and it would be appropriate, I guess, to make it show tracker items in the former Calendar UI at least (since no calendar is shown at all, since it's hardcoded, so far, to use only FullCalenadar). It can be reproduced here:
http://xavi-9794-4993.show.tikiwiki.org/tiki-index.php?page=Community%20Members%20HomePage > "3. Add other tentative events in the common Agenda"
(see that section with non mobile mode to compare)

"Fullscreen Edit" is a new cool feature of 2.x

Quicktags are kept, but Wiki & Plugins Help are missing so it makes editing less enjoyable.

"Edit Summary" is missing as well. Maybe it's intentional?

See the attached screenshot:
{img src=https://dev.tiki.org/tiki-download_item_attachment.php?attId=498&display thumb=box}

To reproduce:
# edit a wiki page on https://doc.tiki.org
# in the edit mode switch to fullscreen edit mode using the icon in the toolbar

fullscreen=y hides all info from top navigation bars in dev.t.o, doc.t.o and themes.to

To reproduce, compare this:
https://dev.tiki.org/tiki-index.php?fullscreen=y

with
https://dev.tiki.org/tiki-index.php?fullscreen=n

If the user didn't change the value of the destination of the help system, it should be updated to what the default value is now.

Need to hunt down what all the previous values were (ex.: http://doc.tikiwiki.org/tiki-index.php?page=) and to update via sql

And for clean installs as well (of course)

However, if someone modified the default value, we don't touch.


Reminder to add a reset to default value in 3.0 (new admin panel should permit this)

href from links (with wiki or html tags like "a", "img", plugin ALINK, ...) do not work at all under 12.x LTS mobile mode. They are missing data-ajax="false" or rel="external" , it seems, according to: http://demos.jquerymobile.com/1.0.1/docs/pages/page-links.html

There is a new feature committed in trunk only so far which allows to resize images to a specified size in the browser before uploading to the tiki at the server.

In my local test I did setup this environment:
* applied "collaborative community 12x" profile, and created a file gallery called "foobar", allowed to upload images by others, etc., add some values to the default settings of max image width and height per gallery, and attempted to upload one image file to that file gallery overiding the max width and height in that file upload.

After uploading the image, I saw just below the image thumbnail:
{CODE()}
File upload failed: Forbidden
{CODE}

And in a higher position next to the page top, this other message was shown:
{CODE()}
Incorrect integer value: '' for column 'deleteAfter' at row 1
{CODE}

See screenshot:
{img fileId="1048" thumb="box"}

I'm using php 7 and mysql 5.7 in my local machine where I tested, in case this matters.

I'll see if I can reproduce in a show.t.o instance

---
I can't reproduce since I can't login to the new trunk show.t.o instance just created, neither with Chrome nor Firefox, with the usual credentials for the first connection:
u: admin
p: admin

Removed the show instance, and created another one, and same effect.

__Describe precisely what you did (how to reproduce)__
I uploaded an oversized image to a wiki page. The oversize image constrains nicely on the wiki page with:
Thumbnail: None
Responsive Image: Default

When the following parameters are applied the image renders poorly:
Thumbnail: None
Responsive Image: Default
Caption: Text
Alternative Text: Text

__Describe exactly the faulty consequences. __
The faulty consequences are the image fly's out of the constrained area of the wiki page into the body of the site when the Caption and Alternative Text params are used.

__Explain what you expected instead of the faulty consequences. __
I expected the image to constrain nicely in the wiki page as it does when only the Thumbnail and Responsive Image params are applied.

Right now PluginJQ documentation ( https://doc.tiki.org/PluginJq ) is very helpful, and I made a profile in 12.x to manage the conditional display of some fields in forms.
http://profiles.tiki.org/Conditional_Display_in_Forms

But in 14.x the required syntax seems to be different, and I don't get it right:
http://profiles.tiki.org/Conditional_Display_in_Forms_14

See it reproduced in here:
http://xavi-9794-5642.show.tikiwiki.org/tiki-index.php?page=CDF+instructions
u: admin
p: 12345

When selecting Case A or Case B in the radio button, all fields are shown, but no bg color for all the shown fields below the radio button.

When selecting Case A in the radio button, still some labels from fields for Case B are shown (text area)

Xavi

Hello,

When you want to create a form to embed a tracker you need to put the trackerId and the fields Id. I improved them in a more user friendly way in order to avoid to remember the ids.

__Before__:
{img fileId="1114" thumb="box"}

__After__:
{img fileId="1115" thumb="box"}

I have uploaded the files modified.

The modified files are:
*lib/wiki-plugins/wikiplugin_tracker.php
*lib/jquery_tiki/tiki-trackers.js
*lib/jquery_tiki/tiki-jquery.js
*lib/tiki-js.js

You will found the modified code tagged inside
// NOTE: Start Modification
......code....
//NOTE: End Modification

Say I include a bunch of pages in one larger page.

I click edit, and find that it's an included page. I should be able to edit directly that included page (assuming I have permissions), a bit like ((doc:section edit))



Benefits:
*Each page has independent history.
*They can be edited in parallel.



__Can page renames also survive inclusions?__


Related:
*{wish id=2668}

Special characters is now via a popup. This is bad because the one click javascript insert doesn't work. "Basic" special characters should be integrated in the template.

Could (should?) be contextual to language. Current page? User language(s)? What if use speaks many?

It could also be a drop down-menu like with available languages. Go edit a page on wikipedia to get an idea.


wikipedia's Basic" special characters:

Additional French special characters:

Additional Spanish special characters:

We should let our translators edit this according to their local needs.


Related:
http://sourceforge.net/tracker/index.php?func=detail&aid=1185212&group_id=64258&atid=506848

insert tracker item with modal window fails due to form refresh when choosing page name from dropdown options (in a tracker field wiki page name)

For the record, it was reproduced here: https://sustainability.seeds4c.org/tracker25
(site in production, intranet for a university course - ask for a temporary user if you are willing to test on site for debugging purposes or something)

When you are on a modal (like when you "Save and Comment" a trackeritem in this tracker) you still can use the "Help" button of the toolbar.
It usually open a modal with help for Wiki Syntax and Plugins but in that case, you are already IN a modal and using it will close all modal and all your previous work is lost.

It is not possible to open a modal from a modal in Tiki (I most case if not all) therefor the action shouldn't be possible and so it shouldn't be allowed and lead to lost of data.

As reported here:
https://bugzilla.mozilla.org/show_bug.cgi?id=398767

{THUMB(image=>img/wiki_up/2008-01-17_low-tech-image_picker_TikiWiki.jpg,url=#)}{THUMB}
{THUMB(id=13,url="show_image.php?id=13")}{THUMB}
{THUMB(id=16,url="show_image.php?id=15")}{THUMB}


Some ideas of nice links to have:

Thumbnail with link:
{img src=images/code.png}%%% {CODE()}
{THUMB(id=13,url="show_image.php?id=13")}{THUMB}
{CODE}


[tiki-upload_image.php|You can test some experimental stuff here] (upload a pic and see the suggested wiki markup to copy in a ((test)) page.)


Nelson Ko and Marc Laporte were planning to work on tiki at ((tw:TikiFestToronto)) but something else came up so it's still on todo list :-)

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

To reproduce: tag something with an apostrophe, like "l'apostrophe".

get to tiki-browse_freetags.php
This tag is displayed as "l\'apostrophe" instead of "l'apostrophe"

Note: it still works for searches, so fixing the display of the freetag should not break the search feature.

Any other Plugin used within PluginTabs doesn't show the edit button. It is not possible to edit them itself like it was before.
For Example, Tab1 with CODE and Tab2 with FANCYTABLE:

{TABS(tabs="code|fancytable|box" toggle="y")}
{CODE()}{CODE}
/////
{FANCYTABLE()}{FANCYTABLE}
/////
{BOX()}{BOX}
/////{TABS}

When nested divs (or other nested plugins of equal name) need to be edited, the edit-plugin-window, does not detect the plugins beginning and ending correctly. Eg:
{CODE()}1. {DIV()}
2. {DIV()}want to edit the nested plugin{DIV}
3. {DIV}{CODE}

If your mouse is within the "want to edit the nested plugin" text and you select the plugin-type because you want to edit using the gui (usefull if the text is quite long), it will pop-up the gui with the text:

~np~{DIV()}want to edit the nested plugin~/np~

Thus it detected the ending of the plugin which started at line 1, to end in line 2, which is not correct. Also, when the mouse is within a nested plugin, the gui should detect the beginning of the plugin in line 2, instead of line 1.

Hope this make sense...quite an annoying behaviour.

It would be nice if it was possible to enable something like a syntax highlighting/coloring when in edit mode, such that plugins are easily detected or that layout is also colored. Wouldn't a tikiwiki syntax highligher be cool! Or is that already available? :)

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.