New features

[wintstar]

Thank you very much, donatj, for the simple PHP calendar rendering class. I’d like to contribute something to it.
Whilst looking for an alternative to Nextcloud, I came across this repository

New features

• Easily configure calendar settings.
• Custom language using language files. Based on the phpBB language function. Very simple.
• Display short or long Weeknames.
• Week numbers can be shown or hidden via the settings.
• View previous calendar days / events and upcoming calendar days / events

Tested with PHP Version 8.5.7.

You can view a Live Demo. This demo incorporates my build_holidays library, which automatically generates German public holidays from 1900 to 2038. It is worth considering whether this can be integrated directly or as an add-on.
I'm currently working on integrating with a calendar server (Baikal). This should resolve issue #3.
If you like the new features, I can add them here wintstar#5.

Parameters / options

Parameter	Description	Default	Valid values
calendarTimezone string	Sets the default timezone	UTC	The timezone identifier, like UTC, America/Vancouver, Asia/Hong_Kong, or Europe/Berlin etc. Look List of Supported Timezones.
calendarWeekStart int or string	Sets the first day of the week	$offset	Day the week starts on. ex: "Monday" or 0-6 where 0 is Sunday
calendarDate \DateTimeInterface false or string or null	Sets the date for the calendar	null	$date - DateTimeInterface for the calendar date. If null set to current timestamp.
calendarToday \DateTimeInterface or string or null	Sets "today"'s date. Defaults to today.	null	$today - null will default to today, false will disable the rendering of Today.
calenderLang string	Sets the User Language for text strings	en	de To add another language, create a translation and name the file according to this template calendar_fr.php For example, for French. Insert the language file into the vendor/donatj/simplecalendar/src/ directory/language.
shortWeekname bool	Sets the display of weekday names in short or full form	true	true for short weekday names false for long weekday names
displayWeeknumber bool	Sets the display of weeknumber	false	true for display false for hide
calendar leading_day trailing_day today event events array<string,string>	Sets the class names used in the calendar	SimpleCalendar SCprefix SCsuffix today event events Map of element to class names used by the calendar	Take a look at the file vendor/donatj/simplecalendar/src/css/SimpleCalendar.css to see how the parameters are used.

Basic usage

Standard Settings:

• Timezone: UTC
• Weekstart: Sunday
• calendarDate: Current date
• User langage: en
• Display Weekname: short form

<?php
require __DIR__ . '/vendor/autoload.php';

echo '<link rel="stylesheet" href="vendor/donatj/simplecalendar/src/css/SimpleCalendar.css" />';

$calendar = new donatj\SimpleCalendar();

echo $calendar->render();

Examples

Standard Settings:

• calendarDate: Current date

Custom Settings:

• Timezone: Europe/Berlin
• Weekstart: Monday
• User langage: de
• Display Weekname: long form

<?php

require __DIR__ . '/vendor/autoload.php';

echo '<link rel="stylesheet" href="vendor/donatj/simplecalendar/src/css/SimpleCalendar.css" />';

$calendar = new donatj\SimpleCalendar([
   'calendarTimezone'   => 'Europe/Berlin',
   'calendarWeekStart'  => 'Monday',
   'locacalenderLangle' => 'de',
   'shortWeekname'      => false,

]);

....

[donatj]

Thanks for your interest in the project. There are several potentially useful ideas here, but this is not a practical form for reviewing or accepting them.

Generally, when proposing changes to someone else’s project, the usual approach is to open a pull request against that project rather than pointing the maintainer to a rewritten version in your own repository.

More importantly, this appears to rewrite much of the library and replace its long-established public interface without any prior discussion. Presenting that as a finished replacement puts a fairly large review and compatibility burden on the maintainer. I suspect many of these features could have been implemented without breaking the existing API.

A better approach would have been to first gauge interest in the individual features, then submit each accepted feature as a small, focused pull request. That would make the changes easier to evaluate, test, and potentially merge.

The rewritten code also does not follow the project’s established coding standards, so it would require substantial reworking before it could be considered for inclusion. Running of the CI tools should catch most such issues automatically.

If you’re interested in submitting the features individually as focused pull requests, while preserving the existing public interface as much as possible, I’d be interested in reviewing them.

[wintstar]

As I’m not very good at implementing things on GitHub, I’ve submitted this as an idea for now. I’ll then submit new features to the current code in stages.