301

(2 replies, posted in Need Help)

Hi there,

The type field in the event table is not used by the calendar.
So you can use it, but some day . . . . when we are 12 releases further . . . .
wink
Roel

302

(11 replies, posted in Need Help)

Hi Bill,

In your post of 2019-09-30, under Tests Failed, the second item says: PHP sessions not working.
But ok, if the emails are going out and if your calendar is working, then apparently the PHP sessions ARE working.

The SQL error in your first post is a

General error: 2006 MySQL server has gone away

This is not a syntax error, it's caused because for whatever reason the MySQL server doesn't respond anymore. It's very hard to say why this happens. From the SQL query string I can see that this happened when retrieving data from the calendar database. Because this function has not changed since years and never caused problems, I'm almost sure the problem has nothing to do with the calendar. If this problem happens often, if possible, I would suggest to open a ticket with your provider and ask if they can have a look in the server logs to see if they can find out why the "General error: 2006 MySQL server has gone away" errors occurred.

Roel

In the previous mini-calendar (display0) in the hover box with long texts the scrolling did not work correctly.  This has been fixed in the new version 2020-01-04.

304

(11 replies, posted in Need Help)

Oops, this is a long time ago.
If the PDO-SQLite extension cannot be enabled, then the only possibility left is the MySQL version of the calendar.
What worries me is the fact that also the PHP sessions are not working. The PHP sessions are used by the calendar and must be working.

If you are still stuck with this problem and interested in a solution, please let me know.

Roel

Hi there,

Have you tried to refresh the page (Ctrl-F5) to clear and reload the browser cache?

Roel

Highlights

This new LuxCal version 4.7.7 includes interesting new features, improved technical issues and bug-fixes.
Most important new features / improvements:
• In Month, Week and Day view optionally a side panel can be shown right next to the main calendar. This is an important new feature.
• A new "Gantt Chart" view has been added to the calendar, showing a graphical presentation of all events during a certain period in sequential order.

Hereafter you will find a full summary of all changes since LuxCal version 4.7.6.

This new release has been tested again with the help of John from Denmark. Thank you John, you're a hero!

New features/Improvements
• In Month, Week and Day view optionally a side panel can be shown right next to the main calendar. This side panel can contain one or several of the following elements:
   1) a mini calendar, which can be used to look back or ahead in the calendar
    without changing the date of the main calendar.
   2) a decoration image per month.
   3) an optional information area with a message per month.
• A new "Gantt Chart" view has been added to the calendar, showing a graphical presentation of all events during a certain period in sequential order. Gantt Charts are particularly useful for project activity planning.
• On the Settings page, in the section Periodic Functions, when selecting Daily calendar changes summary, an empty Recipients list was not flagged as an error. The default Daily calendar changes summary setting for new installations is now set to 0 (disabled).
• To distinguish the Options button from possible other buttons right of the options button, the caption is printed in bold and the margin on the right side has been slightly enlarged
• When on the admin's Settings page, in the Views section, event sorting was set to category sequence nr, in Week and Day view for some events the width of the event rectangle was not maximized. Solved and code optimized.
• In both Matrix views the dates that were shown in each day cell have been removed and replaced by a date in the column header and footer. This creates more space for events and gives the Matrix views a much less crowded impression.
• In Matrix view "users" a user with post rights could click the day cells in any row - so also in the rows of other users - to open the Add Event window. When saving the event it would appear in the row of the user who added the event, which may be confusing. To avoid this behavior, in the new version a user with post rights can only click a day cell in his own row to open the Add Event window.
• For events that need approval but have not yet been approved the hover box with event details now shows a "still to be approved" bar (red bar) in the left margin. This means that now also in calendar views with only a mini-square or symbol per event (Year and Matrix views) the user can see that an event still needs approval.
• A new setting has been added to the General section of the settings page to specify the upper limit in pixels of a small display. If the calendar is visited from a small display, it will run in responsive mode, which means that certain not-essential elements are left out to better fit the calendar on a narrow width display.

Technical issues
• The variable $_SERVER['HTTP_USER_AGENT'] is not always provided by every web server, so before using it, its existence must be checked.
• On the Edit User Group page, a note has been added that the event categories that can be viewed and added/edited are subject to the selected user rights.
• In the navigation bar the trailing semicolon of the magnifier glass symbol was missing, which resulted in an HTML error.
• In header.php script for the side menu there were two different class tags in the same div, which is incorrect HTML. Both classes have now been merged.
• When the event duration is all day, the function that makes the hover box time now returns the text "All day" (from language file), rather than an empty string.
• In the function that makes the hover box time the "break"s were missing in the switch statement. Performance improvement.
• A function has been added to the toolbox file which produces the HTML code content of the event title hover-box. The hover-box content is now identical in all calendar views.
• In week and day view the code to display the events and the event hover boxes with event details has been scrutinized and optimized.
• For links to the calendar server, like the RSS feeds URL and the URL of the calendar itself, the HTTP protocol is now set to "https" if the calendar was queried through the HTTPS protocol.
• For all messages sent, the meta-tag <meta charset="UTF-8"> has been added to the message's <head> section.
• Users with 'assigned' admin rights (uid != 2) could open the database page and backup the database, but could not download the created backup file.
• When present, the upgrade script will show release notes at the end of a successful upgrade. The release notes should be present in the calendar root in file relnotes.html. This feature can be used to notify the admin of important issues when upgrading the calendar.
• If on the search page the end date < the start date an error message will be displayed

Bug fixes
• When a user with no access rights used the cP URL parameter, the selected page with events was shown. This should not be possible.
• In case of an invalid URL parameter (validGetVars function), the alert page is started while the calendar ID is not known yet, resulting in a PHP error message.
• On the Upcoming Events page, for events with an end time, in the hover box title the end time was displayed twice.
• The function to detect event overlaps didn't work correctly when the time of the new event ended on '9'. Problem solved and script simplified.
• When an event had been added without closing the Add Event window and thereafter the same event was added as a new event (Save as New), resulting in a page number change from 30 to 31, this caused a Session Expired message because there was no token for page 31. Solved by reverting to one single Event page number and using the mode to set the Event window title to either "Event - Add" or "Event - Edit".
• During the calendar upgrade procedure, when the calendar db is V4.7.7 the upgrade function returned V4.7.6, which is incorrect.
• In V4.7.3, on the Settings page, the change summary recipients field was renamed from "chgEmailList" to "chgRecipList". During the upgrade process the old field was copied to the new database, but not renamed, which resulted in the field content being lost.
• In the search SQL statement the category name and group name were not 'escaped' resulting in an SQL error when one of the two contained a single quote (like: don't forget).

307

(3 replies, posted in Problems)

Hi Greg,

The fact that you could still lo in with your old password is correct. The old password remains valid until the new password has been used at least once.
The fact that your new password did not work is not correct. I just ran a couple of tests on our test calendars with the same calendar version as your calendar version (V4.7.6M) and I was not able to reproduce this problem. All seems to work correct.

If this is a persistent problem and you want me to further analyse it, I would need a administrator account in your calendar.

Roel

308

(3 replies, posted in Need Help)

If you can make the Americans change their date format from 12-31-2019 to 31-12-2019, or even better 2019-12-31, I will add this "time format option" to the Options Panel.
Have you ever looked at the order of the parameters of PHP's mktime function. The American (must be) who specified this should be jailed for life, or even better, should be forced to work with the Trump administration for a year wink

My mail address is at the bottom of the Contact Us page.

Roel

309

(3 replies, posted in Need Help)

Hi there,
I'm sorry, but the users can't change the time format. As you know, the administrator can specify the time format and that format is applicable for all users.
You are the first asking for this; if there was a great demand for this, we could add this option to the Options Panel, but we are afraid that the next request will be to add the option to change the date formats and then the first day of the week (Sunday or Monday), etc.

I thought Americans always wanted 12hr am/pm times and Europeans 24hr times. But apparently this is not true.

Roel

310

(2 replies, posted in Need Help)

Hi there,

The question is fine wink, but the solution is difficult.
Adding more fields to the events (like the two extra fields) is rather complicated. Adding more fields to the Events table in the database is easy, but the integration of these additional fields in the calendar scripts is a lot of work and requires a good PHP knowledge.

You could perform a global text search for the text strings 'xf1' and 'extra' on all LuxCal files to get an idea of where the changes would be required.

Roel

Hi Lucas,

Just ran a couple of tests with our test calendars and email lists seem to work fine.

Could you confirm the following:
1. Your email list file is called for example "elist.txt"
2. and is present in the calendar's "recipients" folder
3. and the contents looks as follows:

  john@gmail.com
  mary@yahoo.com
  bill.wood@live.eu

4. and the recipients list looks as follows:

  Joanne.crane@gmail.com;[elist];charly.brown@snoopy.com

so the elist file name within square brackets and separated by semicolons from the other email addresses.

Roel

Hi Lucas,

When the list content is correct (each email address on a separate line and valid email addresses) the list.txt should work as well.
However, it depends on the number of email addresses in the list. Most (I think all) ISPs have put some restrictions on sending emails via PHP. because they don't want PHP (their server) to be used for sending spam mails.
So could it be that you are sending too any emails at a time and that your provider is blocking this?

Roel

Hi Lucas,

It's very hard to say what could be wrong when sending emails via SMTP, in particular from a distance. When you are not sending many emails, it could be easier to use PHP mails, but I'm sure you know this already.
In the LuxCal distribution there is a file toolbox.zip which contains a folder smtpmail with a utility smtptest.php; this utility can be uploaded to the calendar folder and started via your browser to test and experiment with SMTP mail. Have you already tried this? (This utility uses the mail settings from the calendar's Settings page.

Regards,
Roel

Complete overhaul and update of Display3. The flexibility to tailor the user interface has increased and there is an interesting new feature: Visitors can log in!
When disabled, visitors will not be able to log in and events will be shown according to the settings in the user group of the Public Access user. When enabled, a login button will be shown at the right upper corner. A not (yet) logged in user will see events according to the settings in the user group of the Public Access user. A logged in user will see events according to the settings in his/her user group.
If enabled and the Public Access user has no rights, the display will open directly with the login form. When a user logs in, he will automatically be remembered during the number of days specified on the Settings page of the calendar, under 'User Accounts'.

Complete overhaul and update of Display2. The flexibility to tailor the user interface has increased and there is an interesting new feature: Visitors can log in!
When disabled, visitors will not be able to log in and events will be shown according to the settings in the user group of the Public Access user. When enabled, a login button will be shown at the right upper corner. A not (yet) logged in user will see events according to the settings in the user group of the Public Access user. A logged in user will see events according to the settings in his/her user group.
If enabled and the Public Access user has no rights, the display will open directly with the login form. When a user logs in, he will automatically be remembered during the number of days specified on the Settings page of the calendar, under 'User Accounts'.

Complete overhaul and update of Display1. The flexibility to tailor the user interface has increased and there is an interesting new feature: Visitors can log in!
When disabled, visitors will not be able to log in and events will be shown according to the settings in the user group of the Public Access user. When enabled, a login button will be shown at the right upper corner. A not (yet) logged in user will see events according to the settings in the user group of the Public Access user. A logged in user will see events according to the settings in his/her user group.
If enabled and the Public Access user has no rights, the display will open directly with the login form. When a user logs in, he will automatically be remembered during the number of days specified on the Settings page of the calendar, under 'User Accounts'.

317

(5 replies, posted in Need Help)

Hi Dan,

Good to now about your customer. I think it's not very difficult to send emails in batches of a certain number. Bill has contacted me by email and is offering to help me testing this. Of course once it's working to our satisfaction I will make this available in the next LuxCal calendar release.

Cheers,
Roel

318

(5 replies, posted in Need Help)

Hi Bill,

Currently there is no way to send emails in blocks.
But I'm willing to experiment with this and change the code so that emails are send in blocks of maximum X recipients. (X to be specified).
In this case you would be kind of a guinea pig.
If you are interested, I suggest you send me your email address (via the Contact Us page) and I will modify the code and send you an updated messaging.php file.

Roel

319

(5 replies, posted in Need Help)

Hi there,

In the LuxCal calendar thee is no limit to the number of recipients in the list, however, emails to the recipients of your list are send in one go and many (probably all) internet providers have set a limit, to avoid their customers to send spam. So I think your limit of 50 is set by your internet provider.
Using two files each with for instance 49 recipients will not help, because LuxCal will process both list before sending the emails.
If you really need to send emails to more than 50 recipients, you should use SMTP mail, or ask your provider to increase the limit of 50 emails.

Roel

320

(2 replies, posted in Suggestions)

Hi there,

Thanks for reporting this. You are right, the PHP manual clearly states that there is no guarantee that the variable $_SERVER['HTTP_USER_AGENT'] is provided by every web server, so before using it, the existence must be checked. This will be fixed in the next LuxCal version.

We are happy to have knowledgeable calendar users in India!

Roel

Hi there,

I had a look in the ics file export script and could not find any reason why the DTEND date should become 99981201.
Could you send me (via the Contact Us page) a screenshot of the event in the Edit Event window of the calendar?

Thereafter I will try to reproduce and analyze the problem.

Roel

322

(2 replies, posted in Need Help)

Everybody happy smile

Roel

Users are encouraged to upgrade to this new version 4.7.6. It's better than ever!

Highlights

This new LuxCal version 4.7.6 includes important new features, improved technical issues and bug-fixes.
Most important new features / improvements:
• Self-registration more secure by using a "question and answer" dialogue during self-registration.
• Two new pages added to export or import user profiles (for users with Manager rights or higher).
• In the event window the extra fields 1 and 2 can now be resized vertically and may contain crlf characters.
Hereafter you will find a full summary of all changes since LuxCal version 4.7.5.

This new release has been tested again with the help of John from Denmark. Thank you John, great job again!

New features/Improvements
• Self-registration more secure: If self-registration has been enabled on the Settings page, any user could register. To make self registrations more secure, on the Settings page an option has been added to specify a question and corresponding answer. During self-registration, for the registration to be accepted, the user will have to answer the question correctly. When a users answers incorrectly 4 times in a row, the user will be told to try again in 30 minutes and the self-registration button will be hidden until the PHP session expires.
• Two new pages have been added to the side menu for users with at least "Manager" rights. One to export and another to import user account data. These pages can for instance be used to quickly copy user accounts from one calendar to another calendar, or to prepare user accounts of-line and import them into the calendar.
• A setting has been added to the administrator's Settings page to specify the sorting criteria of events in the various views. The possible sorting criteria can be: 1) the event times, 2) the event category sequence number.
• In the event window the extra fields 1 and 2 can now be resized vertically and may contain crlf characters.
• On the Settings page for each of the extra fields it can now be specified as of which user rights the field is visible. If a user has less rights than the specified rights, the user will not see the field. Extra fields with user rights > "View right" will not be part of emails, RSS feeds, periodically exported iCal files or the side bar (when installed).
• On the Settings page the default view can now be set for users with a large display and users with a small display respectively
• On the Settings page a default venue can be specified, which will be copied to the Venue field of the event form when adding a new event.
• If the event's description field contains a lot of text, in some views (month view, display0, stand-alone side bar) part of the hover-box with event details may fall outside the viewport. This has now been solved by giving the hover-box a maximum height and a scrollbar, if the content is higher than the box.
• On the Settings page, under File Uploads, the "Maximum file upload size" has changed from 6Mb to 200Mb to allow for uploading of larger attachment files. Note: PHP also restricts the maximum file upload size; it may therefore be necessary to also increase the maximum file upload size in php.ini file.
• The subdivision of the items in the side menu has been improved and made more logical.

Technical issues
• When fields in the database tables have no default value, e.g. an empty string, and MySQL runs in 'strict' mode, then the following SQL error can occur: General error: 1364 Field 'editor' doesn't have a default value. Solved by giving all empty field the value NULL.
• When changing the event category sequence numbers, still the "no cat" category remained the default in the Add Event window. Changed so that the category with the lowest sequence number is the default.
• In month view the lower border of the hover box could just pass the bottom of the screen, causing a vertical scrollbar to appear. Solved.
• The regex to validate user names in the recipient list didn't accept accents and umlauts. The regex has been updated to cope with Unicode special characters (\U00C0 - \U01FF).
• Some forms contained "action='index.php'", which was redundant.
• In the installation script the line "session_set_cookie_params" removed, because this made the PHP session test fail when installing the calendar using Edge and Safari.
• While importing events from a .ics file, events in the uploaded .ics file without title (SUMMARY) are now accepted and flagged as error in the displayed event list.
• In IE and Edge the JavaScript forEach method cannot be used on nodelists and therefore the selection of check boxes, for instance in the Options Panel, didn't work correctly. Solved by converting nodelists to arrays. (Sigh . . . Please, can we all switch to Firefox or Chrome!).
• On the Settings page, in section Periodic Functions, the layout of the form to specify the parameters for the calendar changes summary has been aligned with the rest of the page. Error checking has been added for the calendar changes recipients list.
• Redundancy removed in CSS-styles.
• The side-bar styles have been simplified.

Bug fixes
• Clicking the Todo checkbox in Month view also resulted in opening the Add Event window. Forgot to add "event.stopPropagation();". Solved.
• When the User profile page (Change my data) was displayed, the User Menu in the top bar could not be opened anymore. Solved.
• When editing a user profile, it was possible to change the user name or email address to a user name or email address already existing in the database.
• A bug in the time formatting prevented the display of leading zeros for Am/pm times. Solved.
• When users self-registered, in the SQL query there was a mismatch between the number of parameters to insert and the number of ?-marks. (because in V 4.7.5 the user number was removed from the query).
• When on the settings page, in the section events, posting of private events was set to "default", in the Add Event window the "Private event" check box could not be unchecked anymore.

324

(4 replies, posted in Problems)

Hi there,

I just checked and did a global search and saw that "short_open_tag" is used by one of the LuxCal calendar scripts. It is anyhow a good idea I think set this to "on".
The enable_dl setting is not used by the LuxCal calendar. And, if I'm correct, this setting was removed as of PHP version 7.0. So I don't think this setting is important.

Roel

325

(4 replies, posted in Problems)

Hi there,

Your warning message shows that the problem occurs when in the calendar's index.php file on line 106 the "session_start" function is executed.
This means that in the new PHP version the PHP sessions are not working. From the details it looks like there is a file missing in the PHP installation.

The LuxCal calendar works perfectly with the latest PHP versions (V7.2 & V7.3).

There is nothing I can do about this; I think you should contact your web host and report the problem that the PHP sessions are not working and ask them to solve this.

Roel