Recherche avancée

Médias (1)

Mot : - Tags -/berlin

Autres articles (111)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (12376)

  • How to track single-page websites and web applications using Piwik Analytics

    21 février 2017, par InnoCraft — Community, Development

    Single-page websites and web applications have become a standard over the last years. Getting the tracking of such websites and apps right is crucial to your success as you need to ensure the measured data is meaningful and correct. That’s why we, at InnoCraft, help our clients setting up their web tracking and measurement strategy. Some challenges our clients face are the tracking of single-page websites and web applications. We will cover this challenge in this post with a complete example at the bottom.

    Embedding the Tracking Code

    First you need to embed your JavaScript tracking code into your single-page website or web application as usual. To do this go to “Administration” in the top right in your Piwik, click on “Tracking Code” and adjust the tracking code to your needs.

    Tracking a New Page View

    The challenge begins when you need to track a new page view. A single-page app is different from a usual website as there is no regular new page load and Piwik cannot detect automatically when a new page is viewed. This means you need to let Piwik know whenever the URL and the page title changes. You can do this using the methods setCustomUrl and setDocumentTitle like this :

    window.addEventListener('hashchange', function() {
           _paq.push(['setCustomUrl', '/' + window.location.hash.substr(1)']);
           _paq.push(['setDocumentTitle', 'My New Title']);
           _paq.push(['trackPageView']);
    }

    Resetting previously set custom variables

    If you have set any Custom Variables in scope “page”, you need to make sure to delete these custom variables again as they would be attributed to the new page view as well otherwise. The following code requires Piwik 3.0.2 :

    _paq.push(['deleteCustomVariables', 'page']);      
    _paq.push(['trackPageView']);

    Updating the generation time

    Next you need to update the generation time before tracking a new page view. Otherwise, the initial page generation time will be attributed to all of your subsequent pageviews.

    If you don’t load new content from the server when the page changes, simply set the value to zero :

    _paq.push(['setGenerationTimeMs', 0]);
    _paq.push(['trackPageView']);

    In case you load new content from the server, we recommend to measure the time it took to load this content (in milliseconds) and set the needed time :

    _paq.push(['setGenerationTimeMs', timeItTookToLoadPage]);
    _paq.push(['trackPageView']);

    Updating the referrer

    Depending on whether you want to track the previous page as a referrer for the new page view, you should update the referrer URL by setting it to the previous page URL :

    _paq.push(['setReferrerUrl', previousPageUrl]);
    _paq.push(['trackPageView']);

    Making Piwik Aware of New Content

    When you show a new page, your single-page DOM might change as well. For example, you might replace parts of your page with new content that you loaded from your server via Ajax. This means you need to instruct Piwik to scan the DOM for new content. We’ll now go over various content types (Videos & Audio, Forms, Links and Downloads, Content tracking).

    Video and Audio tracking

    If you use the Media Analytics feature to track your videos and audios, whenever a new page is displayed you need to call the following method :

    _paq.push(['MediaAnalytics::scanForMedia', documentOrElement]);

    When you don’t pass any parameter, it will scan the entire DOM for new media. Alternatively, you can pass an element to scan only a certain area of your website or app for new media.

    Form tracking

    If you use the Form Analytics feature to measure the performance of your online forms, whenever a new page is displayed you need to call the following method :

    _paq.push(['FormAnalytics::scanForForms', docuemntOrElement]);

    Where documentOrElement points either to document to re-scan the entire DOM (the default when no parameter is set) or you can pass an element to restrict the re-scan to a specific area.

    Link tracking

    Supposing that you use the link tracking feature to measure outlinks and downloads, Piwik needs to re-scan the entire DOM for newly added links whenever your DOM changes. To make sure Piwik will track such links, call this method :

    _paq.push(['enableLinkTracking']);

    Content tracking

    If you use the Content Tracking feature, whenever a new page is displayed and some parts of your DOM changes, you need to call this method :

    _paq.push(['trackContentImpressionsWithinNode', documentOrElement]);

    Where documentOrElement points either to document or an element similar to the other methods. Piwik will then scan the page for newly added content blocks.

    Measuring Single-Page Apps : Complete Example

    In this example we show how everything works together assuming you want to track a new page whenever a hash changes :

    var currentUrl = location.href;
    window.addEventListener('hashchange', function() {
       _paq.push(['setReferrerUrl', currentUrl]);
        currentUrl = '' + window.location.hash.substr(1);
       _paq.push(['setCustomUrl', currentUrl]);
       _paq.push(['setDocumentTitle', 'My New Title']);

       // remove all previously assigned custom variables, requires Piwik 3.0.2
       _paq.push(['deleteCustomVariables', 'page']);
       _paq.push(['setGenerationTimeMs', 0]);
       _paq.push(['trackPageView']);
       
       // make Piwik aware of newly added content
       var content = document.getElementById('content');
       _paq.push(['MediaAnalytics::scanForMedia', content]);
       _paq.push(['FormAnalytics::scanForForms', content]);
       _paq.push(['trackContentImpressionsWithinNode', content]);
       _paq.push(['enableLinkTracking']);
    });

    Questions ?

    If you have any questions or need help, please get in touch with us. You can find more information about the Piwik JavaScript tracker on the Piwik Developer Zone.

  • Anomalie #3017 : Gestion des versions de plugins

    18 avril 2020, par RastaPopoulos ♥

    Je passe ce ticket en anomalie, car il s’agit à mon sens très clairement d’un bug (et un gros) : l’ergonomie aussi peut être buguée.

    Récemment, en peu de temps, plusieurs plugins ont eu des problèmes car les utilisateurs ont eu l’invitation de migrer à la dernière version alors qu’il y avait un saut de branche majeure (le X), sans aucun message de warning nulle part : spipr, saisies, prix… Et cela occasionne clairement des gros problèmes pour les gens, et donc bien du bug. Et encore, il ne s’agissait pas de mises à jour modifiant la base de données… là impossible même de revenir en arrière.

    Je pense qu’il faut profiter de ce ticket déjà existant, pour réaffirmer que c’est un bug et réfléchir à une ergonomie cohérente quelque soit les différents endroits : liste des plugins et icône-bouton d’annonce de mise à jour, recherche des plugins et comment on voit les différentes versions, etc.

    Je décris en texte, on verra si j’ai le temps de faire une maquette un jour…

    Vue des plugins actifs :

    C’est le cas le plus courant qui peut casser des choses chez les gens.
    - L’indication de mise à jour classique ne devrait s’afficher que pour les mises à jour Y et Z
    - Éventuellement un autre bouton différent indiquerait qu’il y a une mise à jour majeure X
    - Les mises à jour quelles qu’elles soient (mineures ou majeures) ne devraient se voir que si l’état est aussi stable ou plus stable que l’actuel (c’est déjà le cas je crois)
    - Parfois dans les releases il y a une mise à jour dans la même branche X et une autre changeant de X, dans ce cas on verrait bien deux indications et deux boutons différents
    - Une option générale de SVP pourrait permettre de choisir si on signale les mises à jour majeure ou pas (si non, seules Y et Z seront signalées)
    - Lorsqu’on choisit de mettre à jour à une version majeure supérieure, alors il devrait y avoir un méchant message ATTENTION, indiquant ce qu’on s’apprête à faire, ce qui permet d’annuler. Dans la phrase indiquant cela, il pourrait y avoir un lien vers la doc de la version majeure supérieure qu’on s’apprête à mettre. (Attention, vous allez changer la version majeure du plugin Patates en 3.3.3. Pensez à vérifier que cela ne va pas casser votre site : lien vers la doc)
    - Pour les actions de masse, pareil, ça devrait afficher les mêmes messages, mais plusieurs à la fois dans la même boite.

    Au passage : comme on le voit, parfois il est possible qu’on ait besoin d’ajouter des actions supplémentaires aux plugins. Il serait sûrement profitable de revoir une organisation cohérente des boutons comme discuté dans ce ticket : #4429 (et non pas certains en picto, certains en hover, etc). Notamment aussi car c’est toujours mieux quand on arrive à avoir des labels (d’autant plus si on doit différencier mise à jour mineure et majeure).

    Vue des plugins présents inactifs :

    On ne parle ici que des plugins non actifs ayant déjà une version activée (les autres on s’en fiche, ya rien à dire c’est une installation classique). Si on les a téléchargé et que c’est bien compat avec la version SPIP générale, on doit toujours les voir, seuls les obsolètes sont cachés par défaut.

    - Si dans les inactifs il y a une version supérieure mais mineure d’un plugin déjà actif, on le voit et on peut l’activer et aucun message particulier
    - S’il y a une version supérieure majeure d’un plugin déjà actif, on doit le voir aussi mais dans son cadre, il pourrait déjà y avoir une indication que ce plugin est déjà en cours d’utilisation et que cette version est un changement majeur. Et ensuite quand on essaye de l’activer, on devrait avoir le même message ATTENTION que décrit précédemment dans la boite qui s’ouvre.
    - Contrairement au premier onglet, là on doit voir aussi les versions même si l’état est moins stable (si ya un "test" alors que celui actif est "stable") : si on l’a téléchargé c’est qu’on veut le voir et pouvoir l’activer
    - On ne voit pas les versions plus petites que celles actives, car certaines plugins ont des structures de base, et là ça peut pas marcher de revenir en arrière. Celles là sont cachées si une version plus haute est active, mais on les voit si jamais installé par contre.

    Recherche des plugins :

    Actuellement l’interface ne montre que la dernière version, ce qui ne va pas du tout. De plus quand un plugin est déjà installé, ce plugin sort bien dans les résultats de recherche (avec "déjà installé") mais impossible de le télécharger même si la version indiquée dans la recherche est supérieure à celle en cours.

    Pour cet onglet, c’est plus que des corrections, il faudrait vraiment refaire pour voir au moins la dernière version de chaque X (voire de chaque X.Y) de chaque plugin. Que ce soit pour des plugins qu’on a pas du tout et pour des plugins déjà installés.

    Si j’ai le plugin Patates 3.13.0 installé, et qu’il a plusieurs mises à jour de plusieurs branches, alors dans la recherche je devrais voir :
    - La version 4.0.2 (avec un Attention)
    - La version 3.15.1
    - La version 3.13.4

    Si le plugin n’est pas du tout installé (et n’a jamais été installé ou a été bien désinstallé, bref : qu’il n’a plus son "base_version" du tout !) alors on devrait voir plus, et voir aussi la 2.4.5 etc, si on sait qu’on veut installer telle plus vieille version.

    On pourrait voir un bloc par plugin, et à l’intérieur, au lieu d’une seule case à cocher, sous le titre et slogan, on aurait une liste des versions, chacune avec sa case à cocher.

  • Evolution #4727 (Nouveau) : Des pictos / icônes symboliques pour tout le monde

    12 avril 2021

    Je fais un ticket pour la future PR et poser le plan d’action.
    C’est la suite de https://core.spip.net/issues/4562#Des-ic%C3%B4nes

    Proposition pour intégrer un jeu complet d’icônes symboliques.

    Les besoins sont multiples pour pleins d’éléments d’interface, dans le core et les plugins : des barres d’outils, des boutons d’actions, etc.
    Et chacun doit réimplémenter ça un peu à sa sauce, notamment dans le privé.

    C’est un besoin bien distinct des icônes svg de couleur dont on dispose actuellement dans le privé : on veut des pictos symboliques qui héritent de taille et de la couleur du texte, et issus d’un même set afin d’avoir un style unifié.
    Cela vient donc en complément.

    Il s’agit donc de reprendre un jeu d’icônes existant, qu’on n’aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes. Cf. plus bas pour une comparaison initiale des candidats possibles.

    Utilisation

    Ces icônes seraient utilisables de 2 façons :

    1) Des classes .spicon

    Des classes à ajouter à n’importe quel élément inline quand il s’agit d’icônes purement décoratives.
    Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose la contraption de spip + icon = spicon. Il y a aussi spip-icon mais c’est un peu plus verbeux.

    Exemples :

    <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_menu</span><span class="delimiter">"</span></span><span class="tag">></span>Ouvrir le menu<span class="tag"></span>
    <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_truc</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Du texte
    <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">titrem spicon_machin</span><span class="delimiter">"</span></span><span class="tag">></span>Mon titre<span class="tag"></span>
    </span></span></span></span>

    2) Une balise #ICON

    En complément, on peut vouloir embarquer une icône svg dans le HTML.

    On propose de reprendre et d’adapter la balise #ICON du plugin Zcore, qui fait ça très bien.
    Cette balise permet d’embarquer une icône du set par défaut, mais également n’importe quelle autre (je rentre pas dans les détails).

    Un modèle correspondant permettra aussi d’inclure des icônes svg dans les textes :

    <span class="CodeRay">
    #ICONE{identifiant}
    #ICONE{chemin/vers/mon_icone.svg}
    #ICONE{#identifiant_autre_set}
    </span>

    Identifiants sémantiques

    Les identifiants des icônes seront directement ceux du jeu d’icônes choisi.
    Mais ils peuvent avoir des noms un peu barbares : chevron-double-right, eye-slash, grip-vertical, etc.

    Dans tous les cas on pourra les utiliser tels quels, mais en plus de ça, on propose de faire une correspondance sémantique pour les icônes correspondants aux actions les plus courantes. Par exemple au lieu de faire #ICONE{chevron-double-down} on pourra faire #ICONE{deplier}.
    Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins.

    La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both

    Ressources privé / public

    Cela veut dire 2 ressources à charger :

    • Une font-face pour les classes
    • Un sprite svg pour la balise

    Dans le privé, il faut charger les 2.
    Dans le public, cela pourrait se faire optionnellement, à la demande.

    Candidats

    Pour finir un tableau comparatif des jeux d’icônes possibles (à licences libres), avec mes commentaires initiaux.
    Petite préférence pour Feather actuellement.

    Lib Nb sprite fontface Commentaire
    Bootstrap 1300+ 693ko 85ko Clés en main, beaucoup d’icônes (trop ?)
    Feather 286 ( 100ko) - Styles rounded. Bonne balance nb icônes / poids.
    Octicon (Github) 433 ( 240ko) - Styles rounded. Bonne balance nb icônes / poids. Beaucoup de manips à faire pour créer sprite et cie.
    Material (Google)  ? (?ko) 44ko Style rounded / épaisseur variable. Beaucoup de manips à faire pour créer sprite et cie. Google !
    Core-ui 554 418ko 63ko Clés en main. Sets inutiles non pris en compte dans ce tableau (brands, flags, …)
    Bytesize 101 11ko - Style rounded / épaisseur variable. Léger : le minimum syndical.

    Sprite entre parenthèses = non fourni dans le dépôt ou la dist → poids théorique.