All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh


From TYPO3Wiki
Jump to: navigation, search

notice - Note

This page is currently in the creation process.

It is not finished yet and does not contain final information.

This document has been already published to share information

at an early stage of beeing.


  • front-end-editing support
  • Possibility to use the plugin as a standard content element as well as in standard Typoscript together with the three main concepts of building Typo3-pages: Go-Live-Tutorial, Modern-Template-Building and Templa Voila.
  • Import-/Export-Functions from/to Standard Organizers and Calendar-Systems like Mozilla Calendar or Outlook
  • Downloading of selected events in the iCal format which allows importing them into your favorite desktop calendar application
  • By clicking a day in the month view the user should be directly reach a eventlisting.
  • The DHTML calendar created by Mishoo should be used in the editing form (both, FE and BE).
  • Recurrent events (enter calendar information that occurs e.g. every Monday). Karsten
  • All-day calendar entries (like birthdays or individual festival days etc.). Karsten
  • All-day calendar entries spread over multiple days, e.g. for private holidays, festivals, trade fairs, conventions, conferances etc. Karsten
  • Multiple categories in one event
  • Recurring events that occur monthly on a certain weekday, e.g. every first and second friday each month
  • Categories with n-level subcategories. This is useful for categorizing all kinds of hierarchical organizations (enterprises, parishes, associations). Karsten
  • Ability to use flexforms without forcing the user to use them (I don't agree, using Flexforms should not be a problem for anyone, so why not force users to use them? Ingmar 22:13, 25 Jul 2004 (CEST))

notice - Note

Cal enables administrators to configure it through flexforms and/or TypoScript.

Due to the way how TYPO3 works it is not possible

to use backend editing for editors without using flexforms.
  • Year-, month-, week-, day-, item-view and any other parameter should be handled using the built in session system described in TSref as the "built in shopping Basket" instead of "&tx_whatever_pi1[blubb]=blah" in each URL (I disagree: This doesn't work well with static urls and caching! static urls are a must-have in year 2004!! I originally developped "calendar" using the session support, you *don't want this*, believe me :)) (I don't agree either, using piVars is the way to go. We can discuss that in the Newsgroup if someone is interested. Ingmar 22:13, 25 Jul 2004 (CEST))

notice - Note

Administrators can define which parameters should be stored in a session and which should be handed over as url-parameter
  • Template driven output: design-oriented based on GIFBUILDER-objects to create colored bars with different lenghts and/or accessibility-oriented based on CSS

notice - Note

Cal is template driven, and since 0.17.0 administrators can use GIFBUILDER-objects wherever they want (except fe-editing so far).

Investigating how far these are realized..

  • Update per mail when an entry changes. Karsten
  • E-mailsubscription to new events based on categories
  • stdWrap for all subparts and markers so that any kind of content can be added easily to a subpart or marker via TS (marker_name.cObject = COA)
  • It should be possible to either add static locations, or be able to add the place etc on a per-event base. By defining the fields as "exclude" fields, you can then choose which one you want your backend users to be able to edit, but we really need this, as people want to use both ways.

Not yet realized

Can be done through configuration or other extensions partly:

  • Organizers can be be_users, registered fe_users and anonymous frontend users

notice - Note

This can be done with simulateBE user

and onetimeaccount.

The first one enables FE user to get BE access rights. The second one creates front end user accounts

without a long registration. Those users can't login again if they leave the website.
  • There should be Target Groups based on fe_groups describing who (what group of people) the event is for. --Inshadow 08:01, 27 Jul 2004 (CEST)

notice - Note

This can be done if every fe usergroup gets its own calendar. See the manual for further help.
  • Ability to use registering- and booking-forms to use the calendar as kind of an organizer

notice - Note

Registration for events can be done with seminars extension

and cal_ts_service.

The seminar extension takes care about the events, the service displays these within calendar base
  • Filter by place and type/subcategories. Karsten

notice - Note

Use the search functionality provided by calendar base to filter.
  • Public holiday lists. Karsten

notice - Note

Find holiday ics file in the internet and import them to your calendar. A big amount of related calendars can be found at
  • A supcription function for an event (with and without payment). It should be possible that named fe_users can subscribe to an event. The calendar musst show who has subscribed yet to an event (maybe with a [more] or [detail] link).

notice - Note

See seminars extension above.

Payment is not yet possible but if someone sponsors the extension team,

changes are good.. ;)

Can not be done yet as far as I know

  • Should be integreted with the Project Manager, so that when you add an event to the calendar you also add a timesheet in the project manager and vice versaAdla
(I think that organizer should only be either fe_users(vote) og be_users not to complicate things more than nesecary) --Inshadow 08:01, 27 Jul 2004 (CEST) 
  • single events with edit single/edit all support (I don't get it. Please explain. Ingmar 22:13, 25 Jul 2004 (CEST))(Guess it is regulary returning events. Ex. edit this weeks event - but not all forthcoming events)
  • The Calendar-System should also be able to get the looks from the ScoutNet-Calendar (month-view with a short popup-information about entries when the user is moving the mouse over a single day, etc.)
  • For recurrent events the option to enter an exception that is highlighted. E.g. every Sunday the soccer club meets but not on a specific one - then something like "Today no soccer training!" should be displayed. Karsten
  • At least the functionality of WebCalendar. Or maybe a wrapper? Karsten
  • Something like "myCalendar" - user can select specific views and store them as a kind of favorites. Karsten
  • API funtion for integration of ical, VCS files recieved in mails. Should 1. analyze ical/vcal and return title, dates, times. a.s.o as an array - 2. have a function for importing the ical/vcal into the calendar directly.
  • A truly robust calendar API should be able to deal with recurring events such as Easter, Ramadan, Chusok, Chinese New Year, lunar/solar eclipses (maybe even solstices and equinoxes) that are based on times other than simple 'day of year/month/week' (Most of the above are based on lunar calendar). Having said this, I have almost no idea how to approach it (seems that this would require static astronomical data tables to accompany an extension...) Christopher (Or some math to do the magic - should be readily avalible scripts for it)
  • The API (and extension configuration options) should also include time-zone settings (at least as long as the Typo3 core is unable to do this). I would like to see time zone settings be robust enough to attempt to use putenv() but fall back on an internal offset if putenv() fails [as it seems to do sometimes...] Again, this might require static info tables for time zones. Christopher
  • Further to time zones, the API should be fully capable of dealing with daylight savings time. Christopher
  • the ability to merge external events, either per XML or by user-function (calculated events)
  • A ToDO List, where a list of Things to do could be inserted. An presented like 'Tommorow's Event'

Choose what tags you need: