[spip-dev] un besoin récurrent : des éléments pour la page d'accueil

Coucou,

à chaque fois que je dois mettre un spip en chantier, le truc qui me pose
problème c'est la page d'accueil. On a presque toujours besoin d'y installer
un texte de présentation, ce genre de bêtise.

Où gérer ce(s) texte(s) de présentation ? L'idée est qu'en général ils
n'ont aucun intérêt en soi, ils sont là juste pour orienter le visiteur. Il
ne faut donc pas qu'ils apparaissent dans les sommaires, dans le backend,
dans les "voir aussi", dans le plan du site etc.

On peut bricoler tous les squelettes en ajoutant {id_secteur!=1} dans toutes
les boucles, et stocker ces machins-là dans le secteur 1, mais c'est un peu
lourd de ne rien avoir en "standard", et c'est un peu lourd de devoir penser
à ce critère à chaque boucle articles.

On peut réduire la difficulté en utilisant un auteur dont le login vaudra
"alaune", ce qui offre pas mal de champs à utiliser (plus qu'avec un mot-clé
"à la une", par exemple). Il faut ensuite ajouter {login!=alaune} dans les
boucles auteurs : non seulement il y en a moins, mais en plus comme cet
auteur ne sera affilié à aucun article il n'apparaîtra jamais même si les
boucles auteurs oublient ce critère. M'enfin, détourner un auteur pour
récupérer x champs plus ou moins bien foutus (nom, bio, pgp, email,
nom_site, url_site, statut??), c'est franchement ni suffisant sur le plan
technique ni satisfaisant par rapport à la logique de spip.

Des idées ?

-- Fil

Ca me semble plus une caractéristique classique des sites Nuke qu'autre chose. C'est extrêmement spécifique, et je ne sais pas si ça doit être intégré comme une fonction "générale" de SPIP.

Pour moi, le plus simple pour ce genre de choses, c'est d'utiliser les brèves. Et si nécessaire, un mot-clé qui va bien pour l'afficher en entier sur la page d'accueil.

ARNO*

Hello,

à chaque fois que je dois mettre un spip en chantier, le truc qui me
pose problème c'est la page d'accueil. On a presque toujours besoin
d'y installer un texte de présentation, ce genre de bêtise.

Oui, en effet. C'est un truc qui ne changera jamais, donc si c'est un
texte qui sera repris ailleurs sur le site, je le mets dans un article
que je place en page d'accueil, sinon, je le place dans
'sommaire.html', tout simplement.

Nicolas.

@ Arno* :

Ca me semble plus une caractéristique classique des sites Nuke qu'autre
chose.

Méchant !

Pour moi, le plus simple pour ce genre de choses, c'est d'utiliser
les brèves. Et si nécessaire, un mot-clé qui va bien pour l'afficher
en entier sur la page d'accueil.

Mouais, pas terrible. Mais si j'avais une solution qui cadre bien avec spip,
elle serait déjà codée, hein !

@ Nicolas Hoizey :

Oui, en effet. C'est un truc qui ne changera jamais

Bin euh, non, pourquoi ça changerait pas ?

donc si c'est un texte qui sera repris ailleurs sur le site, je le mets
dans un article que je place en page d'accueil

et il apparaît dans les backend (sauf à s'emmerder)

sinon, je le place dans 'sommaire.html', tout simplement.

et tu n'as pas de correction typo ni de modification facile (si tu crées un
site pour quelqu'un d'autre, par exemple, tu n'as pas envie ni de lui
montrer la manip pour modifier les squelettes, ni de devoir entrer les
corrections à chaque fois qu'une loufoquerie lui passe par la tête)

A l'usage la solution 'mot-clé' semble la meilleure : ça nous donne trois
champs, "titre", "descriptif" et "texte", plus deux images (logo + logo
survol). Et le mot-clé peut servir à faire "monter" des articles ou des
brèves en "une" -- même si ces articles ou brèves sont anciens et
ne s'affichent plus dans les boucles "articles récents".

Pour avoir le bouton "modifier ce mot-clé", il suffit d'ajouter, dans
sommaire.php3, la ligne $id_mot = 567; (où 567 est l'id_mot correspondant
au mot-clé "à la une")

-- Fil

C'est un truc qui ne changera jamais

Bin euh, non, pourquoi ça changerait pas ?

Ah, donc on ne parle pas de la même chose, je retire ce que j'ai dit.

En gros, tu veux gérer des éditos, non ?

Nicolas.

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

En gros, tu veux gérer des éditos, non ?

Nenni. Par exemple, sur http://www.labassijysuis.org/ j'ai mis un texte à
deux francs dans la marge de gauche. Ce texte de "présentation" contient en
plus deux liens spip (faits avec [->5]) vers des articles de "service". Au
lieu de coder ça dans le squelette, je trouve plus souple d'installer ça
dans un item modifiable dans ecrire/ ; ça n'est pas pour autant un édito. Ca
permet juste de modifier de temps en temps la structure de la page d'accueil
sans toucher aux squelettes. De "désautomatiser" une partie du
fonctionnement.

-- Fil

En gros, tu veux gérer des éditos, non ?

Nenni. Par exemple, sur http://www.labassijysuis.org/ [...]

OK, moi j'appelle ça un édito (à tort, oui, je sais), donc je le gère
avec une rubrique spécifique.

Comme ça, tu n'affiche toujours que le plus récent de ceux dont la
date de publi est passée, ce qui veut dire que tu gardes les archives
et que tu peux en préparer à l'avance.

Je dis ça surtout pour les autres, parce que je me doute bien que toi,
Fil, savait déjà ça ... :wink:

Nicolas.

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

et que tu peux en préparer à l'avance.

Argla ! Tu as raison !

-- Fil

Salut,

J'ai complètement cassé le système de documents pour essayer de
le rendre un peu moins limité. Pour l'instant, j'ai modifié
la structure des tables (pas compatible avec l'ancienne version,
désolé), rafistolé l'interface privée (pas fini). Les boucles
documents ne fonctionnent plus. Ce n'est pas joli tout ça, il
aurait mieux valu ne pas se lancer dans cette fonctionnalité
avant d'avoir pas mal remis à plat.

Sinon j'ai aussi rendu le truc de Fil pour les var_ un peu plus
concis.

a+

Antoine.

@ Antoine Pitrou <pitrou@free.fr> : J'ai complètement cassé le système de

documents .../... aurait mieux valu ne pas se lancer dans cette
fonctionnalité avant d'avoir pas mal remis à plat.

Tu penses avoir fini quand ? Il aurait mieux valu créer une 1.4a6 avec tes
trucs bancals. Là quand je réinstalle ta version, je n'ai que des Warning:
Supplied argument is not a valid MySQL result resource in
/www/xxxx/spip/ecrire/articles_edit.php3 on line 285
Impossible de voir ce qui se passe.

Sinon j'ai aussi rendu le truc de Fil pour les var_ un peu plus concis.

Tu as dû merder :
$fichier_requete = eregi_replace('([&?])(submit|valider|(var_[^=&]*)|recalcul)=[^&]*&?', '\\1', $fichier_requete);

ça ne va apparemment pas fonctionner si on passe plusieurs var_xxx (ou alors
il y a un truc que je n'ai pas vu).

-- Fil

Fil wrote:

Tu penses avoir fini quand ? Il aurait mieux valu créer une 1.4a6 avec tes
trucs bancals. Là quand je réinstalle ta version, je n'ai que des Warning:

Quand j'aurai le temps ;)) Ce n'est pas une a6 car elle n'est pas compatible
avec la a5, il y a trop de changements dans la base pour encombrer les upgrades
avec des traitements qui n'auront été vus que par les 3 sites de test. Du
coup il faut installer cette a5 au-dessus d'une a4 (ou, au pire, *dropper*
spip_documents et diminuer le numéro de version dans spip_meta....).

Grosso modo sur les documents :

- il n'y a aucune raison de les faire dépendre des articles (on peut imaginer
notamment de pouvoir ajouter des documents aux messages internes)

- il n'est pas très logique de stocker deux documents différents dans la même
rangée spip_documents (même si c'est plus simple vis-à-vis de l'utilisation
dans les articles ;-))

- les formats de fichier se retrouvent dans une table séparée où on peut
en décrire quelques attributs (notamment si on a le droit de les uploader
via l'interface PHP, le mime-type (peut servir un jour), et la possibilité
de les inclure en HTML (img, embed, ou rien)).

- la nomenclature des raccourcis qui utilise le numéro de l'image à l'intérieur
de l'article obligeait à balader un id_article_img absolument pourri dans
traiter_raccourcis. Dorénavant on utilise l'id du document dans la table
spip_documents. (la transition est traitée par l'upgrade de la base)

Une chose : les images antérieures au champ images dans la table spip_articles
sont perdues (i.e. il faut les réintégrer à la main). Mais c'était la même chose
avec la version d'Arno. Ca ne concerne a priori qu'une quinzaine d'images dans
uzine (c'est très vieux).

Tu as dû merder :
$fichier_requete = eregi_replace('([&?])(submit|valider|(var_[^=&]*)|recalcul)=[^&]*&?', '\\1', $fichier_requete);

ça ne va apparemment pas fonctionner si on passe plusieurs var_xxx (ou alors
il y a un truc que je n'ai pas vu).

Oups, zut, je n'avais pas pensé à ça. Ca doit être possible en simplifiant un
peu la regexp. Une solution : remplacer d'abord les ? par des & (c'est un nom
de fichier, on se fiche de savoir s'il est exactement identique à l'URL ;-)).

a+

Salut,

J'ai intégré un tout petit bout des apports d'Hervé dans l'indexation
(juste les séparateurs, en fait). Ca fait deux petits changements dans
inc_index et inc-calcul-squel.

a+

Antoine.