Recherche avancée

Sur d’autres sites (6024)

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  17 avril 2021

  Je suis bien d’accord avec le cahier des charges, mais je trouverais vraiment dommage de changer de représentation des fieldsets à la racine.

  Pour ces dernier je trouve que la représentation actuelle est de loin la plus simple, la plus claire et la plus élégante : un simple trait discret en séparation. Ça ne « coupe » pas la lecture, ou disons juste ce qu’il faut pour indiquer qu’on passe à une autre partie.
  Et c’est 100% des fieldsets utilisés dans la dist, si ça "pète" ceux-là pour s’accommoder d’éventuels fieldsets imbriqués qu’on ne rencontre quasiment que dans formidable, bof quand même.

  En revanche pour ceux imbriqués, oui je trouve qu’un trait de côté est une bonne solution, ça fonctionne bien sans trop alourdir, et ça montre bien le début et la fin. Peu importe les détails : bords arrondis ou pas, trait en haut ou pas, espèce d’angle droit ou pas comme sur les tests de rastapopoulos.
  Dans l’ensemble c’est le dernier test de nicod_ qui me semble la meilleure piste.

  MAIS (bruit de tonnerre)

  Pour montrer la fin des fieldsets à la racine, c’est la galère.
  À priori il suffit d’une bordure en bas, ok.
  Ça marche si le fieldset est suivi d’autre chose qu’un fieldset.

  Mais pas quand 2 fieldsets se suivent : ça fait 2 bordures successives avec un espace entre, c’est bancal.
  Il faudrait qu’ils soient "collés" avec une seule bordure partagée, mais j’ai aucune idée de comment faire. Il faudrait un sélecteur CSS "élément suivi de" qui n’existe pas.

• Révision 22269 : Retour sur r22264. En fait l’emplacement orginel de "interdire_scripts" provoque ...

  25 juin 2015, par esj -
  • la neutralisation inopportune des scripts introduits par le compilateur (bug corrigé par r22264) ;
    • l’altération des appels à des scripts introduits par un rédacteur, scripts q’il ne faut effectivement pas interpréter (cas du squelette nécessitant une double passe de PHP, cf. scénario possible sur http://article.gmane.org/gmane.comp.web.spip.devel/66397) mais cette stratégie brutale ne répond pas à l’intention d’un rédacteur qui s’attend à voir s’afficher le source de l’appel du script, pas le résultat de son exécution (je ne parle évidemment pas d’un rédacteur malveillant qui essaye d’exploiter une faille).

  A première vue la résolution correcte du 2e point nécessite de gros changements
  dans la stratégie de compilation adoptée depuis le début de SPIP.
  Il vaut mieux se donner le temps de la réflexion avant d’aller dans cette voie.
  Je remets le code antérieur par "svn merge -r -r22264:22263 ."
  pour ne pas laisser cette faille potentielle,
  en actant provisoirement que le premier bug doit être considéré comme une limitation de SPIP,
  savoir le fait qu’il n’est pas possible d’utiliser une balise produisant du PHP dans un argument de filtre.

• Introducing the Matomo Connector for Looker Studio (Formerly Google Data Studio)

  26 janvier 2024, par Erin — Community

  Explore Matomo data like never before with the official Matomo Connector for Looker Studio. Matomo users can now securely display accurate web analytics data in Looker Studio for free.

  Connect Matomo to Looker Studio (formerly known as Google Data Studio) in a few clicks and start building dashboards instantly. Get access to a range of data visualisation capabilities and chart types in Looker Studio’s easy-to-use interface. 

  Leave behind manual, error-prone spreadsheet entries and disparate data. With the Matomo Connector for Looker Studio, you get unified, automated reporting and interactive dashboards for faster insights and smoother collaboration.

  What sets the official Matomo Connector for Looker Studio apart ?

  Our open-source connector puts security first by providing a reliable connection without relying on third-party intermediaries. It’s free, with no hidden charges, and no limits on the number of users or Matomo instances. Connect as many instances as you need. 

  Plus, our Support team is here anytime you need help.

  

  Who is this connector made for ?

  The Matomo Connector for Looker Studio is a good fit for institutions and corporations using Looker Studio, NGOs handling multiple entities, marketing agencies with various clients, and small to medium-sized businesses with advanced data practices.

  When is this connector not the best fit ?

  If you prioritise privacy and compliance, this might not be the right fit. The Looker Studio app operates on Google servers, and while we don’t log or store any data, privacy considerations should be carefully evaluated. Transferring data, especially visitor data, to external platforms can have privacy implications.

  Getting started

  Check out our documentation for an easy setup.

  To help, we’ve also created a template report so you can visualise your Matomo data instantly.

  Here’s how to get started :

  1. Visit the demo template report in Looker Studio
  2. Click the more options button then Make a copy

  

  3. Click Create data source within the New Data Source dropdown.

  

  4. Connect your Matomo (Full Connection Guide)
  5. Select the API > Main Metrics report
  6. Click Connect and then Add to Report
  7. Click Copy Report to finalise

  For additional support, visit our Matomo Looker Studio forum or reach out to our Looker Studio support team via email at support-lookerstudio@matomo.org