Allo,

A chaque fois que je monte un site avec Xoops, je suis obligé de mettre des hacks partout, tout simplement parce que je ne suis jamais satisfait du rendu du core ou des modules et ce n'est pas parce que je suis perfectionniste, mais quand on fait un site, on a des idées bien en tête donc il est normal de devoir effectuer des changements. Du coup tenir un site à jour devient tout de suite compliqué, voir impossible plus on rajoute des hacks.

Mon message n'était pas la pour vous donner la solution miracle, même si y'a surement des moyens technique à coup de comparaison pour restaurer des hacks.

Non en fait je trouve ca pénible, mais on peut pas faire autrement, pour cela faudrait que les développeurs prévoient tous les cas de figure inimaginable. Ne serait ce que prévoir le nom des classes pour telle ou telle partie du site, sans avoir à aller harcodé ca directos dans un fichier.

Qui met des hacks partout sur ces sites ? ;)

A+

Salut king76 ,


Hélas , je crois que faire des hacks sera toujours une obligation .
Si on n'entre pas dans un moule déjà prévu , que faire sinon des hacks .
Il est impossible de prévoir tous les cas , meme si on peut faire un moule trés large .

Depuis de très nombreuses années j'ai vu des systèmes plus ou moins performants .
Mais à chaque fois , il a toujours fallu faire des hacks , ou paremetrages ou adaptations.
On utilise plusieurs termes , mais le resultat est toujours le meme , il faut changer et adapter .
Plus l'application concernée est complexe , plus il est normal de s'attendre a avoir des hacks à faire .


Je pense que tous les efforts pour les concepteurs, sont justement de faire en sorte que les hacks à faire soient les moins douloureux possibles .
Mais prétendre faire un système sans hack est une pure utopie .

Apres , c'est une question de choix et de compromis .
Soit on accepte d'avoir des contraintes , sans hack , mais on doit vivre avec des fonctionalités limitées.
Soit on veut certaines choses et la , fatalement on est condamné a faire des hacks .


Dans ce monde , tout évolue , tout se transforme , il faut s'adapter , et l'informatique comme tout autre chose , ne peut qu'obeir à cela .
La vie n'est qu'une suite de hacks et tant mieux , sinon ca ne serait pas la vie


Alors pour répondre a ta question , oui je mets des hacks partout , dans les programmes , dans ma maison , dans mes sentiments , dans ma vie .

En ce qui me concerne, j'essaie d'éviter au maximum pour faciliter les montées de versions des modules.

j'ai pas mal travaillé avec des "progiciels" complexes auparavant. Le coût des de montées de version est non négligeable. Avec le modèle open source les nouvelles versions sont fréquentes (ce qui est plutôt bien pour la robustesse des modules). Toute adaptation n'est pas à prescrire mais les futurs acheteurs ne sont pas prêt à payer la totalité du temps nécessaire (documentation, évaluation des impacts lors de la montée de version, tests, ..). Le fait de rester dans les standards ne supprime pas toutes les étapes mais facilite grandement le suivi des versions.

Il est vrai que je ne suis pas opérationnel côté codage php, ceci conforte le souhait de rester aussi proche du "standard" que possible

Tout ceci est à modérer en fonction des acheteurs potentiels, il est vrai que jusqu'à présent je n'ai pas approché d'acheteurs ayant un projet avec un budget conséquent. La conséquence importante c'est qu'ils ne veulent consacrer qu'un budget minimaliste pour avoir un site (moins de 2000 euros en moyenne).

Salut,

En fait mon premier message restait discret sur ce que j'avais en tête. Il est clair que je ne peux pas venir ici et dire "il existe d'autres cms mieux que Xoops qui permettent de faire ca et cela.. etc..", car en réalité même si un CMS permet de faire des choses mieux qu'avec Xoops, il sera plus faible dans d'autres orientations (un cms très puissant n'est parfois pas adapté pour faire des communautés ou pour une prise en main rapide..)

Bref, pour répondre à la question de Denis, oui il existe des cms qui permettent d'appliquer des hacks sans modifier le core et donc ce n'est pas une utopie, je ne vais pas citer de nom ici, on pourrait imaginer que je trahirais Xoops en le comparant à d'autres solutions, mais pour expliquer le système.

Imagine que l'ensemble des éléments affichés à l'écran avec Xoops étaient stockés dans un immense tableau (array) exemple

Page des profils de Xoops :

xoops['profil']['login']['valeur']

Il suffirait alors d'écraser la valeur de cette cellule pour modifier la valeur.

xoops['profil']['login'][class']

Il suffirait de modifier cette valeur pour changer la class qui englobe l'affichage du champ login

xoops['profil']['login']['titre']

Il suffirait de changer cette valeur pour changer le titre du champ devant la valeur

Etc .. et imagine que tu pourrais faire la même chose pour d'autres éléments du site

xoops['module']['sondage']['23']['auteur']['class']

La tu pourrais modifier l'apparence d'un auteur d'un sondage (numéro 23) par exemple.

Ce ne sont que des exemples, car dans la réalités j'imagine que ce serait plus puissant.

Mais avec un tel système qui existe deja dans d'autres produits, tu peux facilement avec ton fichier de configuration ecraser les valeurs produites par le cms, ce qui rend les possibilités plus puissante et surtout portable ! Une nouvelle version sort sur le même procédé, hop tu appliques ton "patch" et tu retrouves ta version

Tout ça pour dire, que je me rend compte de plus en plus que les hacks sont un frein pour Xoops, car le fait de ne pouvoir migrer vers une nouvelle version, rend nos développement et mis en place de site rapidement obsolètes, et je trouve ca pénible ;-(

A+

bonsoir,

as-tu pris contact avec l'équipe qui développe la 2.2? Peut-être qu'il n'est pas trop tard pour que les hacks soient plus facilement pris en compte?

Citation :

Malheureusement suis pas assez bon en anglais pour expliquer des trucs qui font plus de deux lignes ;)

Et puis ce type de procédé à mon avis n'est possible qu'avec une refonte de Xoops ce qui est normalement prévu avec XoopSphere

Ceci dit oui, une équipe "HACK" dans le core ce serait vraiment génial, pour analyser et mettre à jour des "petits" hack dans le core, suis certain que ce serait ce genre de petits détails qui pourraient faire la différence. C'est ce que j'ai remarqué en testant Tikiwiki par exemple.. beaucoup d'options vraiment génial.

a+

Bonjour king76,

j'avais commencé il y a quelques temps déjà un module qui "gère" les hack. De mémoire (ça date) les fonctions étaient :

- liste des fichiers hackés avec date des dernières MAJ
- copie de sauvegarde du fichier initial (sans hack)
- insertion du hack directement dans le fichier en indiquant la ligne et le code à insérer
- comparaison du fichier hacké avec le fichier initial : colorisation des lignes ajoutées (en réalité, autodétection des hacks par une balise spécifique au début et à la fin du code ajouté)
- lors des mises à jours du noyau de xoops, les fichiers qui normalement doivent être hackés et ne le sont plus (car mis à jour) sont signalés. On peut ainsi rapidement insérer le code du hack dans les fichiers qui posent problème.

Attention toutefois, ce module n'est même pas une version alpha, et niveau sécurité ça craint vraiement. De plus, il nécessite certaines fonctions PHP activées sur le serveur : lecture et colorisation du code source PHP (dans mon cas ça fonctionnait super bien en local, mais pas en ligne). Ces pour ces raisons, je ne préfère pas jeter en pature le code source de ce module. Cependant, je peux donner le module nommé hack a qui veux bien le tester et surtout le faire évolué (plus de compatibilité, plus de sécurité, ajout de fonctions ...).

J'espère que ça pourra t'aide et que quelqu'un (ou un groupe de programmateur) prendra la suite.

Très intéressant !! Car j'avais dans l'idée de faire un truc identique y'a deja quelques mois (http://dev.xoops.org/modules/newbb/vi ... ost_id=5377#forumpost5377)

Sauf que ca ne sera jamais accepté cause de sécurité, aussi je pense qu'il faudrait mieux s'orienter vers une application offline

1. Garder une version de Xoops Sans Hack pour comparaison avec la nouvelle version
2. Appliquer un ensemble de hack avec des règles précises (test, comparaison, patch, etc..)
3. On obtiendrait une version repatché avec l'ensemble des hacks et une version XoopsHack de la version en cours (Xoops 2.0.13 par exemple)

Le but étant de sortir une version spécial avec le plus de hack possible (les plus utiles et les meilleurs..)

Enfin c'est une idée, car le mieux c'est sans doute de choisir les hacks dans une liste, et appuyer sur PATCHER pour patcher son xoops.

Je veux bien le code, mail moi ca stp : king76 AT gmail.com

merci

King : mail envoyé.

Inutile de garder une version complète de xoops "vierge" : tu verras dans mon module, je garde une copie des fichiers avant leur hackage.

Le problème vient que la plupart des hébergeurs empêche la lecture du code source d'un fichier par un script avec une fonction PHP highlight_file ou highlight_string. Je pense que cela peut être contourné. Dans ce cas, pour la sécurié, on peut toujours utiliser la bonne vielle méthode du fichier .htaccess dans un premier temps.

Pourquoi pas lister en effet tous les hacks pour une insertion encore plus facile, avec un dossier à la manière des plugin du module sitemap (que les développeurs de modules pourront incorporer dans leurs propres modules). Avec comme variables par exemple :
$hack[file] = à insérer dans le fichier X
$hack[after] = après la ligne contenant ce texte Y
$hack[code]= avec le code Z

Allo,

Je n'ai pas vu comment était fait les plugins du module Sitemap, mais de toutes les manières il faut quand même aller modifier les fichiers ? Je vois pas comment en ajoutant un plugin ca pourrait altérer le fonctionnement (donc appliquer un hack) sur un ou plusieurs fichiers ?

a+