401 Reply by Roel

(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

Go to forum: Problems

402 Reply by Roel

(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

Go to forum: Problems

403 Reply by Roel

(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

Go to forum: Problems

404 Reply by Roel

(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

Go to forum: Problems

405 Reply by Roel

(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

Go to forum: Need Help

406 Reply by Roel

(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

Go to forum: Need Help

407 Reply by Roel

(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

Go to forum: Problems

408 Reply by Roel

(11 replies, posted in Need Help)

See my email reply.

Go to forum: Need Help

409 Reply by Roel

(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

Go to forum: Need Help

410 Topic by Roel

(0 replies, posted in What's New)

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

Go to forum: What's New

411 Reply by Roel

(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

Go to forum: Suggestions

412 Reply by Roel

(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

Go to forum: Problems

413 Reply by Roel

(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

Go to forum: Problems

414 Reply by Roel

(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

Go to forum: Problems

415 Reply by Roel

(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!

Go to forum: Problems

416 Reply by Roel

(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

Go to forum: Problems

417 Reply by Roel

(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

Go to forum: Problems

418 Reply by Roel

(5 replies, posted in Need Help)

You found it, I will kill it!

Go to forum: Need Help

419 Reply by Roel

(5 replies, posted in Need Help)

Hi Greg,

Ah, yes, I didn't read your question properly. Sorry for that.
I had to look into the code to find the correct answer to your question.
For events that have to be approved, but have not been approved yet, reminder emails are not sent. This however, needs some further clarification:
If the owner, when adding the event, specifies to send an email reminder let's say 7 days before the due date of the event, and the event is only approved 6 days before the due date, The reminder will not be sent at all anymore, because the 7 days have past and the calendar does not keep track of what reminders have or haven't been sent. So it is the owner's responsibility to defer sending reminders until after the approval date.
What I discovered, when browsing the code, is that if the owner in the Event window checks the "send email Now" box, the email is sent even though the event has not been approved yet. This is wrong! Without approval, the owner should not be able to send any announcement or reminder. So I will change this in the next calendar version (which will be released early 2019).

Roel

Go to forum: Need Help

420 Reply by Roel

(2 replies, posted in Suggestions)

Hi Greg,

This is the struggle of all programmers: how to make sure the application displays correctly and similarly in all the different browsers and browser versions and on all the different devices, with different screen sizes.
For LuxCal we have chosen, and so far managed, to use Unicode/HTML character entities, rather than separate image files, to represent glyph images, The reasons for doing this are the following:
• standardization; The Unicode/HTML character entities are meant - in the long run - to standardize the glyphs used in all web applications and therefore improve the user experience.
• efficiency: no need to load load images from the server for each glyph.
• better software: code not cluttered with unnecessary <img>-tags

The disadvantages are that not all browsers (in particular older versions) support all new Unicode/HTML character entities yet. But the good news is that since a couple of years the standardization among browsers has improved at a rapid pace.

So the dilemma is: do we want to be hold back by older browsers, not adhering to web standards (like IE held us back during the last 2 centuries), or will we go with the flow, which will eventually lead to software applications with a much better graphical user interface, taking the current disadvantages, which will eventually automatically disappear, for granted?

Let us wait and see what other calendar users have to say about this . . .

Roel

Go to forum: Suggestions

421 Reply by Roel

(5 replies, posted in Need Help)

Hi Greg,

If for a certain event category the "Events need approval" checkbox has been checked, it means that the individual events created in this category, will only be visible to the owner of the event and to users with at least Manager rights, until the event has been approved. Once approved the event will be visible for all users. Only users with at least Manager rights can approve "to-be-approved" events.

Hope this helps,
Roel

Go to forum: Need Help

422 Reply by Roel

(7 replies, posted in Need Help)

Hi Jay,

6. You're right. I've added a configurable 'br-style'.
7. The h5-tags don't make sense; I will replace them by p-tags.

All up-to-date displays are shown on the LuxCal Displays page of this website. I've added a download button just under each display, you will be able to download the latest display3.php files from the LuxCal displays page.

Regards,
Roel

Go to forum: Need Help

423 Reply by Roel

(2 replies, posted in Suggestions)

Hi Jay,
I assume you are referring to display3.
Actually a custom 'no events' message should be added to all displays.
I will do this.

Roel

Go to forum: Suggestions

424 Reply by Roel

(1 replies, posted in Suggestions)

Yes, you are right. I will add that to the keywords, the description and to the descriptions in the PAD file.

Thanks,
Roel

Go to forum: Suggestions

425 Reply by Roel

(7 replies, posted in Suggestions)

Hi Dan,
Thanks for this suggestion.
As a matter of fact I have already produced something similar for the next release of V4.7.4 wink (This new version will be released early 2019).
In this new version in the Venue field one can put - as part of the field - the actual address between !-marks. If done so, in all calendar views the address will be shown as a button. When hovering this button, the textual address will be shown and when clicking the button, a new page will open where Google maps will show the address on the map.

What I like very much about your suggestion is to let the admin choose whether Google maps, OpenStreeMap, or an other map viewer will open. So I will add a field to the admin's Settings page, where the admin can specify the "map site" that should open when the user clicks the Address button.

Best regards,
Roel

Go to forum: Suggestions