Download the PHP package italix/calendars without Composer
On this page you can find all versions of the php package italix/calendars. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download italix/calendars
More information about italix/calendars
Files in italix/calendars
Package calendars
Short Description Calendar sets and event feeds: sources declared in PHP, driver-rendered client configuration
License MPL-2.0
Homepage https://github.com/italix-net/calendars
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package calendars
Italix Calendars
A calendar described in PHP — views, toolbar, locale, event sources — with a driver that renders the client configuration and a small contract for range-based feeds.
The feed endpoint is the other half. The widget asks for a window; you answer with the events inside it:
Sources are declared, not discovered
CalendarSource says where events come from. Nothing scans, nothing registers itself at boot: a
calendar that shows the wrong events is a bug you find by reading one file, not by working out which
listener fired.
The </script> breakout
The driver emits its configuration as JSON into a <script> element — the driver's own docblock
shows exactly that placement. json_encode() makes a value safe as a JSON string: quotes and
backslashes are escaped, so nothing can break out of the literal. Nothing had to. A calendar id, a
CSS class, a locale or an AJAX parameter containing </script> closed the element, and the
remainder was handed to the HTML parser. Three call sites also passed JSON_UNESCAPED_SLASHES, which
removed the accidental protection <\/script> would have given.
Fixed with JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT at one door rather than
three. Values decode identically in the browser; the suite runs node --check on the emitted script.
Worth stating for anyone writing a driver: this is a pair of bugs with italix/datasets. The two
drivers were written from one another, so the defect was copied along with the shape — and it
survived in both for exactly as long as neither had a test suite.
Hostile input returns absence, not nonsense
?timeZone[]=Europe/Rome used to return the literal string Array — a query string can hold an
array, casting one produces that word plus a warning, and timezone() handed it back as though it
were a zone name. The caller then met a DateTimeZone exception one layer away from its cause.
Non-scalars now return null, which every caller already handles. The same guard covers start()
and end().
initial_view() is stronger still: it whitelists against the library's own vocabulary (month,
week, day, list), so that name cannot carry a payload at all.
Drivers
FullCalendar ships in the box. A driver is the only piece that knows the widget's option names, which is what keeps the widget replaceable.
Requirements
php >= 7.4, italix/contracts.
