Recherche avancée

Sur d’autres sites (8208)

• Anomalie #3325 : (array) n’est pas suffisant pour convertir l’objet récupéré par l’itérateur YQL

  29 octobre 2014, par Sylvain Lesage

  L’URL est mal écrite, c’est : http://core.spip.org/projects/spip/repository/entry/spip/ecrire/iterateur/data.php#L563.

  J’ai pas le dépôt SVN sous la main, mais le patch en gros pourrait être remplacer à la ligne 547

  /**
   * yql -> tableau
   * @throws Exception
   * @param  string $u
   * @return array|bool
   */
  function inc_yql_to_array_dist($u) 
      define(’_YQL_ENDPOINT’, ’http://query.yahooapis.com/v1/public/yql?&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&q=’) ;
      $v = recuperer_url($url = _YQL_ENDPOINT.urlencode($u).’&format=json’) ;
      if (!$v[’page’]
        OR !$w = json_decode($v[’page’],true)) 
          throw new Exception(’YQL : r&#233 ;ponse vide ou mal form&#233 ;e’) ;
      
      if (isset($w[’error’]))
          throw new Exception($w[’error’][’description’]) ;
      
      return (array) $w ;
  
  

  par

  /**
   *
   * Convert an object to an array
   *
   * @param    object  $object The object to convert
   * @return   array
   *
   */
  function inc_object_to_array( $object ) 
      if( !is_object( $object ) && !is_array( $object ) ) 
          return $object ;
      
      if( is_object( $object ) ) 
          $object = get_object_vars( $object ) ;
      
      return array_map( ’inc_object_to_array’, $object ) ;
  
  /**
  
   * yql -> tableau
  
   * @throws Exception
  
   * @param  string $u
  
   * @return array|bool
  
   */
  
  function inc_yql_to_array($u) 
  
      define(’_YQL_ENDPOINT’, ’http://query.yahooapis.com/v1/public/yql?&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&q=’) ;
  
      $v = recuperer_page($url = _YQL_ENDPOINT.urlencode($u).’&format=json’) ;
  
      $w = json_decode($v) ;
  
      if (!$w) 
  
          throw new Exception(’YQL : r&#233 ;ponse vide ou mal form&#233 ;e’) ;
  
          return false ;
  
      
  
      return inc_object_to_array($w) ;
  
  
  

• Roadmap #3844 : Gérer la parenté dans la déclaration d’un objet éditorial.

  27 février 2018, par RastaPopoulos ♥

  Hello,
  j’ai possiblement besoin de rajouter la prise en compte directe du champ "id_parent" s’il existe lors de la création, qui est un cas vraiment simple et bateau, qui est donc détectable sans déclaration spéciale, lors de la création d’un objet quelconque.

  Actuellement objet_inserer() peut lui passer une variable générique nommée $id_parent, mais en fait dedans la fonction ne gère que le cas si y a un champ "id_rubrique" pour cet objet. Du coup j’ai ajouté le cas encore plus simple où ya un champ "id_parent", càd quand l’objet est parent de lui-même (comme les rubriques).

  Mais finalement je n’ai rien commité, car je me suis dit que ça rentrait dans la réflexion plus générale de ce ticket, et que mon petit bout de code devra bien être utilisé mais à l’intérieur d’un code plus large utilisant la déclaration explicite si elle existe. Je mets le diff de ma modif quand même pour historique.

  En gros pour moi dans objet_inserer(), c’est toute la partie qui teste si ya "id_rubrique" + mon ajout qui teste "id_parent" qui devrait être recodé avec cet algorithme :
  1) s’il y a un déclaration de parentée explicite, on l’utilise et on essaye de remplir les bons champs et la langue avec ça
  2) s’il y a un champ "id_rubrique" on remplit magiquement
  3) s’il y a un champ "id_parent" on remplit magiquement

  Pour le 2) et 3), je ne sais pas si ça doit être à chaque fois en ajout, ou bien en "elseif", càd seulement si le cas précédent n’existe pas ! Il faudra le décider.

  En attendant qu’on statue sur tout ça, je vais me débrouiller avec le pipeline "pre_insertion" pour lequel j’ai rajouté l’information "id_parent" tout à l’heure, car ça du coup je l’ai mis aussi en 3.2 puisque ça ne changeait rien…

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

  17 avril 2021, par RastaPopoulos ♥

  Bé oui ça n’a pas de rapport avec la fin, c’est que dans n’importe quel form, même sans aucun groupe imbriqué, juste ceux racines, il peut y avoir alternance entre fieldsets et champs. Par ex : Prénom, Nom, Adresse (fieldset regroupant des champs logiques entre eux), Téléphone, Etc.

  La règle algorithmique étant : il faut au moins voir la fin de tous les fieldsets qui sont suivis d’un élément n’étant pas un fieldset ni les boutons de fin.

  Et je vois mal comment automatiser ça au niveau production du code puisque par exemple pour un objet, qui aurait à la fin un fieldset, on pourrait se dire qu’on n’a pas à voir sa fin, sauf que Champs Extras peut parfaitement ajouter des champs sans groupe après. Ou n’importe quel plugin.

  Aussi pour aider à styler, comme je le disais tout à l’heure sur IRC, je pense qu’il faudrait corriger une incohérence actuellement : en gros 99% des formulaires dans la nature, core + plugins, ont les vrais fieldsets (pas des radios ensemble quoi), dans un conteneur div.fieldset en plus. Et seulement quelques forms de configs ont des fieldsets directement comme ça qui se baladent sans aucun conteneur dédié. Cela fait qu’on doit à la fois styler ".formulaire_spip .fieldset fieldset" et ".formulaire_spip fieldset" différemment avec des exceptions ajoutées, car ça change les marges !
  Je propose pour ce ticket d’en profiter pour uniformiser tous les quelques formulaires qui ont des "vrais" fieldsets toujours dans un conteneur. Ainsi on stylera toujours une seule chose, et en plus ça sera encore plus simple de styler seulement ces vrais fieldsets par rapport à ceux des radios/checks.