Category: 14.x Regression

Since the use of Bootstrap in Tiki (13.x+), wide tables (like many of the ones we use in dev.t.o to display bugs and their associated variables) display a bunch of columns hidden, and the scrollbar is only shown at the bottom of the whole table.

New users might not notice that there are columns on the right hand side of the table, designed to be shown (like in our case, the column "Comments", which indicates which bugs have been commented, by whom and when, to facilitate info to the viewer about bugs that received feedback and more opinions/replies might be expected, etc).
Example (from https://dev.tiki.org/Tiki14+Blockers on a wide screen):
{img fileId="985" thumb="y" rel="box[g]"}


I was searching for something like what you can doo with doodle on wide tables, but couldn't find any jquery plugin for that.
|| ::Default view on wide table (doodle.com ):: | ::Expanded view after clicking at the shrinked columns (doodle.com)::
{img fileId="983" thumb="y" rel="box[g]"} | {img fileId="984" thumb="y" rel="box[g]"} ||

The floss solutions that we might explore to integrate might be (after 30' of searching around):
# Footable jquery plugin: (MIT licensed)
+ http://fooplugins.com/footable-demos/
# Table column toggle, from jquery mobile (compatible with using Bootstrap?)
+ http://demos.jquerymobile.com/1.3.0-beta.1/docs/tables/table-column-toggle.html

Try the demos, and see
Alternatively, some sort of custom trick could be desinged using colResizable jQuery Plugin? (MIT licensed)
http://www.bacubacu.com/colresizable/

If equally complex to implement, I would cast my vote for Footable jquery plugin, for what I've seen in their website as end user.

This was working quite well in 9.x: images from article topics, and tracker images were shown in the emails sent by tiki newsletters. In Tiki12, they are not shown anymore (links to the images miss the domain name in the url.

Example of url from a missing image (from a tracker item image) in the email:
http://img/trackers/cbc123f5818f99ffa55c3befd01d1a65

Images from rticle topics are not included in the email either, it seems.

---
Images broken also even if I enable the setting "Add BASE tag in the page HEAD" (in Admin home > Look & feel > Miscellaneous". {sign user="xavi" datetime="2014-03-05T13:11:24+00:00"}
---

u: admin
p: 12345

To reproduce:
* Add your email in the recipients of the newsletter 1
+ http://xavi-9794-5162.show.tikiwiki.org/tiki-admin_newsletter_subscriptions.php?nlId=1
* Go to send newsletter 1:
+ http://xavi-9794-5162.show.tikiwiki.org/tiki-send_newsletters.php?nlId=1
* Add a title and select the "Newsletter template 1" in the dropdown of "Apply content template"
** You will that the homepaeg is shown in the newsletter, with some images.
* Click at the button below "Send Newsletter" & "Send"
* You will be missing images from article topics and tracker images (image field and file field)
** the only shown image is hte one with a manual inclusion with img src= and absolute url. (the tiki logo in red)

On "tiki.org/Versions" the link entitled: "Why PHP 5.5 and not 5.4" broken.

I have searched through the site and did not find it, so could not update it myself.
---
Update:
* some links fail the first time that you click on them, but work the second (same browser, computer and all). Odd!. Reproduced with {sign user="xavi" datetime="2015-11-19T09:11:45+00:00"}:
** https://tiki.org/tiki-pagehistory.php?page=Versions&oldver=6
** https://tiki.org/tiki-view_forum_thread.php?comments_parentId=52703#threadId53177

__Update:__ cannot reproduce anymore - got fixed? {sign user="luci" datetime="2018-04-03T07:38:35+00:00"}

Calls to plugins which are inside a call to the WYSIWYG plugin produce no output (which usually means that their effect is invisible). Some plugins, such as FOOTNOTE, have effects other than causing output, so calls to these may keep part or all of their effect.

This bug was introduced by the changes to wikiplugin_wysiwyg.php in {commit id=50752}. Tiki versions 14 to 18+ are affected.

The following call to WYSIWYG demonstrates:
{CODE(theme="default")}{WYSIWYG(use_html="n")}
This dummy content is visible.{FOOTNOTE()}Note which is invisible, but should be indicated by a number which is actually invisible{FOOTNOTE}
{GROUP(groups="Admins")}This should be visible for admins{GROUP}
{FADE(label="This should be visible")}Hidden{FADE}
{WYSIWYG}{CODE}


This happens because plugin_execute() calls ParserLib::convert_plugin_for_ckeditor() since ck_editor is true, and therefore returns an empty string to parse_first(), and therefore to parse_data(). That parse_data() has its ck_editor option true, since it is called by parseToWysiwyg(), called by wikiplugin_wysiwyg().

Unfortunately, the revision bringing this regression also fixes WYSIWYG edition. So going back to the previous situation breaks edition again. One can only choose between working visualization and working edition.

I believe the way to fix is to go back to parse_data(), but re-parse the plugin call's content differently when editing.

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 post a reply on tiki.org forums! (wysiwyg textarea never shows up)
Tried here:
https://tiki.org/tiki-view_forum_thread.php?forumId=15&comments_parentId=57825

with chromium or Firefox and no way, from a desktop computer, as usual, where I've posted many times in the past.

Never ending "loading" bar is shown to me. with a user without admin perms.

When a wikipage uses a namespace, one cannot add a comment due that the "add comment" botton does not show up.

When renaming that page to not use a namepspace, it works.

Example:
"MyNamespace:_:MyPage" does not show the add comment botton.
renaming to
"MyNamespace_MyPage" does show the add comment botton.
or
"MyPage" does show the add comment botton.


Effects 14.x Trunk as of 18.1.2015.

For testing i used the standard default bootstrap template.

Hey there,

talking about tiki-adminusers.php

Just recently tere was a new dialogue added to apply users. Today a popup opens and you can choose respectively multiselect groups to apply the users to or to remove users from.

I could not really test this good looking feature if it works spot on, or is tere would appear objections, because on save the user is not applied to the group - the setting is just ignored.

So on a site already having this update, I have to apply users to groups from tiki-admingroups.php tab 'members', which is a workaround, but not a good UX for te released system (thus a blocker).

I will look into it for a more detailed description lateron and try to find out who committed tis. Anyway, it would be nice, if someone of the coders could check and maybe fix ... I recon, that only a very little bit is missing.

Clicking "Create" button brings up pop-up which is lower z-index and thus unclickable than the grayed overlay. Clicking anything closes it again. Unable to create new tracker manually. Seen in FF.
{img fileId="955" thumb="y" rel="box[g]" width="640"}

When trying to use a tracker category field as a filter, only the value "Any" is displayed.

In the admin-modules page module position dropdown, for example, the selector has an inline 'style="width: 827px;"' that causes the selector to extend past the right side of the containing div. In Firefox there's no problem, but with Opera (which now uses the Webkit renderer) and IE 11 the selector extends beyond the right margin of its containing div.

When Javascript is minified, the ckeditor files are not loaded and (html) wysiwyg editing fails.

This is a regression introduced at some point I don't know exactly when) between Tiki6 or tiki9 and Tiki12 at least, and confirmed to be a regression still for Tiki14.

Content of text area fields can not be shown as parsed any more when displayed through PluginTrackerList, but only when displayed through the tracker interface itself. Ideally, there should be a param in plugin trackerlist to allow whoever needs that content not to be parsed in their sites. this currently breaks the display of comments provided to students on their wiki based reports.

This will hopefully be demonstrated in a tiki instance in the following days (probably after a ad-hoc profile is created to help reproducing this setup, linked to Pretty Trackers, etc, even if the issue is reproduced aside of the pretty trackers, just with standard display of the contents of that text-area field)

Blog entries on tiki-view_blog have syntax like {CODE()} <a name="postId557"></a> {CODE} which should be {CODE()} <a id="postId557"></a> {CODE} to be valid in HTML5. (This may be used in other features not checked yet.)

Reference: https://developer.mozilla.org/en/docs/Web/HTML/Element/a

dev.t.o 13.x: add some scrollbar at the top of wide tables in Bootstrapped themes, since they look as with less content for new users or unexperienced visitors

Example: see for instance
http://dev.tiki.org/tiki-tracker_view_history.php?itemId=5162

{img fileId="940" thumb="y" width="600" rel="box[g]"}

Column related to new content is not shown, and there is no clear indication that some more content is hidden in the right-hand side of that table.

New: A library has been found to solve this problem: [https://www.jqueryscript.net/other/Double-Scrollbar-For-Scrollable-Container-jQuery-DoubleScroll.html] . License is MIT.

dev.t.o 14.x: only the last item in the multiple selection combo box is stored for this tracker item

See it reproduced here:
https://dev.tiki.org/item5464?from=Structure

Edited this item as user "xavi" (without admin rights, in case it matters), Selecting some other categories in the combo box for the field "Category" or the field "Version": => only the last category (or at least, only one from all the ones selected) is stored

Use Firefox to visit [http://zukakakina.com/tiki-listpages.php] for an example. If Tablesorter is turned on, div class="table-responsive" will be out of position, offset far to the right.

The div containing the wide table is positioned correctly in Opera 12, Recent Opera (webkit), and IE11. But in Firefox (latest version), this div (.table-responsive) is positioned so that just the left edge of the table is inside the div and the rest of the table extends to the right, under the right column of the page.

Another table with tablesorter applied, on tiki-adminusers.php, doesn't show this problem in Firefox.

The "Upload New Version" action item in file galleries is no longer reliable. Clicking it opens a file selection dialog, but if the wrench icon controlling the menu of action items is not clicked, the dialog disappears quietly, without reporting any error. This is not too misleading, since there is no false confirmation.

http://bsfez-11581-5668.show.tikiwiki.org/tiki-list_file_gallery.php?galleryId=1
Can't upload a new version....

When the GALLERIFFIC plugin is used in the WYSIWYG editor (full html) then the editor no longer opens - just the 'Loading' message forever. The plugin seems to run ok once it is in there ie it was there before an upgrade or put in new first time round - and you can also use the standard wiki editor ok.

Console errors shown when trying to load the editor are:

"TypeError: imageData is undefined
var index = imageData.index;

jquery....ffic.js (line 505)

which might have something to do with it


... just to confirm that this is still a bug at r 55993 Aug '15

I noticed after pulling the latest code from SourceForge that certain icons in the WYSIWYG and Wiki editors were not being set properly. A condition inside an if statement in /lib/toolbars/toolbarslib.php on the line 1709 was setting several icons to the plugin.php icon.

I began looking for the cause of the issue and discovered a series of several commits that had caused the bug. The icons in question are the features 'Image', 'File', 'Mouseover', 'Insert Module', 'HTML', 'Include', 'Code', and 'Remarks Box'.

The problem code for each of the above features can be found in the lib/wiki-plugins/ directory and is attributed to a single line of code in each file. The structure of the hash tables located in these files appears to have been changed from using

'icon' => 'path/to/icon'
to
'iconname' => 'iconset_definition'

Unfortunately, this has caused the regression on my site. To fix this, I can simply comment out the line with 'iconname', and replace it with the previous 'icon' line, however this increases the number of customizations on my site I would need to keep track of, and would prefer not to go down that route.

The revision numbers and files for the features in question are as follows:

'Image' = r56275 -- /wiki-plugins/wikiplugin_img.php
'File' = r56269 -- /wiki-plugins/wikiplugin_file.php
'Mouseover' = r56280 -- /wiki-plugins/wikiplugin_mouseover.php
'Insert Module' = r56280 -- /wiki-plugins/wikiplugin_module.php
'HTML' = r56273 -- /wiki-plugins/wikiplugin_html.php
'Include' = r56276 -- /wiki-plugins/wikiplugin_include.php
'Code' = r56254 -- /wiki-plugins/wikiplugin_code.php
'Remarks Box' = r56291 -- /wiki-plugins/wikiplugin_remarksbox.php

I looked into the new iconset definitions as well, and didn't notice any issues with it, so this is why I'm am submitting the bug report. Let me know if there is anything I can help with!

It has display:block instead of inline or inline-block now. E.g.:

fivealive-lite.css on line 3968:
{CODE()}
.navbar-brand > img {
display: block;
}
{CODE}

When a file (image) is selected for insert in a page, and when the "Mouseover - enlarges in popup when moused over" Thumbnail parameter is set, the mouse over does not function correctly.

Please see how the file(image) mouse over is supposed to function at http://tpwtestuser.com/tiki12/tiki-index.php?page=Image+Mouseover+Test and hover over the image at this tiki12 test site.

Please see how the file(image) mouse over does not function at a tiki14.2 and a tiki15 beta site. When the cursor is hovered over the image, the image does not appear or display. But if you click on the image, the image does have a mouse over behaviour, but it is the incorrect behaviour, as the image should enlarge by simply hovering over the image.
---
(Tiki14.2) http://tpwtestuser.com/tiki/Image+Mouseover+Test
(Tiki15) http://tpwtestuser.com/tiki15/tiki-index.php?page=Image+Mouseover+Test
UPDATE 4-12-16: The above links now show mouse-over functional using geeza's fix as suggested at the comments page of this bug report. Though the action still needs some work as far as size of pop-out and image placement.
---
Here is the link to the tiki.show instance at http://jmorris-11758-5895.show.tikiwiki.org/tiki-index.php?page=Image+Mouseover+Test

Thank you for considering this in your line up of bug fixes!
John

Images displayed with the img wiki plugin are being assigned a CSS class that's simply a number (it's the file id number). This isn't valid CSS. The number should be appended with something like "fileId_".

For POI map items ie a tracker item with an Icon field, the icon image is no longer updating WHEN USING FIREFOX and the tracker_legacy_insert pref is enabled – in the tracker item edit screen a new/different icon image can be selected from the available options in the file gallery, and this is correctly shown just after selection but when the item is saved the icon reverts to the previous image.

Using Chrome it is all OK - not checked other browsers yet

Show instance with tracker setup:
http://eromneg-10122-5815.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
admin
admin12345

UPDATE: OK – I’ve narrowed down the issue further

I’m using FF44.0.1 so no difference there, but because my test site has evolved from much earlier versions it has got a whole range of tracker prefs that have been set over the years (or have arrived during upgrades to give backwards compatibility)

I’ve spent a bit of time aligning the show instance to what my test site uses and the key difference is the tracker_legacy_insert pref which is set in the Tracker Control Panel. With this set the issue occurs in the show instance with FF but is OK in Chrome

In a wiki page set an img plugin, choose, image from gallery (file), upload an image, save.
Back on the page click on the "edit plugin" icon.
File ID, click on the "image" link (picture selector) or change by hand the File ID.
Click submit, nothing change.

It took me hard time to reproduce but you got it here : http://bsfez-11581-5669.show.tikiwiki.org/tiki-index.php?page=HomePage

It seems it is something to do with the hebrew text in the fancylist.