Skip to content
Extraits de code Groupes Projets
  1. jan. 19, 2021
  2. sept. 28, 2020
  3. jan. 22, 2020
  4. jan. 01, 2020
  5. août 05, 2019
  6. juil. 26, 2019
  7. jan. 08, 2019
  8. avr. 01, 2018
  9. mai 06, 2017
  10. nov. 30, 2016
  11. nov. 02, 2016
  12. août 31, 2016
  13. juin 25, 2016
  14. jan. 01, 2016
  15. déc. 13, 2015
    • marcimat@rezo.net's avatar
      Meilleure compatibilité avec PSR-2 et nos règles d'écriture, en appliquant · 69fc6182
      marcimat@rezo.net a rédigé
      différents fix avec php-cs-fixers. Fixers appliqués ici :
      
      	'encoding',                // utf8
      	'eof_ending',              // un saut de ligne en fin de fichier
      	'elseif',                  // elseif plutôt que else if
      	'function_call_space',     // espaces sur fonctions
      	'function_declaration',    // espaces sur fonctions
      	'function_typehint_space', // espaces sur fonctions
      	'linefeed',                // sauts de ligne \n uniquement
      	'lowercase_constants',     // true, false, null en munuscule
      	'lowercase_keywords',      // mots clés PHP en lowercase
      	'method_argument_space',   // espaces sur appels de fonctions
      	'multiple_use',            // use unique sur fonctions anonymes
      	'newline_after_open_tag',  // ouverture de php… et c'est tout sur cette ligne
      	'operators_spaces',        // espaces de part et d'autres des opérateurs binaires
      	'parenthesis',             // pas d'espace juste après parenthèse ouvrante, ou avant parenthèse fermante
      	'php_closing_tag',         // pas de fermeture de php
      	'short_tag',               // tag PHP corrects
      	'trailing_spaces',         // pas d'espace qui traîne en fin de ligne
      	'visibility',              // déclarer 'public / private / protected' sur les méthodes
      69fc6182
    • cedric@yterium.com's avatar
  16. déc. 11, 2015
  17. nov. 22, 2015
  18. mai 08, 2015
  19. oct. 25, 2014
  20. jan. 01, 2014
  21. mai 31, 2013
  22. fév. 25, 2013
  23. jan. 24, 2013
  24. oct. 03, 2012
  25. juil. 03, 2012
  26. juin 08, 2012
  27. nov. 14, 2011
    • cedric@yterium.com's avatar
      Le media d'un document (image, video, audio, file) utilise par convenance dans... · a1f6242c
      cedric@yterium.com a rédigé
      Le media d'un document (image, video, audio, file) utilise par convenance dans l'interface ne peut dependre en dur de l'extension du fichier :
      avec oEmbed, on peut se retrouver a integrer toute sorte de media au format html
      Du coup on revoit la structure de la base :
      spip_types_documents porte un champ media_defaut (renommage de l'ancien media) utilise comme valeur par defaut du media si non renseigne quand un document est ajoute
      spip_documents porte son propre champ media, qui est peuple en fonction de media_defaut, sauf si renseigne lors de l'ajout du document
      (ie via fonction de description ou pipeline)
      Revision du code partout ou on referencait media, en dispatchant sur l'un ou l'autre selon les cas
      upgrade de la base (en deux fois)
      
  28. oct. 17, 2011
  29. juin 20, 2011
  30. juin 19, 2011
  31. avr. 15, 2011
    • cedric@yterium.com's avatar
      Unification de l'API editer_xxx des objets : · ba095b08
      cedric@yterium.com a rédigé
      on renomme de façon cohérente pour tous les objets
      xxx_inserer
      xxx_modifier
      xxx_instituer
      
      Les points d'entrée de l'API sont donc
      action_editer_xxx pour le traitement global d'un post
      xxx_inserer et xxx_modifier pour les operations elementaires
      
      xxx_instituer n'est pas un point d'entree et ne devrait pas etre appelee en direct : il faut passer par xxx_modifier.
      
      Le fichier inc/modifier contenait de façon centralisee des fonctions
      revision_xxx pour les objets historiques de SPIP (essentiellement utilisées par les crayons)
      Cette construction centralisée n'est pas facilement extensible. On evacue donc chaque fonction dans le action/edtier_xxx de l'objet concerné, et on propose en remplacement un point d'entrée unique
      revision_objet($objet,$id,$c)
      qui va dispatcher vers la fonction xxx_modifier de l'objet, ou a defaut la fonction generique objet_modifier de 
       action/editer_objet. Les fonctions revision_xxx sont par ailleurs dépréciées.
       
      Les anciennes fonctions insert&set sont toujours definies et renvoie vers la fonction a nommage conventionnel, pour eviter trop de rupture de compatibilité
      ba095b08
  32. mars 27, 2011
  33. mars 21, 2011
  34. mars 02, 2011
  35. fév. 04, 2011
    • cedric@yterium.com's avatar
      report de r44136 · 7816319e
      cedric@yterium.com a rédigé
      prevoir que l'on peut rattacher un document a un autre. C'est une pre-figuration de la reorganisation des documents.
      Dans spip_documents_liens id_document designe toujours l'enfant (dependant de) et (id_objet,objet) le parent.
      Donc ici un document annexe (sous-titrage, licence, ..) est designe par id_document, et (id_objet,objet='document') pointe vers le document maitre.
      Des variantes du mode 'vignette' sont donc a prevoir, pour les documents annexes
      7816319e
  36. jan. 22, 2011
  37. jan. 21, 2011
Chargement en cours