476

(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

480

(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

482

(7 replies, posted in Need Help)

Great Michael! You too.
Roel

483

(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

484

(7 replies, posted in Need Help)

This depends . . .
Do you want to set the automatic logout time to < 24 minutes, in other words: do you want to abort the PHP session?
I assume that if you want to automatically logout users after a limited number of minutes, you also want to remove the "Remember me" check box from the login page.
Let me know if I'm correct and thereafter I will try give you a hint on what should be done.

What calendar version are you using?
Roel

Hi Dan,

Interesting link!
Most of these editors have a lot of functions which require changes to the calendar as well. I will investigate if I can find an editor which is not too sophisticated and not depending on jQuery. Thereafter I will have to see if and how this can be integrated in the calendar. Quite a challenge wink

Regards,
Roel

486

(7 replies, posted in Need Help)

Hi there,

I'm not quite sure what you mean. Would you like to force a log out after a certain number of minutes?

This is how it works at the moment:
- If a user logs in and checks the "Remember me" check box, then a cookie with the user ID is stored. So each time the user starts the calendar he/she will be logged in automatically. If the "Remember me" check box was not checked, the user will have to log in each time he/she starts the calendar.
- When the calendar is started, the PHP session mechanism is used to remember the current user and his/her last selections during the time the user is using the calendar (the calendar session).
- The PHP session length stored in the PHP installation (php.ini file) is for most installations set to 1440 seconds which is 24 minutes. This means that if a user stays inside the calendar without any activity, his/her session will expire after 24 minutes. This means that at the following action a message will be displayed and the user will have to refresh the page.

Maybe with this knowledge you could give me further details of what you would like to do.
Regards,Roel

Hi there,

No there is currently no WYSIWYG editor available. There are more users interested in a WYSIWYG editor. This should be done on the client side via JavaScript. We will see if this can be done without too many troubles.

Roel

488

(3 replies, posted in Need Help)

Hi there,

Yes indeed, recurring events taking place (partially) in the future will not automatically be deleted.
Please note that a recurring event is only one event in the database and as such takes up very little space. If you want, deleting past occurrences is fine, but it will not free up any space in the database.
Roel

Highlights

This new LuxCal version 4.7.0 contains a number of important new features and has quite some technical issues improved and bugs solved.
Most important new features:
• A new thumbnail management page to upload and manage thumbnail images and a more user-friendly way to add thumbnails to events
• A new side menu (hamburger button), replacing the majority of the buttons on the right side of the navigation bar.
Hereafter you will find a full summary of all changes since LuxCal version 4.6.1 . . .

This new release has beens tested with the help of the two extremely competent beta testers John from Denmark and Bill from New Zealand!

New features/Improvements
• A thumbnails management page has been added where users can upload and manage thumbnail images. On the user group page the admin can specify for each user group the thumbnail rights. And on the Settings page the admin can specify the maximum thumbnail image size (W x H).
All thumbnails must be stored in the thumbnails folder. Consequently the thumbnail folder is not shown anymore in the description fields.
• A new section File Uploads has been added to the admin's Settings page, where the accepted file extension and the maximum file size for uploaded attachment files and for uploaded thumbnails can now be specified by the administrator.
• Through the introduction of a side menu, the number of buttons on the right side of the navigation bar has been reduced significantly. The majority of the buttons has been replaced by one 'hamburger' button, which when selected will open the side menu. The menu items shown in the side menu depend on the current page and the user rights. This gain of space is especially important when the calendar is shown on a display or in an area with a limited width.
• The options panel now drops down gently, rather than being shown instantly.
• To have a calendar wide uniform approach to deleting items, on the Categories page, the Users page and the Groups page, the button "Show delete buttons" has been removed. Instead, to avoid users to accidentally delete an item, a confirmation dialog will be shown before deleting the item.
• In the Event window, to avoid users to accidentally delete an event, a confirmation dialog will be shown before deleting the event.
• On the admin's Categories page a minimum gap between two events which may not overlap can be specified.
• On the admin's Category page a check box has been added to select a fixed event duration, rather than a default duration. If checked, when adding or editing an event in this category, a notice will be shown at the top of the Event window and the fields end date, end time and all day will be hidden. When the event is saved, the calendar will automatically add the fixed time duration to the start date and time. If the end time falls on the next day, a multi-day event will be created.
• On the admin's Category page the event duration can now be specified in hours and minutes, rather than just minutes. Since the calendar can now cope with event durations which span more than one day, the upper limit has been extended from 720 minutes to 99 hours and 59 minutes.
• If on the Categories page a default event duration has been specified, when adding or editing an event in this category, a notice will be shown at the top of the Event window.
• A simple visits counter has been added, which can be enabled on the Settings page. When enabled, available visitor or web-bot data will be logged in the
    files respective files logs/hitlog.log and logs/botlog.logs and a counter of visitors and web-bots will be kept in the respective files hitcnt.log and botcnt.log. Users with access right >= manager will see a visits counter of the real visitors in the left lower corner of the calendar. When clicking counter the contents of the logs/hitlog.log file will be shown in a new window. Visits of users with admin rights will not be logged.
• URL and email links have been added to the User Interface Styling page and can now be given their own text and background color.
• Thumbnails shown in the Event Report window are now hyperlinks. When clicked, the thumbnail will be shown full-size in a new window.
• When on the admin's Category page a category symbol has been defined, display0 (aka mini Calendar), will now display this symbol, instead of a mini square (similar to the matrix view).
• Since on the admin pages there is enough space on the navigation bar, the page titles on these pages have moved to the navigation bar.
• Embellishment of the pages Upcoming Events, Added / Edited Deleted Events and Text Search. The page with search results is split in one-day events, multi-day events and recurring events. The latter has been done to avoid repetitions of multi-day events and recurring events.
• If on the Settings page "Send notification of calendar changes" is activated, messages of changed events now also contain for each event the date and time of adding and editing and the names of the owner and editor.


Technical issues
• In the makeE function, for the "td" type events, if no labels have been specified for the extra fields 1 & 2, the colon (:) was still displayed.
• In the Event window the number of columns of the event table were not always correct and the width of column 4 was not defined. On some displays this made the Event window higher than necessary.
• To save some space in the Event window, the max. file size for uploaded attachments is now displayed right of the browse button.
• In the Event window the mail Help "?" was not removed when selecting the Print button.
• The cursor in the Event and Event report windows was not always an arrow in passive areas.
• In the cron job summary the email and SMS reminder recipients were not shown each on an individual line.
• MySQL calendar only. The way to find the calendars in use, based on finding MySQL database tables names in the format xxxx_settings, has been improved. It is now based on the intersection of found table names xxxx_groups and xxxx_styles.
• Function eol2txt changed. Before the crlf characters are converted to text, clfl characters are removed form the start and the end of the source string.
• SQL queries related to testing dates for value '9999-00-00' (no date) have been simplified.
• When a category symbol was defined on the Categories page, in Matrix view these symbols were each displayed on a separate line, rather than in-line with other mini squares or symbols in the same day cell.
• HTML symbols (e.g. ⚫) which can be defined on the Categories page have a number of blank pixels at the top. Because of these blank pixels, in Matrix view and in the display1 (mini calendar), symbols were not vertically aligned with the the mini-squares. Solved.
• Both image links and attachment links are now relative to the calendar root. I.e. "./thumbnails/" and "./attachments/" respectively. This makes these link independent of the location of the calendar and thus improves the portability of the calendar.

Bug fixes
• Dutch language only. The help text for the email list in the Event window did not pop up because of an un-escaped quote in the text of the Dutch language file.
• If on the admin's Settings page in the general template the 7, signifying "added & edited, date, time, name", was removed, in the event window these fields were still displayed.
• Since the introduction of the three log message levels errors, warnings and notices, the cronjob messages produced by the lcalcron.php script were not logged correctly. Solved
• When checking if dates are due for a notification message, for repeating events the check for excluded dates went wrong and produced a PHP notice.
• When cloning (Save as new) an event in a category for which no overlap is allowed, in the overlap test the original event was not taken into account.
• The function repeatText, which creates the repeat text did not treat empty "until dates" (9999-00-00) correctly.

Roel

The EU's General Data Protection Regulation, aka "GDPR", which was adopted April 2016, will be enforced as of 25 May 2018. The regulation contains provisions and requirements pertaining to the processing of personally identifiable information.
Although the LuxCal calendar is using cookies and does not ask users to accept the use of cookies, we believe the calendar complies with the GDPR. As required by the GDPR we are applying data protection by design and default in the following way:

  • the calendar does not use so-called tracking cookies,

  • the calendar is only collecting the calendar ID (e.g. 'mycal') and numbers (i.e. User ID, and the current page, category, group, language) which are meaningless to other parties; so no sensitive data is stored in the cookies,

  • the data stored in cookies is serialized and as such not understandable by the human eye.

If you prefer, you could of course add a notice on your calendar web page saying that the calendar is using cookies and is compliant with the EU's GDPR.
Roel

491

(2 replies, posted in Need Help)

Hi Meena,

Like Dan said above, I assume you have created a MySQL database. If so, then "problem connecting to database" means one of the following parameters you entered during the calendar installation is wrong: db host, db username, db password or db name.

Again like Dan said above, if you have difficulty to get the MySQL database connection working, I suggest to install the SQLite version of the calendar, which has exactly the same functionality, is very fast and easier to install.

Roel

492

(5 replies, posted in Need Help)

Fred,

In the To section a file with or without file extension can be specified. When the extension is omitted, the default .txt will be assumed.

It is strange that if the cron job summary report says emails have been sent, but the recipients did not receive any. This means that the PHP mail function executed successfully, but the produced emails were not delivered by your server. (I remember from other posts from Dan and Schwartz that some ISPs require the sender email address to be registered with the ISP!?)

As said in an earlier post the cron job starting the lcalcron.php script should run early in the morning and it must run before 12 noon! If it runs after 12 noon, it is considered to be running for the next day. (This is done to best cope with reminders sent to different countries with different time zones.).

Roel

493

(5 replies, posted in Need Help)

Hi Fred,

Is it the MySQL or SQLite calendar you used for this notification test?
Did the cronjob summary say that email notifications were sent to the recipients in your text file?
At what time did your cron job run? It should normally run early in the morning, but it MUST run before midday of the day the notifications should be sent.

Since you gave me FTP access, I took the liberty to look in your log files and I saw that in your MySQL luxcal.log file that the last cronjob was aborted, because the remote IP address of the cron job service had changed and did not match the one specified on the Settings page.

Roel

494

(24 replies, posted in Need Help)

Hi Fred,

I'm sorry for all this hassle and I do understand you get frustrated.
Don't give up; this calendar is used by many people and we must get it to work.

I have a few remarks and suggestions . . .
Remarks:
Going back to your post yesterday at 16:09 . . .
Under point 5. you said you received a blank page when running the lcalcron.php script manually. This is correct, this scrip does not produce any output (unless there are errors) because there is no need to send output to cronjobs. So no output means it ran successfully. Also the cron.png image shows that the script ran successfully.
Under point 4. you said you received the same error message as the day before  (the one with SQL error . . . Query string: SELECT `name`,`value` FROM `alumni_settings`). This would normally not be possible; if there is no table `alumni_settings` in the database, there can be no error related to this table. I don't know, maybe the cronjob started a different calendar!?
Both points above show that starting lcalcron manually works and the cron job coming from cron-job.com works, but most probably starts the wrong lcalcron.php script. So we should look at this last problem.

Suggestions:

1. Taking your SQLite calendar, give it one more try and do the following:
a. Create a test event for tomorrow and check the "Send mail now" check box and specify 1 day(s) before event and fill in your email address (if not done already) and hit the Add and Save button. Now you should get 1 email message.
b. Go to the settings page and in the section Periodic Functions ensure that the Cron job host is set to "remote"
c. Start the lcalcron.php script from your browser. This must be done before midday. Now you should receive 2 mail messages, a reminder and a cron job summary.
If so far all works well, the only thing left to do is set up a cronjob, so . . .
d. The URL http://www.fredsfollies.com/fsptracker/ in your last post does not exist. Correct this and try again.
If this also works, then on the Settings page, in the section Periodic Functions check Cron job host "IP address" and fill in the IP address of cron-job.com.

2. Give me temporarily FTP access to your calendar folder on your server (send me the credentials by email) and create a user account for me with admin rights in your SQLite calendar. I will then analyze the problem and make sure that periodic functions work.

Roel

495

(24 replies, posted in Need Help)

Fred,

1. Yes, this is certainly possible.
3. Most PHP installations have both PDO-MySQL and PDO-SQLite installed. If you want you can check this by going to the calendar's settings page and under General select "Show info"  just after the PHP version (2nd line from the top). When selected, you will get the PHP page with all installation details. Now you can search for the "PDO" section (somewhere half way) and directly thereafter you will find which databases are enabled.

Roel

496

(24 replies, posted in Need Help)

Fred,

Now I understand what's going wrong. What's happening is the following:
The lcalcron.php script will search the database for installed calendars and it does this by looking for table names xxxx_settings (e.g. mycal_settings, pools_settings). Coincidentally and unfortunately Admidio also has a table called settings with a prefix in the format xxxx_. So the lcalcron.php script thinks that there is a calendar with name alumni and tries to read the alumni_settings table which results in a SQL error sad

There are several solutions:
1. You separate the databases of the Admidio application and the LuxCal application.
2. I will change the lcalcron.php script for you, so that it will not look for xxxx_settings tables, but instead for e.g. xxxx_styles tables to find the installed calendars.
3. You will use the SQLite version of the LuxCal calendar.

Solution 1 will not be possible if you have run out of databases.
Solution 2 has the disadvantage that you will have a dedicated lcalcron.php script (future upgrades).
Solution 3 would be my choice. No disadvantages, exactly identical functionality.

Please let me know your preference and I will help you.

Roel

497

(2 replies, posted in Need Help)

Hi there,

Yes, this can be easily done as follows:

  1. On the admin's Categories page of the calendar create a category with the check mark (2/3 from the top) checked. So now you will have an event category for ToDo events. Remember the category ID! If you already have a ToDo category, you can of course skip this step.

  2. Edit the file display2.php and in the General Settings change $header to "To be done" (or whatever you want) and in the Filters set $cats to the ID of the ToDo category (remembered above).

Now only events created in this ToDo category will appear in your display2.

In case of problems, please let me know.
Roel

Hi there,

This problem is solved in LuxCal V4.6.1, which we released 2018-04-24 (yesterday). A couple of other issues were solved as well in this new version. So best would be to upgrade.
Or otherwise edit the file common/toolbox.php and change line 16 to . . .

$rxEML = '~(^|\s)([^@\s]{2,40})@((?:[^@\s\.]{2,30}\.)*[^@\s\.]{2,30}).(\w{2,6})(?:\s*\[([^<>\[]+?)\])?(\.|\s|<|$)~im'; //jd@skyweb.com [title]

Disabling the checking would require a program change, which is not recommended.

Roel

Highlights
This new LuxCal version 4.6.1 has a few important new features and has some technical issues and bugs fixes.
Hereafter you will find a full summary of all changes since LuxCal version 4.6.0 . . .

This new release was tested with the help of the best beta tester of the universe: John from Denmark!

New features/Improvements
• A contact button has been added to the navigation bar, which opens a Contact page which can be used to send a message to the calendar administrator. When  a contact message is sent, the user will receive a confirmation message. This feature can be enabled / disable on the admin's Settings page in the section Navigation Bar.
• It is now possible to add a logo image with a maximum height and width of 70px to the left upper corner of the calendar. The logo image file should be loaded to the server and it can be activated on the admin's Settings page, in the General section, by specifying the path to the logo file. If a URL back link has been specified as well, the logo will become the back link.
• The layout of all email messages send by the calendar have been standardized and embellished. If a logo (see above) has been activated on the Settings page, it will also appear in the left upper corner of all email messages.

Technical issues
• To show the PHP installation details, the PHPinfo page can now be started via the admin's Settings page in the general section, under versions. This makes the phpinfo.php file in the LuxCal toolbox redundant.
• On the admin's Settings page, a validation check has been added for the specified time zone. In the past entering an invalid time zone resulted in many warning messages.
• The isMobile function uses the user-agent string. Because this string is not always supplied a test has been added to check it's presence.
• Function calBaseUrl could not be used from the script lcalcron.php and has been replaced by the function calRootUrl.
• Several discrepancies solved in the administrator interface texts.

Bug fixes
• Due to a bug, for users without administrator rights the Options panel button was not displayed. Solved.
• Problem in the email validation patterns which makes the validation of mail addresses ending on .xxx.yyy, like tom.dowd@mymail.com.uk, and addresses with hyphens, like tom.dowd@my-mail.com, fail. All email validation patterns have been improved to cope with more dots and with hyphens in the domain part of the email address.
• For the MySQL version only: when editing one occurrence of a multi-day or repeating event, the retrieval of the event ID of the new event failed. So when the user saved the new event without closing the Event window and then tried to edit the still displayed event, it failed. Solved by using function dbLastRowId() of the toolboxd.php to get the ID of the last inserted event.

500

(3 replies, posted in Problems)

Hi Stefan,
I was very sure, but not anymore neutral
I guess you are right, for MySQL it should be LAST_INSERT_ID(). Strange that MySQL does not produce an SQL error.
I further investigated this problem and found out that when editing a single occurrence of a repeating or multi-day event and selecting the Save button (so without closing the Event window) and thereafter changing the same event failed because the event ID of the event was not available.
The dbLastRowId() function solves this problem.
Very good that you found this error !
Roel