Import ICS — agenda distant

Published : 2 August 2016 – updated on 25 January 2026 – by Amaury Adon, Maïeul – 97 commentaires

1
2
3
4
5
8 Votes

Le plugin “Import ICS” permet l’ajout automatique d’évènements distants dans la liste des évènements d’un site.

Le besoin

Le plugin Agenda permet de gérer des évènements. Il peut être utile de récupérer automatiquement des évènements d’un site distant qui fournirait un fichier .ics, afin de proposer un site agrégeant les calendriers de différents sites.

Exemple de cas d’application:

  • des séminaires de recherche de plusieurs organismes diffusés sur le même site;
  • un site d’information locale reprenant les évènements des associations et entreprises locales;
  • un site d’association affichant les évènements de ses partenaires.

Utilisation avec un site SPIP distant

Dans le cas d’un site distant sous SPIP utilisant le plugin agenda, le fichier .ics distant est disponible à la page http://url-du-site/spip.php?page=agenda-ical. Un paramètre &id_article=xxx ou &id_mot=xxx peut être ajouté pour filtre par article ou par mot clé.

Fonctionnement

Ce plugin permet de s’abonner à un calendrier distant. L’abonnement se fait via la création d’un nouvel objet “Almanach”. Celui-ci est lié à un fichier ics distant. Le plugin lira régulièrement ce fichier et ajoutera automatiquement des évènements dans la base de données du site SPIP local. Les évènements créés sont du même type que ceux gérés par le plugin Agenda.

Les évènements ainsi ajoutés seront liés:

  • à l’almanach;
  • à l’article choisi lors de la création de l’almanach;

Ce plugin ajoute donc une entrée “Almanachs” au menu “Édition” ainsi qu’un bouton d’ajout rapide d’almanach. Les évènements importés sont liés à ces objets.

La page {Almanachs} permet de lister les almanachs présents sur le site et de les administrer.

Configuration du plugin

Une fois le plugin installé, il existe deux possibilités de configurer le plugin:

  • soit à travers le formulaire accessible à travers le lien de configuration sur la page de gestion des plugins ;
  • soit par des constantes PHP mises dans le fichier mes_options.php – ou dans un fichier options.php d’un plugin. Ceci permet de déployer rapidement à grande échelle une configuration du plugin.

La configuration PHP l’emporte sur la configuration par formulaire.

Voici la liste des paramètres configurables:

  • Définir l’article par défaut. Pas de constante PHP.
  • Archiver automatiquement les évènements distants qui ne sont plus présents dans le fichier ics distant lors de la vérification de celui-ci. En PHP define ('_IMPORT_ICS_DEPUBLIER_ANCIENS_EVTS','on');.
  • Ne pas importer les évènements passés, utiles pour les sites qui se contente d’afficher les évènements à venir.
  • Permettre d’éditer certains champs manuellement

Ajouter un almanach

L’ajout d’un almanach est simple. Il suffit de remplir le formulaire d’ajout dans lequel tous les champs sont obligatoires.

Formulaire d’ajout d’almanach

L’url du flux peut être de la forme http, https ou webcal.

Une fois le formulaire validé, les évènements importés apparaissent dans la page récapitulative de l’almanach. Si ces évènements sont trop nombreux, la liste est paginée. Le plugin récupérera à intervalle régulier la nouvelle version du flux pour mettre à jour la liste des évènements.

À noter :

  • si un évènement apparaît dans plusieurs flux avec le même uid (identifiant unique distant), il ne sera pas réimporté ;
  • afin que la reconnaissance de l’heure d’été / d’hiver puisse fonctionner, il est nécessaire que la configuration PHP ait un timezone correspondant à un pays où le changement d’heure est effectué. SPIP permet de configurer si besoin le timezone.

Supprimer un almanach

Pour supprimer un almanach, le passer en statut “à la poubelle”. Tous les évènements liés sont alors basculés en “à la poubelle”.

Comme pour les articles, SPIP supprime régulièrement les évènements et les almanachs à la poubelle.

Statut des évènements

Les évènements possèdent le statut de l’almanach:

  • si l’almanach est publié, les évènements sont automatiquement publiés (modération a posteriori), à condition que l’article lui-même soit publié ;
  • si l’almanach est proposé, les évènements sont proposés, et il vous faut les publier manuellement (modération a priori).

Lorsque vous modifiez le statut d’un almanach, les évènements voient leurs statuts modifiés.

Lorsque vous modifiez le statut d’un article, les évènements et almanachs liés voient leurs statuts modifiés.

Le plugin ajoute également un statut “archivé” aux évènements, pour les évènements qui ne sont plus présents sur le flux distant. Une fois un évènement archivé, il n’est plus jamais désarchivé, sauf intervention manuel d’une rédacteurctrice.

Mots-clé

Dans la configuration des mots-clé, vous pouvez activer l’ajout de mots-clés aux almanachs.

Les évènements associés à un almanach reçoivent automatiquement les mots-clé de l’almanach. Si les mots-clé de l’almanach changent, les mots-clé des évènements sont automatiquement modifiés.

Outils pour squelette

Le plugin ajoute le critère {id_almanach} sur la boucle (EVENEMENTS) pour sélectionner les évènements liés à un almanach précis.

Usages avancés

Champs extras, adresse, gestion des inscriptions

Le flux ICAL du plugin peut agenda peut transmettre, sous forme de propriété supplémentaire :

  • l’adresse (et pas seulement le lieu)
  • le nombre de places et s’il faut gérer les inscriptions
  • les éventuels champs extras Pour ce faire il faut definir à true la constant PHP _EVENEMENT_ICAL_X_PROPERTIES.

Techniquement, ces champs sont passés dans le flux ICAL sous forme de propriétés préfixées par X. Dans l’exemple ci-dessous, est indiqué l’adresse, le nombre de place, la gestion de la réservation ainsi qu’un champ extra public.

X-ADRESSE:3 place Babel
X-INSCRIPTION:1
X-PLACES:10
X-PLACES-RESERVEES:6
X-PLACES-RESTANTES:4
X-PUBLIC:enfants

Un site SPIP peut abonné à flux distant peut également insérer la valeur de ces champs dans sa base de données. Les champs synchronisés sont :

  • adresse
  • nombre d’inscriptions
  • gestion des inscriptions
  • champs extra, s’ils existent sur le site receveur, L’identification se base par homonymie. Ainsi dans l’exemple précédent, X-PUBLIC alimentera le champ public.

Pipeline

Le principe du plugin est de convertir des champs d’un flux ICAL en champ SQL. Le plugin propose des équivalences par défaut. Mais il est possible de modifier cela, en utilisant le pipeline evenement_ical_to_sql. Ce pipeline reçoit en arguments:

  • data la valeur des champs SQL qui seront mis en base;
  • args un tableau regroupant différents paramètres :
    • objet_evenement un objet PHP décrivant l’évènement, généré par la librairie IcalCreator
    • decalage : les infos à propos du décalage horaire pour l’almanach courant
    • dtend_inclus : si le DTEND est inclus dans l’évènement pour l’almanach courant
    • xprops les propriétés ICAL d’évènements préfixées par X; qui sont difficiles à récupérer depuis objet_evenement
    • champs_x la liste des champs SQL ayant des équivalents potentiels dans les propriétés ICAL préfixées par X (champs extra, gestion des inscriptions, etc).

Exemple : pour un site, je souhaite que la synchronisation des évènements récupère dans le champ places le nombre de places restantes, et non pas le nombre de places totales. Après avoir déclarer dans paquet.xml l’emploi du pipeline, je le règle ainsi :

function formations_evenement_ical_to_sql($flux = array()) {
	if (isset($flux['data']['places'])) {
			$flux['data']['places'] = $flux['args']['xprops']['X-PLACES-RESTANTES'];
	}
	return $flux;
}

Fréquence d’actualisation

Toutes les 5 minutes, sous réserves que le site soit visités, le plugin :

  • recherche le flux dont l’actualisation est la plus ancienne, s’il a été actualisé il y a plus de 1,5 h ;
  • recherche un flux qui a (éventuellement) échoué à être actualisé, il y a plus de 1,5 h, en commencant par celui dont l’echec d’actualisation est le plus ancien ;
  • actualise les 1 ou 2 flux trouvés.

Il est possible de définir dans un fichier mes_options.php la constante _PERIODE_IMPORT_ICS pour régler le temps d’actualisation (en secondes, par défaut 5400 = 1,5h).

Attention à ne pas actualiser trop souvent : lire un flux ICAL et l’interpréter mobilise des ressources importantes.

Discussion

5 years 1 year 3 months Without limit
par date
Filter

23 discussions

  • 3
    dut

    J’utilise ce plugin pour importer les événements d’un compte facebook.

    Etrangement, je vois que certains événements s’importent spontanément, alors pour vous d’autres ’amis’ facebook, il faut que j’aille explorer tous les événements et les enregistrer pour qu’au cron suivant ils soient importés.

    Avez-vous une opinion sur ce soucis ?

    Reply to this message

  • 1
    olivierlef

    Bonjour Maïeul,

    Je rencontre un problème avec un calendrier ics : https://messes.info/horaires/.fr%2084%20saint%20agricol.ics.
    Google agenda, le lit bien, mais import ics n’y trouve aucun évènement.

    En fouillant un peu, j’ai trouvé que ce fichier ics utilise DTSTART et DURATION pour définir l’évènement, mais DURATION n’est pas géré dans import ics qui n’utilise que le binôme DTSTART et DTEND.

    Voilà, si tu as un peu de temps pour y jeter un coup d’œil.

    Merci d’avance

    Reply to this message

  • 2
    olivierlef

    Bonjour Maïeul,

    J’ai le cas suivant : lors que une personne supprime un événement de son calendrier ics, cela ne supprime pas l’événement dans SPIP.

    Effectivement dans import_ics.php, on traite :
    -  les modifications des événements avec le test sur LAST-MODIFIED
    -  l’ajout de nouveaux événements,
    mais on ne gère pas la suppression d’événements. Est-ce intentionnel ?

    Merci à toi

    • Maïeul

      c’est une option à cocher si mes souvenirs sont bons, qui fait passer les evt distant supprimés au statut “archivés”

    • olivierlef

      Super, tes souvenirs sont bons.

      Merci à toi

    Reply to this message

  • 1
    Philippe

    Bonjour,

    J’utilise un serveur de calendrier Baikal avec lequel je souhaiterais synchroniser le calendrier SPIP.

    La particularité de Baikal, c’est qu’on ne peut s’y connecter qu’avec un identifiant et un mot de passe, et que rien n’est prévu pour saisir ces informations à la création d’un almanach.
    Résultat: échec de connexion.

    Une idée ?
    Merci

    • Maïeul

      Changer de serveur?

      Plus concrètement, j’aurais besoin d’un exemple avec un identifiant/mdp de test (à m’envoyer en privé). Je pourrais essayer de travailler cela ce week-end, après un autre projet sous SPIP.

    Reply to this message

  • o2

    Bonjour

    J’ai testé l’import ICS avec un calendrier google.
    Les événements sont bien importés dans agenda et dans le mini calendrier. Par contre quand on clique sur l’événement dans l’agenda, ça renvoie sur l’article qui est couplé à l’almanach.
    Or dans cet article je n’ai aucun contenu distant qui ne s’affiche : comment cela se fait il ? que dois je faire pour qu’ils apparaissent en ligne (sous forme de liste je suppose) ?

    merci

    Reply to this message

  • 2
    jeanmarie

    Salut,

    petite question au niveau de la mise en forme des textes : avec le format ics, on ne peut pas conserver la mise en forme (gras, italique...) ni les liens et images, c’est bien ça ?

    Ou alors ce n’est pas une contrainte du format mais ce sont les filtres |supprimer_tags|textebrut|filtrer_ical du fichier inc/un-evenement-ical.html qui le font et on pourrait donc imaginer récupérer la mise en forme et les images/liens de la source ?

    Merci,

    jean marie

    • Maïeul

      la RFC qui décrit le format ical n’aborde pas ces questions.

      J’imagine qu’en soit on pourrait avoir des balises, que SPIP pourrait interpréter … mais je ne suis pas sûr que les autres lecteurs supporterait.

      Donc la solution actuelle de SPOP me paraît le mieux.

      Voir la description de la RFC http://www.faqs.org/rfcs/rfc2445.html

    • jeanmarie

      Hello,

      merci pour ta réponse.
      je pense également que c’est mieux ainsi, je vais me tourner vers une autre solution.

      jean marie

    Reply to this message

  • 9
    dut

    Je pense que j’ai levé un lièvre, mais qu’il est peut-être du à un fonctionnement de plugin qui a évolué au fil du temps.

    Depuis quelques temps déjà, je trouvais que les modifications faites sur des événements importés étaient ’perdues’ ensuite.

    J’ai constaté sur un cas concret que pour l’événement importé, la version initiale (id_version =1 dans la table versions se voyait attribués cpmme date de debut celle de l’événement (et non pas la date d’import). Sans doute pourrait-il être dû au fait que evenements:date_creation a pour valeur 0000-00-00 00:00:00 ?

    Toujours est-il que la date de la révision initiale se retrouve du coup ulterieure à celle des modification effectuées ensuite.

    J’espère avoir sur exprimer clairement le soucis rencontré.

    Je pense pouvoir traité les événement déjà importés en retouchant la date de version initiale, mais il serait sans doute utile de verifier ce qu’il en est pour une install fraiche.

    Bye.

    • Maïeul

      je n’ai rien compris… tu modifier à la main les evenements importés? ou le problème se trouve lorsque les evenements distants sont modifiés?

    • dut

      Non, ils sont préimportés, puis modifiés manuellement et publiés.

      C’est en constatant que les modifs n’étaient pas affichées ensuite (au profit de la version initiale importée) que j’ai pensé qu’un truc clochait.

    • Maïeul

      a oui, j’ai jamais testé l’idée de modification de versions… c’est possible qu’il y a un reecrasement lors de la mise à jour du flux distant.

      mais bon, pour en savoir plus, il faudrait que tu me fasse un test précis, pour que je puisse reproduire. franchement j’ai pas le temps de préparer moi même pour ca, surtout que c’est pas un truc prévu au départ.

    • dut

      La révision initiale est dans le futur. C’est donc que la date est mal initialisé (voir hépothèse émise plus haut)

      Voir les explication ci-dessus et je t’octroie sans soucis si tu le souaite un accès sur la base, mais prudence.

    • Maïeul

      non, j’ai pas le temps de regarder, si tu me produit pas un exemple que moi je puisse reproduire.…
      C’est à dire que tu me décrit toutes les étapes, une par une, qui pose souci, avec un fichier .ics de test.

    • dut

      Je crois que ce fil et le fil précédent (du 23 novembre) sont en relation.

      Comme l’import par le génie ne marche plus chez moi, j’utilisais depuis quelques jours le bouton ’mettre à jour cet almanach maintenant’.
      Me confirme-tu que qu’avec l’utilsation de ce bouton l’écrasement est systématique alors qu’avec le génie seulement en cas de mise à jour d’événément (c’est du moins ainsi que j’avais compris le comportement du plugin).

    • Maïeul

      Non, le genie et le bouton de mise à jour manuel sont branchés, normalement, sur la même fonction.

      Ce qui n’est pas normal est que le génie ne marche plus chez toi.

    • dut

      Oui, d’autant que par ailleurs le génie donne satisfaction.

      Je crains un mécanisme chez facebook qui rejette des imports ou des imports trops fréquents (j’ai utilisé le déclenchement manuel à des reprises plus rapprochées que 24h ces temps).

    • Maïeul

      ce n’est pas impossible, mais le genie est programmer pour fonctionner toutes les 24heures. As tu plusieurs almanach chez facebook? il se peut qu’il bloque plusieurs requetes d’affiler…

      en tous cas, je confirme que génie comme action passent, in fine, par la même fonction importer_almanach().

      Par contre comme je n’ai toujours pas d’element concret de problème de modification de l’evenement, je ne peux pas résoudre le bug à l’origine de ce fil…

    Reply to this message

  • 2
    dut

    Help ! depuis la mise à jour qui introduit des décalages différencies heure d’été heure d’hiver, je n’importe plus rien !

    C’est un flux issu d’un compte facebook. Je peux en filer l’adresse en message perso si besoin.

    • dut

      Il est toujours possible que ma mise à jour du plugin coincide avec le moment ou facebook à decider de changer quelque choses dans ses flux sortants.

      Avez vous moyen de déterminer ce qu’il en est ?

    • Maïeul

      je pense que c’est une coïncidence, puisque mes propres tests avec d’autres flux marchent parfaitement. Il me faudrait effectivement l’adresse du flux problématique pour cerner le souci.

    Reply to this message

  • 9
    olivierlef

    Bonjour Maieul,

    L’année avance et nous allons bientôt changer d’heure, jusqu’à présent - à Paris - nous étions en GMT +2, et on va passer à GMT + 1.

    Les fichiers ICS sont édités en GMT et pour gérer les fuseaux horaires, tu as mis en place une valeur de décalage, mais qui est la même toute l’année....hors 2 fois par an, on change d’heure...

    A bientôt

    PS: lorsque j’appuie sur le bouton “Supprimer ces événements” j’ai le message “Fichier supprimer_evenements_almanach introuvable” - c’est pas bloquant

    Reply to this message

  • 3
    dut

    Est-ce qu’il existe un moyen de suspendre/reactiver l’import d’événements à chaque execution du job pour un almanach donné (sans perdre les événements déjà importés) ?

    • Maïeul

      Non, pas pour le moment.

    • dut

      Je reviens un peu à la charge.

      Un des flux auquel j’avais souscrit est notoirement doublonné, je ne souhaite plus l’importer

      Comme par contre j’aimerai garder les événement déja importés. il me faut trouver un mécanisme

      Couper le lien entre les évenements en question et leur almanach d’import initial permettrait t-il de supprimer ensuite l’almanach sans perdre les événements en questions. ?

      Ne plus importer ce flux, tant pis si les objets déja importés restent est également une possibilité. Introduire une coquille dans l’adresse de l’agenda permettrait d’eviter des imports suivants ?

      Merci de vos avis

    • Maïeul

      couper les liens devrait suffire. Faire une sauvegarde avant quand même.

    Reply to this message

Add a comment

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom