Include fichier dynamique

Version imprimable

Voir 40 message(s) de cette discussion en une page

27/01/2010, 17h31
Général03

Include fichier dynamique
Bonjour,

l'arborescence de mon site est comme cela
Code:

1 2 3 4 5 6 7 8 |- page1.php |-scripts |- fichier.php |- js |-javascript.js |- admin |- page2.php |-...
Je dois appeler dans page1 et page2 le même script fichier.php à partir de mon javascript javascript.js
Or je ne sais pas quoi mettre dans javascript.js car page1 est placé à la racine alors que page2 est dans un dossier admin.

Si je met "../scripts/fichier.php" le require fonctionne pour page2 alors que si je met "./scripts/fichier.php" c'est page1 qui fait le lien.
Comment faire un include dynamique depuis page1.php et page2.php vers fichier.php ?

Merci
27/01/2010, 18h57
riete

Peut être que je n'ai pas les idées claires mais ....:aie:

Citation:

Comment faire un include dynamique depuis page1.php et page2.php vers fichier.php ?

A priori ce serait plutôt statique étant donnée que la position des fichiers est statique non ?
Je n'ai pas bien compris qui appelle qui :?
En gros ../ te permet de remonter d'une branche dans l'arborescence pour deux tu ferais ../../. Et avec / tu démarre de la racine du serveur.
Si tu exécute ton script depuis admin et que tu veux charger fichier.php qui se trouve dans script, il faut appeler: ../scripts/fichier.php.
Il faut juste ne pas s'embrouiller.
27/01/2010, 19h27
Général03

En faite le cheminement de traitement est le suivant

Code:

page1.php -> javascript.js -> fichier.php

et

Code:

page2.php -> javascript.js -> fichier.php

Or la page 1 et 2 ne sont pas au même endroit donc que dois je mettre dans mon fichier javascript.js pour appeler ce fichier "fichier.php" ?

J'espère avoir été clair, merci de ton aide

Salut

Et si tu essayais en mettant un chemin complet ?
Exemple :

Code:

<script type="text/javascript" src="http://www.domaine.com/js/javascript.js"></script>

Une autre petit truc, c'est de définir dans le HTML le répertoire du wwwRoot avec un : base href.
Ca se place dans le <head>, exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 <!DOCTYPE ... > <html> <head> <title>page</title>  <base href="http://www.domaine.com/" /> <script type="text/javascript" src="js/javascript.js"></script> </head> <body> ... bla bla bla </body> </html>
Ensuite, tous les fichiers seront en relations de ce chemin, comme les images, css, etc ...
Théoriquement ça devrait le faire.

29/01/2010, 09h25
riete

Je comprends mieux ton problème.

La proposition de RunCodePhp fonctionne à coup sûr, mais l'inconvénient est la non portabilité du code sur un autre site. Par exemple si ton site est testé en local et que tu transfert ton code vers un hébergeur.

Je te suggère donc d'utiliser la variable $_SERVER['DOCUMENT_ROOT'] puis d'y concaténer le chemin absolu de la page appelée.
29/01/2010, 10h42
RunCodePhp

Citation:

Envoyé par riete

Je comprends mieux ton problème.

La proposition de RunCodePhp fonctionne à coup sûr, mais l'inconvénient est la non portabilité du code sur un autre site. Par exemple si ton site est testé en local et que tu transfert ton code vers un hébergeur.

Disons que j'allais y venir, je ne voulais pas mettre la charrue avant le boeufs ... faut savoir en 1er si la technique était la bonne.
Mettre "en dur" les chemins dans un 1er temps ça va bien plus vite pour le vérifier ... après on essai d'automatiser ça, rendre les chose plus "dynamiques".

A coté de ça, un $_SERVER['DOCUMENT_ROOT'] renvoie un chemin type "physique", en relation avec le disque, ça ne renvoie pas une URL quoi.
Faut distinguer 2 types de chemins :
- type URL : http://www.domaine.com
- type physique : /web/domaine/www/

Dans un cas comme celui ci, avoir un fichier genre config.php qui définirait une bonne fois pour toute les différents chemins serait une solution (parmi d'autres).
S'il y a un changement d'hébergeur ou de nom de domaine, suffit de mettre à jours le contenu config.php et tout le reste suivra.
29/01/2010, 16h29
Général03

Je vais essayer de résumer tout ça. Il existe 2 chemins, celui sur le disque ou celui du serveur. Dans le cas d'un serveur mutualisé il faut utiliser le chemin URL.
Pour fixer la base de ce chemin url il faut faire en html

Code:

<head><base href="http://www.domaine.com/" /></head>

Je m'interroge sur plusieurs points :
- en utilisant un chemin absolu en dur (sur <link> par exemple) ca fonctionne par contre si je met ma <base> dans un fichier html qui fait un include d'une autre page html ça ne fonctionne pas. Normal ou pas ?
- la portabilité de la solution <base> sur un autre site est elle possible ? Ou faut il à chaque fois modifier le <base href=""> ?
- en php quelle est la variable qui puisse me donner la racine URL du site

Merci
29/01/2010, 18h32
riete

Je pense qu'il n'y a pas de solution idéale, mais un mix à faire en fonction de la destination du site et du mode d'hébergement qui doit en être fait.

La Balise <Base> est à mon avis plutôt destinée à du HTML static. Dans le cas ou le code est construit dynamiquement, il vaut mieux réservé à PHP le soin de construire toutes les formes de liens.

Comme le précise RunCodePhp, soit tu construis tes liens à chaque fois, soit tu utilise un fichier de variables qui contient le nom de tes pages.

Citation:

Il existe 2 chemins, celui sur le disque ou celui du serveur. Dans le cas d'un serveur mutualisé il faut utiliser le chemin URL.

Le chemin reste celui du disque sur lequel le services http est hébergé. L'URL est le chemin à partir de la racine du service mis à dispo pour le client http.
Le chemin disque absolu est celui qu'il faut absoluement utilisé car il est valable quelque soit la machine sur laquelle se trouve hébergé ton site.
Si tu veux t'en convaincre fais toi-même l'essai sur plusieurs type d'hébergement

Code:

echo $_SERVER['DOCUMENT_ROOT'];

Citation:

Envoyé par Général03

- en utilisant un chemin absolu en dur (sur <link> par exemple) ca fonctionne par contre si je met ma <base> dans un fichier html qui fait un include d'une autre page html ça ne fonctionne pas. Normal ou pas ?
- la portabilité de la solution <base> sur un autre site est elle possible ? Ou faut il à chaque fois modifier le <base href=""> ?

Tu donnes la réponse à ta question au dessus :aie: ;)

Citation:

Envoyé par Général03

- en php quelle est la variable qui puisse me donner la racine URL du site

Je n'en connais pas, tu peux aussi la construire dans un fichier de paramètre avec Document_ROOTsi tu le souhaite.
Est ce plus clair ?
@+

Citation:

Envoyé par Général03

- en utilisant un chemin absolu en dur (sur <link> par exemple) ca fonctionne par contre si je met ma <base> dans un fichier html qui fait un include d'une autre page html ça ne fonctionne pas. Normal ou pas ?

Un <base> c'est du HTML, par conséquent cela n'affectera que le HTML et que la page en court (rien avoir avec Php : include ou require ).
Il n'y a pas à le modifier partout, il faut juste qu'il y soit, et qu'il soit adapté selon le contexte. De ton coté tu as 2 contexte : partie public et l'admin.

Aussi, un <base> n'est peut être pas forcement une bonne solution dans ton cas, ça peut justement compliquer plus qu'autre chose.
Si tu n'adhère, et bien n'utilise cette technique tout simplement.

Citation:

Envoyé par riete

Si tu veux t'en convaincre fais toi-même l'essai sur plusieurs type d'hébergement

J'ai essayé sur mon poste en local certes, et cela ne fonctionne pas ... pas sur un <link>, et ça me semble normal, un DOCUMENT_ROOT ne retourne pas une URL.

Ton cas est un peu particulier car en quelque sorte, tu as 2 sites au sein d'un même site :
- Une partie publique à la racine : www/index.php
- Une partie privé d'aministration : www/admin/index.php

Quelque part, la racine de l'administration serait : www/admin/
De plus, tu exploite certain contenu communs comme du Css et Javascript.
Puis qui ssait, peut être prévois tu du Css, Javascript, des images même propre à cette partie admin.
Exemple :
www/admin/css/
www/admin/js/
www/admin/images/

Ce qui pose problème c'est cette admin.
Et bien suffit à chaque fois utiliser des chemins complet, que ce soit des chemin physiques ou absolu.

Il faudrait alors définir un fichier config du genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 $domaine = 'domaine.com'; $www = 'www.domaine.com'; $http = 'http://www.domaine.com'; $publicPhysique = '/web/domaine/www'; $publicHttp = 'http://www.domaine.com'; $adminPhysique = '/web/domaine/www/admin'; $adminHttp = 'http://www.domaine.com/admin'; etc ... etc ... le tout c'est d'avoir ce qu'il faut pour pointer sur les divers fichiers.
Et l'exploiter coté html :
Code:

1 2 3 4 5 6  <html> <head> <script type="text/javascript" src="<?php echo $publicHttp; ?>/js/javascript.js"></script> </head>
Code:

1 2 3 4 5 6  <html> <head> <script type="text/javascript" src="<?php echo $publicHttp; ?>/js/javascript.js"></script> </head>
Ceci n'est qu'un exemple simpliste, va falloir approfondir, améliorer, c'est certain.
Certaines config pourraient aussi être stocker dans une Bdd au lieu dans ce fichiers config (mais pas l'essentiel comme les chemins).

Je ne peux pas te donner un fichier de config "type", car à mon avis il existe autant de manières différentes qu'il existe de projet.
Certains projets utilisent des fichier de type INI, d'autres essentiellement des variable, ou un tableau rassemblant le tout, mais encore d'autres utilisent des constantes.
De mon coté j'utilise des constantes, car cela à l'avantage qu'une constante ne peut être redéfinie.
Exemple :

Code:

define('DOMAINE', 'domaine.com');

En tout cas, à partir du moment où les chemins sont complets, il n'y a aucune raison que le serveur ne trouve pas les fichiers, le tout c'est de les définir 1 seul fois et y faire référence dans tout le projet, sans exception.

En tout cas utiliser des chemins "relatifs" du coté admin me semble pas une solution, car si un jour tu décide de déplacer un répertoire, c'est certains codes qui ne fonctionneront pas, et là c'est galère ...

Citation:
Envoyé par RunCodePhp
Code:

1 2 3 4 5 6 7 8 9 10 11 $domaine = 'domaine.com'; $www = 'www.domaine.com'; $http = 'http://www.domaine.com'; $publicPhysique = '/web/domaine/www'; $publicHttp = 'http://www.domaine.com'; $adminPhysique = '/web/domaine/www/admin'; $adminHttp = 'http://www.domaine.com/admin'; etc ... etc ... le tout c'est d'avoir ce qu'il faut pour pointer sur les divers fichiers.
8O J'ai du mal me faire comprendre.
A mon avis, il ne faut surtout pas utiliser ce genre de fichier. Au moins la partie 'http', il suffit de spécifier le chemin à partir de la racine serveur, d'ou l'utilité de DOCUMENT_ROOT.
Suggestion:
Code:

1 2 3 4 5 // Fichier de conf $Admin_Path = "/admin/"; // Appel depuis le code php require_once($_SERVER['DOCUMENT_ROOT'].$Admin_Path."page2.php");
Cette méthode fonctionne dans tous les cas (jusqu'à preuve du contraire ;) )

01/02/2010, 12h42
RunCodePhp

Citation:

8O J'ai du mal me faire comprendre.

Ou c'est toi qui a du mal à comprendre :mouarf:

J'déconne ;)

Concernant les require ou autre include, ok ...
Mais pour un <script></script>, c'est à dire importer un Javascript par exemple, et bien j'ai fais un essai, ça ne marche pas avec un $_SERVER['DOCUMENT_ROOT'].
Fais un essai ;)

Bon, je me suis contenté de faire cette essai uniquement en local, mais si déjà en local ça ne marche pas, alors on ne peu plus parler de portabilité.

Puis je ne vois pas en quoi avoir un fichier config rassemblant toutes des données comme les chemins, etc ... poserait un problème.
Quasi tous les CMS et autres FrameWork procèdent ainsi ...

Puis il y a des cas de figure ou il est impossible de faire autrement que de définir un chemin ne serait ce qu'1 fois en "dur" car ni Apache ni Php n'en connait l'existence, comme par exemple si on déporte une librairie de code Php ailleurs que dans le webRoot (ou répertoire virtuel).
Bref ... tous les fichiers ne se trouvent pas obligatoirement au niveau du serveur Web.
02/02/2010, 15h43
riete

Citation:

Envoyé par RunCodePhp

Concernant les require ou autre include, ok ...
Mais pour un <script></script>, c'est à dire importer un Javascript par exemple, et bien j'ai fais un essai, ça ne marche pas avec un $_SERVER['DOCUMENT_ROOT'].
Fais un essai ;)

T'as du un peu trop :zzz: au soleil ;)
J'ai environ 3500 scripts qui fonctionnent de cette façon sur des serveurs en exploitation.
Donc on dira que j'ai déjà fait quelques essais non ?
02/02/2010, 16h20
RunCodePhp

Citation:

Envoyé par RunCodePhp

Bref ... tous les fichiers ne se trouvent pas obligatoirement au niveau du serveur Web.

Soit tu comprends pas, soit tu fais exprès de ne pas comprendre.

Toujours est il qu'il n'y a pas qu'une seule et unique façon d'organiser son ou ses projets, sans compter qu'il peu très être différents entre en local et sur serveur distant.

Je me tue à te dire qu'un DOCUMENT_ROOT dans certain cas ne pourra jamais trouver le fichier vu que le fichier ni s'y trouve pas justement.
Renseigner "en dur" le chemin devient obligatoire.

Pour exemple, tu as un webRoot dans D:/wamp/www/projet1/index.php
Et les librairies Php dans : D:/phplib/communs/classes/PdoMySQL.php

Tu ferais comment pour inclure PdoMySQL.php dans index.php ?
Avec un $_SERVER['DOCUMENT_ROOT'] ????

Faut bien définir le chemin quelque part, peu importe où, mais il faudra l'écrire.

Petite info météo à la Réunion.:)
Il pleut ... :pleure:
Bah, c'est les tropiques, et c'est la saison des pluies ... alors il pleut :)
Par contre il faut chaud ... mais alors ...
8-)
02/02/2010, 19h17
Général03
Je vais opter pour la solution de RunCodePhp avec un fichier de config qui contiendra tous mes chemins en utilisant define(). Pour inclure mes fichiers en PHP ca ne me pose pas de problème. J'aurais voulu vous parler de php.ini, ne serait il pas aussi une solution pour enregistrer les chemins à chercher pour éviter d'inclure le fichier de config sur chaque page.

Citation:

Ton cas est un peu particulier car en quelque sorte, tu as 2 sites au sein d'un même site :
- Une partie publique à la racine : www/index.php
- Une partie privé d'aministration : www/admin/index.php

Quelque part, la racine de l'administration serait : www/admin/
De plus, tu exploite certain contenu communs comme du Css et Javascript.
Puis qui ssait, peut être prévois tu du Css, Javascript, des images même propre à cette partie admin.
Exemple :
www/admin/css/
www/admin/js/
www/admin/images/

Ce qui pose problème c'est cette admin.
Et bien suffit à chaque fois utiliser des chemins complet, que ce soit des chemin physiques ou absolu.

:mouarf:, tout a fait tu as bien compris. Si j'ai bien compris en javascript il faut que je mette un chemin comme cela
Code:

1 2 3 4 <html> <head> <script type="text/javascript" src="<?php echo $publicHttp; ?>/js/javascript.js"></script> </head>
Merci pour vos remarques
02/02/2010, 20h32
RunCodePhp

Citation:

Si j'ai bien compris en javascript il faut que je mette un chemin comme cela

C'est ce que je suggère.
Mais ça reste une méthode, comme d'autres, ce qui veut dire que celle suggérée par riete en est une aussi ;)

Il faudra tout de même faire des essais, car ton arborescence est particulière sans compter le fait de vouloir exploiter du Javascript + Css communs dans 2 parties (arborescences) différentes.
C'est pas dit que cela fonctionnera comme prévu.

Prenons un exemple simple sur le Css.
Admettons que tu ai ceci :
--- Partie Publique ---
www/index.php
www/css/stylePublic.css
www/images/fond.png

Dans la feuille de style stylePublic.css une classe comme ceci :
.fond { background: url("images/fond.png") }

--- Partie Privée ---
www/admin/index.php

Si tu mets une DIV dans le index.php de la partie publique qui appelle la classe "fond", l'image devrait s'afficher.

Part contre, je ne suis pas certain de l'image s'affichera pour une DIV + classe "fond" dans le index.php de la partie privée.
Il est fort probable que l'image soit recherchée dans un répertoire images située dans la partie admin, ce qui n'est pas le cas.

Faut voir un peu plus loin que le simple import des Css et Javascript.
03/02/2010, 10h06
riete

Citation:

Envoyé par RunCodePhp

Soit tu comprends pas, soit tu fais exprès de ne pas comprendre.

Toujours est il qu'il n'y a pas qu'une seule et unique façon d'organiser son ou ses projets, sans compter qu'il peu très être différents entre en local et sur serveur distant.

Si si je comprends, je suis d'accord avec toi pour dire qu'il n'y a pas qu'une seul façon d'organiser son projet. Il y en a juste des portables et des non portables ;).

Citation:

Envoyé par RunCodePhp

Je me tue à te dire qu'un DOCUMENT_ROOT dans certain cas ne pourra jamais trouver le fichier vu que le fichier ni s'y trouve pas justement.
Renseigner "en dur" le chemin devient obligatoire.

Pour exemple, tu as un webRoot dans D:/wamp/www/projet1/index.php
Et les librairies Php dans : D:/phplib/communs/classes/PdoMySQL.php

Voici un bon exemple de ce que je dis plus haut. Essaye de mettre ces chemins sur des serveurs hébergés sous Linux ou autre chose que Win, tu va voir comme ils fonctionneront bien ;)

Citation:

Envoyé par RunCodePhp

Petite info météo à la Réunion.:)
Il pleut ... :pleure:
Bah, c'est les tropiques, et c'est la saison des pluies ... alors il pleut :)
Par contre il faut chaud ... mais alors ...
8-)

Bon alors ce doit être un séjour prolongé à proximité des coulées de lave alors:rire:
Maintenant, chacun fait sa propre expérience et en tire les conclusions qui lui semblent s'imposer. Wait and see 8-)
a+
03/02/2010, 11h13
RunCodePhp

Citation:

Envoyé par riete

Maintenant, chacun fait sa propre expérience et en tire les conclusions qui lui semblent s'imposer. Wait and see 8-)
a+

Et bien justement, je crois qu'il t'en manque une d'expérience, un crash disque en plein développement ... soit une journée de travail au minimum de perdue.
Je ne parle même pas des dégâts si on n'as de sauvegarde antérieur.

Tu oubli qu'un projet se développe et se maintient avant tout en local, donc chez soi, pas directement sur le serveur distant.

Encore une fois, ta méthode suppose que tous ce trouve dans le WebRoot, absolument tout.
Personnellement, je préfère 100 fois avoir un poil en moins non portabilité et de séparer les librairies du projet, j'évite de mettre tout dans le même panier.

Concrètement, j'ai le projet qui est placé dans le disque C, et les librairies dans un autre disque D.

Comme je travail uniquement sur Win. et le serveur distant est obligatoirement linux de même que ce n'est pas tous les 4 matins que je change d'hébergeur, ces 2 point sont parfaitement connue et ne changeront pas avant ... longtemps.
Au bout, une seule alternative suffit pour savoir sur quel système je suis, et définir les chemins en relation.

La fonction set_include_path(get_include_path().PATH_SEPARATOR. chemins_root et chemin_particulier); est là pour simplifier les choses.

Bref ... il n'y a pas de méthode universelle, et la portabilité n'est pas seule donnée à prendre en compte.
La tienne en est une, elle ne me convient pas, pas en terme d'organisation.

Pour continuer dans le cas présent, c'est à dire que les fichiers JS et CSS se trouvant dans le WebRoot, les importer en indiquant une Url absolue (htt://etc...) me semble mieux.
Si on l'importe avec un chemin "physique", il suffit d'afficher le code source de la page HTML pour y voir en clair l'arborescence du serveur, c'est à dire de voir un chemin comme : /web/espaceRoot/www/js/javascript.js
Ce genre d'info ne devrait pas apparaitre dans une page Web, c'est faciliter le travail à un pirate.
J'adhère pas à ce principe :cry:

Tu n'aurais pas besoin d'un peu d'soleil par hasard ?
:lun:
03/02/2010, 11h48
Fladnag

Si je suis plutot d'accord sur le fait qu'un projet *peut* se maintenir ou se développer en local, mais on peut aussi mettre en place une architecture pour le maintenir a distance.

Personnellement, j'ai la flemme de gérer un LAMP chez moi, donc c'est souvent EasyPHP ^^
Mais les solutions suivantes existent et sont faciles a mettre en oeuvre pour développer en distant :
* Editeur texte ou IDE qui fait du FTP a chaque sauvegarde de fichier (ca a l'air lourd mais pas tellement)
* .htaccess bien parametré (pour éviter les acces non souhaités, il suffit d'autoriser uniquement son IP a acceder au dossier dans lequel on travaille)

Les avantages :
* Une configuration ISO pro... que celui qui n'a jamais eu un code qui marchait différemment sur sa plateforme de dev et de prod lorsqu'elle est différente me jete la premiere pierre ^^
* Bien souvent des solutions de backup (les serveurs sont plus backup que les PCs individuels)

Les inconvenients :
* Plus d'internet = plus de boulot du tout

En général je respecte donc le schema suivant :
* Si je touche a la config ou aux fichiers .htaccess : developpements/tests en local
* Sinon, developpement en local parce que je suis feignant, mais idéalement développement en distant.
* Avant mise en prod, tests et ajustements en distant obligatoires.
* Que ce soit en distant ou en local, backup du code, idéalement avec un gestionnaire de configuration (SVN ou autre)
03/02/2010, 12h58
riete

Citation:

Envoyé par RunCodePhp

Et bien justement, je crois qu'il t'en manque une d'expérience, un crash disque en plein développement ... soit une journée de travail au minimum de perdue.
Je ne parle même pas des dégâts si on n'as de sauvegarde antérieur.
Tu oubli qu'un projet se développe et se maintient avant tout en local, donc chez soi, pas directement sur le serveur distant.

:D ce serait très long a expliquer, mais si tu savais depuis quand je mets les doigts dans le cambouis, tu ne dirais pas cela. L'expérience n'est pas obligatoirement quelque chose que l'on aquière dans l'erreur et la difficulté, mais aussi dans l'anticipation ;). Je te sens un peu trop fougeux

Ne pas développer en local quand c'est possible, mais sur un volume réseau. Ce volume réseau en RAID5 minimum et en plus un cluster du volume ou de la machin qui héberge le volume, avec en prime 2 rotations de sauvegardes automatique sur des media différents.
La ceinture et les bretelles avec des pinces à linge en plus. Tu vois ?

Citation:

Envoyé par RunCodePhp

La fonction set_include_path(get_include_path().PATH_SEPARATOR. chemins_root et chemin_particulier); est là pour simplifier les choses.

Bref ... il n'y a pas de méthode universelle, et la portabilité n'est pas seule donnée à prendre en compte.
La tienne en est une, elle ne me convient pas, pas en terme d'organisation.

Je suis entièrement d'accord avec ce que tu dis. Et la méthode avec set_include _path me semble très souple.

Citation:

Envoyé par RunCodePhp

Tu n'aurais pas besoin d'un peu d'soleil par hasard ?
:lun:

Ici il faut un ciel bleu splendide, sur la neige c'est superbe aujourd'hui. Heureusement que je vais allé un peu glisser entre midi et deux. Par contre il faut bien se couvrir :pingoin2:

Nul n'est prophète en son pays.
03/02/2010, 13h38
RunCodePhp

@riete
Tu fais exprès de ne pas comprendre, c'est pas possible.:aie:

Il faut que tu sorte un peu de ton contexte et ouvrir un peu plus grand les yeux pour voir qu'il n'y a pas que des pros qui utilisent Php et les solutions qui gravites autour.

Ton histoire de Raid 5 me fait plutôt rire qu'autre chose.

Encore une fois ta solution est tout simplement farfelue, c'est comme si tu me disais d'investir dans un semi-remorque alors que mon besoin se réduit à acheter une baguette de pain.
Complètement absurde ... :calim2:

Ne peux tu pas concevoir que la grande masse de codeurs/amateurs en ont rien à faire de ces solutions complètement inaccessibles pour la simple raison qu'ils n'ont a ni l'envie, ni le temps, et encore moins les moyens de se les offrir ?

Pour quelqu'un si se vante d'avoir de la bouteille dans ce secteur, limite arrogant même, ça frise la correctionnelle.

Tu admettras tout de même que tu n'apporte pas grand chose comme solution ni l'ombre d'un argument pour résoudre cette affaire, tout juste reprendre mes propos pour tenter de les confondre ... de les confondre avec quoi d'ailleurs ? pas grand chose jusqu'à l'heure.

De plus, je pense que tu as perdu de vue que ce n'est pas moi qui demande une aide, mais Général03.
J'ai pas besoin d'aide pour la simple raison que je n'ai pas de problème, pas pour le moment.

Ne te couvre pas trop, et surtout enlève tes lunettes pour mieux te rendre compte qui utilise Php, dans quel contexte, et pourquoi, etc ... 8O
Fais gaffe quand tu glisse aussi ... un sapin peu en cacher un autre :mouarf:

Voir 40 message(s) de cette discussion en une page