Mise à niveau des plugins

Préparez votre plugin pour la prochaine version de Elgg.

Voir les guides d’administration pour savoir comment mettre à niveau un site en production.

Contenus

De 2.2 à 2.3

Version de PHP

PHP 5.5 a atteint la date de fin de support en Juillet 2016. Afin de s’assurer que les sites Elgg soient sécurisés, nous exigeons désormais PHP 5.6 pour les nouvelles installations.

Les installations existantes peuvent continuer à utiliser PHP 5.5 jusqu’à Elgg 3.0.

Afin de mettre à niveau Elgg vers la 2.3 en utilisant composer avec PHP 5.5, vous pouvez avoir besoin d’utiliser le drapeau --ignore-platform-reqs.

APIs dépréciées

  • Enregistrement pour le hook to:object par le nom de l’extenseur : Utilisez plutôt les hooks to:object, annotation et to:object, metadata à la place.

  • ajax_forward_hook() : N’est plus utilisé comme gestionnaire pour le hook “forward”,”all”`. La réponse Ajax est maintenant enveloppée par la ResponseFactory

  • ajax_action_hook() : N’est plus utilisé comme gestionnaire pour le hook “action”,”all”. La mise en mémoire tampon de la sortie commence maintenant avant que le hook ne soit déclenché dans ActionsService

  • elgg_error_page_handler() : N’est plus utilisé comme gestionnaire pour les hooks “forward”,<error_code>

  • get_uploaded_file() : Utilisez la nouvelle API d’envoi de fichiers à la place

  • get_user_notification_settings() : Utilisez ElggUser::getNotificationSettings()

  • set_user_notification_setting() : Utilisez ElggUser::setNotificationSetting()

  • événement pagesetup, system : Utilisez le menu ou les hooks de la coquille de la page (page shell) à la place.

  • elgg.walled_garden ce JavaScript est osbolète : Utilisez le module AMD elgg/walled_garden à la place.

  • elgg()->getDb()->getTableprefix() : Utilisez elgg_get_config('dbprefix').

  • update_entity_last_action() privée : Évitez de mettre à jour manuellement le timestamp de la dernière action.

  • Définir un access_id non-public sur une métadonnée est obsolète. Voyez ci-dessous.

  • get_resized_image_from_existing_file() : Utilisez elgg_save_resized_image().

  • get_resized_image_from_uploaded_file() : Utilisez elgg_save_resized_image() en combinaison avec l’API d’envoi de fichier (upload).

  • get_image_resize_parameters() sera supprimé.

  • elgg_view_input() : Utilisez elgg_view_field(). Toutes nos excuses pour le changement d’API.

Vues obsolètes

  • resources/file/world : Utilisez la vue resources/file/all à la place.

  • resources/pages/world : Utilisez la vue resources/pages/all à la place.

  • walled_garden.js : Utilisez le module elgg/walled_garden à la place.

Nouvelle API pour la gestion des pages et des actions

Les gestionnaires de pages et les fichiers de script d’action doivent maintenant renvoyer une instance de \Elgg\Http\ResponseBuilder. Les plugins devraent utiliser les fonctions suivantes pour créer des réponses :

  • elgg_ok_response() envoie une réponse 2xx avec des données HTML (gestionnaire de page) ou JSON (actions)

  • elgg_error_response() envoie une réponse 4xx ou 5xx sans contenu/données

  • elgg_redirect_response() redirige silencieusement la requête

Nouvelle API pour travailler avec l’envoi de fichiers

  • elgg_get_uploaded_files() - renvoie un tableau d’objets Symfony de fichiers téléchargés

  • ElggFile::acceptUploadedFile() - déplace un fichier téléchargé dans le répertoire de fichiers de Elgg

Nouvelle API pour la manipulation d’images

Le nouveau service de manipulation d’images met en œuvre une approche plus efficace pour recadrer et redimensionner les images.

  • elgg_save_resized_image() - recadre et redimensionne une image aux dimensions choisies

Nouvelle API pour les événements

  • elgg_clear_event_handlers() - similaire à elgg_clear_plugin_hook_handlers cette fonction supprime tous les gestionnaires d’événements enregistrés

Nouvelle API pour la signature des URLs

Les URL peuvent désormais être signées avec une clé HMAC SHA-256 et validées à tout moment avant l’expiration de l’URL. Cette fonctionnalité peut être utilisée pour tokenizer l’URL d’action dans les notifications par e-mail, ainsi que d’autres utilisations en dehors de l’installation Elgg.

  • elgg_http_get_signed_url() - signe l’URL avec la clef HMAC

  • elgg_http_validate_signed_url() - valide l’URL signée

  • elgg_signed_request_gatekeeper() - gardien qui valide la signature de la requête en cours

Vues de formulaire extensibles

Le rendu du pied de page du formulaire peut maintenant être reporté jusqu’à ce que la vue du formulaire et ses extensions aient terminé le rendu. Cela permet aux plugins de collaborer sur les vues de formulaire sans casser la logique de balisage.

  • elgg_set_form_footer() - définit le pied de page du formulaire pour le rendu différé

  • elgg_get_form_footer() - renvoie le pied de page du formulaire défini

Métadonnées access_id

Il est maintenant obsolète de créer des métadonnées avec une valeur explicite de access_id autre que ACCESS_PUBLIC.

Dans Elgg 3.0, les métadonnées ne seront pas contrôlées et seront disponibles dans tous les contextes. Si votre plugin repose sur le contrôle d’accès des métadonnées, il serait sage de migrer le stockage vers des annotations ou des entités à la place.

Nouvelle API pour extraire des noms de classes à partir des tableaux

Semblable à elgg_extract(), elgg_extract_class() extrait la clef class (si elle est présente), la fusionne avec les noms de classe existants, et renvoie toujours un tableau.

Notifications

  • Un hook de haut niveau 'prepare','notification' est maintenant déclenché pour les notifications instantanées et d’abonnement et peut être utilisé pour modifier les objets de notification quel que soit leur type.

  • le hook 'format','notification:<method>' est maintenant déclenché pour les notifications instantanées et d’abonnement et peut être utilisé pour formater la notification (par ex. pour supprimer les balises HTML, envelopper le corps de notification dans un modèle, etc.).

  • Les notifications instantanées sont désormais traitées par le service de notifications, de sorte que la quasi-totalité des hooks applicables aux notifications d’abonnement s’appliquent également aux notifications instantanées.

  • elgg_get_notification_methods() peut être utilisé pour obtenir les méthodes de notification enregistrées

  • Ajout de ElggUser::getNotificationSettings() et ElggUser::setNotificationSetting()

Les fonctions de liste d’entités peuvent générer des tableaux

Dans des fonctions telles que elgg_list_entities($options), le rendu sous forme de tableau est possible en définissant $options['list_type'] = 'table' et en fournissant un tableau de colonnes de tableau dans $options['columns']. Chaque colonne est un objet Elgg\Views\TableColumn, généralement créé via des méthodes du service elgg()->table_columns.

Les plugins peuvent fournir ou modifier ces méthodes d’usine (voir Elgg\Views\TableColumn\Columfactory). Pour un exemple d’utilisation, consultez la vue admin/users/newest.

Composants d’onglets en ligne

Le composant szq onglets en ligne peut désormais être rendu avec l’affichage page/composants/onglets. Les composants permettent de basculer entre pré-rempli et chargé-par-ajax. Voir page/components/tabs dans les vues du noyau et theme_sandbox/components/tabs dans le plugin developers pour les instructions et les exemples d’utilisation.

API pour modifier l’URL d’inscription et de connexion

  • elgg_get_registration_url() doit être utilisé pour obtenir l’URL d’inscription sur le site

  • elgg_get_login_url() doit être utilisé pour obtenir l’URL de connexion du site

  • le hook registration_url, site peut être utilisé pour modifier l’URL d’inscription par défaut

  • le hook login_url, site peut être utilisé pour modifier l’URL de connexion par défaut

Prise en charge des jeux de champs (fieldsets) dans les formulaires

  • elgg_view_field() remplace elgg_view_input(). Elle dispose d’une API similaire, mais accepte un seul tableau.

  • elgg_view_field() prend en charge #type, #label, #help et #class, permettant l’envoi de versions non préfixées à la vue d’entrée $vars.

  • La nouvelle vue input/fieldset peut être utilisée pour rendre un ensemble de champs, chacun rendu avec elgg_view_field().

De 2.1 à 2.2

APIs dépréciées

  • Bibliothèque JavaScript elgg.ui.river : Supprimez les appels à elgg_load_js('elgg.ui.river') du code du plugin. Mettez à jour core/river/filter et forms/comment/save, s’ils sont remplacés, pour exiger des modules de composants AMD

  • Méthodes elgg.ui.popupOpen() et elgg.ui.popupClose() dans la bibliothèque JS elgg.ui : Utilisez plutôt le module elgg/popup.

  • Bibliothèque lightbox.js : n’utilisez pas elgg_load_js('lightbox.js'); à moins que votre code ne référence l’espace de nom déprécié elgg.ui.lightbox. Utilisez plutôt le module AMD elgg/lightbox.

  • Bibliothèque elgg.embed et objet elgg.embed : N’utilisez pas elgg_load_js('elgg.embed'). Utilisez plutôt le module AMD elgg/embed

  • Accéder directement à la valeur de configuration icons_sizes : Utilisez elgg_get_icon_sizes()

  • can_write_to_container() : Utilisez ElggEntity::canWriteToContainer()

Vues obsolètes

  • elgg/ui.river.js est déprécié : ne vous fiez pas aux URLs de simplecache pour travailler.

  • groups/js est déprécié : utilisez à la place le module AMD groups/navigation comme dépendance d’élément du menu pour les éléments de menu « feature » (mettre en Une) et « un-feature » (retirer de la Une).

  • lightbox/settings.js est déprécié : utilisez l’attribut getOptions, ui.lightbox ou data-colorbox-opts du hook plugin JS.

  • elgg/ckeditor/insert.js est déprécié : vous n’avez plus besoin de l’inclure, l’enregistrement des hooks a lieu dans le module elgg/ckeditor

  • embed/embed.js est déconseillé : utilisez le module AMD elgg/embed.

Ajout du module elgg/popup

Le nouveau module elgg/popup peut être utilisé pour créer des interactions plus complexes de déclenchement de popup, y compris la liaison des types d’ancrage personnalisés et l’ouverture/fermeture de popup programmatiquement.

Ajout du module elgg/lightbox

Le nouveau module elgg/lightbox peut être utilisé pour ouvrir et fermer la lightbox par programme.

Ajout du module elgg/embed

Même s’il est rarement nécessaire, le module AMD elgg/embed peut être utilisé pour accéder aux méthodes d’intégration par programme. Le module s’initialise lui-même si nécessaire et est peu susceptible de nécessiter une décoration supplémentaire.

Nouvelle API pour la manipulation des icônes d’entités

  • ElggEntity implémente désormais l’interface \Elgg\EntityIcon

  • elgg_get_icon_sizes() - renvoie les tailles d’icônes spécifiques au type/sous-type d’entité spécifié

  • ElggEntity::saveIconFromUploadedFile() - crée des icônes à partir d’un fichier téléchargé

  • ElggEntity::saveIconFromLocalFile() - crée des icônes à partir d’un fichier local

  • ElggEntity::saveIconFromElggFile() - crée des icônes à partir d’une instance de ElggFile

  • ElggEntity::getIcon() - renvoie une instance de ElggIcon qui pointe vers l’emplacement de l’icône de l’entité dans le répertoire de fichiers (il peut s’agir simplement d’un espace réservé, utilisez ElggEntity::hasIcon() pour vérifier si le fichier a été écrit)

  • ElggEntity::deleteIcon() - supprime les icônes d’entité

  • ElggEntity::getIconLastChange() - retourne la date de modification du fichier icône

  • ElggEntity::hasIcon() - vérifie si une icône de cette dimension a bien été créé

  • elgg_get_embed_url() - peut être utilisé pour retourner une URL pour intégrer l’icône d’une entité (servie via le gestionnaire /serve-icon)

Les avatars des utilisateurs sont désormais servis via le gestionnaire serve-file. Les plugins devraient commencer à utiliser elgg_get_inline_url() et noter que :

  • le gestionnaire de page et la vue ressource``/avatar/view`` sont devenus obsolètes

  • le fichier /mod/profile/icondirect.php est devenu obsolète

  • profile_set_icon_url() n’est plus enregistré comme fonction de rappel (callback) pour le hook plugin "entity:icon:url","user"

Les avatars de groupe sont désormais servis via le gestionnaire serve-file. Les plugins devraient commencer à utiliser elgg_get_inline_url() et noter que :

  • le gestionnaire de page groupicon (groups_icon_handler()) est devenu obsolète

  • le fichier /mod/groups/icon.php est devenu obsolète

Les miniatures et les téléchargements sont dsormais servis via le gestionnaire serve-file. Les plugins devraient commencer à utiliser elgg_get_inline_url() et elgg_get_download_url() et noter que :

  • le gestionnaire de page et la vue ressource``file/download`` sont devenus obsolètes

  • le fichier mod/file/thumbnail.php est devenu obsolète

  • Plusieurs vues ont été mises à jour pour utiliser les nouvelles URLs de téléchargement, notamment :

    • mod/file/views/default/file/specialcontent/audio/default.php

    • mod/file/views/default/file/specialcontent/image/default.php

    • mod/file/views/default/resources/file/view.php

    • mod/file/views/rss/file/enclosure.php

APIs supprimées

Juste un avertissement pour indiquer que les fonctions de caches d’entité privée (par ex. _elgg_retrieve_cached_entity) ont été supprimées. Quelques plugins ont pu les utiliser. Les plugins ne devraient pas utiliser les API privées dans la mesure où elles seront plus souvent supprimées sans avertissement.

Un module elgg/ckeditor amélioré

le module elgg/ckeditor peut maintenant être utilisé pour ajouter un éditeur WYSIWYG à un textarea de manière programmatique avec elgg/ckeditor#bind.

De 2.0 à 2.1

APIs dépréciées

  • ElggFile::setFilestore

  • get_default_filestore

  • set_default_filestore

  • elgg_get_config('siteemail'): Utilisez elgg_get_site_entity()->email

  • URLs commençant par /css/ et /js/ : Utilisez elgg_get_simplecache_url()

  • elgg.ui.widgets L’objet JavaScript est déprécié par le module AMD elgg/widgets

changements de Application::getDb()

Si vous utilisez cette API bas niveau, ne vous attendez pas à ce qu’elle renvoie une instance Elgg\Database dans 3.0. Elle renvoie maintenant un Elgg\Application\Database avec de nombreuses alertes de dépréciation. Ces méthodes n’ont jamais été destinées à devenir une API publique, mais nous ferons de notre mieux pour les prendre en charge dans en 2.x.

Ajout du module elgg/widgets

Si le code de votre plugin appelle elgg.ui.widgets.init(), utilisez plutôt le module elgg/widgets.

De 1.x à 2.0

Elgg peut maintenant être installé en tant que dépendance de composer au lieu d’être situé à la racine

Cela signifie qu’un site Elgg peut ressembler à ceci :

settings.php
vendor/
  elgg/
    elgg/
      engine/
        start.php
      _graphics/
        elgg_sprites.png
mod/
  blog
  bookmarks
  ...

elgg_get_root_path et $CONFIG->path vont renvoyer le chemin vers le répertoire racine de l’application, qui n’est pas nécessairement le même que le répertoire racine d’Elgg core (qui dans ce cas est vendor/elgg/elgg/).

N’essayez pas d’accéder directement au noyau Elgg depuis votre plugin, car vous ne pouvez pas compter sur son emplacement dans le système de fichiers.

En particulier, n’essayez pas de charger engine/start.php.

// Don't do this!
dirname(__DIR__) . "/engine/start.php";

Pour démarrer Elgg manuellement, vous pouvez utiliser la classe Elgg\Application.

// boot Elgg in mod/myplugin/foo.php
require_once dirname(dirname(__DIR__)) . '/vendor/autoload.php';
\Elgg\Application::start();

Cependant, utilisez cette approche avec parcimonie. Préférez le routage Routage dans la mesure du possible, car cela permet de découpler vos URLs publiques et la structure du système de fichiers.

En outre, n’essayez pas d’accéder directement aux fichiers _graphics.

readfile(elgg_get_root_path() . "_graphics/elgg_sprites.png");

Utilisez le vues à la place :

echo elgg_view('elgg_sprites.png');

Les vues cacheables doivent avoir une extension de fichier dans leurs noms

Cette exigence nous permet de servir des actifs directement à partir du disque pour des raisons de performance, au lieu de les servir par PHP.

Il est également beaucoup plus facile d’explorer les ressources disponibles dans le cache en allant vers dataroot/views_simplecache et en naviguant à partir de là.

  • Mauvais : my/cool/template

  • Bon : my/cool/template.html

Nous mettons maintenant en cache des ressources par $viewtype/$view, et plus md5('$viewtype|$view'), qui entraînait des conflits entre les vues pouvant être mises en cache qui n’avaient pas d’extension de fichier pour les distinguer des répertoires.

Abandon de jquery-migrate et mise à niveau de jquery vers ^2.1.4

l’API jQuery 2.x est compatible avec 1.x, mais abandonne la prise en charge de IE8-, que Elgg ne prend plus en charge depuis un certain temps de toutes façons.

Lisez http://jquery.com/upgrade-guide/1.9/ pour savoir comment se passer de jquery-migrate.

Si vous préférez la conserver, vous pouvez utiliser ce code dans l’initialisation de votre plugin :

elgg_register_js('jquery-migrate', elgg_get_simplecache_url('jquery-migrate.js'), 'head');
elgg_load_js('jquery-migrate');

Définissez également une vue jquery-migrate.js contenant le contenu du script.

JS et CSS ont été déplacés hors des répertoires js/ et css/

Ils ont également reçu des extensions .js et .css respectivement s’ils ne les avaient pas déjà :

Ancienne vue

Nouvelle vue

js/view

view.js

js/other.js

other.js

css/view

view.css

css/other.css

other.css

js/img.png

img.png

Le principal avantage que cela apporte est d’être en mesure de co-localiser les actifs connexes. Ainsi, un modèle (view.php) peut avoir ses dépendances CSS/JS juste à côté (view.css, view.js).

Un grand soin a été pris pour rendre cette modification aussi rétro-compatible que possible, de sorte que vous ne devriez pas avoir besoin de mettre à jour les références des vues immédiatement. Cependant, vous êtes certainement encouragés à déplacer vos vues JS et CSS vers leurs nouveaux emplacements canoniques.

En pratique, ceci introduit quelques pièges :

Les hooks view_vars, $view_name et view, $view_name fonctionneront sur le nom canonique de la vue :

elgg_register_plugin_hook_handler('view', 'css/elgg', function($hook, $view_name) {
  assert($view_name == 'elgg.css') // not "css/elgg"
});

L’utilisation du hook view, all et la vérification des vues individuelles peuvent ne pas fonctionner comme prévu :

elgg_register_plugin_hook_handler('view', 'all', function($hook, $view_name) {
  // Won't work because "css/elgg" was aliased to "elgg.css"
  if ($view_name == 'css/elgg') {
    // Never executed...
  }

  // Won't work because no canonical views start with css/* anymore
  if (strpos($view_name, 'css/') === 0) {
    // Never executed...
  }
});

Merci de nous faire part de tous les autres problèmes de rétro-compatibilité que ce changement provoque. Nous aimerions en résoudre le plus grand nombre possible pour faciliter la transition.

fxp/composer-asset-plugin est maintenant nécessaire pour installer Elgg à partir de la source

Nous utilisons fxp/composer-asset-plugin pour gérer nos actifs de navigateur (js, css, html) avec Composer, mais il doit être installé globalement avant d’installer Elgg afin que les packages bower-asset/* soient reconnus. Pour l’installer, exécutez :

composer global require fxp/composer-asset-plugin

Si vous ne le faites pas avant d’exécuter composer install ou composer create-project, vous obtiendrez un message d’erreur :

[InvalidArgumentException]
Package fxp/composer-asset-plugin not found

Liste des vues dépréciées et des arguments des vues qui ont été supprimés

Nous avons abandonné la prise en charge et/ou supprimé les vues suivantes :

  • canvas/layouts/*

  • categories

  • categories/view

  • core/settings/tools

  • embed/addcontentjs

  • footer/analytics (Utilisez page/elements/foot à la place)

  • groups/left_column

  • groups/right_column

  • groups/search/finishblurb

  • groups/search/startblurb

  • input/calendar (Utilisez input/date à la place)

  • input/datepicker (Utilisez input/date à la place)

  • input/pulldown (Utilisez input/select à la place)

  • invitefriends/formitems

  • js/admin (Utilisez AMD et elgg_require_js au lieu d’étendre les vues JS existantes)

  • js/initialise_elgg (Utilisez AMD et elgg_require_js au lieu d’étendre les vues JS)

  • members/nav

  • metatags (Utilisez le hook plugin “head”, “page” à la place)

  • navigation/topbar_tools

  • navigation/viewtype

  • notifications/subscriptions/groupsform

  • object/groupforumtopic

  • output/calendar (Utilisez output/date à la place)

  • output/confirmlink (Utilisez output/url à la place)

  • page_elements/contentwrapper

  • page/elements/shortcut_icon (Utilisez le hook plugin “head”, “page” plugin hook à la place)

  • page/elements/wrapper

  • profile/icon (Utilisez elgg_get_entity_icon)

  • river/object/groupforumtopic/create

  • settings/{plugin}/edit (Utilisez plugins/{plugin}/settings à la place)

  • user/search/finishblurb

  • user/search/startblurb

  • usersettings/{plugin}/edit (Utilisez plugins/{plugin}/usersettings à la place)

  • widgets/{handler}/view (Utilisez widgets/{handler}/content à la place)

Nous avons également abandonné les arguments suivants des vues :

  • « value » dans output/iframe (Utilisez plutôt « src »)

  • « area2 » et « area3 » dans page/elements/sidebar (utilisez plutôt « sidebar » ou l’extension de vue)

  • « js » dans les vues des icônes (par exemple icon/user/default)

  • Les options pour input/radio et input/checkboxes qui ne sont pas des paires de clef-valeur ne seront plus acceptées.

Tous les scripts ont été déplacés vers le bas de la page

Vous devriez tester votre plugin avec la console d’erreur JavaScript visible. Pour des raisons de performance, Elgg ne prend plus en charge les éléments script dans l’élément head ou dans les vues HTML. elgg_register_js chargera désormais tous les scripts à la fin de l’élément body.

Vous devez convertir les scripts en ligne en AMD ou en scripts externes chargés avec elgg_load_js.

Au début de la page, Elgg fournit un shim de la fonction RequireJS require() qui met simplement le code en file d’attente jusqu’à ce que les modules AMD elgg et jQuery soient définis. Cela fournit un moyen simple de convertir de nombreux scripts en ligne pour utiliser require().

Du code en ligne échouera car la pile n’est pas encore chargée :

<script>
$(function () {
    // code using $ and elgg
});
</script>

Ceci devrait fonctionner dans Elgg 2.0 :

<script>
require(['elgg', 'jquery'], function (elgg, $) {
    $(function () {
        // code using $ and elgg
    });
});
</script>

Le formateur d’attributs supprime les clefs avec des tirets bas

elgg_format_attributes() (et toutes les API qui l’utilisent) filtrent désormais les attributs dont le nom contient un tiret baswordre (underscore). Toutefois, si l’attribut commence par data-, il ne sera pas supprimé.

Callbacks dans les Requêtes

Assurez-vous d’utiliser uniquement des valeurs appelables (callable) valides pour l’argument/les options de la fonction de rappel dans l’API.

Les fonctions de requête lanceront désormais une RuntimeException si is_callable() renvoie false comme valeur de la fonction de rappel donnée. Cela comprend des fonctions telles que elgg_get_entities(), get_data(), et bien d’autres encore.

Hook plugin des commentaires

Les plugins peuvent désormais renvoyer une chaîne vide à partir du hook 'comments',$entity_type afin de remplacer la vue du composant de commentaires par défaut. Pour forcer le composant de commentaires par défaut, votre plugin doit renvoyer false. Si vous utilisiez des chaînes vides pour forcer l’affichage des commentaires par défaut, vous devez mettre à jour vos gestionnaires de crochet pour qu’ils renvoient false.

Hook des permissions du conteneur

Le comportement du hook container_permissions_check a changé lorsqu’une entité est créée : avant 2.0, le hook était appelé deux fois si le conteneur de l’entité n’était pas le propriétaire. Lors du premier appel, le propriétaire de l’entité était transmis en tant que $params['container'], ce qui pouvait créer des confusion dans les gestionnaires.

Dans 2.0, lorsqu’une entité est créée dans un conteneur comme un groupe, si le propriétaire est le même que l’utilisateur connecté (ce qui est presque toujours le cas), cette première vérification est contournée. Ainsi, le hook container_permissions_check sera presque toujours appelé une seule fois avec $params['container'] comme conteneur correct de l’entité.

La création ou la suppression d’une relation déclenche un seul événement

Les événements de relation « create » et « delete » sont désormais déclenchés une seule fois, avec "relationship" comme type d’objet.

Par ex. Écouter l’événement "create", "member" ou "delete", "member" ne capturera plus les ajouts/suppressions d’appartenance au groupe. Utilisez les événements "create", "relationship" ou "delete", "relationship" events.

La fonction de discussion a été extraite des groupes vers son propre plugin

Le sous-type object, groupforumtopic a été remplacé par le sous-type object, discussion. Si votre plugin utilise ou modifie l’ancienne fonctionnalité de discussion, vous devez la mettre à niveau pour utiliser le nouveau sous-type.

Rien ne change du point de vue du propriétaire du groupe. La fonction de discussion est toujours disponible en tant qu’outil de groupe et toutes les discussions anciennes sont intactes.

Fonctionnalité de connexion via https abandonnée

Pour une meilleure sécurité et de meilleures performances, servez toutes les pages par HTTPS en changeant le schéma dans le wwwroot de votre site en https dans http://votresite.tld/admin/settings/advanced

Elgg a migré d’ext/mysql vers PDO MySQL

Elgg utilise désormais une connexion PDO_MYSQL et n’utilise plus de fonctions ext/mysql. Si vous utilisez les fonctions mysql_ *, en vous appuyant implicitement sur une connexion ouverte, celles-ci échoueront.

Si votre code utilise l’une des fonctions suivantes, lisez ce qui suit.

  • execute_delayed_write_query()

  • execute_delayed_read_query()

Si vous fournissez un objet $handler qui doit être appelé avec les résultats, votre gestionnaire recevra désormais un objet \Doctrine\DBAL\Driver\Statement. Auparavant, il s’agissait d’une ressource ext/mysql result.

L’ordre d’appel d’un événement/hook pourrait changer

Lors de l’inscription aux événements/hooks, le mot clé all pour la correspondance générique n’a plus aucun effet sur l’ordre dans lequel les gestionnaires sont appelés. Pour vous assurer que votre gestionnaire est appelé en dernier, vous devez lui donner la plus haute priorité de tous les gestionnaires correspondants, ou pour vous assurer que votre gestionnaire est appelé en premier, vous devez lui donner la plus faible priorité de tous les gestionnaires correspondants.

Si les gestionnaires ont été enregistrés avec la même priorité, ceux-ci sont appelés dans l’ordre où ils ont été enregistrés.

Pour émuler le comportement antérieur, les gestionnaires du noyau Elgg enregistrés avec le mot clé all ont été relevés en priorité. Certains de ces gestionnaires seront très probablement appelés dans un ordre différent.

Les URL export/ ne sont plus disponibles

Elgg ne prend plus en charge ce point de terminaison pour exposer les données de ressources.

Icônes migrés vers Font Awesome

Les sprites d’Elgg et la plupart des classes CSS commençant par elgg-icon- ont été supprimées.

L’utilisation de elgg_view_icon() est rétro-compatible, mais le HTML statique utilisant les classes elgg-icon devra être mis à jour vers le nouveau balisage.

Augmentation de la valeur de l’index z dans la classe elgg-menu-site

La valeur de l’index z dans la classe elgg-menu-site est passée de 1 à 50 pour permettre aux éléments de page de la zone de contenu d’utiliser la propriété z-index sans que le menu du site « Plus » (More) ne s’affiche derrière ces éléments. Si votre plugin/thème remplace la classe elgg-menu-site ou les vues/default/elements/navigation.css veuillez ajuster la valeur de z-index dans votre fichier CSS modifié en conséquence.

vue input/autocomplete

Les plugins qui remplacent la vue input/autocomplete devront inclure l’URL source dans l’attribut data-source de l’élément d’entrée, exiger le nouveau module AMD elgg/autocomplete et appeler sa méthode init. La bibliothèque javascript 1.x elgg.autocomplete n’est plus utilisée.

Introduction d’une bibliothèque tierce pour l’envoi de courriels

Nous utilisons l’excellente bibliothèque Zend\Mail pour envoyer des courriels dans Elgg 2.0. Il y a probablement des cas particuliers que la bibliothèque gère différemment de Elgg 1.x. Prenez soin de tester attentivement vos notifications par e-mail lors de la mise à niveau vers 2.0.

Éléments d’étiquetage

Les vues suivantes ont reçu des éléments label autour de certains des champs d’entrée. Si votre plugin/thème remplace ces vues, veuillez vérifier le nouveau contenu.

  • views/default/core/river/filter.php

  • views/default/forms/admin/plugins/filter.php

  • views/default/forms/admin/plugins/sort.php

  • views/default/forms/login.php

Plugin Aalborg Theme

La vue page/elements/navbar utilise désormais une icône Font Awesome pour le sélecteur de menu mobile au lieu d’une image. L’image bars.png et la prise en charge de CSS pour le rendu 1.12 ont été supprimées, aussi mettez à jour votre thème en conséquence.

Plugin Likes

Les objets ne peuvent plus être aimés (« likés ») par défaut. Pour qu’ils puissent être aimés, vous pouvez enregistrer un gestionnaire pour permettre l’annotation, ou plus simplement vous inscrire au hook ["likes:is_likable",<type>" :<subtype>"] et renvoyer true. Par ex.

elgg_register_plugin_hook_handler('likes:is_likable', 'object:mysubtype', 'Elgg\Values::getTrue');

Tout comme auparavant, le hook permissions_check:annotated est toujours appelé et peut être utilisé pour remplacer le comportement par défaut.

Plugin Messages

Si vous avez supprimé ou remplacé la fonction de gestionnaire messages_notifier pour masquer/modifier l’icône de la boîte de réception, vous devrez plutôt le faire de même pour le gestionnaire de menu de la barre supérieure (topbar) messages_register_topbar. messages_notifier n’est plus utilisé pour ajouter le lien de menu.

Les messages ne recevront plus les métadonnées “msg” pour les messages nouvellement créés. Cela signifie que vous ne pouvez plus compter sur ces métadonnées.

Plugin Blog

Les pages de blog qui affichent les articles “Mine” (Moi) ou “Friends” (Contacts) ont été modifiés pour lister tous les articles de blog appartenant aux utilisateurs (y compris ceux créés dans les groupes).

Plugin Bookmarks

Les pages des signets qui affichent les listes de signets “Mine” (Moi) ou “Friends” (Contacts) ont été modifiées pour lister tous les signets appartenant aux utilisateurs (y compris ceux créés dans les groupes).

Plugin File

Les pages de fichiers qui affichent les listes de fichiers “Mine” (Moi) ou “Friends” (Contacts) ont été modifiées pour lister tous les fichiers appartenant aux utilisateurs (y compris ceux créés dans les groupes).

Classes supprimées

  • ElggInspector

  • Notable

  • FilePluginFile: remplacez par ElggFile (ou chargez avec get_entity())

Clefs retirées disponibles via elgg_get_config()

  • allowed_ajax_views

  • dataroot_in_settings

  • externals

  • externals_map

  • i18n_loaded_from_cache

  • language_paths

  • pagesetupdone

  • registered_tag_metadata_names

  • simplecache_enabled_in_settings

  • translations

  • viewpath

  • views

  • view_path

  • viewtype

  • wordblacklist

Notez également que les plugins ne devraient pas accéder à la variable globale $CONFIG à l’exception de settings.php.

Fonctions supprimées

  • blog_get_page_content_friends

  • blog_get_page_content_read

  • count_unread_messages()

  • delete_entities()

  • delete_object_entity()

  • delete_user_entity()

  • elgg_get_view_location()

  • elgg_validate_action_url()

  • execute_delayed_query()

  • extend_view()

  • get_db_error()

  • get_db_link()

  • get_entities()

  • get_entities_from_access_id()

  • get_entities_from_access_collection()

  • get_entities_from_annotations()

  • get_entities_from_metadata()

  • get_entities_from_metadata_multi()

  • get_entities_from_relationship()

  • get_filetype_cloud()

  • get_library_files()

  • get_views()

  • is_ip_in_array()

  • list_entities()

  • list_entities_from_annotations()

  • list_group_search()

  • list_registered_entities()

  • list_user_search()

  • load_plugins()

  • menu_item()

  • make_register_object()

  • mysql_*(): Elgg n’utilise plus ext/mysql

  • remove_blacklist()

  • search_for_group()

  • search_for_object()

  • search_for_site()

  • search_for_user()

  • search_list_objects_by_name()

  • search_list_groups_by_name()

  • search_list_users_by_name()

  • set_template_handler()

  • test_ip()

Méthodes supprimées

  • ElggCache::set_variable()

  • ElggCache::get_variable()

  • ElggData::initialise_attributes()

  • ElggData::getObjectOwnerGUID()

  • ElggDiskFilestore::make_directory_root()

  • ElggDiskFilestore::make_file_matrix()

  • ElggDiskFilestore::user_file_matrix()

  • ElggDiskFilestore::mb_str_split()

  • ElggEntity::clearMetadata()

  • ElggEntity::clearRelationships()

  • ElggEntity::clearAnnotations()

  • ElggEntity::getOwner()

  • ElggEntity::setContainer()

  • ElggEntity::getContainer()

  • ElggEntity::getIcon()

  • ElggEntity::setIcon()

  • ElggExtender::getOwner()

  • ElggFileCache::create_file()

  • ElggObject::addToSite(): la fonction parente est toujours disponible dans ElggEntity

  • ElggObject::getSites(): la focntion parente est toujours disponible dans ElggEntity

  • ElggSite::getCollections()

  • ElggUser::addToSite(): la fonction parente est toujours disponible dans ElggEntity

  • ElggUser::getCollections()

  • ElggUser::getOwner()

  • ElggUser::getSites(): la fonction parente est toujours disponible dans ElggEntity

  • ElggUser::listFriends()

  • ElggUser::listGroups()

  • ElggUser::removeFromSite(): la fonction parente est toujours disponible dans ElggEntity

Les arguments suivants ont également été abandonnés :

  • ElggSite::getMembers() - 2: $offset

  • elgg_view_entity_list() - 3: $offset - 4: $limit - 5: $full_view - 6: $list_type_toggle - 7: $pagination

Actions supprimées

  • widgets/upgrade

Vues supprimées

  • forms/admin/plugins/change_state

Variables des vues supprimées

Pendant le rendu, le système de vue ne les injecte plus dans le champ (scope) :

  • $vars['url']: remplacé par elgg_get_site_url()

  • $vars['user']: remplacé par elgg_get_logged_in_user_entity()

  • $vars['config']: utilisez elgg_get_config() et elgg_set_config()

  • $vars['config']: utilisez elgg_get_config() et elgg_set_config()

Plusieurs solutions de contournement pour des vues très anciennes ne sont plus effectuées. Effectuez ces modifications :

  • Définissez $vars['full_view'] au lieu de $vars['full'].

  • Définissez $vars['name'] au lieu de $vars['internalname'].

  • Définissez $vars['id'] au lieu de $vars['internalid'].

Bibliothèques supprimées

  • elgg:markdown : Elgg ne fournit plus d’implémentation de balisage (markdown). Vous devez fournir la vôtre.

Spécifier des Vues via les propriétés

La métadonnée $entity->view ne spécifie plus la vue utilisée pour l’affichage dans elgg_view_entity().

De même, la propriété $annotation->view n’a plus d’effet dans elgg_view_annotation().

Le type de vue est statique après l’appel initial elgg_get_viewtype()

elgg_set_viewtype() doit être utilisé pour définir le type de vue au moment de l’exécution. Bien que Elgg vérifie toujours l’entrée view et $CONFIG->view initialement, cela n’est fait qu’une fois par requête.

Dépréciation

Il est déprécié de lire ou d’écrire les clef de métadonnées commençant par les filestore:: sur les objets ElggFile. Dans Elgg 3.0, ces métadonnées seront supprimées si elles indiquent le chemin d’accès racine des données actuel, aussi peu d’objets de fichiers devraient l’avoir. Les plugins ne doivent utiliser ElggFile::setFilestore que si les fichiers doivent être stockés dans un emplacement personnalisé.

Note

Ce n’est pas la seule dépréciation dans Elgg 2.0. Les développeurs de plugins devraient regarder leurs journaux d’erreurs de site.

De 1.10 à 1.11

Mise en surbrillance des commentaires

Si votre thème utilise le fichier views/default/css/elements/components.php, vous devez y ajouter les définitions de style suivantes pour activer la mise en surbrillance pour les commentaires et les réponses de discussion :

.elgg-comments .elgg-state-highlight {
        -webkit-animation: comment-highlight 5s;
        animation: comment-highlight 5s;
}
@-webkit-keyframes comment-highlight {
        from {background: #dff2ff;}
        to {background: white;}
}
@keyframes comment-highlight {
        from {background: #dff2ff;}
        to {background: white;}
}

De 1.9 à 1.10

Chargements de fichier

Si votre plugin utilise un bout de code copié à partir de l’action file/upload pour corriger les types mime détectés pour les formats zippés Microsoft, ce bout de code peut maintenant être supprimé en toute sécurité.

Si votre action de téléchargement effectue d’autres manipulations sur le type mime détecté et les types simples, il est recommandé de faire usage des hooks plugin disponibles :

  • 'mime_type','file' pour filtrer les types mime détectés

  • 'simple_type','file' pour filtrer les types simples analysés

De 1.8 à 1.9

Dans les exemples, nous mettons à niveau un plugin imaginaire Photos.

Seuls les changements de clefs sont inclus. Par exemple, certaines des fonctions dépréciées ne sont pas mentionnées ici séparément.

Chaque section comprendra des informations sur la compatibilité arrière avec Elgg 1.8.

Le fichier manifest.xml

Aucun changement n’est nécessaire si votre plugin est compatible avec 1.8.

Il est toutefois recommandé d’ajouter l’étiquette <id>. Sa valeur devrait être le nom du répertoire du plugin à l’intérieur du répertoire mod/.

Si vous effectuez des modifications qui cassent la compatibilité arrière (BC pour Backward Compatibility), vous devez mettre à jour les versions du plugin et de Elgg requises.

Exemple d’ancienne version (raccourcie) :

<?xml version="1.0" encoding="UTF-8"?>
<plugin_manifest xmlns="http://www.elgg.org/plugin_manifest/1.8">
    <name>Photos</name>
    <author>John Doe</author>
    <version>1.0</version>
    <description>Adds possibility to upload photos and arrange them into albums.</description>
    <requires>
        <type>elgg_release</type>
        <version>1.8</version>
    </requires>
</plugin_manifest>

Exemple de nouvelle version (raccourcie) :

<?xml version="1.0" encoding="UTF-8"?>
<plugin_manifest xmlns="http://www.elgg.org/plugin_manifest/1.8">
    <name>Photos</name>
    <id>photos</id>
    <author>John Doe</author>
    <version>2.0</version>
    <description>Adds possibility to upload photos and arrange them into albums.</description>
    <requires>
        <type>elgg_release</type>
        <version>1.9</version>
    </requires>
</plugin_manifest>

$CONFIG et $vars[“config”]

La variable mondiale $CONFIG et le paramètre $vars ['config'] ont été dépréciés. Ils devraient être remplacés par la fonction elgg_get_config().

Exemple d’ancien code :

// Using the global $CONFIG variable:
global $CONFIG;
$plugins_path = $CONFIG->plugins_path

// Using the $vars view parameter:
$plugins_path = $vars['plugins_path'];

Exemple de nouveau code :

$plugins_path = elgg_get_config('plugins_path');

Note

Compatible avec 1.8

Note

Voyez comment le plugin community_plugins a été mis à jour : https://github.com/Elgg/community_plugins/commit/f233999bbd1478a200ee783679c2e2897c9a0483

Fichiers de langues

Dans Elgg 1.8, les fichiers linguistiques devaient utiliser la fonction add_translation(). En 1.9, il suffit de simplement renvoyer le tableau qui a été précédemment passé à la fonction en tant que paramètre. Le noyau Elgg utilisera le nom du fichier (par exemple fr.php) pour déterminer quelle langue contient le fichier.

Exemple d’ancienne manière de faire dans languages/en.php:

$english = array(
    'photos:all' => 'All photos',
);
add_translation('en', $english);

Exemple de nouvelle manière de faire :

return array(
    'photos:all' => 'All photos',
);

Avertissement

Non compatible avec 1.8

Notifications

L’un des plus grands changements dans Elgg 1.9 est le système de notifications. Le nouveau système offre une manière plus flexible et évolutive d’envoyer des notifications.

Exemple d’ancienne manière de faire :

function photos_init() {
    // Tell core that we want to send notifications about new photos
    register_notification_object('object', 'photo', elgg_echo('photo:new'));

    // Register a handler that creates the notification message
    elgg_register_plugin_hook_handler('notify:entity:message', 'object', 'photos_notify_message');
}

/**
 * Set the notification message body
 *
 * @param string $hook    Hook name
 * @param string $type    Hook type
 * @param string $message The current message body
 * @param array  $params  Parameters about the photo
 * @return string
 */
function photos_notify_message($hook, $type, $message, $params) {
    $entity = $params['entity'];
    $to_entity = $params['to_entity'];
    $method = $params['method'];
    if (elgg_instanceof($entity, 'object', 'photo')) {
        $descr = $entity->excerpt;
        $title = $entity->title;
        $owner = $entity->getOwnerEntity();
        return elgg_echo('photos:notification', array(
            $owner->name,
            $title,
            $descr,
            $entity->getURL()
        ));
    }
    return null;
}

Exemple de nouvelle manière de faire :

function photos_init() {
    elgg_register_notification_event('object', 'photo', array('create'));
    elgg_register_plugin_hook_handler('prepare', 'notification:publish:object:photo', 'photos_prepare_notification');
}

/**
 * Prepare a notification message about a new photo
 *
 * @param string                          $hook         Hook name
 * @param string                          $type         Hook type
 * @param Elgg_Notifications_Notification $notification The notification to prepare
 * @param array                           $params       Hook parameters
 * @return Elgg_Notifications_Notification
 */
function photos_prepare_notification($hook, $type, $notification, $params) {
    $entity = $params['event']->getObject();
    $owner = $params['event']->getActor();
    $recipient = $params['recipient'];
    $language = $params['language'];
    $method = $params['method'];

    // Title for the notification
    $notification->subject = elgg_echo('photos:notify:subject', array($entity->title), $language);

    // Message body for the notification
    $notification->body = elgg_echo('photos:notify:body', array(
        $owner->name,
        $entity->title,
        $entity->getExcerpt(),
        $entity->getURL()
    ), $language);

    // The summary text is used e.g. by the site_notifications plugin
    $notification->summary = elgg_echo('photos:notify:summary', array($entity->title), $language);

    return $notification;
}

Avertissement

Non compatible avec 1.8

Note

Voyez comment le plugin community_plugins a été mis à jour pour utliser le nouveau système : https://github.com/Elgg/community_plugins/commit/bfa356cfe8fb99ebbca4109a1b8a1383b70ff123

Les notifications peuvent aussi être envoyées par la fonction notify_user().

Il a toutefois été mis à jour pour prendre en charge trois nouveaux paramètres optionnels passés à l’intérieur d’un tableau comme cinquième paramètre.

Les paramètres donnent aux plugins de notification plus de contrôle sur les notifications, de sorte qu’ils doivent être inclus dans la mesure du possible. Par exemple, le plugin site_notifications ne fonctionnera pas correctement si les paramètres sont manquants.

Paramètres :

  • object L’objet pour lequel nous envoyons une notification (par ex. ElggEntity ou ElggAnnotation). Ceci est nécessaire pour que les plugins de notification puissent fournir un lien vers l’objet.

  • action Chaîne qui décrit l’action qui a déclenché la notification (par ex. « create », « update », etc.).

  • summary Chaîne qui contient un résumé de la notification. (Elle devrait être plus informative que le sujet de notification, mais moins informative que le corps de la notification.)

Exemple d’ancienne manière de faire :

// Notify $owner that $user has added a $rating to an $entity created by him

$subject = elgg_echo('rating:notify:subject');
$body = elgg_echo('rating:notify:body', array(
        $owner->name,
        $user->name,
        $entity->title,
        $entity->getURL(),
));

notify_user($owner->guid,
                        $user->guid,
                        $subject,
                        $body
                );

Exemple de nouvelle manière de faire :

// Notify $owner that $user has added a $rating to an $entity created by him

$subject = elgg_echo('rating:notify:subject');
$summary = elgg_echo('rating:notify:summary', array($entity->title));
$body = elgg_echo('rating:notify:body', array(
        $owner->name,
        $user->name,
        $entity->title,
        $entity->getURL(),
));

$params = array(
        'object' => $rating,
        'action' => 'create',
        'summary' => $summary,
);

notify_user($owner->guid,
                        $user->guid,
                        $subject,
                        $body,
                        $params
                );

Note

Compatible avec 1.8

Ajout d’éléments à la liste des Activités

add_to_river('river/object/photo/create', 'create', $user_guid, $photo_guid);

elgg_create_river_item(array(
    'view' => 'river/object/photo/create',
    'action_type' => 'create',
    'subject_guid' => $user_guid,
    'object_guid' => $photo_guid,
));

Vous pouvez également ajouter le paramètre facultatif target_guid qui indique la cible de l’action create.

Si la photo avait été ajoutée par exemple dans un album photo, nous pourrions l’ajouter en passant aussi :

'target_guid' => $album_guid,

Avertissement

Non compatible avec 1.8

Gestionnaires d’URL des entités

La fonction elgg_register_entity_url_handler() a été dépréciée. Dans 1.9, vous devez utiliser le hook plugin 'entity:url', 'object'.

Exemple d’ancienne manière de faire :

/**
 * Initialize the photo plugin
 */
my_plugin_init() {
    elgg_register_entity_url_handler('object', 'photo', 'photo_url_handler');
}

/**
 * Returns the URL from a photo entity
 *
 * @param ElggEntity $entity
 * @return string
 */
function photo_url_handler($entity) {
    return "photo/view/{$entity->guid}";
}

Exemple de nouvelle manière de faire :

/**
 * Initialize the photo plugin
 */
my_plugin_init() {
    elgg_register_plugin_hook_handler('entity:url', 'object', 'photo_url_handler');
}

/**
 * Returns the URL from a photo entity
 *
 * @param string $hook   'entity:url'
 * @param string $type   'object'
 * @param string $url    The current URL
 * @param array  $params Hook parameters
 * @return string
 */
function photo_url_handler($hook, $type, $url, $params) {
    $entity = $params['entity'];

    // Check that the entity is a photo object
    if ($entity->getSubtype() !== 'photo') {
        // This is not a photo object, so there's no need to go further
        return;
    }

    return "photo/view/{$entity->guid}";
}

Avertissement

Non compatible avec 1.8

Web services

Dans Elgg 1.8, l’API des services Web a été incluse dans le noyau et les méthodes ont été exposées à l’aide de expose_function(). Pour activer la même fonctionnalité pour Elgg 1.9, activez le plugin Web services 1.9 et remplacez tous les appels à expose_function() par elgg_ws_expose_function().

1.7 vers 1.8

Elgg 1.8 est le plus grand bond en avant dans le développement d’Elgg depuis la version 1.0. Pour cette raison, cela demande plus de travail pour mettre à jour le noyau et les plugins qu’avec les mises à niveau précédentes. Il y a eu un petit nombre de changements d’API et, suivant notre pratique standard, les méthodes que nous avons dépréciées ont été mises à jour pour travailler avec la nouvelle API. Les plus grands changements sont dans la normalisation des plugins et dans le système de vues.

Mettre à niveau le cœur

Supprimez les répertoire du noyau suivants (même niveau que _graphics et engine) :

  • _css

  • account

  • admin

  • dashboard

  • entities

  • friends

  • search

  • settings

  • simplecache

  • views

Avertissement

Si vous ne supprimez pas ces répertoires avant une mise à niveau, vous allez avoir des ennuis !

Mettre à niveau les plugins

Utilisez le routage standard avec vos gestionnaires de pages

  • Tout : /page_handler/all

  • Publications de l’utilisateur : /page_handler/owner/:username

  • Publications des contacts de l’utilisateur : /page_handler/friends/:username

  • Entité seule : /page_handler/view/:guid/:title

  • Ajout : /page_handler/add/:container_guid

  • Modification : /page_handler/edit/:guid

  • Liste du groupe : /page_handler/group/:guid/all

Inclure des scripts de gestionnaire de page à partir du gestionnaire de page

Presque tous les gestionnaires de page doivent avoir un script de gestionnaire de page. (Exemple : bookmarks/all => mod/bookmarks/pages/bookmarks/all.php)

  • Appelez set_input() pour les guids d’entité dans le gestionnaire de page et utilisez get_input() dans les scripts du gestionnaire de page.

  • Appelez gatekeeper() et admin_gatekeeper() dans la fonction du gestionnaire de page si nécessaire.

  • L’URL d’un groupe doit utiliser le script pages/:handler/owner.php.

  • Les gestionnaires de pages ne devraient pas contenir de HTML.

  • Mettez à jour les URL dans tout le plugin. (N’oubliez pas d’enlever /pg/ !)

Utilisez les gestionnaires de pages standardisés et les scripts

  • Stockez les scripts du gestionnaire de page dans mod/:plugin/pages/:page_handler/:page_name.php

  • Utilisez la disposition de page de contenu dans les scripts du gestionnaire de pages :

    $content = elgg_view_layout('content', $options);

  • Les scripts de gestionnaires de pages ne devraient pas contenir de HTML.

  • Appelez elgg_push_breadcrumb() dans les scripts du gestionnaire de pages.

  • Pas besoin de définir le propriétaire de la page si les URLs sont au format standard.

  • Pour le contenu du groupe, vérifiez le conteneur container_guid en utilisant elgg_get_page_owner_entity().

La vue object/:subtype

  • Assurez-vous qu’il existe bien des vues pour $vars['full_view'] == true et $vars['full_view'] == false. $vars['full_view'] a remplacé $vars['full].

  • Vérifiez l’objet dans $vars['entity']. Utilisez elgg_instance_of() pour vous assurer qu’il s’agit du type d’entité que vous souhaitez.

  • Renvoyez true pour court-circuiter la vue si l’entité est manquante ou erronée.

  • Utilisez elgg_view('object/elements/summary', array('entity' => $entity)); et elgg_view_menu('entity', array('entity' => $entity)); pour faciliter le formatage. Vous devriez utiliser très peu de balisage dans ces vues.

Mettre à jour la structure de l’action

  • Fichiers d’action et noms d’action de l’espace de noms (exemple : mod/blog/actions/blog/save.php => action/blog/save)

  • Utilisez les URLs d’action suivantes :

    • Ajoutez : action/:plugin/save

    • Modifiez : action/:plugin/save

    • Suppression : action/:plugin/delete

  • Faites que l’action de suppression accepte action/:handler/delete?guid=:guid de sorte que le menu des métadonnées de l’entité ait la bonne URL par défaut.

Mettez à jour les fonctions obsolètes

  • Les fonctions dépréciées en 1.7 produiront des erreurs visibles en 1.8.

  • Vous pouvez également mettre à jour les fonctions dépréciées dans 1.8.

    • De nombreuses fonctions d’enregistrement ont simplement ajouté un préfixe elgg_ pour la cohérence, et devraient être faciles à mettre à jour.

    • Voyez /engine/lib/deprecated-1.8.php pour la liste complète.

    • Vous pouvez définir le niveau de débogage sur “warning” pour obtenir des rappels visuels des fonctions obsolètes.

Mettez à jour les vues widget

Voyez les widgets des plugins blog ou file pour des exemples.

Mettez à jour le module de profil de groupe

Utilisez les plugins blog ou file pour des exemples. Cela vous aidera à pouvoir appliquer un thème à votre plugin avec le nouveau framework CSS.

Mettre à jour les formulaires

  • Déplacez les corps de formulaire vers la vue forms/:action pour utiliser le nouveau elgg_view_form d’Evan.

  • Utilisez les vues d’entrée dans les corps de formulaire plutôt que du html. Cela aide à utiliser des thèmes et permet de préparer l’avenir.

  • Ajoutez une fonction qui prépare le formulaire (voyez mod/file/lib/file.php pour un exemple)

  • Rendre vos formulaires persistants (voir l’action de téléchargement du plugin file et la fonction de préparation du formulaire).

L’API des formulaires est discutée plus en détail dans Formulaires + Actions.

Nettoyez le CSS/HTML

Nous avons ajouté de nombreux modèles CSS au fichier CSS du noyau (modules, bloc avec une image, primitives d’espacement). Nous vous encourageons à utiliser ces modèles et ces classes dans la mesure du possible. Faire cela devrait :

  1. Réduire les coûts de maintenance, car vous pouvez supprimer la plupart des CSS personnalisés.

  2. Rendre votre plugin plus compatible avec les thèmes de la communauté.

Recherchez des modèles qui peuvent être déplacés dans le noyau si vous avez besoin de CSS significatif.

Nous utilisons des traits d’union plutôt que des soulignements dans les classes/ids et vous encourageons à faire de même pour maintenir la cohérence.

Si vous avez besoin de votre propre CSS, vous devez utiliser votre propre espace de noms, plutôt que elgg-.

Mettre à jour manifest.xml

  • Utilisez http://el.gg/manifest17to18 pour automatiser cette étape.

  • N’utilisez pas la catégorie bundled avec vos plugins. C’est réservés aux plugins distribués avec Elgg.

Mettez à jour les paramètres et les vues des paramètres utilisateur

  • La vue pour les paramètres est maintenant plugins/:plugin/settings (auparavant settings/:plugin/edit).

  • La vue pour les paramètres utilisateur est maintenant plugins/:plugin/usersettings (auparavant usersettings/:plugin/edit).