Hi Dan,

Since several calendar users have asked for the possibility to add additional fields, it may be a good idea to implement a flexible possibility to add/delete extra fields to events. I will investigate the feasibility of this new feature; as you suggested, maybe something similar to adding/deleting categories.
If this appears to be feasible without too many troubles and we decide to go ahead, then implementing this new option will for certain take quite some time (months). But it's always nice to have something to look forward to wink

Regards,
Roel

377

(9 replies, posted in Problems)

Hi there,

In the latest calendar version 4.7.4, the Print funtion in the side menu is not working.
Below you will find two minor changes: 1) to show the end times in Month view and 2) to fix the print problem.

The changes are for calendar version 4.7.4!

1) edit the file views/month.php and replace line 17 . . .

$dTime = $evt['mde'] ? $time : ITtoDT($evt['sti']);

by . . .

$dTime = $time;

2) edit the file common/toolbox.js and replace line 379 . . .

var els = $T("*");

by . . .

var els = [].slice.call($T("*")); //convert nodelist to array

Now you will see the end times, if there is one, in Month view and the print function in the side menu will work.

I think this could be interesting for other calendar users too, therefore in the next version of the calendar I will add a setting to enable/disable the display of the event end time in Month view.

Roel

378

(2 replies, posted in Problems)

Hi Chuck,
Thank you for reporting this bug.
This problem can be solved by editing the file "pages/eventform1.php" and . . .

replace line 216:

echo "<select name='r_m' id='r_m' onclick=\"\$I('r_t2').checked=true\">

by:

echo "<select name='rpm' id='rpm' onclick=\"\$I('r_t2').checked=true\">

In other words: replace "r_m" by "rpm" (2x).

The problem will be fixed in the next calendar version 4.7.5.
Roel

Hi  there,
Send me your email address (via the Contact Us page) and I will send you a very small PHP session test script. If this script shows your PHP sessions are not working, then we will takeit from there.

Roel

380

(2 replies, posted in Problems)

Hi there,
This problem is most probably occurring because LuxCal 4.7.4 has a problem with PHP 7.3 (PCRE library V10.32). The problem has been solved and will be fixed in the next LuxCal v 4.7.5.
I'm afraid there are only two possibilities:
1. Downgrade  to a lower PHP version
2. I can send you a pre-copy of the new version 4.7.5

If you chose option 2, please send me your email address, so that I can send you V4.7.5.
Roel

381

(1 replies, posted in Need Help)

In the next LuxCal version 4.7.5, Thumbnail links will use the full URL, rather than the URI. This means that if the calendar URL, specified on the Settings page, starts with https;//, also the thumbnails will use SSL. Using the full URL for thumbnails makes it possible to use thumbnails in email messages.

Roel

382

(1 replies, posted in Need Help)

Restricting the number of days events can be added in advance is currently not possible.
We're considering to add this as an option per event category, not in the next LuxCal version, but in the version thereafter.

To help cknath, we modified one of the calendar scripts and inserted a hard coded test for x number of days and have sent this modification to cknath.

Roel

Hi Doss and John,
I had a careful look and it appears that when on the Settings page, under Views, "Show images in month view" is not checked, then in the hover box with event details, thumbnails are shown next to each other, which is fine. However, if "Show images in month view" has been checked, in the day cells in Month view the images are shown under each other.
Don't ask me why hmm
To solve this, edit the file "views/month.php" and
change line 49 from . . .

  foreach ($imgs as $img) { echo $img[0]."<br>"; }

to . . .

  foreach ($imgs as $img) { echo $img[0]; }

In other words: delete ."<br>"

Now the thumbnails will be shown in line (if they are not too wide and fit).

Roel

PS. I will change this is the next calendar version.

384

(6 replies, posted in Problems)

Hi Greg,

Yes, I see the point. The Changes page shows something else than the email report, which is not correct and should be avoided.
So fair enough, for the next calendar version I will change the delete script and at the moment of deletion set the "edited by" field to the current user.
If you want to implement this change also in v4.7.4, then you should edit the file "pages/event.php" and make the following changes:

just below line 423 ( if ($mode == "del") { ) add . . .

$_SESSION['evt']['edr'] = $usr['name'];

and change lines 425 and 426 from . . .

$stH = stPrep("UPDATE `events` SET `status` = -1, `mDateTime` = ? WHERE `ID` = ?"); //delete
tExec($stH,array($todayDT,$eid));

to . . .

$stH = stPrep("UPDATE `events` SET `status` = -1, `editor` = ?, `mDateTime` = ? WHERE `ID` = ?"); //delete
stExec($stH,array($usr['name'],$todayDT,$eid));

and change lines 429 and 430 from . . .

$stH = stPrep("UPDATE `events` SET `xDates`=? WHERE `ID` = ?"); //exclude date
stExec($stH,array($_SESSION['evt']['xda'],$eid));

to . . .

$stH = stPrep("UPDATE `events` SET `xDates` = ?, `editor` = ?, `mDateTime` = ? WHERE `ID` = ?"); //exclude date
stExec($stH,array($_SESSION['evt']['xda'],$usr['name'],$todayDT,$eid));

After these changes, deleting an event will be treated similar to editing an event as far as the "edited by" and the "date/time edited" fields are concerned.
Roel

385

(5 replies, posted in Problems)

Hi Greg,

Yes, you are right.
MySQL and SQLite have no functions to convert HTML entities or ignore HTML tags.
It could be done by using multiple REPLACE functions, but replacing all possible HTML entities in all fields to be searched still doesn't solve the problem with HTML tags.
It could be done by regular expressions, but to deal with all entities and tags, it would require a very complicated expression.

Since the search results are very volatile (just for the eyes) and the search criteria can be easily changed, I think it's not worth making the search algorithm much more complicated..

Roel

386

(6 replies, posted in Problems)

Hi Greg,

The current logic is the following:
1. When an event is added, the "added" date, time and user are stored in the event record (if the event was added by an "admin" for Mr. X, then Mr. X will be stored as the one who added the event.
2. When the event is modified within 10 minutes from the moment of adding the event, the edit action will not be recorded. (When you add an event, and directly (within 10 minutes) correct a typo, this will be considered part of the "adding").
3. When the event is edited at least 10 minutes later than it was added, the date, time and user will be recorded.
4. When you delete an event, the date and time are recorded, but not the user who deleted the event.

Number 4 could be called a 'bug', although it was done like this on purpose because we thought it was not worthwhile to add two special fields (name and date/time) just for a deleted event .

It is an easy change to save the user who deletes the event in the "edited by" field, so that on the Changes" page you can see who deleted the event, but then a possible "editor" will not be known any more.

If there is more demand for this, adding two additional fields "deleted by" and "date and time of deletion" is of course also possible, but this requires a database schema change which has more implications.

Roel

387

(1 replies, posted in Problems)

Hi Lee,

I had a thorough look at the upgrade script of V4.6, but could not find any problem.
Did you get this SQL error while you were upgrading, or did the upgrade run successfully and did you get the error when you started the calendar for the first time after the upgrade?
Would it be possible to email me  (via the Contact Us page) a .sql back-up file of your calendar database (either V4.5 or 4.6). I will then further analyze the problem and fix it. If you send me V4.5, I will upgrade it.

Just a question: Why do you upgrade to v4.6 and not to the latest version 4.7?

Roel

388

(6 replies, posted in Need Help)

Hello Mike and John,

I think John's two questions are rhetorical questions wink
and therefore my answer to both questions is: Yes!

Don't ask me why it is not working as it should, but the good news is that I've already fixed both problems.

Mike, if you send me your email address (via the Contact Us page), then I will  send you a fix before the end of the day.

Roel

389

(4 replies, posted in Need Help)

Hi Laur,
What kind of second check mark do you exactly mean? I don't quite understand what you mean.

Roel

390

(11 replies, posted in Problems)

Hi Greg,

The link to V4.7.2L when you hover the Powered by LuxSoft button is my mistake and will be corrected in a next version. This doesn't harm.
The fact that you get a Session expired message with "== no token assigned ==" in the footer could be caused because of "old" cookies in the browser cache.

I'm certainly willing to help you and with FTP access further analyse the problem. However, if you re-upgrade, the users of your calendar will most probably encounter the same problems, which will be annoying.
Is there no way to install the new 4.7.4 calendar in a test folder, so that I can test without affecting the main calendar? Via email I can explain to you in a few lines how to do this; it's really easy - no Softaculous needed.
Let me know if you want me to do this.

Roel

391

(11 replies, posted in Need Help)

See my email reply.

392

(11 replies, posted in Need Help)

Shock,

Could you try deleting all cookies related to the calendar.
If that doesn't help, could you send me the URL of your calendar so that I can have a look myself.

Roel

Highlights

This new LuxCal version 4.7.4 contains a number of important improvements and bug fixes.
Most important new features / improvements:
• New "address button", showing an address from the venue field in a map viewer (e.g. Google Maps).
• URL-links, Mailto-links and Address buttons (see below) can now be clicked in the hover box, without opening the Event Report window.
• New "display" for narrow-width displays and all existing "displays" have been updated. Displays can now be viewed and downloaded on the LuxSoft website.
Hereafter you will find a full summary of all changes since LuxCal version 4.7.3.

As usual this new release has been tested again with the help of John from Denmark. Thank you John, you've done a great job!

New features/Improvements
• In Month view the position of the hover boxes with additional event details is now fixed just over the right side of the event title and the boxes can be hovered with the cursor. An important advantage is that URL-links, Mailto-links and Address buttons (see below) can now be clicked in the hover box, without opening the Event Report window. Since URL-links and Mailto-links can now easily be selected in the hover box, these links have been removed from the day cells, which saves precious space in the day cells.
• If in the venue field the address is placed between exclamation marks (!), in the calendar views the address will be replaced by an "Address button". When hovering the Address button, the address will be shown and when clicking the button, a map viewer window will open, showing the specified address. On the Settings page the administrator can disable/enable this feature and can specify the map viewer to be used. The default map viewer is Google Maps. The exclamation marks will not be visible to the calendar visitors.
• In day and week view on a device with a small display it is now possible to open the edit event window by clicking the event title.
• The display of thumbnails in Month view has changed as follows: When on the Settings page "Show images in month view" is enabled, thumbnails will be shown in the day cells and when disabled, thumbnails will be shown in the on-mouse-over boxes instead. So thumbnails will not be displayed in both at the same time.
• In the previous calendar versions, the Search page can only be opened via the side menu; because this function is often used, a magnifying glass has been added to the right side of the navigation bar.
• When an event that needs approval is approved by a user with manager rights, the event owner will now receive a notification by email.
• On the Users page, when adding a new user, the default access rights will be the rights set for self-registrations.
• All 'displays' (upcoming events listings) have been upgraded and are more flexible with more settings. Displays will not be included in the zip-file of new calendar versions anymore. Instead they can be viewed and downloaded directly on the LuxCal Displays page of the LuxSoft website.

Technical issues
• When used on a small-screen mobile device, the header of the page (date range) will be shown without week number, so that the header will fit on one line.
• Error messages related to validating URL GET and POST parameters are now presented on a special 'calendar-style' page.
• The logic to deal with an expired PHP session has been completely revised. If the calendar is left open in the browser without using it, the user will get a warning alert after 25 minutes of calendar inactivity. In case of more than 30 minutes of calendar inactivity, the PHP session will expire and when starting to use the calendar again the user will get a "PHP session expired" alert page and will be asked to restart the calendar.
• The protection against spoofed form submission, cross-site scripting and other vulnerabilities has been improved.
• The separate PHP session to store the current calendar ID has been abandoned. The implementation was unnecessary complex. The scrips detach.php and checkevt.php do not need a PHP session at all anymore. Code simplification.
• The way to find if the user is using a small display or window has been simplified and is now 100% accurate. This opens the way to make the calendar more responsive.
• To guarantee identical behavior of the delete functions which ask user confirmation, the three separate functions have been combined in one delConfirm function.
• The 'reload' function has been combined with the 'done' function, which made the reload function redundant. Code simplification.
• On the Event page to select 'edit the series or this occurrence', the start of the form was at the wrong point, which conflicted with the display of the Google map if the address was put in between exclamation marks.
• URL and image regexes and the processing to add URL-links and images to the event description fields improved. No extra spaces are added anymore in the description fields.
• Changed the JavaScript code to using 'strict' mode, which forces the use of variable declarations and therefore results in better code quality.
• The JavaScript code for the drag functions moved from the dw-function.php file to the toolbox.js file. The code has been improved and is now running in strict mode too.
• The validation regex for Send notification of calendar changes on the settings page, under General, did not allow for recipients lists between square brackets. Solved.
• On the Event page to select 'edit the series or this occurrence', the background color of the event title continued until the end of the line, whilst it should end at the end of the title text.
• More logic has been added to the check boxes in the Edit User Group form. When a user can add events in a certain category, he can automatically view this category.

Bug fixes
• Removed the default function parameter in the 'pop' function. Default function parameters are not supported by Internet Explorer (sigh) and older versions of Safari and cause errors.
• In the date picker, the text color style in the header with week days (Mo, Tu, etc.) was not set properly, resulting in illegible week days when on the User Interface Styling page dark backgrounds have been selected for bars, headers and lines.
• In year view events represented by a symbol (specified in the event category) were hiding (overlapping) events represented by a mini square.
• When a user was part of a user group for which posting repeating event was disabled, the Event window layout was corrupted.
• When an event needs approval, the user could already send an email/sms "now", before the event was approved. This should not be possible and has been solved by not displaying the "notify now" check box as long as the event has not been approved.
• If on the Settings page, under Views, "Weeks to show in Month view" is set to 1 (display one full month) and the "First day of the week" is set to 1 (Monday), then when the first day of the month is Sunday, the first week, with the first day of the month on Sunday, was not shown.
• When specifying the repeat parameters in the Event window, an invalid end date format could result in a PHP error message.
• An invalid source date could corrupt the display of the date picker.
• Due to an error in the upgrade function when upgrading from V4.5 to a greater version the category symbol (if specified) and the sub-category ID (if a sub-category was specified) were not copied from the v4.5.2 database to the upgraded database.

Roel

394

(3 replies, posted in Suggestions)

Hi Mike,

I've no experience with Lightning. I will have a look at the web to see if this is feasible.

Roel

395

(6 replies, posted in Problems)

Brian,

I'm not quite sure what you mean. You implemented the change I posted and you downloaded the new version. To which one of the two are you referring? (If you downloaded the new version, there is no need for alterations).
If you download the latest display0 zip-file, then on line 20 you will find a setting "$fullCal" to disable / enable the link to the full calendar. If you make this setting 0 (disabled), the link to the full calendar will disappear and the cursor will revert to the default arrow.

If this does not solve the problem, please let me know.

Roel

396

(8 replies, posted in Problems)

Hi Greg,

"Bugette" solved in next calendar version.

I can (most probably) help you to resize the iframe to fit the space allotted to the diary, in an easy way.
If you are interested, I suggest to do this via email, because it is off-topic.

Roel

397

(6 replies, posted in Problems)

Brian,
There is no setting to turn the link to the full calendar off, but a quick fix would be to change the PHP code as follows:
Change line 234 of the display0.php file
from . . .

$dateHdr = "<button type='submit' title=\"{$xx['vws_view_full']}\">".makeD($dateD1,3)."</button>\n";

to . . .

$dateHdr = "<button type='button'>".makeD($dateD1,3)."</button>\n";

. . . delete line 229 to get rid of the text "for full calendar click month".
That's all.
In addition you could of course also delete all lines related to the form: Lines 230 - 233 and 238.

Update: A minute ago I've made this a setting in the mini calendar. If you upload the mini calendar (display0) from the LuxCal Displays page, you will have the updated version.

Roel

398

(8 replies, posted in Problems)

Why would you remove the iframe? When you put your page header in the calendar code, each time there a calendar update, you will have to re-integrate your page header.
A lot of web developers, including myself, don't like frames. but iframes are fine!

399

(6 replies, posted in Problems)

Hi Brian,

What I can say is that there is NO error in this JavaScript function. The pop function is used to show the event details when hovering the event title for instance in Month view and is working as it should
Maybe DreamWeaver doesn't like the default popMaxChar value (= 80) in the function definition. The possibility to add default values for function parameters was added to JavaScript in 2015 (ECMAScript 2015). Maybe your DW version is older and doesn't know this.

Roel

400

(8 replies, posted in Problems)

Yes, you found a bug Greg! Thanks or reporting this.
Same problem with September 2019. It is exactly the combination of the settings mentioned in your post both set to 1.

Easy fix: Edit the file views/month.php and change line 75
from . . .

  $sOffset = date("w",$tfDay) - $set['weekStart']; //offset first day

to . . .

  $sOffset = date("N",$tfDay) - $set['weekStart']; //offset first day (ISO)

Just the "w" should be replaced by an "N" in the date function (and ISO added to the comments at the end).
This fix will be included in the next calendar version, which I will release early 2019.

Roel

PS. I very much like the colors you have chosen for the different categories in the Church Diary; not too hard and not too soft, exactly right. I also read with interest your Updater's Guide, very clear explanation, I could not find any error wink