Votre avis sur mon CMS svp

tryan · 13 Avril 2013

Bonjour,

Bidoullieur en programmation, je suis en cours de création d'un petit CMS maison et j'aimerais avoir vos avis sur celui-ci (erreurs, améliorations, etc..).
L'architecture voulu est simple, catégorie » sous-catégoire » article.
Avec et sans rewriting.
Système de commentaires.
Modification de certaines partie de l'article en cliquant dessus.
Image ou pas pour illustrer un article.
Etc..

L'url -http://teste.reflink.fr
Accès administration en bas de page. Entrez 2 fois le mot admin.

Merci

UsagiYojimbo · 13 Avril 2013

J'ajouterais :

- Mettre les articles à la racine (je suis pas fan des url à rallonge), ou tout du moins pouvoir le faire
- Réécrire les url des tags
- Prévoir des champs dédiés au SEO (title, meta description) et à l'Open Graph
- Pouvoir saisir une accroche qui soit autre chose qu'une version tronqué du texte principal
- Tu as pensé à la manière de gérer le multilingue ? (multi-domaine, sous-dossier, sous-domaines, etc. + localisation des contenus)
- Pour les commentaire, proposer d'utiliser les api type Facebook, Disqu.us, etc

C'est un système de template ? As-tu envisagé une gestion du cache ou non ? Comment peut-on changer les url des articles et catégories ? Et si on les change, y a t'il redirection automatique ?

C'est un début un peu en vrac, mais voilà à quoi j'ai pensé d'emblée en voyant la chose.

tryan · 13 Avril 2013

Mettre les articles à la racine (je suis pas fan des url à rallonge), ou tout du moins pouvoir le faire

C'est à dire?

Réécrire les url des tags

Ok.

Prévoir des champs dédiés au SEO (title, meta description) et à l'Open Graph

Catégorie, sous-catégorie et article on tous un champ titre et description servant à alimenter respectivement le "title" et "meta description". Concernant l'Open Graph, je ne savais même pas ce que c'était

.. si il sagit d’implanter les balises Open Graph fondamentales (og:title, og:type, og:url, og:image) c'est jouable. Si il en faut beaucoup plus, ça va m'être très compliqué.

Pouvoir saisir une accroche qui soit autre chose qu'une version tronqué du texte principal

En faite il sagit de la description et non du texte principal servant à la fois pour la description et la méta description. Ce n'est pas suffisant? Pour obtenir une accroche différente de la description ou du contenu, ça oblige à ajouter un champ en plus ce qui ferait que la rédaction d'un "article" nécessiterai : un titre, une description (meta description), une accroche(pour le visuel), le contenu..ça ne fait pas de trop?

Tu as pensé à la manière de gérer le multilingue ? (multi-domaine, sous-dossier, sous-domaines, etc. + localisation des contenus)

Absolument pas et je ne sais pas faire.

Pour les commentaire, proposer d'utiliser les api type Facebook, Disqu.us, etc

Je n'y avais même pas songé.

C'est un système de template ?

Non et je ne sais pas faire. J'ai dissocié un max le PHP/SQL du reste mais c'est tout. Pas de MVC non plus.

As-tu envisagé une gestion du cache ou non ?

Non et je ne sais pas faire.

Comment peut-on changer les url des articles et catégories ?

On ne peut pas sauf en modifiant la fonction permettant la ré écriture, la disposition des liens eux même et les règles de rewrites utilisés.

Comme je l'est précisé en début de poste, je suis tout juste un bidouilleur, je "bricole" et je me rend compte que les "exigences" d'un webmaster confirmé comme toi dépasse "mes compétences" actuelles

.

Merci de m'avoir répondu

.

UsagiYojimbo · 13 Avril 2013

Pour ce qui est des url, c'est au niveau des articles. Je ne supporte pas les CMS qui se sentent obligés de stocker les slug des articles dans les dossiers et sous-dossiers des catégories auxquelles ils appartiennent. Rien qu'en cas de gestion de catalogue avec des produits multi-catégorie (même si tu n'en est pas là), mieux vaux mettre les url terminales à la racine. Et limiter les niveaux d’arborescence.

Pour ce qui est de la saisi, j'aime bien quand par défaut les infos SEO se remplissent automatiquement à partir des infos éditoriales (en gros que le title reprenne par défaut le h1, et la meta description le début du texte) MAIS il est essentiel de pouvoir faire du spécifique par dessus. Donc d'avoir des champs dédiés pour affiner.

Pour le reste, mon ancienne boîte était parti sur le développement d'un CMS maison, donc je me suis longuement frotté à ces problématiques. Mais je reste convaincu que les dev spécifiques n'ont d'intérêt que dans des cas très spécifiques, pour coller au plus près des demandes du client. Pour un site institutionnel standard, je suis davantage dans l'optique d'opter pour un CMS connu.

tryan · 14 Avril 2013

...mieux vaux mettre les url terminales à la racine. Et limiter les niveaux d’arborescence.

Je pensais qu'il était mieux de bien catégoriser chaque élément car il me semblait logique qu'un article soit, dans mon cas, à sa place dans un sous dossier plutôt qu'en "bordel" à la racine...
Quand tu dis "url terminal", ça veut dire que chaque niveau (cat, sous-cat, article) serait bien mieux à la racine?

Pour ce qui est de la saisi, j'aime bien quand par défaut les infos SEO se remplissent automatiquement à partir des infos éditoriales (en gros que le title reprenne par défaut le h1, et la meta description le début du texte) MAIS il est essentiel de pouvoir faire du spécifique par dessus. Donc d'avoir des champs dédiés pour affiner.

Dans mon cas c'est plutôt l'inverse, le h1 se remplit en fonction du titre saisie et la méta description en fonction de la description saisie. Je pourrais très bien utilisé le début de l'article tronqué pour la méta description et utiliser le champ description pour du "spécifique" mais j'ai du mal à en saisir l'utilité.

Dans mon petit cerveau, je schématise un page de cette façon :

Un titre.
Une description.
Un contenu.

Le titre est injecté dans l'url pour obtenir des mots clés dans celle-ci, utilisé dans la balise title et le h1.
La description remplit la meta description et donne une accroche différente du contenu. Elle sert également en version tronqué d'accroche visuel dans les niveaux d’arborescence.

Je ne cherche pas à réaliser un truc super sophistiqué, juste un petit CMS de base pas trop compliqué à prendre en main et à modifier qui pourrait éventuellement servir à d'autres recherchant un "truc" simple.

zeb · 14 Avril 2013

tryan a dit:
je schématise une page de cette façon :

Un titre.
Une description.
Un contenu.

perso j'y ai ajouté qques données très utiles qui élargissent l'horizon des pages en les rendant compatible a plusieurs contraintes.

Une méta keyword (c'est tout con et ça coute pas cher)
Un vrai faux pour le verrouillage (peut être modifié ou pas)
Un ID pour identifier l'utilisateur qui a créé la page (permettra d'autoriser la modification par X ou Y en cas de multiples éditeurs)
Une date de création ou modification (permet de gérer des maj de pages, les dates des flux etc ...)
Un id de la rubrique auquel est attaché la page (pourrait être une collection pour répondre attentes de UsagiYojimbo en terme d'urtl simple et de catalogue a entré multiples)
Un décompte des hits (un simple int qui s'auto incremente à la lecture)
Une Url (url de la page sans le domaine pratique pour beaucoup d'opérations internes)

Mais le gros plus c'est que cette table contenant mes pages comprend un dernier champs qui est le Type de page.
Comprend part là qu'une page peut être soit :
* un simple article
* une page de présentation de site web (une fiche annuaire)
* un billet de blog (un genre d'article pouvant être commenté et être associé a d'autre infos comme" un bloc média avec texte d’accroche individuel", "chapeau", "image a la une")
* un sujet de forum (une sorte de concaténation de messages)
* une fiche produit (pour l'e-commerce)
* une fiche de définition (genre d'article qui sera lié automatiquement dans les contenu en affichant un lien et une courte description sous forme de bulle vers la page définition)

mieux vaux mettre les url terminales à la racine. Et limiter les niveaux d’arborescence.

Si tu peux mettre des articles dans une sous catégorie tu peux les mettre aussi à la racine ... c'est une politique éditoriale a voir dès le début mais le souci viendra du fait qu'il faut avoir un système qui est sois orienté "rubriques" soit orienté "tag" les deux ayant des postulas différents a la base.
Après si Tryan laisse la main sur les urls en les associant à sa table page le souci est réglé car le système répondra sur l'url stockée et pas sur la structure ; ses indexs deviendront des catégories (ref WP) a la place d'index pur (hiérarchie du contenu basé sur des dossiers). Il faut bien sur pour cela que la structure du site soit totalement virtuelle et que les frontaux soit compatibles.

zeb · 14 Avril 2013

UsagiYojimbo a dit:
Tu as pensé à la manière de gérer le multilingue ? (multi-domaine, sous-dossier, sous-domaines, etc. + localisation des contenus)

A ce sujet pour avoir travaillé la dessus il y a pas longtemps, je te conseille de :
* mettre le nom de tes tables en variable
* mettre le nom de domaine en variable aussi
* rendre la structure du code totalement indépendante des urls (virtualiser toutes les pages et la structure)
Cela permettra au CMS de répondre quelque soit le nom de domaine qui y est pointé et de prendre les décisions qui conviennent au moment du traitement a l'aide d'un simple fichier de configuration qui affectera les variable en fonction du domaine qui est sollicité dans la requête HTTP.

Ceci te donnera les moyens de traiter les langages, le multi site, les sous domaines etc ...

Pour le langage, l'avantage de dissocier traitement sur les données et "contenu brut html" est qu'en fonction d'un simple fichier de config linguistique tu pourra servir les messages systèmes en anglais ou en français etc ... ce choix pourra se faire au niveau du fichier de config et être basé sur le domaine ou le sous domaine, ou une simple url.

A ce stade intègre tout de suite la virtualisation totale des urls (rien d'écrit physiquement sur le disque) car tu va devoir traiter d'autres choses comme du cache sinon la complexité va rendre le système trop lourd.

spout · 14 Avril 2013

- Captcha inutile, trop facile à parser le span.captcha.
- Manque de <label for="idXX"> dans les forms
- Validation des forms: 1 seule erreur à la fois ?

C'est clean continue comme ça