Recherche avancée

Sur d’autres sites (8353)

• Anomalie #4357 (Fermé) : page ’contact.html’ différente ?

  27 juin 2019, par Louis Possoz

  Le début du (header et nav) de la page ’contact.html’ est différent de celui des autres pages (i.e. article.html, rubrique.html, sommaire.html...).
  Ceci peut compliquer la personnalisation css. Y a-t-il une raison à cette différence ?

  CONTACT

  header} />
  

  nav,env} />

  AUTRES

  header} />
  nav,env} />

• 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 #4114 : paramètre media:joindre_deballer_lister_zip ignoré

  19 mars 2018, par Alexis Z

  Effectivement, j’ai oublier de précisé.
  Spip 3.2.0 révision 23778

  Le 19 mars 2018 à 14:35, <redmine@spip.org> a écrit :

  La demande #4114 a été mise à jour par b b.

  Salut et merci pour le signalement, sur quelle version de SPIP observes-tu
  le problème ?
  ------------------------------
  Anomalie #4114 : paramètre media:joindre_deballer_lister_zip ignoré
  <https://core.spip.net/issues/4114#change-13736>

  - Auteur : Alexis Z
  - Statut : Nouveau
  - Priorité : Normal
  - Assigné à :
  - Catégorie :
  - Version cible :
  - Resolution :
  - Navigateur :

  Bonjour,

  Il me semble avoir trouvé une petite incohérence dans le code du plugin
  media, plus précisément dans la fonction "joindre_deballer_lister_zip"
  ligne 301, de media/inc/joindre_document.php.
  Sauf erreur de ma part, cette fonction a pour but de déballer le contenu
  d’un fichier zip qui lui est passé en paramètre dans un répertoire
  temporaire et de retourner une liste décrivant sont contenus.

  Cette fonction prends deux paramètres $path et $tmp_dir :
  - $path corresponds au chemin du fichier zip à déballer
  - $tmp_dir corresponds au dossier temporaire ou celui-ci sera déballé

  Cette fonction utilise la librairie Pclzip.

  L’incohérence se trouve au niveau du deuximère paramètre, $tmp_dir,
  celui-ci est censé indiquer dans quel répertoire le contenu du zip sera
  déballer or ce chemin n’est pas pris en compte par la fonction
  Pclzip->extraire (ligne 305), et n’est pas non plus pris en compte par la
  fonction callback ’callback_deballe_fichier’ indiqué à la fonction extraire
  de Pclzip.
  En effet dans le code le chemin pris en compte est déclaré dans un define
  "_TMP_DIR" celui-ci déclaré à la ligne 140 de la fonction
  "joindre_trouver_fichier_envoye" (meme fichier php, début ligne 26).
  ($tmp_dir est uniquement utilisé dans la définition du chemin du fichier
  qui est renvoyé par la fonction : ligne 317 : ’tmp_name’ => $tmp_dir . $f)

  Donc le paramètre $tmp_dir quasi non-utilisé induit en erreur car on
  s’attend à se que le contenu ce trouve dans le chemin $tmp_dir de plus si
  on appeler directement la focntion "joindre_deballer_lister_zip" sans
  appeler "joindre_trouver_fichier_envoye" on ne définit pas _TMP_DIR et on
  a une erreur incohmpréensible.

  Du coup, le pire sénario (mon cas) j’appelais
  "joindre_deballer_lister_zip" après un autre appel "joindre_trouver_fichier_envoye"
  indirect, donc la variable _TMP_DIR etait défini et le contenu de mon zip
  déballer à cette endroit alors que je donnais un $tmp_dir completement
  différent, cette destination restait vide et aucun message d’erreur de la
  fonction "joindre_deballer_lister_zip".

  Bref, je suggère de prendre en compte pour l’extraction la variable
  $tmp_dir, et/ou d’ajouter test/définition de la variable _TMP_DIR en début
  de fonction pour prévenir tout exécution "bizarre".
  ------------------------------

  Vous recevez ce mail car vous êtes impliqués sur ce projet.
  Pour changer les préférences d’envoi de mail, allez sur
  http://core.spip.org/my/account