Category: 14.x

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

Some icons are hard-coded through javascript files. One example from lib/jquery_tiki/tiki-trackers.js line 139:
{CODE()}
$row.append($('<td class="action"/>').append($('<a href="#" class="text-danger"><span class="glyphicon glyphicon-remove"/></a>')
{CODE}

This line hard codes a glyphicon icon regardless of the iconset set by the admin. In php files this can be fixed by loading the smarty function icon but haven't been able to fix here (tried using ajax services).

Please see like http://code.google.com/p/sabredav/wiki/Migrating1_6to1_7#Composer_package_name_changed

{flash type="url" movie="display515" width="614" height="376"}

New feature, so should go to trunk

The online translation on i18n.tiki.org is not working.
I want to test on show.tiki.org first and later come back with detailed report.

//Update://
On show.tiki.org the online translation works smoothly! No problems.

So I guess, we have either a configuration problem or a server problem - I will refer aswell to the infrastructure team. //done//

...

The user "gour" did report about an adress error (redirect or .htaccess) in the dev-list and I faced frequently the last days, that the tick-box of the translation is not working, the translation dialogue on i18 is different than ist should be (just compare with show.tiki.org), the translation does not save - is that Ajax or JS? <-> loading for ages, but not finishing - not any result, just endlessly loading.

I use GNU/Linux Ubuntu 14.04
Firefox: tickbox of interactive translation get's not staying ticked, translations are editable on both sides (original and new)
Chromium (Chrome): activating interactive translation seems to work on the first view, but ticking the box or deactivating the interactive translation via quickadmin causes WSOD
~np~(http://i18n.tiki.org/tiki-interactive_trans.php?interactive_translation_mode=on and
http://i18n.tiki.org/tiki-interactive_trans.php?interactive_translation_mode=off)~/np~

As said: no problem on show.tiki.org!

...

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}

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

When using the ImgPlugin with "mouseover" or "mousesticky" and have aligned teh thumbnail to be right, after a mouseover or a click, the thumbnail moves to the left.

Example:
{CODE()}
{img type="attId" attId="1" thumb="mouseover" imalign="right" alt="Image1"} __mouseover__ Full size image appears when thumbnail is moused over;.
{CODE}

{CODE()}
{img type="attId" attId="1" thumb="mousesticky" imalign="right" alt="Image1"} __mousesticky__ Full size image appears when thumbnail is clicked. full size image stays open as long as no further click happens.
{CODE}

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

When I click Insert Object Link, it hangs forever, and PHP lists errors in searchlib-unified.php

Same problem in category admin if you have unified_add_to_categ_search enabled the add objects hangs too {sign user="jonnybradley" datetime="2016-02-01T10:13:11+00:00"}

{syntax type="tiki" editor="plain"}
Because if you are good in English, it's not immediately obvious what is translated vs needs to be translated.

Any unstranslated string should be seen in a fraction of a second

This is a feature request for trunk
Edit: {sign user="Bsfez" datetime="2017-03-09T10:08:17+00:00"}
To activate the interactive translation : Admin -> i18n -> enable Multilingual, enable Use database for translation.

In the admin menu: Edit Language -> Toggle interactive translation ON.
Go to a page, at the top of the display you’ll have a switch to turn to start translation.

I tried to upload a file with size over the maximum allowed.
No error was displayed and the interface got dupplicated instead

1 - Screenshot of the form filled with upload information (file had 72MB)
{img fileId="988" thumb="y" rel="box[g]"}

2 - Screenshot of the result after the upload failed
{img fileId="989" thumb="y" rel="box[g]"}

The error doesn't occure when the file is under the maximum filesize allowed.

To reproduce, setup a new client server setting under Known Hosts on the InterTiki master.

All works fine. Then modify the key for the setting, and you will find that login now fails with Invalid Server Key message.

The reason why this is so is because the "key" is used as the "key for the preference setting" and also at the same time used for the "key to determine if there is such a setting for that server". So obviously it cannot function for both these uses robustly if it can be changed....

Currently, the Banning System interface (tiki-admin_banning.php) only allows IPv4-format addresses to be specified for matching purposes.

I believe this should be updated when convenient to enable IPv6 addresses to be specified, either as a new field ("IPv6 Regex Matching", with the existing field renamed to "IPv4 Regex Matching") or as a single field that allows both.

It appears from documentation that support for IPv6 in System Administration tables was part of the [https://doc.tiki.org/Tiki8#IPv6|Tiki 8 release]. Assuming I understand that correctly, this request should only require interface changes to be made.

Plugin Lastmod does not default to current page when page name is not specified.

The documentation for the [http://doc.tiki.org/PluginLastmod|Lastmod Plugin] says if you don't specify the page name, Lastmod defaults to the current page.

From forum [https://tiki.org/tiki-view_forum_thread.php?comments_parentId=40353&post_reply=1&comments_threshold=0&comments_reply_threadId=43856&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=40353&thread_style=commentStyle_threaded#form|thread] posted by user TomJarvis:

I have now tested:
{LASTMOD()/}
and
{LASTMOD(page=HomePage)/}
in the HomePage of Tiki versions 2 through 9.

In each version of Tiki, the plugin with the pagename specified worked correctly (other than the '%0' in Tiki 2 mentioned in the documentation).

When Lastmod is coded without specifying the page name, the current date and time are returned in Tiki versions 2 through 6, and nothing at all is returned in Tiki versions 7 through 9.

There appears to be a problem with how the Lastmod plugin get the page name when it is not specified.

This is a bug that could be reported. The workaround is to specify the page name.

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

The "((doc:PluginTrackerCalendar))" (fullcalendar resourceviews) needs annual view (for project management)

Because real projects last more than just a month... and managers want to see the evolution over time (monthts)

Moreover, we need "filters" for up to 3 tracker fields to control de display of data from the tracker

3 tracker fields because you usually want to review by:
(1) user/s,
(2) dates,
(3) a field related to the project itself (priority, custom field such as project type, etc)

---
A basic attempt is using plugin custom search, but I don't yet get the right syntax to filter events in the trackercalendar based on the results of the dynamic filter specified by the user.
Reproduced:
http://xavi-9794-4391.show.tikiwiki.org/tiki-index.php
u: admin
p: 12345

Currently in tiki when a link to a non-existent page is made, the page name is not styled or in any way distinguishable in the HTML and a link is only around a following hard-coded question mark. What I would like to see is to change it so that the page name is in fact the link text and the appearance can be styled via CSS. This would allow a particular theme to use the question mark indicator or a Mediawiki-style "red link" or some other styling for these "edit new page" links.

Since Tiki10 the Tiki SMARTY Plugin, using the 'eval' option to simply display a smarty variable, no longer works because the underpinning smarty function.eval.php is no longer part of the Tiki distribution - the SMARTY Plugin code checks for the availability of function.eval.php in either lib/smarty/libs/plugins/ or the lib/smarty_tiki/ folders and gives an error message "Incorrect parameter"  if it is not found. Its removal is probably due to the move Smarty 3  but it is not clear whether there is Smarty 3 version of eval available. The Tiki 9 version of function.eval.php does not work in 10/11/trunk (gives fatal errors) so this doesn't give us a 'quick fix'.  

Solution needed to be able to 'eval' and display any smarty variable type not just strings

jsCalendar widget unaware of time zones and recording event to one day earlier than selected (timezone difference of 6h)

[https://tiki.org/Community] user info popups show "Last Login" as "Never logged in" but on the user info page such as [https://tiki.org/user1553] it shows fine.

It's also not a problem on dev so i suspect an intertiki thing...

The "LDAP external group" settings are not correctly used.

In lib/userslib.php around line 1320.
The array "ldap_group_options" is filled with the data for a search on the groups in ldap.
Later on "ldap->get_groups" is called with this options.

Inside "ldap->get_groups" the first action is to call "get_user_attributes".
But now the configuration is set up for the group search, means the search for the user attributes is done with the ldap configuration (host,port,basedn,...) from the "LDAP external groups".

Usually (with a single more or less unstructured ldap) you will not notice it.
But if you have a separate ldap or at least another "scope" for the groups, this will fail, because it will not find the user-attributes in the ldap where the groups are.

I have not thought about a fix yet ... first I wanted to report it :-)

Besides this, there are some harmless typos in lib/userslib.php: auth_ldap_groupdescattr is with one "t" only in some places.

It seems that there is an error in the following line of function validate_user_ldap() of /lib/userslib.php:
$this->ldap->setOption('bind_type', 'full');
Because of that ldap bind_type is always full, no matter what bind_type user sets in settings in admin panel.

There was an issue with the LDAP not syncing groups properly, and would thus cause a blank page to appear when logging into my site.

Essentially, the entire problem is attributed to a typo in the function name for the ldap_sync_groups function. The file ~/lib/userslib.php contains the function:

{CODE()} private function _ldap_sync_groups($user, $pass)
{...}{CODE}
The major problem is that this function name has a leading underscore (_) and causes an issue when it attempts to sync the groups with the LDAP.

Simply removing the underscore solves the whole problem. The function should be named as such:

{CODE()} private function ldap_sync_groups($user, $pass)
{...}{CODE}
This will make it so that when the file reaches the line:

{CODE()}$ret &= $this->ldap_sync_groups($user, $pass);{CODE}
It can successfully sync with the LDAP.

9.x - trunk: Can NOT export fields nor synchronize a big tracker

Smaller trackers seem to be fine with exporting tracker fields.
But with this one, no content is shown in the popup box where the exported fields should be shown.
Somehow I managed to replicate this issue in my localhost in a Tiki 11.x, and I see this error message then:
{CODE()}
Request-URI Too Large

The requested URL's length exceeds the capacity limit for this server.
--------------------------------
Apache/2.2.22 (Ubuntu) Server...
{CODE}

This seems to be related to these two apache directives, that I didn't manage to change in my localhost (or at least, the error didn't dissapear):
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

Show instance created.
U: admin
P: 12345
To reproduce, try to export all or any of the 167 fields here:
http://xavi-9794-4756.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

---

I tried also exporting the whole tracker, fields and data through the tracker synchronization feature (), but After I click at the button to "search the trackers to clone" (or similar), at teh remote tracker duplication step, then I get this fatal error page:

{CODE()}
Fatal error: Uncaught exception 'Zend_Http_Client_Adapter_Exception' with message 'Read timed out after 10 seconds' in /path/lib/core/Zend/Http/Client/Adapter/Socket.php:511 Stack trace: #0 /path/lib/core/Zend/Http/Client/Adapter/Socket.php(329): Zend_Http_Client_Adapter_Socket->_checkSocketReadTimeout() #1 /path/lib/core/Zend/Http/Client.php(1075): Zend_Http_Client_Adapter_Socket->read() #2 /path/lib/core/Services/RemoteController.php(57): Zend_Http_Client->request('POST') #3 /path/lib/core/Services/RemoteController.php(26): Services_RemoteController->getJson('list_trackers', Array) #4 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->__call('list_trackers', Array) #5 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->list_trackers() #6 /path/lib/core/Services/Tracker/SyncController.php(280): Services_Tracker_SyncController->getRemoteTrackerList('http://ueb.vhir...') #7 /path/lib/core/Services in /path/lib/core/Zend/Http/Client/Adapter/Socket.php on line 511
{CODE}

Any help to get the tracker exported, by any means, to another Tiki install?

__Update:__ Clarified some of the description below.

^Please note this field type is marked "experimental" in 12.x^

[http://doc.tiki.org/Action+Tracker+Field|Action Tracker Field] type does not work in Tracker plugin.
I have tried it but no button appears labeled "Reset" on the action field row next to the "Reset Password" in the table.
To reproduce:
General > Name: Reset Password
Options for Action > Name: Reset, Post: get, Script: tiki-remind_password.php, Parameters: name:userName

{img fileId="941" thumb="y" rel="box[g]" width="320"}

__It should render a post or get form or just a button labeled "Reset" pointing to tiki-remind_password.php__ but renders nothing in the Tracker plugin. Maybe it should render below the tracker form in the code to avoid ''form in a form'' conflict and be placed on the row position of the field using jQuery?


It only shows up (while editing the Tracker item) in a special section called
"__Special Operations__".

But clicking the button from there is buggy too. Goes to:
tiki-remind_password.php?name%3AuserName=name%3AuserName&trck_act=Reset

Instead of:
tiki-remind_password.php?name=admin&trck_act=Reset