Category: 14.x

After a fresh install of the Tiki 14 suite I was immediately unable to log in to my website. When I attempted to do so, a blank white page would appear, and no further progress could be made. My PHP memory was not an issue. After doing some tracking as to what was causing the problem, I found a single line that was causing the blank pages to appear when I attempted to log in. Inside the file: /lib/userslib.php, on line 1465, the code:

$ret &= $this->ldap_sync_groups($user, $pass);

was causing some sort of problem with the ldap and thus caused the blank pages to appear. I simply commented the line out and was then able to log in to my website.

Hi,

We've been using the LDAP to authenticate our users ever since we created our site a couple years ago. We've run into a few road bumps along they way, but this time I can't seem to figure out the issue that is occurring with the LDAP. The main issue that I am seeing here is that the LDAP doesn't appear to be syncing with our groups.

If I attempt a log in on my normal admin account, it appears to allow me to log in as if it's recognizing that I am a user, but while it logs me in, the groups aren't being synced. This results in an error that says "You do not have permission to view this page." So I logout of that account and log back in with the default admin account (which seems to be the only account still working without the LDAP group sync). When I check the Users list, I can see that even my normal admin account has been completely removed from the groups I previously belonged to before my login attempt.

Therefore, this leads me to believe that the issue is with the ldap_sync_group functions somewhere inside the lib/userslib.php file. I've tried a couple of workarounds, but to no avail. Has anyone experience anything like this?

Please help, as this is completely breaking my Tiki installation!

{CODE()}PHP (5.5.3-1ubuntu2) NOTICE (E_DEPRECATED):
File: lib/shoutbox/shoutboxlib.php
Line: 57
Type: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead{CODE}

Please do in 12.x if easy / not risky, otherwise, just trunk

Visible on the footer of
http://tiki.org/tiki-admin.php

{img fileId="656"}

A check box to mark the tacker can only be submitted once per person, like in the quiz feature, but with trackers.

I've tried everything I can think of that was written in every tracker help page to force only one submission per user. (not the same as one entry per user, since it seems I can re-submit the form over and over to modify the answer.)
---
Tested in trunk as of Jan 19th 2016 (r57256) and I confirm that there is some regression bug at least in trunk: standard registered user is able to submit a new item even if the setting to allow just one item per user or ip is enforced. {sign user="xavi" datetime="2016-01-19T10:13:02+00:00"}
To reproduce: login as
u: user1
p: user1
(plain registered user)

And go to

http://duqtape-11783-5792.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

where you will be able to insert new items, when you shouldn't, since the tracker setting "Only one item per user or IP (The tracker needs a user or IP address field with the auto-assign set to Creator)" is enabled, and that user field is set as required.

You can admin the site with:
u: admin
p: 12345

Clicking on the interrogation mark that exist on the right of the title "Assign global permissions" on objectpermissions.php takes the user to a wrong doc page: [https://doc.tiki.org/Permission] (The word Permission in the singular form)

!!!!Facts:
*The page [https://doc.tiki.org/Permissions] (in the plural form) exists.
* An alias "permission" at the bottom of the page above also exists, but seems not to work properly.

!!!!Trying to workaround myself:
*I created an alias called "Permission" at https://doc.tiki.org/Permissions to test if the the upper case sensitivity of the letter "P" could eventually be what was preventing at the alias to work properly. It did not work. Another possible bug.

Different browsers have a different behavior so ideally the Tiki plugin accepts the file path and produces what is needed for each browser.

* http://stackoverflow.com/questions/5317834/workaround-for-href-file-in-firefox
* http://stackoverflow.com/questions/192080/firefox-links-to-local-or-network-pages-do-not-work


{CODE(caption="link to a file")}W:\00 - Project Management\01 - Project Plan\GLOBAL PLAN.pdf
{CODE}

{CODE(caption="link to a folder")}W:\00 - Project Management\01 - Project Plan\
{CODE}

live.t.o: Add a new param to plugin BigBlueButton so that only recordings longer than X minutes are displayed

See it reproduced in https://tiki.org/Live > BBB current recordings (once loged in)

There are 140+ recordings, and most of them are kind of demo trials, of less than 10 minutes. Last year 2013 I spent like 1h reviewing the short meetings and deleting them from the recordings list, since they pollute the list. But every month there are new of those recordings, demo, tests, support requests in the wrong place, etc. and it's tedious to do this manual work, which might happen also in other sites using Tiki + BBB.

A simple workaround would be to add an extra param to the ((doc:PluginBigBlueButton)) so that only recordings longer than X minutes (default to 10' ?) are displayed in the recordings list.

Not 100% if it's a regression or not as not tested in older versions for now. But if I have a tracker with a location field and also a date-time field, and if I trigger the date time field and if the jscalendar popup goes over the map it will go behind the map and be unclickable as a result.

Look & Feel for http://suite.tiki.org is currently (14.x) worse than expected. It seems as if no one could tweak the look and feel of that domain/perspective/whatever handles the suite.t.o layout/look&feel

Even http://tikisuite.org displays an enormous logo in firefox for me, I don't know why.
Maube it's a known temporary issue, but just in case, I'll drop an item here...

When attempting to register a new user in a 12.x tiki site (svn updated to recent revisions as of today {sign user="xavi" datetime="2016-03-03T09:31:44+00:00"}), users see this image after filling in the form with all required fields (and images from the recaptcha test) and clicking at the register button:

Fatal error: Call to undefined function curl_init() in /path/tiki12svn/lib/captcha/Captcha_ReCaptcha20.php on line 49

See show instance at http://marclaporte-11197-4860.show.tikiwiki.org/

In a superfish menu, a menuSection (parent) item followed by an option (child), then a "separator", then another option, will put the menuSection and the last option on the top level, and the first option will be below the menuSection. This is the right way. But in a Bootstrap menu, both of the options will be under the menuSection, with the separator ignored.

Hello,

I already reported my discovery in the forum. But here again for the formal way.

The problem:
If you want to use the feature "cookie" on a menu, it will not work.

Test Case:
Open up a menus sub structure, click on a link, and the menu is collapsed on the new site.

Reason:
tiki wiki checks if the menu cookie "menu.menu_structure_pageID" is existing and if so, it looks if it is opened or closed.

But, the cookies name is not "menu.menu" but "menu.menus".

Where is the problem:
/lib/menubuilder/menulib.php:468
$ck = getCookie('menu'.$params['id'].'__'.$option['position'], 'menu');

should be changed into:
$ck = getCookie('menus_'.$params['id'].'__'.$option['position'], 'menu');


Another problem is, that this only works for a flat hierachie (like in the bootstrap menu), but if you want to work properly in all menus, you have to change the else if statement too.
Same file, line 464:
} elseif ($option['type'] == 's') {

on every lower level, the option.type is not set. We commented it out, so we have a simple } else { and it works.

If use Bootstrap menu is set to "y", the menu is vertical instead of horizontal even if the type is set to horiz. If "bootstrap=y" is not explicitly set (left empty, since it's the default), then type=horiz has the expected effect.

The set up I have on my local install, and it is demonstrated below.


Problem:
#have structure
#have menu module showing structure
**when add page to structure, it should show in menu module
#menu module is cached, though it has cache time set to 0 (to never cache). This makes it so when you add a page you have to clear cache for it to show up in the menu module.

When entering the parameters for the menu module, to have a horizontal Bootstrap menu, if you don't enter anything in "Use Bootstrap menus", the menu will be Bootstrap as this is the default. And it will be horizontal if for "Type" you enter "horiz". But if for "Use Bootstrap menus" you enter "y", then the resulting menu is vertical, not horizontal.

On /tiki-admin_menu_options.php , "Preview" tab, a preview of the menu should display. The hierarchy of links is ok, but the menu type doesn't match the requested options (CSS or not, horizontal or vertical). Maybe this code hasn't been updated since Bootstrap integration.

When uploading files in the file gallery (XXX.JPG) with uppercase filenames they will be detected as application/octet-stream (XAMPP on Windows 7).
Instead they should be recognized as jpeg.

Proposed patch (i.e. convert extension to lower case before testing for mime type).
~pp~
--- mimelib-ori.php 2013-12-07 13:07:10.000000000 +0100
+++ mimelib.php 2013-12-07 13:08:07.000000000 +0100
@@ -101,7 +101,7 @@
global $mimetypes; include_once('lib/mime/mimetypes.php');

if (isset($mimetypes)) {
- $ext = $this->get_extension($filename);
+ $ext = strtolower($this->get_extension($filename));
$mimetype = isset($mimetypes[$ext]) ? $mimetypes[$ext] : '';

if (!empty($mimetype)) {
~/pp~

jQuery fails to load if minify is enabled and a JS CDN is in use.

Go to http://jonnybradley-8515-5634.show.tikiwiki.org/tiki-admin.php?page=performance (login is admin 12345) and try different CDN settings. Curiously on my production server both Google and jQuery CDN settings fail, but on this show instance the Google one works - odd {sign user="jonnybradley" datetime="2015-04-17T11:13:37+00:00"}

I've twice lost a long page of input information by accidentally clicking outside the modal popup (first in Opera and then in Firefox). Is this inherent in modals? Or is there some way they can be done that is forgiving of errant clicks? I'm thinking an explicit "close" or "save" click is necessary to close the popup, not just clicking outside of it.

Hi, I first want to setup a show instance to check.

In Tiki 14 on wiki pages I am using a module, for example: ~np~{module module=articles lang=de ... } ~/np~.

The module is showing articles of all languages and not filtering for the language specified in the parameter.

In a menu the link ~np~/articles?lang=de~/np~ is working alright.

Torsten

When I edited some modules for a client in Tiki 14.x I spotted this oddity: I moved the module to position 2, then edited the module for some params, then saved it and it was back on position 1 in the order of modules. So I tried editing the module again, choose order 2, save, and again, it got reset to 1.
Will try to reproduce on show... hold on!

Hmm... cannot reproduce on show 14.x - either a local space oddity or was fixed in 14.x SVN - closing.

Discussed here:
https://dev.tiki.org/Cleanup#Moving_libs_from_Code_to_Composer

Nested footnotes do not display in footnote area.

This is because footnote content is not evaluated until after footnote area renders it. Using a second footnote area will render the footnotes correctly, in the second footnote area, but the links to those footnotes in the second footnote area no longer function.

Evaluating footnote content within the footnote plugin should fix the error.

!!!Begin Footnote Test

non footnote area {FOOTNOTE()}Footnote 1 {FOOTNOTE()}Nested Footnote 2 {FOOTNOTE} Continuation of Footnote 1 {FOOTNOTE()} Nested Footnote 3 {FOOTNOTE()}Footnote Nested Twice 4{FOOTNOTE}{FOOTNOTE}{FOOTNOTE}
text after all footnotes

{footnotearea() /}

!!!Expected Result

non footnote area {SUP()}((1)){SUP} text after all footnotes

((1)). Footnote 1 {SUP()}((2)){SUP} Continuation of Footnote 1 {SUP()}((3)){SUP}
((2)). Nested Footnote 2
((3)). Nested Footnote 3 {SUP()}((4)){SUP}
((4)). Footnote Nested Twice 4

The expected result is for each footnote to appear once, each with there own footnote number, and referenced as such in the main body of the text. Additionally, using a footnote should not create a line break in the original text.

!!!End Footnote Test

Basically what happens is when you try to create a new calendar item, when altering the Start and End times, there is some sort of bug occurring in how it calculates the time codes in the back end. If the times of the event start in the AM and end in the PM, it causes some sort of issue with the way the timecodes are calculated. As well, it appears to be an issue with the 'predictive' functionality it uses. When you select something like an 8AM Start time, it will automatically try to adjust the End time to something an hour in advance or so. This will cause it to get hung up thinking, and sometimes it automatically changes the year to some distant future date like in the year 2507.

As well, selecting a Start time in the AM, and an End time in the PM such as 9AM-9PM causes the calendar to say "Events cannot end before they start."

To test: simply go to the Test calendar on the Show Instance and try creating a new event. Play with the Hours on the Start and End times by just changing them around several times. This will always result in the calendar lagging out and sometimes an unresponsive page.

I will replicate this in a tiki show instance.

Thanks.