Recherche avancée

Sur d’autres sites (9038)

• Announcing Piwik will end PHP 5.3 support in six months (May 2015)

  20 octobre 2014, par Piwik Core Team — Community

  This post is an important announcement concerning all Piwik users who are using PHP 5.3.x to run Piwik. Piwik project will end support for PHP 5.3 in about six months in May 2015.

  All Piwik users are encouraged to upgrade to the latest PHP 5.5 or PHP 5.6 which brings huge benefits in terms of performance, memory usage, security and overall stability.

  Why is this important ?

  The PHP version 5.3 has reached its End of Life (EOL). Using this old version may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP.

  If you are still using PHP 5.3, note that Piwik will stop supporting this PHP version in May 2015. Around this time Piwik will start requiring PHP 5.4.

  Upgrade your PHP version before it’s too late !

  Learn more

  • PHP 5.3 End Of Life announcement
  • Piwik Requirements
  • How do I find out which version of PHP is running on my server ?

  Learn more about Piwik release schedule :

  • When is the next release of Piwik ?
  • How long is each release of Piwik maintained for ?
  • Piwik 3.0.0 release planning

• Evolution #3897 (Nouveau) : Traduction des configurations (yaml, xml, json) et certains formulaire...

  6 février 2017, par marcimat ☺☮☯♫

  Je remets le texte d’un mail envoyé sur spip-devel (comme il n’y a plus de liens gmane pour les voir), sur le sujet parlant de la fonction _T_ou_typo() qui permet de pouvoir traiter des chaînes contenant

  • soit "du texte"
  • soit une "<:chaine_de_langue:>"
  • soit des "<multi>...</multi>"

  La fonction _T_ou_typo() a comme usage principal d’appliquer la fonction typo() sur le texte qui lui est envoyé, ou récursivement sur chaque valeur si un tableau lui est donné.
  Et, si un des textes est de la forme <:cle_de_langue:> ou <:module:cle_de_langue:> (une forme simple de l’écriture de chaîne de langue dans les squelettes donc), alors c’est la valeur de traduction de cette chaîne de langue qui est retourné.

  Autrement dit :
  

  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo("<:module:bonjour :>") == "Coucou" (avec le fichier de langue qui va bien quand même)
  _T_ou_typo("Coucou") == "Coucou" 
  _T_ou_typo(["Coucou", "<:module:bonjour :>", "Coucou"]) == ["Coucou", "Coucou", "Coucou"]
  

  Cette intégration pose plusieurs questions sur l’usage / le besoin d’origine et sur la réponse apportée.

  L’usage et solution actuelle¶

  Le besoin est de permettre dans des fichiers de configuration (yaml, xml, json) de certains plugins, ou dans des options de configuration de certains plugins directement dans l’interface privée de SPIP (Menus, Formidable, Champs Extras, ...), de pouvoir indiquer soit un texte quelconque, soit de se référer à une chaîne de langue quelque part.

  Par exemple, dans une déclaration .yaml d’une saisie, on peut trouver : label: '<:saisies:option_groupe_description:>'. On pourrait utiliser pour des saisies spécifiques à un site label: 'Description' si on sait que le site n’est pas multilingue par exemple.

  La difficulté d’utiliser directement le code de langue (ie : label: 'saisies:option_groupe_description'" qui paraît pourtant plus simple) est qu’il est impossible de discriminer les cas où on écrirait un code de langue, des cas où c’est réellement le texte voulu, par exemple avec "label: 'todo'", qui si on utilise le code de langue retournerait ’à venir’ (dans spip_fr.php), alors que ce n’était pas forcément ce qui serait souhaité.

  D’où donc l’apparition de cette écriture <:truc:muche:> pour les textes de configuration, écriture connue déjà dans les squelettes SPIP, avec les nuances qu’on parle bien ici d’une syntaxe simplifiée.
  On ne peut pas écrire label: '<:module:nb_elephants{nb=5}:>' par exemple.

  Proposition¶

  Il me semble qu’on pourrait voir la chose autrement, en considérant que toute présence d’un idiome doit être transformé par la fonction typo().
  La fonction typo() traite déjà en fait le cas des polyglottes <multi>...</multi> que l’on peut écrire à la fois dans les squelettes SPIP et à la fois dans le texte d’un article.
  Il suffirait d’ajouter la gestion de l’idiome <:module:cle:> également. Ainsi typo("<:module:bonjour:>") retournerait "Coucou" en allant piocher la chaîne de langue correspondante.

  La conséquence est que ça permettrait plus de possibilités que le besoin d’origine (on pourrait mettre des chaines de langue dans les textes d’articles par exemple)
  (je ne dis pas que ça serait recommandé non plus, mais dans certains cas ça serait pratique !), tout en répondant au problème avec les configurations de type .yaml ou d’autres déclarations multilingues : il leur suffirait d’appliquer typo() sans autre question, du moins en théorie.

• Anomalie #3894 : Jointures (erronées ?) avec les boucles documents et leurs critères

  27 janvier 2017, par marcimat ☺☮☯♫

  Les cas objet / id_objet¶

  En appelant page=test&objet=rubrique&id_objet=1 :

  - (DOCUMENTS){objet?}{id_objet?}
  - (DOCUMENTS){id_objet?}{objet?}
  - (DOCUMENTS){objet?}{id_objet?}{vu=non}
  - (DOCUMENTS){id_objet?}{objet?}{vu=non}
  - (DOCUMENTS){vu=non}{id_objet?}{objet?}
  Jointures correctes : 1 seule jointure L1 sur spip_documents_liens

  - (DOCUMENTS){id_article?}{objet?}{id_objet?}
  Jointure incorrecte : il y a 2 jointures différentes pour objet & id_objet
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.objet = ’rubrique’)
      AND (L3.id_objet = 1)
  GROUP BY documents.id_document
  

  - (DOCUMENTS){id_article?}{objet?}{id_objet?}{vu=non}
  Même comportement erroné, avec vu sur L1 et 2 jointures pour objet & id_objet :
  

  SELECT documents.fichier
  FROM spip_documents AS `documents`  
  INNER JOIN spip_documents_liens AS L3 ON ( L3.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L2 ON ( L2.id_document = documents.id_document ) 
  INNER JOIN spip_documents_liens AS L1 ON ( L1.id_document = documents.id_document )
  WHERE (documents.statut = ’publie’)
      AND (documents.mode IN (’image’,’document’))
      AND (documents.taille > 0 OR documents.distant=’oui’)
      AND (L2.objet = ’rubrique’)
      AND (L3.id_objet = 1)
      AND (L1.vu = ’non’)
  GROUP BY documents.id_document
  

  Il me semble que les jointures objet / id_objet ne fonctionnent que s’ils sont les premiers critères optionnels créant possiblement une jointure de la boucle.
  Cependant (DOCUMENTS){vu?}{objet?}{id_objet?} fonctionne aussi avec vu optionnel (1 seule jointure).