Recherche avancée

Sur d’autres sites (8076)

• Révision 22075 : Intégration dans SPIP de la possibilité de gérer des liens entre objets

  8 mai 2015, par marcimat ☺☮☯♫

  avec des rôles.

  On intègre l’API présente actuellement dans le plugin Rôles, en modifiant
  un peu les fonctions d’édition de liens.

  Celles-ci permettent maintenant d’éditer des liens ayant donc des rôles.
  Ces différents rôles et le nom de la colonne SQL qui les reçoit,
  s’ils sont utilisés, doivent être déclarés avec la déclaration
  de l’objet éditorial correspondant.

  Un exemple est donné avec le plugin « Roles auteurs » qui définit
  quelques rôles. Les champs décrivant les rôles : `roles_colonne`, `roles_titres` et `roles_objets`
  doivent être déclarés (via le pipeline declarer_tables_objets_sql).

  ```
  "roles_colonne" => "role",
  "roles_titres" => array(
  ’redacteur’ => ’info_statut_redacteur’,
  ’traducteur’ => ’roles_auteurs:traducteur’,
  ’correcteur’ => ’roles_auteurs:correcteur’,
  ’relecteur’ => ’roles_auteurs:relecteur’,
  ),
  "roles_objets" => array(
  ’articles’ => array(
  ’choix’ => array(’redacteur’, ’traducteur’, ’correcteur’, ’relecteur’),
  ’defaut’ => ’redacteur’
  )
  #’*’ => array()
  )
  ```

  Une fois déclaré, on peut appeler les fonctions d’édition de lien
  en transmettant des valeurs de rôles, tel que :

  ```
  objet_associer(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’correcteur’)
  ) ;

  // utilisera le rôle par défaut
  objet_associer(
  array(’auteur’ => 3),
  array(’article’ => 11)
  ) ;
  ```

  Si aucun rôle n’est indiqué, le rôle par défaut est appliqué.

  Dans le cas d’une dissociation également, si aucun rôle n’est indiqué,
  seuls les liaisons avec le rôle par défaut seront supprimés ; pour
  supprimer tous les rôles, il faut à ce moment là indiquer ’*’ :

  ```
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’correcteur’)
  ) ;

  // utilisera le rôle par défaut
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11)
  ) ;

  // enlèvera tous les rôles
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’*’)
  ) ;
  ```

  Le formulaire d’édition de liens n’utilisera pas les mêmes squelettes
  de liaison lorsqu’une colonne de rôle est déclarée.

  Ainsi dans cet exemple, au lieu de `prive/objets/liste/auteurs_lies.html`
  et `auteurs_associer.html`, cela utiliserait `prive/objets/liste/auteurs_roles_lies.html`
  et `auteurs_roles_associer.html`. Il faut donc créer ces squelettes.

  Ces squelettes peuvent poster les valeurs au formulaire pour insérer
  de nouveaux liens, de la forme `qualifier_lien[auteur-3-article-11][role]`
  en postant `redacteur` par exemple.

  Il est possible au passage de poster en plus d’autres valeurs, qui seront
  intégrées dans l’enregistrement du lien.
  Ainsi, poster en même temps `qualifier_lien[auteur-3-article-11][valeur]` = `50`
  enregistrera la valeur 50 dans la colonne `valeur` de la table de lien (qui doit
  exister !).

  D’autres informations sont présentes dans http://contrib.spip.net/Des-roles-sur-des-liens,
  http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles_auteurs ou encore
  http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles

• Evolution #3638 (Nouveau) : Utiliser la rechercher Fulltext par défaut pour le critère {recherche}

  7 janvier 2016, par Gilles VINCENT

  Suite à la discussion entammée sur spip-dev, je suggère d’utiliser la recherche Fulltext par défaut, au lieu des REGEXP actuelles
  http://thread.gmane.org/gmane.comp.web.spip.devel/66780

  Par défaut, recherche génère des requêtes des type REGEXP, ce qui n’est utile que si des utilisateurs font des recherches avec des expressions régulières, ce qui n’est pas le cas. Depuis le commit r21697 les tables ont installées par défaut au format MyISAM (demande #2727). SPIP gagnerait donc à utiliser les recherches en Fulltext.

  Analyse détaillée du problème faite par Remi (root@lautre.net) :

  Le problème c’est que ce type de requête est généré dès lors qu’il y a un
  espace dans la recherche et les requêtes REGEXP n’utilisent pas les index.

  Donc ça ne concerne pas que les utilisateurs qui recherchent des
  expressions régulières.

  Pour une recherche aussi bête que "chercher un mot" ça recherche
  REGEXP sur chaque colonne de la table
  spip_articles. Evidemment ça renvoie tous les articles contenant "un".

  Un exemple particulièrement inefficace : 51s pour faire une recherche sur 2
  mots sans avoir la certitude que les 2 mots ne s’y trouvent.

  1. Query_time : 51.073814 Lock_time : 0.018906 Rows_sent : 16363 Rows_examined : 36816

  SELECT t.id_article, t.surtitre, t.titre, t.soustitre, t.chapo, t.texte,
  t.ps, t.nom_site, t.url_site, t.descriptif FROM `xxxxxx`.spip_articles AS t
  WHERE t.surtitre REGEXP ’Etats unis|Etats|unis’ OR t.titre REGEXP ’Etats
  unis|Etats|unis’ OR t.soustitre REGEXP ’Etats unis|Etats|unis’ OR t.chapo
  REGEXP ’Etats unis|Etats|unis’ OR t.texte REGEXP ’Etats unis|Etats|unis’
  OR t.ps REGEXP ’Etats unis|Etats|unis’ OR t.nom_site REGEXP ’Etats
  unis|Etats|unis’ OR t.url_site REGEXP ’Etats unis|Etats|unis’ OR
  t.descriptif REGEXP ’Etats unis|Etats|unis’ ;

  Ici, ça me renvoie les articles qui contiennent "punissons",
  "réunis".

  A ce niveau, un bête like me met "que" 5s :

  SELECT * from (select *, concat( t.surtitre, t.titre, t.soustitre,
  t.chapo, t.texte, t.ps, t.nom_site, t.url_site, t.descriptif) search from
  spip_articles t) s WHERE s.search like ’%unis%’ or s.search like
  ’%Etats%’ ;

  Mais honnêtement 5s, ce n’est pas non plus acceptable.

  Mais s’il vous faut mettre un truc par défaut autre que du fulltext,
  utilisez LIKE sur la chaine à rechercher. Ca ira plus vite et ça vous
  renverra des résultats plus cohérents.

  Remi

• How to dump ALL metadata from a media file, including cover image title ? [closed]

  9 avril, par Unideal

  I have an MP3 song :

  


  # ffprobe -hide_banner -i filename.mp3
Input #0, mp3, from 'filename.mp3':
  Metadata:
    composer        : Music Author
    title           : Song Name
    artist          : Singer
    encoder         : Lavf61.7.100
    genre           : Rock
    date            : 2025
  Duration: 00:03:14.04, start: 0.023021, bitrate: 208 kb/s
  Stream #0:0: Audio: mp3 (mp3float), 48000 Hz, stereo, fltp, 192 kb/s
      Metadata:
        encoder         : Lavc61.19
  Stream #0:1: Video: png, rgb24(pc, gbr/unknown/unknown), 600x600 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn (attached pic)
      Metadata:
        title           : Cover
        comment         : Cover (front)


  


  The task is to save its metadata to a text file and restore from that file later. Both goals should be accomplished with ffmpeg.

  


  The simpliest method is to run :

  


  # ffmpeg -i filename.mp3 -f ffmetadata metadata.txt


  


  After that, metadata.txt contains :

  


  ;FFMETADATA1
composer=Music Author
title=Song Name
artist=Singer
date=2025
genre=Rock
encoder=Lavf61.7.100


  


  I got global metadata only, but stream-specific info (cover image title and comment in my case) are missing.

  


  Google suggested a more complex form of the command above to extract all metadata fields without any exclusions :

  


  # ffmpeg -y -i filename.mp3 -c copy -map_metadata 0 -map_metadata:s:v 0:s:v -map_metadata:s:a 0:s:a -f ffmetadata metadata.txt


  


  But the output is exactly the same :

  


  ;FFMETADATA1
composer=Music Author
title=Song Name
artist=Singer
date=2025
genre=Rock
encoder=Lavf61.7.100


  


  Again, no info about the attached image.

  


  Please explain what am I doing wrong.