🌍
Français
En 1.7 il existe Additional Pages
Bonjour,
Je fais remonter ce post car j'ai un petit problème avec une version 1.7.0 que je suis en train de préparer.
Je voudrais créer une page "Liens" dans la partie "Menu" et l'afficher tout en gardant le menu à gauche...
J'ai bien suivi les instructions de vimages, sauf qu'à l'étape 2, j'ai copié/renomé about.php en liens.php et modifé tous les "about" en "liens" en conservant la casse... et que le contenu de la page html est différent...
Tout se passe bien (j'ai bien le lien, la page s'affiche bien, le menu aussi), mais j'ai ce message d'erreur au dessus :
Notice: Undefined index: section in e:\af sites web\aa mes sites web\lmollard.free.fr\train-spirit\include\menubar.inc.php on line 114
Quelqu'un peut-il me mettre sur la voie pour résoudre ce petit problème ?
Par avance merci...
Lionel
VDigital a écrit:
Ne décourageons personne! L'expérience peut être menée via tools ou par un gros plugin.
Question technique: Je pense qu'il faudra une table... local.lang.php ne devrait pas suffire. Rub a raison.
Une table ou un fichier propriétaire, l'idée est la.
VDigital a écrit:
...aux thermes...
Si je dis que c'était un test pour nos maitre capelo du forum, personne me croit ;-)
(il est interdit de faire le résumé hebdo de mes boulettes...)
VDigital a écrit:
mathiasm a écrit:
... avec les plugins, on devrait pouvoir se passer de beaucoup de modifications directement dans le php qui génère le tpl. Les modifs des tpl peuvent devenir un nouveau template, adapté à la fonction. et la conclusion, plus de modifs des fichiers par défaut, ce qui est le but recherché.
et
rub a écrit:
faire le moins de php pour les utilisateurs
On vise à terme (et aux thermes éventuellement 8-) ) l'absence totale de modif dans l'ensemble des fichiers livrés en standard. Tout pouvant être réalisé simplement par des ajouts de fichiers et de tables.
Tu as parfaitement raison. On adhère tous à cette idée.
L'idée fait son chemin et c'est très bien.
VDigital a bien résumé l'ensemble, je pense.
De toute façon, j'ai déjà une demande en cours pour la NBM, quand je le ferais, je m'emploierais à faire un système générique qui rentre dans le cadre que ce qu'on a dit.
Je ferais ma proposition pour NBM (mais quand?) et on disposera.
Pour vimages, tu peux faire un fiche pour mettre ton idée initiale en plugin.
Je prendrais le point.
Tu peux aussi le livre en MOD, je pense.
vimages a écrit:
On vise à terme (et aux thermes éventuellement 8-) ) l'absence totale de modif dans l'ensemble des fichiers livrés en standard. .
on devrait pouvoir se passer de beaucoup de modifications directement dans le php
oui et re oui !
Je fais le test de monter une galerie avec mon frère qui n'a jamais fait de site web, etc. Ca me permettra de me faire un nouveau point de vue sur les problèmes de novices et sur la façon de les restreindre.
On vise à terme (et aux thermes éventuellement 8-) ) l'absence totale de modif dans l'ensemble des fichiers livrés en standard. .
on devrait pouvoir se passer de beaucoup de modifications directement dans le php
oui et re oui !
Ne décourageons personne! L'expérience peut être menée via tools ou par un gros plugin.
Question technique: Je pense qu'il faudra une table... local.lang.php ne devrait pas suffire. Rub a raison.
mathiasm a écrit:
... avec les plugins, on devrait pouvoir se passer de beaucoup de modifications directement dans le php qui génère le tpl. Les modifs des tpl peuvent devenir un nouveau template, adapté à la fonction. et la conclusion, plus de modifs des fichiers par défaut, ce qui est le but recherché.
et
rub a écrit:
faire le moins de php pour les utilisateurs
On vise à terme (et aux thermes éventuellement 8-) ) l'absence totale de modif dans l'ensemble des fichiers livrés en standard. Tout pouvant être réalisé simplement par des ajouts de fichiers et de tables.
Tu as parfaitement raison. On adhère tous à cette idée.
L'idée fait son chemin et c'est très bien.
8-)
mathiasm a écrit:
rub a écrit:
Le but n'est pas non plus de faire un cms ou un blog à part entière.
Le plus important à mes petits yeux, c'est de pouvoir gérer facilement x langues sur un contenu personnalisables (NBM ou conditions d'utilisation, ...).
C'est à dire une gestion de contenu au sens le plus strict.Dans ce cas là, tu as un très grosse fonctionnalité à mettre en oeuvre. Description de photos et catégories multilingues...
Nous somme d'accord sur le fond. le local.lang.php devrait répondre à ça.
Si on fait toutes les données d'un coup effectivement.
Le local.lang.php ne répond à ce besoin pour moi.
Le fichier local.lang.php est statique est permet de changer des traductions/expressions qui ne plaisent pas à cretains (tag=>mot clef) ou pour les MODs... ce n'est vraiment pas adapté pour les contenus saisissables par l'utilisation (personnalisés)
mathiasm a écrit:
rub a écrit:
Pour finir, je vais citer la 1er phrase de ce site:
PhpWebGallery est un système de gestion de contenu open-source, gratuit, avancé et simple d'utilisation, orienté vers la présentation de collections d'images.Oui, mais là, tu as voté pour plus clair ;-)
=> PhpWebGallery est un logiciel libre et gratuit de présentation de photos sur le web
le contenu dont il était question était le type d'éléments possibles dans la galerie, soit $conf['file_ext'].
J'ai voté pour plus clair mais j'ai repris la phrase en cous quand même en , c'est vrai, extrapolant "légèrement" les thermes utilisés.
mathiasm a écrit:
La réponse de manière plus générale repose sur une amélioration du système de template, sujet de multiples fois discuté, qu'il faudra un jour résumer et définir une bonne fois pour toutes. Tel qu'il est actuellement, ce n'est normalement qu'une version transitoire vers du modulaire (voir le sujet de chris dans le forum de la team pour l'équipe).
Par le template?
Non, pas vraiment, je pense.
mathiasm a écrit:
L'idée est passée, mais de mon point de vue, si tu fais de l'"avancé", tu dois comprendre un minimum ce que tu fais, donc mettre les mains dans les rouages, ce qui n'est pas contradictoire avec simple, mais qui est contradictoire avec ta version qui veut que simple=centralisé, protégé et interfacé.
Par exemple, avec les plugins, on devrait pouvoir se passer de beaucoup de modifications directement dans le php qui génère le tpl. Les modifs des tpl peuvent devenir un nouveau template, adapté à la fonction. et la conclusion, plus de modifs des fichiers par défaut, ce qui est le but recherché.
Le but est de faire comme les plugins, permettre de faire le moins de php pour les utilisateurs.
D'ailleurs, je n'ai jamais écrit que simple=centralisé, protégé et interfacé.
Pour moi, simple, c'est interfacé mais pas forcément centralisé, l'interface se faisant au niveau de chaque fonctionnalité.
Et avancé, c'est pour moi, un contenu modifiable multi-lingue donc pas forcement nécessaire de mettre les mains dans les rouages (c'est le but d'ailleurs).
rub a écrit:
Le but n'est pas non plus de faire un cms ou un blog à part entière.
Le plus important à mes petits yeux, c'est de pouvoir gérer facilement x langues sur un contenu personnalisables (NBM ou conditions d'utilisation, ...).
C'est à dire une gestion de contenu au sens le plus strict.
Dans ce cas là, tu as un très grosse fonctionnalité à mettre en oeuvre. Description de photos et catégories multilingues...
Nous somme d'accord sur le fond. le local.lang.php devrait répondre à ça.
rub a écrit:
En fait, le but n'est pas de gérer du contenu mais de faciliter la mise en place par un utilisateur lambda.
Modifier un fichier php, ca semble pour certains compliqués alors si en plus il faut qu'il comprenne les ' \ " ca va être très compliqué.
C'est pour ça que j'ai parlé de l'intégration aux CMS. Si tu prends drupal ou CMSMS, tu le "linkes" à phpwebgallery et pouf! tu as ton éditeur wysiwyg adpaté à des pages de texte, etc... Là, je suis d'accord qu'on est hors-champ pour du multilingue dans pwg.
rub a écrit:
Pour finir, je vais citer la 1er phrase de ce site:
PhpWebGallery est un système de gestion de contenu open-source, gratuit, avancé et simple d'utilisation, orienté vers la présentation de collections d'images.
Oui, mais là, tu as voté pour plus clair ;-)
=> PhpWebGallery est un logiciel libre et gratuit de présentation de photos sur le web
le contenu dont il était question était le type d'éléments possibles dans la galerie, soit $conf['file_ext'].
rub a écrit:
Avoir une interface qui gére les traductions d'un contenu personnalisé de façon avancée mais simple est l'idée que j'avais envie de passer...
Avancée mais simple... Une petite quadrature du cercle!
Et le motto de Pierrick, qui est un peu celui de phpwebgallery:
Faire facilement les choses simples, pouvoir faire des choses complexes.
La réponse de manière plus générale repose sur une amélioration du système de template, sujet de multiples fois discuté, qu'il faudra un jour résumer et définir une bonne fois pour toutes. Tel qu'il est actuellement, ce n'est normalement qu'une version transitoire vers du modulaire (voir le sujet de chris dans le forum de la team pour l'équipe).
L'idée est passée, mais de mon point de vue, si tu fais de l'"avancé", tu dois comprendre un minimum ce que tu fais, donc mettre les mains dans les rouages, ce qui n'est pas contradictoire avec simple, mais qui est contradictoire avec ta version qui veut que simple=centralisé, protégé et interfacé.
Par exemple, avec les plugins, on devrait pouvoir se passer de beaucoup de modifications directement dans le php qui génère le tpl. Les modifs des tpl peuvent devenir un nouveau template, adapté à la fonction. et la conclusion, plus de modifs des fichiers par défaut, ce qui est le but recherché.
Le but n'est pas non plus de faire un cms ou un blog à part entière.
Le plus important à mes petits yeux, c'est de pouvoir gérer facilement x langues sur un contenu personnalisables (NBM ou conditions d'utilisation, ...).
C'est à dire une gestion de contenu au sens le plus strict.
Ensuite, c'est vrai qu'on peut aller un peu plus loin tout en étant à la limite mais bien utile pour l'utilisateur final...
En fait, le but n'est pas de gérer du contenu mais de faciliter la mise en place par un utilisateur lambda.
Modifier un fichier php, ca semble pour certains compliqués alors si en plus il faut qu'il comprenne les ' \ " ca va être très compliqué.
Pour finir, je vais citer la 1er phrase de ce site:
PhpWebGallery est un système de gestion de contenu open-source, gratuit, avancé et simple d'utilisation, orienté vers la présentation de collections d'images.
Avoir une interface qui gére les traductions d'un contenu personnalisé de façon avancée mais simple est l'idée que j'avais envie de passer...
On sort un peu du sujet...
C'est malgré tout très original. Combien de blog ou de CMS veulent proposer un système intgrant une galerie...?
Tous ou presque non?
Je pense qu'il est plus facile d'intégrer PWG dans la plupart des solutions actuelles.
Mais je ne rejette pas l'idée l'idée d'un add-on de PWG qui lui donnerait des fonctions style Blog ou CMS à PWG.
Ce qu'il faut éviter: c'est prendre une voie séparée (punBB et punPortal).
Un exemple dans tools m'irait très bien.
8-)
.... je me suis borné à faire une personnalisation, à la proposer... et puis la richesse des échanges fait entrevoir d'autres possibilités.. ...mon avis n'est que celui d'un humble utilisateur. C'est au team de choisir les évolutions, la façon de les intégrer.
Cette mise au point faite, ...
Je ne veux pas dénaturer PWG, en faire ce qu'il n'est pas. MAIS, si on peut rendre l'interface de certaines personnalisations, plus conviviale aux non-initiés, je pense que c'est une bonne chose.
amicalement,
éric.
Dans ce cas, il suffit de fournir un integrated_page.tpl pour chaque template, et un integrated_example.php dans /tools, non ?
non non.... pour ma part je ne voyais tout ça que comme le moyen d'aider les moins bon en programmation à personnaliser leur site PWG.. c'est tout. L'ajout d'une page ou deux, lapersonnalisation des titres et mots utilisés ne font pat de PWG un CMS.
Avec tout ça, on devient un CMS (gestionnaire de contenu, de portail) complet, là.
On vire carrément en mode portail.
Il est à mon avis plus pérenne de savoir s'intégrer dans un CMS comme dans un blog ou un forum. Chacun son métier.
Et pour être complet, il suffira de sortir les themes equivalents à ceux de PWG dans les principaux CMS (ou l'inverse) et le tour est joué.
La même chose avait été faite pour punBB, c'est devenu punPortal, un dev à part.
vimages a écrit:
1,2,3,4, le reste
C'est bien ca l'idée.
vimages a écrit:
5) ==>le résultat serait écrit dans le fichier "local.lang.php" lui même enregistré dans le dossier de langue choisie en 1)
Non par forcement dedans mais soit dans un nouveau fichier soit en base... mais un fichier qu'on ne peut/doit pas modifier soi-même pour éviter les écrasements, soucis, etc.
vimages a écrit:
C'est une idée sympa, mais réellement utile que pour les pages ajoutées ou / et personnalisables... rare sont les mots et expressions du site de base que les utilisateurs voudront changer, mais qui sait..?.
Utile pour la NBM par exemple, pour gérer le contenu du mail complémentaire suivant la langue (besoin demandé!) ou pour la bannière, etc...
En gros, c'est utile que les données personnalisables... mais peut être appliqué au reste de PWG pour facilité les traductions...
Si j'ai bien compris, c'est une page du site, fonctionnant un peu comme un éditeur.
1) On choisirait la langue concernée dans une liste (basée automatiquement sur les langues disponibles).
2) On entrerait d'une part le mot ou l'expression servant d'appel (équivalent à {lang:xxxxx}) .
3) On entrerait dessous le mot ou le texte à afficher, dans la langue choisie (équivalent à $lang[xxxx] = '').
4) Si il est possible de faire s'afficher la liste des entrées existantes dans le fichier "common.lang.php" de la langue choisie, cela permettrait aussi de pouvoir gérer, modifier les termes utilisés par défaut pour le site !!!!!!!
5) ==>le résultat serait écrit dans le fichier "local.lang.php" lui même enregistré dans le dossier de langue choisie en 1)
Important : Il faut penser à faire s'afficher dans la langue par défaut les mots qui n'auront pas été traduits dans toutes les langues.
On pourrait, comme tu le suggères ajouter des commandes de style. Les basics sont indispensables si on ne veut pas avoir à intervenir dans le php, genre wyswyg. (pour faire simple, au début, on peut ajouter dans le texte les balises html, il suffit de donner les exemples pour les non-connaisseurs, mais à terme, un éditeur type wyswyg est mieux, c'est sur.
C'est une idée sympa, mais réellement utile que pour les pages ajoutées ou / et personnalisables... rare sont les mots et expressions du site de base que les utilisateurs voudront changer, mais qui sait..?.
Je ne prétends pas que cela intéresse beaucoup de monde. Moi oui, mais je saurais me débrouiller sans.
Toutefois, aprés avoir étudié les dev. plus urgent :o))..... , ce pourrait être un atout de plus pour PWG.
amicalement,
éric.