You are not logged in. Please login or register.
LuxCal Web Calendar → Posts by Roel
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 
Regards,
Roel
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
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
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
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
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
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
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
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 
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
Hi there,
Yes, this can be easily done as follows:
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.
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.
Hi Stefan,
I was very sure, but not anymore 
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
Hi Stefan,
It's not a bug. The code . . .
$stH = stPrep("SELECT last_insert_rowid()");
$row = $stH->fetch(PDO::FETCH_NUM);
$stH = null;
$eid = $row[0]; //set id to new eventhas the same effect as . . .
$stH = null;
$eid = dbLastRowId(); //set id to new eventHowever, since the function dbLastRowId() is already used some 18 lines up, I agree - for consistency reasons - it would be better to use this function. I will change this for LuxCal v4.6.1.
The purpose of the code is the following:
When a user chooses to edit one specific occurrence of a repeating (or multi-day) event, then this occurrence will be removed from the repeating (or multi-day) event and a new event will be created to replace the removed occurrence. The code to get the ID of the last added row makes the newly added event the currently active event.
Thanks for reporting this,
Roel
Thanks Mark,
I've solved the problem for the calendar as well as for the Contact Us page. Both were using the same erroneous validation pattern (regex).
If you upload the two files I've sent you by email, the problem will be solved.
Roel
Hi Mark,
I would like to have your email address that is not accepted, could you send it to me via the Contact Us page please.
I'm about to release calendar version 4.6.1 and would like to fix this problem before.
Thanks,
Roel
Hi Dilbert,
I suggest to export the calendar database to a .sql file, for instance using phpMyAdmin, as soon as possible and send it to me via the email address at the bottom of the Contact Us page. I think you are in the USA, so if you send me the file by the end of your day, I will work on it while you are asleep and send the upgraded database back to you next day.
Roel
Hi Gilbert,
The column name sendSms is a valid name and therefore it is hard to say what went wrong.
Could you export the database from your 4.5.2 version to a .sql file and email this file to me. I will then analyze the problem, upgrade the file to 4.6 and send it back to you. Thereafter you can import the file in your v4.6 calendar and all should be fine.
Roel
Hey Dan,
This bug has not been fixed yet in the download, because I don't want to bring out a new calendar release just for one bug. But it will surely be fixed in the download of the next calendar release.
Cheers,
Roel
There is a bug in the LuxCal calendar version 4.6.0, which makes the Option button disappear for users who have no administrator rights.
To solve this problem, edit the file common/header.php and change line 410 from . . .
$options = ($dbSel and $usr['privs'] == 9) or $set['viewMenu'] or $set['groupMenu'] or $set['userMenu'] or $set['catMenu'] or $set['langMenu']; //menusto . . .
$options = (($dbSel and $usr['privs'] == 9) or $set['viewMenu'] or $set['groupMenu'] or $set['userMenu'] or $set['catMenu'] or $set['langMenu']) ? true : false; //menusThereafter the Options button will be visible to all users.
Roel
Hi Phil,
That's hard to say. I still believe the most likely problem is that the styles are not refreshed.
Do you maybe display the calendar in a frame or an iframe? If so, then just ctrl F5 is not enough, but the (i)frame contents should be refreshed (Firefox: right click in frame - This frame > Reload frame).
Roel
LuxCal Web Calendar → Posts by Roel