476

(1 replies, posted in Problems)

Hello Emilie,
Great, you've been digging in the code details smile
Yes, you are right in eventform0.php and eventreport.php the nom and nos parameters (nom => number of days before event to send a reminder email and nos => idem for SMS) are not added to the $evt array before calling the function makeE. However, the nom and nos parameters are only used by the makeE function if the template (2nd parameter in makeE function) contains a '6' and - and this is important - if a '6' is present in the last parameter 'show'.
In both cases, eventform0.php and eventreport.php, the last parameter of the makeE call does NOT contain a '6'! So in these cases the makeE function will never use the nom and nos parameters and therefore these parameters need not be present in the $evt array.

So it is intentional that in the eventform0.php and eventreport.php code the nom and nos parameters are not present in the $evt array.
(If makeE would use these parameters while they are not present, a PHP warning would be produced, which is not the case.)

Kind regards,
Roel

Hi Stefan,

It's all done in one JavaScript function. I'm not sure this can be easily changed. I will investigate what's possible.

Roel

478

(7 replies, posted in Suggestions)

Hi there,

Adding additional event fields has an impact on many of the calendar scripts and is quite a big change. We have currently no plans to increase the number of fields, but since more calendar users have asked for this, we should maybe change our plans.

Roel

479

(1 replies, posted in Problems)

Hi Bernard,

This is a bug in version 4.7.0. You can download a fix in this forum under "Known Issues and Fixes" (LuxCal 4.7.0 - Problem when editing one occurrence of repeating event).

Roel

480

(1 replies, posted in Problems)

Hi there,
Thanks for reporting this problem.
It can indeed be solved by changing the type of the defslot field in the categories table to SMALLINT.

The problem only applies to the MySQL version of the calendar. In the SQLite version the defslot field in the categories tables is INT.

This problem will be fixed in the next LuxCal calendar version 4.7.1.

Roel

Good guess, but not quite right wink
Thanks for reporting this problem.

I've posted a fix in this forum under Known Issues and Fixes.

Roel

In email reminder messages the links to possible attachments were relative links and therefore the attachments could not be opened from the emails.

To make the attachment links in email reminder messages absolute, so that attachments can be opened from the email messages, apply the following change.
Edit file common/toolbox.php and on line 228 replace . . .

href='./attachments/

by . . .

href='".calRootUrl()."attachments/

You can also download the changed toolbox.php file here.

Roel

Good point.

And since you've already given me the file and line number, it should be a piece of cake wink However, to make the attachment accessible from an email reminder, the change should be made somewhere else. I will see what should be done.
Where did you get this $calUrl? This is not an existing global variable, it's only used locally in the file messaging.php. We should use $set['calendarUrl'] and strip off the possible suffix "?cal=<calID>".
I will add this change to the next calendar version 4.7.1 and tomorrow, Belgium time, I will post a fix, for those who can't wait smile

Roel

484

(2 replies, posted in Problems)

Hi Stefan,

You are right. Neither bug nor feature wink
In LuxCal version 4.6 we introduced a user number, which could be specified when creating/editing a user account.
This user number however, was used nowhere and our plans to use it changed.

So in LuxCal version 4.7 we removed it again, because just entering a number which is never used does not make much sense.
I commented out the code to enter the number and left it, just in case we would need it later for the future "participation feature.

Roel

485

(11 replies, posted in Need Help)

Hi Stefan,

In the calendar's index.php file the function "isMobile" is called and the return value is stored in the variable $isMob. The return values can be: 0: not mobile, 1: mobile tablet, or 2: mobile small display.
So if you do a global search with "$isMob" through all calendar files you will find the places where measures are taken to make the calendar more responsive.
(Just in case: To do global text searches, you could use the free application TextCrawler)
Roel

During his holidays Gérard has update and completed the French language files for LuxCal version 4.7.0.
The updated language pack can be downloaded on the Downloads page.
Roel

487

(2 replies, posted in Need Help)

Ha ha, yes great question, why exactly at 3:15am? Actually it does not matter so much when lcalcron.php is started.
Since this file triggers the sending of email reminders for the day, it should start before the early rising calendar users open the calendar.
So why not start lcalcron.php just after midnight, or at 1:00am? Because various countries have Summer and Winter times (DST) and the DST change is not always at the same hour in each country. If you would start the lcalcron.php file for instance at 2:00am and at the end of the Summer at 2:00am  the clock is set 1 hour back, during that night it will be 2:00am twice! This would then start the lccron.php script twice resulting in duplicate reminder messages.
So, to make a long story short, we said let's suggest 3:15am; this will not interfere with DST changes in the various countries and it's still early enough to send reminders for the day to come.
I hope this sufficiently explains the 3:15am mystery smile
Roel

488

(4 replies, posted in Suggestions)

Hi there,

That's a fair request and good suggestion.
So, yes, I will add this possibility.
It should not take too long to implement; if you are interested and send me your email address (via the Contact Us page), I will send you a changed file, with this option added, most probably within one week.

Roel

Hi there,
Currently selecting a calendar, in case of multiple calendars in one install, is only possible for users with administrator rights. This is done because for a certain user the rights for one calendar can be completely different from the rights for an other calendar. For instance if a certain user would have view or post rights in one calendar and would have no access rights in an other calendar, then if the user could switch to the other calendar, he/she would get the log-in dialogue (no Options Panel) and there would be no way back to the first calendar anymore.

As said by John in the other thread, we're planning to review the concept of multiple calendars (in one install and in different folder) for the next calendar version.

If this is not exactly what you meant, please let me know.
Roel

490

(6 replies, posted in Problems)

Hi Luigi,

Hmm, I did exactly the same, I created a user group Operators with exactly the same parameters as in your last post.
Then I created a user and assigned the user to the group Operators and thereafter I could create/edit events and I could also edit the events of other users. So it worked fine, as expected.

The error message 'no edit rights (event). Please log in.' should normally never appear. This error message only shows if something unusual happens.
Are you sure that the user Test can successfully log in? Is the user name Test displayed in the right upper corner of the calendar after log in?

Could you send me (via the Contact Us page) a link to your calendar and a temporary user account with admin or manager rights? I will then have a thorough look at what is happening.

Il tuo inglese è molto meglio del mio italiano wink

Roel

When running the file lcalcron.php via a cronjob, a PHP notice message may occur, saying "PHP Notice:  Undefined index: xda in /home/eakpvwdu/public_html/kal.irweb/cronjobs/notify.php on line 39".
This PHP Notice issue was already reported "solved" in the latest calendar version 4.7.0, but for mysterious reasons the solution was not included in the V4.7.0 zip-file.
This PHP Notice has no detrimental effects on the functioning of the email reminder function, but if you want to solve the issue, then you can download the changed file here.

You can also fix this problem by applying the following changes:
Edit the file cronjobs/notify.php and replace lines 37 - 39 . . .

if ($evt['mde'] <= 1 and //first day
  ($daysDue == $evt['nom'] or $date == $todayD00) and //email due
  !($evt['r_t'] and strpos($evt['xda'],$date))) { //date not excluded if repeating event

by . . .

if ($evt['mde'] <= 1 and //single day event or first day of multi-day event
  ($daysDue == $evt['nom'] or $date == $todayD00)) { //email due

and replace lines 93 - 95 . . .

if ($evt['mde'] <= 1 and //first day
  ($daysDue == $evt['nos'] or $date == $todayD00) and //SMS due
  !($evt['r_t'] and strpos($evt['xDates'],$date))) { //date not excluded if repeating event

by . . .

if ($evt['mde'] <= 1 and //single day event or first day of multi-day event
  ($daysDue == $evt['nos'] or $date == $todayD00)) { //SMS due

Use cut and paste!

Roel

Hi Mike,

Thanks for reporting this error.
The PHP Notice issue was already reported "solved" in the latest calendar version 4.7.0, but for mysterious reasons the solution was not included in the V4.7.0 zip-file.
Coincidentally this PHP Notice has no detrimental effects on the functioning of the email reminder function.

Nevertheless I have posted the solution under Known Issues and Fixes.

Roel

493

(2 replies, posted in Need Help)

Hi Luigi,
There could be two reasons:
1. You have selected maybe via the Options Panel the English language and this is saved in a PHP session variable. During the PHP session, the calendar will take the language from this PHP session variable, unless you select an other language. PHP sessions last normally no longer than 22 minutes (of calendar inactivity), so this problem should solve itself when you close the calendar for more than 22 minutes.
2. On the Settings page, under User Accounts you have checked "Restore last user selections" and you have once selected English, which was subsequently stored in a cookie. If you log out now and log in again, it will take the last user selections, i.e. English. To overrule this, take care that on the Settings page, under User Accounts, "Restore last user selections" is checked and in the Options Panel select the Italian language. Now the last selections, including the Italian language will be stored in a cookie. Now the problem should be solved.

Roel

A bug in V4.7.0 causes the following problem:
When editing one occurrence of a repeating or multi-day event, the other days of the event disappear.
When deleting one occurrence of a repeating or multi-day event, the whole event is deleted.

To fix this problem changes to two files are required. You can download the changed files here.

You can also fix this problem by applying the following changes:
1. edit file pages/eventform1.php and just after line 49 (<input type='hidden' name='eid' value='{$eid}'>) add the following line . . .

<input type='hidden' name='evD' value='{$evD}'>

2. edit file pages/event.php and change line 107 from . . .

$ediN = 0;

to . . .

$ediN = (isset($_POST['ediN'])) ? $_POST['ediN'] : 0; //0: not relevant, 1: occurrence, 2: series

and change line 115 from . . .

$ediN = ($mode == 'edi' and is_numeric($_POST['action'][3])) ? $_POST['action'][3] : 0; //0: not relevant, 1: occurrence, 2: series

to . . .

if ($mode == 'edi' and is_numeric($_POST['action'][3])) { $ediN = $_POST['action'][3]; } //0: not relevant, 1: occurrence, 2: series

and change line 222 from . . .

if (!empty($evD)) { $sda = IDtoDD($evD); }

to . . .

if (!empty($evD) and empty($sda)) { $sda = IDtoDD($evD); }

Use cut and paste!

All users of v4.7.0 are advised to implement these changes.

Roel

When you have upgraded the calendar to a new version and you discover some unexpected behavior, like certain buttons are not working, some form fields are not pre-filled properly, etc., then  . . .

TRY REFRESHING /RELOADING THE PAGE IN THE BROWSER (Ctrl-F5)

this will reload the styles and JavaScript tools which are often kept in the computer's cache.

Roel

There is a flaw in the upgrade script. In the upgrade script the thumbnail privileges in the user groups are not initialized. The result is that, when upgrading, all existing user groups in the database have the Thumbnail privileges set to a non-existing value, which results in no privileges at all.

Solution:
- Go to the admin's User Groups page. A number of PHP notices will be displayed. Ignore these messages.
- Edit each user group and set the Thumbnail privilege to one of the values from the drop-down menu.
That's all.
After going through the steps above, there are no further adverse effects on the functioning of the calendar itself.

Only the upgrade script has this flaw; new installations are fine.

Roel

497

(3 replies, posted in Need Help)

Hello Dan,
Yes, right, I will look into this and change the privileges for the default user groups.

I will also look at the Notice messages; they should not appear. Could be a cache problem.
Kind regards,
Roel

Great!
Thanks Gérard, good point.
For the next calendar version I will change the upgrade script too.

Roel

499

(7 replies, posted in Need Help)

Great Michael! You too.
Roel

500

(7 replies, posted in Need Help)

Try the following:
- edit the file pages/login.php and to get rid of the "Remember me" check box delete line 204:

<span class='floatR'><input type='checkbox' id='cookie' name='cookie' value='1' ".(isset($_COOKIE['LCALuid']) ? " checked" : '')."><label for='cookie'> {$ax['log_remember_me']}</label></span>

- edit the file index.php in the calendar root and before line 65 (session_start();) add the following line:

session_set_cookie_params(1440);

and replace "1440" (in the line above) by the number of seconds you would like a session to last. E.g. 600 = 10 minutes.

Roel