Utilise-t'on encore les fichiers à la place des bases de données ?

Rien compris.

 

Mais... une base de données c'est aussi des fichiers, il faut bien enregistrer les données quelque part.
L'intérêt de la base de données, c'est le moteur par dessus, qui gère le tout.
Après rien n'empêche de faire son propre système de gestion des données :idea:

 

oui, on peut toujours utiliser des fichiers et c'est plus rapide
Mais dès que tu as beaucoup de données à manipuler, les bases relationnelles sont plus adaptées et sans doute plus sécurisées aussi.

 

Oui bien sûr. Chaque cas a des besoin différents.
Tu peux gèrer les infos dans un fichier txt, xml, json, une base de données.

Oui c'est tout nouveau j'ai mis le site en ligne il y a quelques jours seulement. Le code sera probablement en libre accès, il faut que je choisisse la bonne option (mais ça veut pas dire gratuit). Mais c'est pas juste un script. La suite en MP si tu le souhaite, c'est peut-être HS ;-)

 

Bon

J'utilise abondamment pour mon site des fichiers temporaires, qui me servent de caches MySQL.

Avec bocage virtuel en écriture, utilisant des fichiers "verrou{$numcrs-$date}.txt" ( verrouillage synchrone ), et d'autres fichiers servant de verrous persistants, ( verrouillage en écriture dans les deux cas ).

Avec çà, mon site va plus vite.

Les fichiers temporaires sont effacés la nuit à minuit ( l'heure du crime, arf..;( ).

Respectueusement.

 

Les différences je ne sais pas, je ne connais pas exactement ces CMS.
Mais ce que je peux dire c'est que je suis un fainéant et que l'ensemble a été travaillé pour éviter de recommencer ce qui a déjà été fait.

Tu as une base autour de laquelle s'articulent des modules. Un module c'est deux fichiers JSON et au moins un fichier PHP (évidemment certains sont bien plus fourni, mais c'est pour dire que ça peut être très léger). Et les modules sont capables de communiquer entre eux.

Pour te donner un exemple simple j'ai un module qui permet de publier sur les réseaux sociaux (Facebook, Twitter, Linkedin et Viadéo pour le moment. Pinterest et Instagram à venir.).
Tu paramètres tes accès et ensuite, depuis l'admin du site, tu envois en 1 clic tes messages sur tes comptes / pages. Jusqu'ici rien d'extraordinaire.
Là où ça devient intéressant c'est qu'un autre module peut utiliser ces capacités avec un simple appel de fonction :

Code:

ModIntegrate(9, 'SendMessageToAll', ['Mon super message à poster']);

- 9 c'est l'ID du module
- SendMessageToAll c'est la fonction qui va envoyer le message à tous les réseaux sociaux mais tu peux préciser Twitter uniquement
- array['Mon super message à poster'] c'est la liste des paramètres. Avec ici le message à poster.

Et voilà ! Ton message est en ligne. Pas de fichier à intégrer, d'objet à instancier, des librairies à paramétrer, le CMS charge le module nécessaire et le module en question répond à la demande. Et des ponts entre module il y en a plein. Mon module d'actu peut se servir de ça. Tu publies une actu et ton actu est envoyée vers les réseaux sociaux automatiquement (si tu veux évidemment).

Les accès à la base de données se font par des appels MySQLi et des requêtes préparés. Là encore pour le dev c'est simplifier au maximum. L'idée par la suite c'est de pouvoir l'installer sur autre chose que MySQL et que les modules soient immédiatement compatible.

Tout ça c'est plus le côté framework.

Pour le webdesigner le CMS fonctionne selon le principe des gabarits d'affichage. Tu crées ton document HMTL, tes fichiers Javascript, CSS et tu indiques les zones dynamiques (entête, menu et contenu essentiellement).
Ensuite, pour chaque module installé, tu as accès à différents gabarits. Ces gabarits seront insérés dans la zone de contenu de la maquette. C'est encore de l'HTML dans lequel tu indiques les zones dynamiques.

Tu paramètres les droits de ton client pour qu'il puisse faire des mises à jour de contenu sans flinguer ton joli travail et surtout… sans qu'il se retrouve devant une interface incompréhensible. Ici tout est fait pour faciliter l'utilisation. J'ai pas encore eu de remarque me disant "je comprend rien !".

Pour l'utilisateur du site (on peut dire webmaster) le fonctionnement et très simple. C'est le principe du CRUD. Il y a un système d'installation et de mise à jour en 2 clics qui marche pas mal (je me lance des fleurs). Tu choisi le module que tu veux rajouter, tu clic sur installer et il est copié sur ton serveur, les tables du modules sont créées et les paramètres de base du modules sont enregistrés. Tu n'as plus qu'à la lier à une rubrique pour que les visiteurs du site y ait accès.

Tu peux monter un site de vente, un site de blogging, un site pour montrer tes photos, un site vitrine, un forum de discussion, etc.

Voilà en gros ce que je peux en dire. Je ferais une présentation plus complète quand je mettrais la version de démonstration en ligne. Mais d'abord je dois faire une mise à jour de l'interface d'admin qui est un vieux truc moche).

Ah oui, et l'ensemble est très léger, multi-utilisateurs, multi-langues (pour le contenu pas l'interface) et sécurisé.

 

Sauf qu'objectivement, partir sur un CMS/Framework totalement inconnu, avec 0 communauté, c'est toujours un très mauvais choix pour le moyen/long terme.

 

+1 UsagiYojimbo.

On attend de voir le topic de présentation du CMS de niap (perso surtout le code).

 

Oui bien sûr je comprend.
C'est aussi pour ça que j'aimerais trouver une licence GPL qui va bien. Que je puisse mettre le code source à disposition sans me faire dépouiller.

 

Pour le débat entre pages statiques et dynamiques, je continue à mélanger les 2.

Tous mes articles standards sont dans une base BDD, mais mes pages "qui sommes nous", glossaire, contact, CGU, sont statiques. J'ai aussi quelques articles spéciaux qui sont hors BDD. La BDD est utile pour les articles qui ont besoin d'être classés et triés. Pour les autres contenus, pas besoin de l'alourdir.