Recherche avancée

Sur d’autres sites (6415)

• Help us to improve Piwik by sending anonymous usage data (and get usage data yourself)

  22 octobre 2015, par Thomas Steur — Community, Plugins

  At Piwik we have developed a new plugin named AnonymousPiwikUsageMeasurement. The opt-in and anonymised usage tracking information will be used by us to build a better product and a great user experience. The plugin can be installed via the Piwik Marketplace with just a few clicks in your Piwik installation. As a Super User simply go to the Administration and select Marketplace in the left menu. There you will find the plugin and can install it with just one click.

  The plugin allows you to track usage data into up to three Piwik installations :

  • demo-anonymous.piwik.org (enabled by default, can be disabled).
  • your own Piwik (can be configured optionally)
  • a custom Piwik (can be configured optionally)

  The usage data that is sent to Piwik can be publicly viewed by anyone under demo-anonymous.piwik.org.

  What are the advantages by tracking the data into my own installation ?

  You can see how your Piwik installation is used and how well your Piwik performs by checking the average generation time of pages and API calls. Use the Row Evolution feature to see how your Piwik is performing over time.

  What is Piwik doing to make sure the data is anonymized ?

  We are very careful in what we track and we make sure to anonymize data that could contain user data.

  • We overwrite the page title as the title could contain the name of the viewed website
  • We remove any referrer information
  • We replace URL paramaters with a predefined value apart from a few whitelisted ones to make sure no actual token_auth, CSRF token or user defined value will be tracked
  • On demo-anonymous.piwik.org 3 bytes of the IP are anonymised (eg when IP is 192.168.1.1 we track only 192.0.0.0). We do not track nor collect your location and provider information.
  • We do not track clicks on outlinks or downloads

  When should I not install this plugin ?

  If you have developed a custom Piwik plugin that contains for example the name of your business in any of the following names we recommend to not install this plugin as it might be tracked :

  • name of a plugin
  • name of a controller action
  • name of a report
  • name of a widget
  • name of an API method

  Plugins that are installed via the Marketplace should not pose a problem as their names don't contain any user specific information such as the name of your business.

  The data is tracked as efficiently as possible as to not slow down your Piwik server. If you already have some performance challenges with your Piwik, we recommend not to install this plugin.

  Which data is tracked ?

  When the plugin is activated, the following data will be tracked :

  • The pages and reports that are viewed
  • The visitors' software and devices data like the used browser and the resolution
  • Some clicks or interactions with certain selectors or buttons. For example we track an event when a segment is selected (but we do not track the actual segment name or value).
  • In a daily task we track the following data :
    • Piwik version
    • PHP version
    • Number of websites
    • Number of users
    • Number of segments
    • How often which API method was called (only plugin name and method name but no parameters) and how long the API calls took on average.

  Are there any prerequisites ?

  • If sending usage data to Piwik is enabled, the Piwik installation must be connected to the internet
  • If tracking to a custom Piwik installation is enabled, your Piwik installation and your Piwik users must be able to connect to this instance

  Where can I report any issues with the plugin ?

  If you experience any issues with the plugin please create a new issue. The source code is available under GPL v3+ on GitHub. We always appreciate pull requests and suggestions to improve this plugin.

• Evolution #4148 : Augmenter la largeur de l’espace privé

  13 juin 2018, par tcharlss (*´_ゝ｀)

  Super nicod_, merci pour les remarques et le boulot :)

  Alors concernant la largeur, 1200px ce serait déjà beaucoup mieux.
  Mais pour ma part je pense que du 100% serait toujours la meilleur option. Au début ça fait un peu bizarre je le concède, mais on s’y fait vite et c’est dur de revenir sur une largeur fixe après. Pour les tableaux / listes d’objets par exemple ça devient vite indispensable. Le menu ne me pose pas de problème non plus : on comprend que les items sont alignés à gauche.

  Il y a bien certains contenus qui doivent être limité en largeur pour avoir 80 caractères par ligne c’est vrai, mais il s’agit de quelques blocs à identifier, et ça reste valable quelque soit la largeur globale de l’interface.
  Pour l’instant je ne vois que 2 blocs concernés : le #wysiwyg et les formulaires d’édition.
  Donc mon constat c’est : à partir du moment où on limite la largeur de certains blocs qui contiennent du texte afin que ça reste lisible, pourquoi limiter arbitrairement la largeur globale de l’interface ?
  Dans le plugin privé fluide, seul le #wysiwyg est ciblé pour l’instant. Attention il reste aussi des petits problèmes à régler dans certains cas, cf. capture d’écran.

  Pour comparaison, avec RastaPopoulos on avait installé une floppée de CMS pour étudier leurs interfaces au moment où on s’intéressait au sujet, et ils ont tous une largeur 100%.
  Je ne dis pas qu’il faut suivre bêtement ce que font les autres, mais ça donne des exemples concrets de choix de layouts qui fonctionnent.

  Sur la question de rendre cette largeur configurable, je ne suis pas très chaud. C’est exactement pour ça que j’avais fait le plugin privé fluide dans mon coin alors qu’il existe déjà le plugin d’Ybbet : je pense que l’interface doit être d’office adaptée à tous les écrans, sans rien à configurer. Aucune envie d’avoir à configurer ça sur chaque nouvelle instance de SPIP qu’on déploie :p

  Du coup on écrivant tout ça, je verrais finalement la chose comme ça :

  • Largeur globale 100%
  • Supprimer carrément la préférence utilisateur « taille de l’écran »
  • Jusqu’à 1200px : 2 colonnes (#navigation + #extra | #contenu)
  • Au-delà : 3 colonnes (#navigation | #contenu | #extra)

  Du coup en écran large on aurait toujours 3 colonnes et ça équilibre un peu plus.
  Et plutôt que du flex, je pense qu’on pourrait partir directement sur du css grid, avec un bête fallback en float pour les vieux navigateurs.
  Parceque du coup je ne vois pas comment mettre la colonne #extra soit en dessous de #navigation, soit à droite de #contenu juste avec du flex.

• Anomalie #3260 (Nouveau) : Problème de dump sur les tables comportants des index de longueur spéci...

  28 août 2014, par b b

  Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=@476655#forum476655

  En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu’à spip_mysql_show_table() (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump).

  J’ai d’abord étudié ce qui se passe dans base_copier_table() de ecrire/base/dump.php :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536

  À ce niveau, dans $desc_source['key'] la longueur des index n’est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente.

  Du coup, j’en suis remonté à sql_showtable(), et plus précisemment à spip_mysql_show_table() :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754

  Depuis phpmyadmin, un SHOW CREATE TABLE renvoie bien ce qu’il faut, ex :

  CREATE TABLE `spip_gis` (
   `id_gis` bigint(21) NOT NULL AUTO_INCREMENT,
   `titre` text NOT NULL,
   `descriptif` text NOT NULL,
   `lat` double DEFAULT NULL,
   `lon` double DEFAULT NULL,
   `zoom` tinyint(4) DEFAULT NULL,
   `adresse` text NOT NULL,
   `pays` text NOT NULL,
   `code_pays` varchar(255) NOT NULL DEFAULT ’’,
   `region` text NOT NULL,
   `departement` text NOT NULL,
   `ville` text NOT NULL,
   `code_postal` varchar(255) NOT NULL DEFAULT ’’,
   PRIMARY KEY (`id_gis`),
   KEY `lat` (`lat`),
   KEY `lon` (`lon`),
   KEY `pays` (`pays`(500)),
   KEY `code_pays` (`code_pays`),
   KEY `region` (`region`(500)),
   KEY `ville` (`ville`(500)),
   KEY `code_postal` (`code_postal`),
   KEY `departement` (`departement`(500))
  ) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1
  

  Il semble que la regex de la ligne 736 ne match pas la table spip_gis certainement à cause des (500) :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736

  Et du coup, on bascule sur le plan B, qui ne fait qu’un simple SHOW COLUMNS FROM ne contenant pas l’information de longueur des index :

  http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765

  Wala où j’en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.