Category: 12.x

tiki-forum_rankings.php is broken since Tiki 4 due to its usage of function forums_ranking_last_topics(), which was removed:
Fatal error: Call to undefined method RankLib::forums_ranking_last_topics() in /var/www/tiki/6.x/tiki-forum_rankings.php on line 70

or

Fatal error: Call to undefined method RankLib::forums_ranking_last_topics() in /var/www/tikitrunk/tiki-forum_rankings.php on line 72

The method was removed in r20573.

We've been using the forum notifications ("email this address for any postings to this forum"), but would like to start exercising more fine-grained control over these notifications. The "Watch" concept appears to be exactly what we need, but some of the behavior I am seeing is confusing and may be contradictory to the docs.

According to the Tiki Docs on Watches, there are three kinds associated with forums:

1. A Watch for a Forum. Any new topic/thread posted should notify this user. I'm assuming it is represented by forum_post_topic associated with forum id within the Mail Notifications listing.

2. A Watch on a Forum Topic. Any new posts to that specific Topic/thread will notify user. Assuming forum_post_thread, associated with the topic's ID.

3. A Watch on Forum Topics & Threads. Any postings within that forum, be it Thread or Replies, will be sent. Assuming forum_post_topic_and_thread associated with the forum ID.

The problem I'm seeing:
* Some people have established forum_post_topic and forum_post_topic_and_thread on a specific forum
* Different user has posted to a forum, and he is set to watch that topic/thread (from_post_thread).
* People respond to his post
* The only people receiving notifications are a union between forum_post_topic and forum_post_topic_and_thread.
* I expected the notifications to be a union of the original author (forum_post_thread, on that thread) and forum_post_topic_and_thread (on that forum).
* In other words, the original author asked to watch his topic, but he received no notifications of posts/responses. Additionally, people who have asserted forum_post_topic on that forum are receiving updates, when I would expect they only receive notifications of his original topic post, not the subsequent responses.

Thanks,
Josh
---
Show instance details:
http://jhamell-10333-5804.show.tikiwiki.org/
u: admin
p: 12345
"Consensus Forums" profile has been applied. This demo profile creates two users (user1 and user2, with passwords user1 and user2 respectively)
See more information here:
http://jhamell-10333-5804.show.tikiwiki.org/tiki-index.php?page=Instructions+for+the+Consensus+Forums

Can you please reproduce your issue in this shjow instance, please, so that it's easier to debug the issue?
Thanks! {sign user="xavi" datetime="2016-02-04T08:24:58+00:00"}

Admin Toolbars
all installed from scratch.
v12.0 error

PHP (5.5.11) NOTICE (E_STRICT):
File: H:\WEB\**\tiki-12.0\tiki-admin_toolbars.php
Line: 52
Type: Only variables should be passed by reference

PHP (5.5.11) NOTICE (E_NOTICE):
File: H:\WEB\**\tiki-12.0\lib\parser\parserlib.php
Line: 705
Type: Undefined index: wikiplugin_expandingoutline

v12.1

When added to the line 1, 2 or 3, Plugin Tools Formatting Tools or disappear all Rows except one, but it after saving. Tulbars stops working, it disappears. Error tested as a demo version, and on the local server.
v12.1 editing tools do not work, v12.0 works, but with errors which have above.
PHP (5.5.11) ERROR (E_WARNING):
File: H:\WEB\liksoft.ru\tiki-12.1\tiki-admin_toolbars.php
Line: 161
Type: Invalid argument supplied for foreach()
PHP (5.5.11) NOTICE (E_NOTICE):
File: H:\WEB\liksoft.ru\tiki-12.1\lib\parser\parserlib.php
Line: 705
Type: Undefined index: wikiplugin_expandingoutline

{img fileId="771" thumb="y" rel="box[g]"}
{img fileId="772" thumb="y" rel="box[g]"}
{img fileId="773" thumb="y" rel="box[g]"}
{img fileId="774" thumb="y" rel="box[g]"}
{img fileId="775" thumb="y" rel="box[g]"}

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)

There are checkboxes to choose which days of the week to display in the calendar when creating/editing a calendar. I would expect when saved it will not display these days unchecked but instead it displays them all.

Hi to the readers,
I had an issue on a Tiki that I'm administrating.
This issue was that I had always the same IP address both in tiki-syslog.php and the history of a wiki page.
This happened because this Tiki installation is behind a reverse proxy.

To get the correct IPs, I had to check the "feature_loadbalancer" option in the "general" icon from the admin panel.

The strange thing about this from an user point of view is that I shouldn't expect to tick that box option as I'm not doing nothing about load-balancing. I was expecting to see an option such as "click that check-box if your Tiki installation is behind a reverse proxy".

It may be only a definition issue or a bigger bug. I don't know really and this is far away from my knowledge and skills.

Hope that helps and thanks again for this beautiful piece of software that Tiki is.

{GOOGLEDOC(key=pXsHENf1bGGY92X1iEeJJI, type=sheet, name=docFrame1, width=400, height=500, align=middle, frameborder=0", marginheight=5, marginwidth=5, scrolling=yes, editLink=both)}
{GOOGLEDOC}

This bit of code is refusing to work for me on my Tiki Site. I have tried several different types of google docs with open viewing permissions without even getting a single one of them to display anything other then the code in text form on the page. I have the googledocs plugin enabled in the tiki admin controls as well.

Toggling highlighting shows that the code is being recognized for what it is despite it just coming up as text on the page. Any help getting this plugin working would be very much appreciated I am utterly stumped.

When putting a user in a group that inherits permissions from the Registered group, that group is not visible when trying to share a task with a group.

1) Create a group that inherits permissions from Registered Group
2) Assign a user to that group.
3) Create a new user task
4) Try to share task with the above group
5) That group is not visible in the drop down box.

PS. The group name has Greek characters, I don't know if this is of any importance.

__Solved and closed! SORRY! It was a dumb configuration fault. I just unknowingly did set it this way - OUCH!__

Last update from SVN (12.0svn): Thursday 10.10.2013 22:59:47 CEST- REV 47972

When I create an article (example.com/tiki-edit_article.php) everything is fine,

but when I want to reedit th article (add some info, correct a typo etc.) and use the edit link to the article (example.com/tiki-edit_article.php?articleId=16), the body editor is disappeared.

The body (main part of the article) is alright shown in view mode, but it is not possible to reedit the body, cause then the body part of the editor isn't there.

--I try to reproduce on show.tiki.org now.--

__I could not reproduce on show.tiki.org__

--Weird! -> So I lower the importance and try to find out more.--

__Solved - it was a configuration fault! I can be so dumb.__

Last update from SVN (12.0svn): Friday 18.10.2013 12:58:31 CEST- REV 48060

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

{syntax type="tiki" editor="plain"}
Using the HTMLplugin in Wiki WYSIWYG. First time works fine (iniital entry and save)

if you re-edit the page, once you save, data from the plugin gets lost

This does NOT happen in normal editor

Wysiwyg enabled, using wiki syntax. Article has wysiwyg, and in the body, this content is added:
{CODE()}
{file type="gallery" fileId="41" showicon="y"}
{CODE}

When viewing the article, the html tags for the icon are shown instead of showing the file icon.
{CODE()}
<a href="dl41" class="internal"> <img src="dl41?thumbnail=y&x=16" alt="Image" class="regImage pluginImg" /> </a>
{CODE}

Mmmm, I can't reproduce, for some reason, with the show instance. I will provide a dbdump of my production site to any developer willing to have a go to fix this issue. (whatever permutation of settings is needed seems to be achieved - by chance - in that production site). {sign user="xavi" datetime="2014-04-24T16:49:50+00:00"}

(For the record: diaspora site)

{flash type="url" movie="display651" width="1119" height="601"}

http://i18n.tiki.org/Status shows fatal error

{CODE()}
Fatal error: Class 'Table_Plugin' not found in /www/htdocs/w00ec2fb/lib/wiki-plugins/wikiplugin_fancytable.php on line 11
{CODE}

{flash type="url" movie="display559" width="878" height="732"}

Hold on, trying to reproduce on show...

__Update__: OK, it worked Please ignore. Closing and deleting.

__Update 2__: Well, actually it turned out that the "culprit" was adding the IP address to whitelist of the server requesting the FB login to Facebook App Advanced tab. Re-opening the item and re-categorizing, because I feel, Tiki should support that and not fail with the login attempt when someone sets that up on the FB App side.

Please ignore. This is not actually a bug or feature request.

Too frequently, when you want to do some stuff at i18n.t.o, you get stuck with:

{CODE()}
Fatal error: Class 'Table_Plugin' not found in /www/htdocs/w00ec2fb/lib/wiki-plugins/wikiplugin_fancytable.php on line 11
{CODE}

something similar happens when you enable interactive translation and attempt to go to any admin panel.

When inserting a plugin into a page, it brings you to a different place than where the cursor is.

PluginMouseOver is a good one to test

{flash type="url" movie="display719" width="671" height="535"}

If 'Store attachments in file galleries' is enabled (feature_use_fgal_for_wiki_attachments , in File Gallery admin panel: "Use file galleries for wiki attachments"), a new file gallery is created each time a new wiki page is created.

When you removing a wiki page, the file gallery (which may carry no files at all) is left in place. The user would expect to see an option to remove the file gallery of the attachments too, along with the remove wiki page confirmation step.

Like when attempting to remove a wiki page from a structure: remove wiki page from structure only, or remove wiki page itself also.

When plugin are editable on the web page, the iframe edit-dialog is hidden behind the iframe "window".

{img fileId="655"}

Images uploaded to tracker field image do not respect multitiki paths.

When you upload an image to this type of field, they go to

__img/trackers/__

When you are in a multitiki of, let's say, site1.example.com and site2.example.com, you have a folder for site1 at:

__img/trackers/site1.example.com/__

but your image files don't get uploaded there, but to the general

__img/trackers/__

And the same with all the other multitiki sites.
When you want to backup files, or migate a site to a new server, you are in trouble to know which files belong to which site from the multiki installation.

For consistency with how multitiki works, they should be uploaded to, and used from, the multitiki-aware path:

__img/trackers/site1.example.com/__

Since {commit id=24627}, the IMG plugin supports percentages in its width or height parameter to scale the image. For example...
~np~{img fileId="2970" width="50%"}~/np~
... would display image 2970 with its original dimensions halved.

This was unfortunately broken for Tiki 9 and later on some systems by {commit id=37006}. Setting dimensions this way is ignored, for example on French systems, which use a comma as decimal separator instead of a point.

The attached patch fixes in 2 ways. Any one is sufficient. The change to tiki-download_file.php is not quite clean as it alters $_GET.

Note that this exposes a lack of validation in tiki-download_file.php.

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