Category: 12.x

Hello,

I need someone with Kaltura access to remove the following clip: 0_vl6gaflc

-=::You will find the clip at this location::=-

http://tv.tiki.org/tiki-kaltura_video.php?mediaId=0_vl6gaflc


This above video clip is no longer needed as the two approved ones are done.

I do not have Kaltura admin access. Therefore, if someone who does have kaltura access on the tv.tiki.org side, please help.


Tks

Daniel.

View a Spreadsheet in Mobile mode: tiki complains inifinitely that jquery_ui is not enabled

You enable it, try again, and you get the same error message.

If you switch to non-mobile mode, the tiki sheet is there as usual. But when you switch back to mobile mode, you get the same error again.

If you visit the admin panel "Features", "Interface" tab, you can see that jquery_ui is disabled indeed in Mobile. However, if you switch to non-mobile mode, jquery_ui is shown as enabled.

In mobile mode, as a reference, these seem to be the css libraries loaded (no jquery-ui) when attempting to view a spreadsheet:
{CODE()}
<link rel="stylesheet" href="vendor/jquery/photoswipe/photoswipe.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-mobile/jquery.mobile-1.3.2.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/treetable/stylesheets/jquery.treetable.css" type="text/css" />
<link rel="stylesheet" href="styles/mobile.css" type="text/css" />
{CODE}

When in non-mobile mode, these are the ones loaded (they include jquery-ui):
{CODE()}
<link rel="stylesheet" href="css/cssmenus.css" type="text/css" />
<link rel="stylesheet" href="vendor_extra/elfinder/css/elfinder.full.css" type="text/css" />
<link rel="stylesheet" href="vendor/codemirror/codemirror/lib/codemirror.css" type="text/css" />
<link rel="stylesheet" href="lib/codemirror_tiki/codemirror_tiki.css" type="text/css" />
<link rel="stylesheet" href="temp/public/codemirror_modes.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-ui-themes/themes/flick/jquery-ui.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-timepicker-addon/dist/jquery-ui-timepicker-addon.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/cluetip/jquery.cluetip.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/colorbox/example1/colorbox.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/plugins/treetable/stylesheets/jquery.treetable.css" type="text/css" />
<link rel="stylesheet" href="vendor/jquery/jquery-sheet/jquery.sheet.css" type="text/css" />
<link rel="stylesheet" href="styles/fivealive.css" type="text/css" />
{CODE}

Te reproduce, login to view this spreadsheet here:
http://xavi-9794-4985.show.tikiwiki.org/tiki-view_sheets.php?sheetId=1

u: admin
p: 12345

Click at Switch to mobile mode. Done.
---
UPDATE: Closing item as outdated, since Tiki 15+ doesn't have this issue due to Bootstrap. {sign user="xavi" datetime="2017-01-29T14:37:58+00:00"}

CentOS 6.3
APC 3.1.13
PHP 5.4.11 (apache2handler)
MySQL 5.5.30-log

Tiki 12, new/clean install

I use inline Plugin Tools, Wanted Pages, to display it, but failed, such as:

http://giprs.org/wiki/Project(external link)

http://giprs.org/wiki/Issue(external link)

I do not receive notifications when watched tracker item is commented. Is it a setting or is it a missing feature ? Is it a consistency bug when wiki pages allow notifications on new comments ?

This URL will load but not present the Web page

-------------------------------------------------------------

http://tiki.org/doc.tiki.org/plugincountdown

-------------------------------------------------------------

Firefox 26.0 running on Linux Mint

The wysiwyg_wiki_parsed preference influences WYSIWYG edition, [https://tiki.org/forumthread67421|even if it was not supposed to]. When it is enabled, what one sees in the WYSIWYG HTML (wysiwyg_htmltowiki disabled) editor is not necessarily what one gets. For example, if one enters ~np~"__Text__"~/np~, "Text" will be displayed in bold after parsing, the underscores parsed as if the page contained wiki syntax.

This issue persists in trunk as of r65130. Moreover, following r30245 (2010-10-23), this behavior is "specified" by the editor's help. So fixing this may be considered as a semantic change for existing data. A simple fix without data conversion could disappoint user expectations. Plus, HTML WYSIWYG does not have equivalents to some wiki features, such as plugins.

[https://dev.tiki.org/item6532|Ticket #6532] reports a corresponding bug when wysiwyg_htmltowiki is enabled.

When I use trackerfilter with the option sqlsearch in a wiki page to search a tracker it does not work as expected.

On PCs running Windows 7 and Windows 10 respectively. I can reproduce the problem in Tiki14.0 and 14.2 (both with MYSQL). In both versions there is no search box created on the wiki page with trackerfilter to enter the search string.

I have tested on the demo site and the versión 14.x demo site has the same problem.

Versión 12.x on the demo site does give a me a field to enter the search string, however, it appears to only search for the string in the first field and not in both fields.

To reproduce:
I created a Tracker with 2 fields ( "Name" a Text Field and "Description" a TextArea Field).

Then I créated a Wiki page with:
{trackerfilter filters="(1:2)/sqlsearch" displayList="y" noflipflop="y" trackerId="1" fields="1:2"}

In versión 14.x wiki page does not give área to enter search string.
In versión 12.x wiki page gives área to enter search string but search only appears to search first field regardless of field(s) requested. In my example there are two ítems. The word "Green" appears in ITEM1 field 2 and in ITEM2 field 1. If I search for Green only ITEM2 is listed (where Green appears in field1). If I search for "fruit" which appears in field 2 of both ítems there are no records found.
I understood that sqlsearch option should find the search string in any of the fields specified i.e. in my case "green" in field 1 AND/OR field2.

I have listed below:
tracker_1.csv to recreate the simple tracker used
itemId,status,created,lastModif,"Name -- 1","Description -- 2",
1,o,1453722833,1453722833,"Apple","A green or red fruit",
2,o,1453722869,1453722869,"Green","The color of some fruits",

I have uploaded the following images:
tiki14.png a screen shot showing the filter created which has no space to enter data in 14.x
tiki12.png a screen shot showing the filter created which has space to enter data in 12.x
tiki12_incorrect.png a screen shot showing how search does not opérate as I expected in 12.x only Ítem2 is listed and not Item1 despite the search string appearing in field 2 of first Ítem.

Tried other threads and worked fine.

Issue is with http://tiki.org/tiki-view_forum_thread.php?forumId=26&threadId=50119&comzone=show#threadId50119

wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)

See it reproduced here:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The homepage has at the bottom the standard code for an alias at teh page "HomePage" to be accessed also from "Casa" alias page name.
{CODE()}
(alias(Casa))
{CODE}

Therefore, you can access to the homepage also with:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=Casa

However, if you open that wiki pade for edition with "Inline wiki editor", make some changes, and saved the page through the inline wiki editor (click again at that button that you used to open the inline editor), then the alias link is gone. If you edit the page with the standard wiki plain text aditor, you will see that the code at the bottom is replaced with a standard wiki link pointing to "HomePage" and using "Casa" as label.
{CODE()}
((HomePage|Casa))
{CODE}

Check this page: https://dev.tiki.org/Tiki+Slideshow+used+in+BigBlueButton

See screencast for explanation

{flash type="url" movie="display560" width="859" height="603"}

The functionality to allow comments in wiki pages on a 'per page' basis that was in Tiki 6 has been moved from Wiki admin to Comments admin and is therefore less visible

It should be replicated in Wiki admin as well to make it more visible


Fixed r48529

Wiki Feed fails with maximum memory error, or max execution time (sometimes) error.

I have created a show instance with a page that will kill it.

I am sure it is plugin related somehow. When I disable all the plugins, it runs just fine, Even with the same page content.

I had previously formatted this page with wiki syntax, but it was just too much for any tiki functions to work properly, so I reformatted it to use HTML and only when wiki plugins offer functionality that goes beyond formatting do I use them, (things that would be impossible to do with just HTML formatting, such as TOC and Footnoes).

Error messages:

PHP Fatal error: Maximum execution time of 30 seconds exceeded in /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php on line 431
PHP Stack trace:
PHP 1. {main}() /Sites/tiki/tiki-wiki_rss.php:0
PHP 2. TikiLib->parse_data() /Sites/tiki/tiki-wiki_rss.php:75
PHP 3. ParserLib->parse_data() /Sites/tiki/lib/tikilib.php:139
PHP 4. typography() /Sites/tiki/lib/parser/parserlib.php:1723
PHP 5. Michelf\SmartyPants->transform() /tiki/lib/init/typography.php:59
PHP 6. Michelf\SmartyPantsTypographer->educate() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPants.php:194
PHP 7. Michelf\SmartyPantsTypographer->spaceUnit() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php:192
PHP 8. preg_replace() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php:431

or

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /Sites/tiki/lib/diff/Diff.php on line 501
PHP Stack trace:
PHP 1. {main}() /Sites/tiki/tiki-wiki_rss.php:0
PHP 2. diff2() /Sites/tiki/tiki-wiki_rss.php:80
PHP 3. Text_Diff->__construct() /Sites/tiki/lib/diff/difflib.php:98
PHP 4. Text_Diff_Engine_native->diff() /Sites/tiki/lib/diff/Diff.php:44
PHP 5. Text_Diff_Engine_native->_compareseq() /Sites/tiki/lib/diff/Diff.php:379
PHP 6. Text_Diff_Engine_native->_diag() /Sites/tiki/lib/diff/Diff.php:586

In the Properties tab of the Wiki edit screen (either standard wiki editor or wysiwyg) there is an option to Import the content of wiki page that has previously been exported (needs some Wiki options set to see these)

The export process works fine producing a text file with a special header area then the content which is in wiki syntax for the normal editor or html when using the (full) wysiwyg editor (not tested the wiki syntax wysiwyg option)

To import the page you simply browse to the file and then save the page - which used to import the content at that point.

However now (22 Aug 2013) in 11.x and trunk nothing happens and the page remains empty. It used to work Ok at some point probably version 6 or perhaps earlier?

In Wiki page, the print function should show the current information of the page, but the page was shown the unapproved details after I clicked the print icon. I have activated the Approval function so that the edited page will be shown after approval.


---
Info to reproduce it {sign user="xavi" datetime="2014-12-31T07:30:58+00:00"}:
u: admin
p: 12345
* Log in as admin to the attached show.t.o instance: http://marshallau-11729-5521.show.tikiwiki.org/
* See that the "Official Document" has no approved page:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-index.php?page=Official+document
* click at the Wiki print button, and you will see the latest version of the document, even if unapproved:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-print.php?page=Official+document
* log out as admin, and as anonymous, visit again the url of the print-version of the document. You can see it freely:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-print.php?page=Official+document

Attempting to remove a page fails by default, without reporting any error. Before Tiki 18, it seems to do nothing or little. Since 18, it merely removes the last version of the page.

When the "Remove all versions of this page" is checked, removal works.

According to r31226 (7/12/10, by killianebel ):
{QUOTE()}[MOD] Wiki pages can be viewed at a specific version, using the &version or &date URL parameter. Files included in pages with the FILE plugin correspond to the specified version. This feature must be enabled with 'feature_wiki_use_date'.
{QUOTE}

However, I can't get this feature to work with Tiki14 or Tiki12 or Tiki9 (with or without revision approval). It seems as if important pieces of code are missing. Did this ever worked?

When you try the Slideshow wikiplugin to customize the appearance of the wiki page Slideshow (background image, font color, etc.), it just flashes for a second and then it is being overwritten by the Slideshow default "theme" (vendor/jquery/jquery-s5/images/bg.png) rendering the plugin kind of useless.

Reproduced here: http://luci-199-5148.show.tikiwiki.org/

Just click the Slideshow button on the bottom of the page or go directly to the slideshow:
http://luci-199-5148.show.tikiwiki.org/tiki-slideshow.php?page=HomePage#

--I was originally having a smaller wysiwyg bug on my tiki 12 instance, but I'm not sure what is going on with it anymore after testing with a fresh instance.

On the current instance created for this ticket, the formatting bars (Format, styles, font, size, etc) are not showing up for WYSIWYG, and going to the toolbar admin and changing things doesn't change the toolbars for the WYSIWYG, but changing things for "Wiki only" added them to the WYSIWYG too.

It seems to be acting really weird, and "link" and "unlink" show up when you go to the editor toolbar admin, but don't show up in the editor (feature is enabled).

user: admin
password: 12345

update: looks like maybe WYSIWYG only shows the "visual wiki" toolbar, but I'm not too familiar with how that works. Hopefully this is user error, but I've customized editor toolbars in tiki wiki before, and this seems to be working strangely.--

!!Here is a more concise explanation of what is going on. Ignore Above

Turns out it was in fact mostly user error + confusingness, though there is a bug.

bug:
Setting the toolbar selection mode to "WYSIWYG Only", and then adding an icon to the toolbar adds the icon for all editors instead of just WYSIWYG. This is present in tiki 11 also, but I can't seem to destroy the instance and test other versions (tried from multiple browsers).

Possible bug:
"Link" icon tiki WYSIWYG does not set link element class to "wiki" by default, resulting in possible css/styling inconsistencies. Links created with square bracket tiki syntax always have class="wiki external". I think that links from both should be generated with same class so css can apply to both without having to set css for all anchors just to cover links generated by "Link" (but I'm not a CSS guru, so I don't really know css best practices. Seems inconsistent though).

Discussion/What I thought was a bug:

I had previously talked about the lack of formatting bars (Format, styles, font, size, etc) in wysiwyg being a bug, but this is not really bug. In tiki 12, the "Use Wiki syntax in WYSIWYG" perference's description says "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools", which would make it so that only the visual wiki toolbar shows up when you are in the wysiwyg editor, and you don't get any WYSIWYG toolbar icons (as I understand it).

When you enable WYSIWYG, the "Use Wiki syntax in WYSIWYG" preference is enabled along with it by default, meaning that by default WYSIWYG does not actually have any WYSIWYG toolbar functionality, and is really tiki toolbar icons with a wysiwyg text interface.

The reason I thought this was a bug was because I did not understand the implications of "Use Wiki syntax in WYSIWYG", and in tiki 11.0, with "Use Wiki syntax in WYSIWYG" enabled, the toolbars were still usable. The description still stated "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools" however, suggesting that perhaps in tiki 11.0, the fact that the formatting bars still worked was itself a bug. However, if that can happen through a bug maybe that is something that should happen intentionally? Seems like a big loss that if you enable "Use Wiki syntax in WYSIWYG" you lose the entire WYSWIWYG toolbar, and you don't get a hybrid toolbar. Anyway, just throwing that out there/explaining confusion.

WYSIWYG is now a basic feature in 12, but the panel is not visible from tiki-admin.php

In version 12 the Wysiwyg editor is no longer an experimental feature.
The wysiwyg help text should be updated.
The help text should cover both fullscreen and inline editing, since the toolbar icon to display it is there for both.

{img fileId="435"}

This bug happens when you have WYSIWYG editing enabled, and a wiki page template that looks like this:

{CODE()}
[tiki-index.php?page=HomePage#SomeSection]
{CODE}

i.e., it contains a link to a page section.

If you setup a quickedit module to create a page with that template, then when you save the page, the #SomeSection part of the link gets deleted. So the link points to HomePage instead of HomePage#SomeSection.

Here is an example of opening a page in WYSIWYG, not changing anything, but the data is affected.

{flash type="url" movie="display364" width="495" height="338"}

Most icon images are absent from the WYSIWYG toolbar when using Firefox. The below table lists experimentation results. I did disable all Firefox browser add-ons as part of the testing. This issue does not effect the Wiki toolbar.

The problem does not occur in the "Show" instance that was created. This tells me the problem is not entirely browser specific, but some combination of site settings with Firefox create the problem.

||__Computer__|__OS__|__OS_Ver__|__Browser__|__Browser_Ver__|__Result__
::Rorschach::|::Linux::|::Mint 14::|::Firefox::|::25.0.1::|::Broke::
::Rorschach::|::Linux::|::Mint 14::|::Opera::|::12.16::|::Works::
::Snowball::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Snowball::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::works::
::Darkknight::|::Linux::|::Mint 14::|::Firefox::|::24.0::|::Broke::
::Darkknight::|::Linux::|::Mint 14::|::Midori::|::0.4.3::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Birch::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Birch::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Gem::|::OS X::|::10.6.8::|::Firefox::|::23.0.1::|::Broke::
::Gem::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::WinXP::|::Windows::|::5.1 SP3::|::Firefox::|::25.0.1::|::Broke::
::WinXP::|::Windows::|::5.1 SP3::|::IE::|::8.0::|::Works::
::Aiuto::|::iOS::|::4.3.3::|::Safari::|::-::|::Broke::%%%(never loads)
::BCi::|::iOS::|::5.1.1::|::Safari::|::7534.48::|::Works::
::BCi::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::
::iPS::|::iOS::|::5.1.1::|::Mercury::|::7.4.2::|::Works::
::iPS::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::||

In IE & Chrome, it's OK

{img fileId="678"}

Renaming a group doesn't update the name in the corresponding group watches

Reproduced in our production site: http://ueb.vhir.org

This might be the culprit for this other more serious usability issue in our production site:
http://dev.tiki.org/item5497?from=Watch