Avis aux créateurs de thèmes
Skyline
Member
dans Annonces officielles
Le 1er janvier vient d'être marqué par la sortie (ou l'annonce) de sites proposant des thèmes pour Pluxml, ce qui me réjouit profondemment car il me prouve que Pluxml intéresse 
Je voudrais pouvoir vous aider dans la réalisation de vos thèmes, non dans la partie graphique du processus (je n'ai pas de talent de graphiste) mais dans la partie code. Plus clairement je souhaite faire en sorte que la réalisation de thèmes pour Pluxml soit facilitée et je compte travailler dessus pour les prochaines versions.
Pour vous, en quoi Pluxml (toutes versions confondues) peut progresser pour vous faciliter la réalisation de thèmes ?
Des idées sont déjà remontées comme la possiblité d'avoir un unique thème compatible avec les deux versions de Pluxml, je pense aussi au sélécteur de thèmes sur la partie publique que je dois toujours publier. Sinon, y a-t-il des remarques sur la sémantique de Pluxml, l'utilisation des id et des class ?
La parole est à vous
P.s. : s'il vous plait, n'oubliez pas que la structure des thèmes n'est pas figée puisque aucune des deux versions de Pluxml n'est au stade de la version finale. Cependant, après consultation auprès des créateurs de thèmes, je souhaite pouvoir proposer une solution qui durera dans le temps pour la structure des thèmes.
Je voudrais pouvoir vous aider dans la réalisation de vos thèmes, non dans la partie graphique du processus (je n'ai pas de talent de graphiste) mais dans la partie code. Plus clairement je souhaite faire en sorte que la réalisation de thèmes pour Pluxml soit facilitée et je compte travailler dessus pour les prochaines versions.
Pour vous, en quoi Pluxml (toutes versions confondues) peut progresser pour vous faciliter la réalisation de thèmes ?
Des idées sont déjà remontées comme la possiblité d'avoir un unique thème compatible avec les deux versions de Pluxml, je pense aussi au sélécteur de thèmes sur la partie publique que je dois toujours publier. Sinon, y a-t-il des remarques sur la sémantique de Pluxml, l'utilisation des id et des class ?
La parole est à vous
P.s. : s'il vous plait, n'oubliez pas que la structure des thèmes n'est pas figée puisque aucune des deux versions de Pluxml n'est au stade de la version finale. Cependant, après consultation auprès des créateurs de thèmes, je souhaite pouvoir proposer une solution qui durera dans le temps pour la structure des thèmes.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et je pense que un pluxml qui pèse 500ko au lieu de 76ko... sa ne change rien, et que via l'administration on choisie, Blog ou Pluxml de base.
Je laisse la parole aux autres, et ensuite je commante lesautres idées.
Dans un autre post, on avait déjà parlé d'un minimoteur de template qui pourrait être développé pour Pluxml. Des irréductibles disent que PHP est le meilleur moteur de template possible, mais disons-le : sur les deux kits que j'avais adapté pour mon Pluxml, j'avais eu du mal avec les deux dans la partie du code "si on est en mode article", etc.
Donc je sais pas comment, mais il serait bon d'améliorer ce point-là.
Deuxio, il m'est arrivé de changer de thème pour des tests, et mon colorisateur syntaxique en javascript, dont le code a été mis dans mon template.php, n'était pas activé et je devais refaire une modification.
Je verrais alors un header et un footer commun à tous les thèmes.
Enfin, l'utilisation des id et des class est bien dans Pluxml, mais 2-3 erreurs de sémantique (pas vraiment importantes) subsistent, ainsi que quelques erreurs de validation (cf. mon post dans le rapport de bugs).
Je te dis ça en détail dès que possible.
Enfin, pour argumenter les propos d'Ali, le fait que Pluxml, de base, fasse le triple de son poinds initial ne me dérange pas du tout. Par contre, pour l'impact publicitaire que cela donnera, je me pose des questions...
En effet, mieux vaut à la fois que le codage de Pluxml soit un plaisir (pas de problème de compactibilité future), que la possibilité de personnalisation soit un plaisir (quoi de plus irritant qu'un truc que l'on ne veut pas -un sous-titre de blog, par exemple (j'ai rien contre ça)- soit imposé, et rende Pluxml non valide si on l'oublie ?
C'étaient mes arguments, je vous laisse le loisir de lire mon long discours :P
PS : Une solution simple au problème de sous-titre est de rajouter un si aucun sous-titre n'est spécifié.
La structure ? Voila comment je la verrais
-- Du haut vers le bas
D'abord, posons la première div ID #body (qui servira à auto-centrer tout le contenu ou lui définir un calibrage précis "800", "1024" ou "full" ou le caler à gauche)
La zone Header comprenant 3 div's en ID (les trois seront facilement activables par CSS -> display: none ou visibility: hidden) mais inscrite "en dur" dans le code du template. Ensuite c'est au choix des designers
- 1) Le logo (gauche, droite ou rien)
- 2) La zone Banner" (pour les pubs du style Adsense Google ou échanges partenariats ...) la aussi, centre, droite ou rien !
- 3) Le Menu Horizontal (comme tu l'avais sur ton ancienne version graphique), il peut y avoir des demandes dans le futur ou même un plug-in style "citations ou autres" qui voit le jour :P
* en annexe et juste après le point 3) une balise avec classe <hr class"hr_top"> pourrait servir de séparateur harmonieux (header / contenu)
Donc ces 3 points sont optionnels de cette manière mais on le mérite d'exister.
On passe au coeur du sujet :
- Le top qui est le conteneur de "page" et le blog (a bé quand même)
- Cette partie pourrait être subdivisée pour accueillir la sidebar_menu latérale, comportant le menu (droite , gauche ou même rien si on choisi un menu horizontal !) et l'ID page qui sera en float: left, right voire display: inline ou block (et le petit plus) une autre définition de sidebar_scrapt je sais plus le nom exact en englich pour les pub's verticales de 400 ou 500px (à positionner à l'opposer de la sidebar_menu tant qu'à faire et activable par CSS optionnel)
En fait on crois que c'est des gadgets mais "je me répète", l'avantage réside dans le codage de ces "points" en dur, disablé dans la feuille de style mais au moins, il n'y a pas besoin d'aller mettre les mains dans le cambouis :mad:
Une seconde balise <hr class"hr_inter"> intercalaire billets/commentaire|/i]
Revenons à l'ID page car il ne faut pas oublier le sélecteur de page en bas du document pour feuilleter les billets (la je pense qu'il faudrais que tu revois différement le code) pour qu'on puisse aller dans les deux sens "montant / descendant" mais c'est pas le but de ce message :rolleyes:
La troisième balise <hr class"hr_bottom"> séparation du sélecteur de page ou pied de page
Il faut aussi inclure une balise ancre #top "haut de page" manquante en ce moment qu'on peut remplacer par une icône si on veut la rendre graphique ...
Il nous reste le pied de page Footer en div ID #foot et pour finir la marque de fabrique juste en dernier toujours en div comprenant les classes "copy" (pour le copyright), "release" (pour la version en cours), "chrono" (pour le temps de génération du document) et "admin" pour passer en "authentification"
Ce n'est qu'un shéma mais çà permet d'entrevoir de grandes possibilités
Voila, j'ai fini mon roman (au suivant ...)
Voilà une tres bonne idée qui mérite une étude approfondie. Je suis du même avis que mon camarade Balou et aussi sur les points soulevé par les autres.
Je verrai tout de même bien le sélecteur de thème par défaut sur pluXML qui permet aussi aux visiteurs de choisir leurs thèmes de prédilection à l'arrivée sur un site.
Le tout est de prévoir les évolutions futurs pour ne pas avoir à retoucher les templates et définir le mode de page : xhtml strict, transitionnel, etc...
Même si pluXML venait à grossir jusqu'à 1Mo, il resterait une version allégé de ce qui peut exister et surtout au vue des quantités d'espace disponible sur le web, cela reste pour le moins tres accessible et rapide (car ont ne charge pas les 1Mo directement).
Cela devient tres interessant et vais étudier dans mon coins des éventualités de séparation contenu / contenant.
Si on m'impose direct un template, c'est plus dur de rendre compactible un thème
Enfin chacun son avis moi je trouve que c'est une bonne idée.
- Séparation totale de toute forme de code. Tout ce qui est Templates, modules futures seraient séparés.
- Faire de PluXML un 'Core' total. Un noyau (1 fichier seul) qu'on doit installer.
- Les templates serais alors indépendant a 100%. Meme que si un intégrateur veux faire un DocType autre que Xhtml strict, il pourrais puisque qu'il controle 100% de la page.
- Les modules qui affiche les sections serait que sous forme de tags. Le script gère les tags a 100%. Le template reste alors très légé.
Perso je fonctionne de cette facon pour mes scripts de clients. C'est a la base plus dur a coder pour le createur du script mais ensuite, est beaucoup plus versatile après !
Je rejoins certain sur ce post qui dise que meme si le PluXML devient plus gros cela n'est pas grave. L'éxécution moyenne des pages reste toujours < 0.5 secondes ce qui est tres bien meme avec des script de 2000ko. Le PHP de serveur est toujours rapide (quoique j'ai deja vu des host lowcost avoir tellement de sites dessus que c'est un peu normal d'avoir un ralentissement)...
Merci de m'avoir lu..
Skyline : Si tu veux, j'accepte ta proposition de forum privé (ie : mon premier topic).
L'optique c'est que tout soit facile d'installation (tout comme la version Blog qui est dans un /core/) et de permettre au Staf de PluXML de bien gérer le support en laissant les possibilité d'erreurs (en mettant le core du script séparé de l'affichage par exemple).
Est-ce plus clair ainsi?
/.admin/ *pages php admin*
/.cores/ *fichiers noyau du script*
/.inc/ *fichiers includes/class/config pour le coté user et admin (protégé en htaccess)*
/.inc/tpl/ usr_*.html *fichiers template pure utilisé pour le user*
/.inc/tpl/ adm_*.html *fichiers template pure utilisé pour l'admin*
La seule remarque que j'ai a faire , c'est l'inbrication de la structure html , il serait plus judicieux d'utiliser , garder par defaut le conteneur #page comme conteneur globale , body n'acceptant pas toujours bien les regles css imposé ( version anterieur d'opera par exemple , qui n'arrive pas a positionné un element ou un fond autrement qu'en em selon les conditions a partir de body en parents direct).
Ce conteneur global faciliterais la mise en forme , (centrage , fluidité totale ou en marge , positionnement d'un pied de page , transfert de min-height 100% sans jonglage perilleux , etc ...) sans compter qu'en xhtml , html, body et un conteneur permettent d'afficher 3 fond , differents , dont un fond de page , un haut de page et un pied de page.
C'est le seul point que je releve qui pourrait grandement faciliter la mise en forme en generale .
Ce conteneur existe deja et englobe #content et #sidebar par defaut (pluxml blog) et sans reel interet , #content et #sidebar se suivant dans le flux et etant 2 conteneurs distinct , je ne vois pas la raison de son existence.
Chaque zone (entete, contenu ,menu, pied) a un 'id' qui lui sert d'ancre.
Ce n'est que mon avis et je n'ai pas encore fait grand chose avec pluxml pour en percevoir toutes ces facettes.
GC
a méditer Skyline non ?
Nouvelle utilisatrice de Pluxml, je nen reviens pas de ce combo puissance/simplicité, le tout en XML, CSS et francais ...
Et en plus Skyline le créateur qui propose son aide pour coder des modifs sur le theme, merci ^^
Donc j'aurais surtout 2 demandes, en rapport avec mes besoins actuels, peut etre que j'aurais plus de souhaits/idées avec le temps, mais pour linstant voila ce ki me taraude pour exploiter davantage le coté CMS que BLOG :
- les Catégories pointant vers le CONTENU et non le chapo avec le lien vers le contenu (en fait ca serait le meme lien que celui proposé sur le titre de l'article ou sur Lire : ...)
En fait je considere un article comme une PAGE de contenu, donc il n'y a qu'une page liée a une catégorie.
Actuellement je ne remplis que le chapo avec une suppression de la ligne "Lire: ..." pour aboutir sur la page directement.
- Ajouter une Sidebar HORIZONTALE ds le header, en plus de la sidebar vertical sur le coté du site, avec gestion ds ladmin.
Pour linstant je compte ajouter des articles (page) et récupérer les liens en durs pour les images de rubrique ds le header (en mode HOME biensur).
J'ai lu la soluce de plrs pluXMl imbriqués mais cela compliquerait l'admin et mon client est un gros néophyte je ne vais pas lui imposer cela ^^
Ensuite une derniere petite chose, ce serait juste un formulaire de contact intégré d'office (quoique j'ai récupérer une solution fourni par un site tiers, a tester) et surtout qques boutons pour insérer des balises BBCode type Retour a la ligne, Saut de ligne, Gras, Couleur, Liste et prkoi pas Lien.
Juste de koi permettre au néophyte (qui est qd meme le coeur de cible de cet outil), de ne pas se retrouver avec un pavé de texte uniforme peu lisible et esthétique.
J'ai lu ds le forum qu'une intégration d'un éditeur HTML était possible mais sans aller juska l'usine a gaz non plus, ce ki revient au meme pour le néophyte !
Voila jespere avoir été claire, sinon je suis pret a détailler
Des que j'aurais fini le design et son intégration ds le theme pluXML, je donnerai l'url pour voir à l'oeuvre les modifs sur les Catégories par ex.
Je termine en précisant que je suis pour l'intégration des 2 versions de PluXML dans une seule, avec un choix de l'orientation CMS ou BLOG ds ladmin géré par exemple via menu déroulant ou bouton radio ?
Merci de m'avoir lu jusquau bout, de vos apports a tous, et surtout a Skyline
Je précise que je suis graphiste/webdesigner et que g envie de particper activement au développement de cette solution en donnant ma pierre a l'édifice, c a d proposer des themes originaux et surtout qui vont plus loin que le seul changement de l'image du header
sur le forum boite a idées , tu trouveras quelques propositions des membres pour le formulaire.
A la recherche de cette fonction , je viens de proposer 2 nouvelles idées , l'une Genre plug-in et une autre reutilisant surchargeant legerement la fonction qui gere les commentaire.
Pour ces 2 pistes que je vient de tester , il est possible d'envoyer un mail a une adresse predeterminée.
le premier en simili plug-in que je propose de tester et de commenter est en fin de ce topic :
http://forum.pluxml.org/viewtopic.php?id=220
(gestion des erreurs et envoi de mail)
et celle se greffant dans le fichier class.pluxml.php
(pas de gestion d'erreur ni de confirmation , use du formulaire commentaires , beneficie du capcha et peut-etre affiché ou non en passant par l'admin , page "contact" créer a l'install ).
Cela fait 3 approches differentes avec celle qui a ouvert le premier topic.
d'ailleurs avec ce topic http://forum.pluxml.org/viewtopic.php?id=332
tu as aussi une autre variante , 3/4 approches en 15 jours ...
Ma demarche/recherche est effectivement un formulaire integré et qui se fonde dans et avec pluxml quelque soit le theme utilisé , ce qui semble correspondre en partie a ta demande.
Pour l'editeur html "integré" une option aussi prete a l'emploi est proposé la :
http://forum.pluxml.org/viewtopic.php?id=342
(tout ces post sont recents !? ).
Pour la side bar horizontal , rien vu ... ou remarqué .
GC
re_impec ....
Pour mon cas particulier cela ne devrait pas changer grand chose puisque je v faire des images voir meme une anim flash ds le header, mais c une bonne option pour les projets futurs
Sinon au fait kelles seront les "features" de la prochaine version béta, et sil y a peut etre une date de sortie prévue ...? jen demande peut etre bcp
Sinon merci gcyrillus pour tes réponse, en effet jai déja téléchargé ta soluce de formulaire de mail