Findel

Aie aie aie, effectivement s'il s'agit d'une table dont tu tente de modifier le contenu, ça va pas être du gâteau de faire fonctionner ça comme il faut. Tu ne peux pas plutôt partir sur une solution sans table ? Ca serait beaucoup plus facile pour toi

Premier point : es tu certain que l'id utilisé est bien présent une seule fois sur la page ? Second point : Essai de couper ton instruction en deux : var z = document.getElementById(zone); z.innerHTML = "une chaine de caractere"; Histoire de voir si c'est bien le getElementById qui plante ou le innerHTML.

Prend ce que tu veux, tu ne verras de toute façon pas beaucoup de différence à ton niveau. Quant à la différence entre ton système et celui de ton hébergement, n'ai pas de crainte, tu peux avoir Windows chez toi et Linux chez l'hébergeur, ça reviendra au même que s'il y avait du Windows partout ou Linux partout. Il te reste donc deux critères : Le prix et la qualité. Pour le prix, tu peux voir ça sur le site de 1 & 1. Pour la qualité, vois en fonction de ce que disent les gens ici pour te décider, mais tu peux partir du principe qu'il y aura autant de défenseurs de Windows que de défenseurs de Linux. Reste à voir à quels arguments des deux camps tu es le plus sensible, là on ne peut pas choisir pour toi

Il n'y a pas que l'aspect gratuit/payant... Pour travailler autant sur des serveurs Linux que des serveurs Windows, pour ce qui est du simple hébergement Web, Linux est plus stable que Windows... Nous travaillons grosso modo avec 50% de chaque, et nos problèmes (liés au système) sont plutot 4/5 pour Windows et 1/5 pour Linux. Pourtant, nous avons tous été formés Windows et autoformé Linux, nous devrions donc avoir plus de soucis avec ce dernier. Edit : Je précise également que la plupart des problèmes rencontrés avec Windows ne sont pas liés au service web, mais à d'autres composants logiciels... Ce qui est dommage pour des serveurs qui ne sont utilisés que pour faire de l'intranet... C'est là à mon avis le point faible restant actuellement sur Windows Pour ma part, je vois deux raisons de choisir Windows plutôt que Linux : 1/ Developper en ASP ... Là on a pas le choix. 2/ Prendre un serveur Dédié sans rien y connaitre, ou pas suffisamment pour administrer un serveur, en Linux et sans vouloir faire d'investissement sur l'apprentissage ou la maintenance par un tiers. Mais si on ne rentre dans aucun de ces deux cas, ce qui semble être le cas de la personne qui pose la question, l'aiguiller vers une solution Linux, plus documentée sur le web et la plus répandue, me semble le mieux à faire... Surtout pour un hébergement mutualisé, où elle n'aura donc pas à vraiment administrer son serveur complètement

Je te conseille quand même de mettre un index sur ton titre, ça aidera bien pour ta requête. Et si c'est juste pour créer un fichier, pourquoi ne pas se servir d'un id, que tu dois déjà avoir, plutot que le titre ? Tu n'aurais alors plus à faire de count ou quoi que ce soit

En théorie, et à condition que le serveur soit bien paramétré, l'internaute ne peut pas voir le code PHP. En effet, les fichiers PHP sont d'abord traités par Apache+PHP avant d'être envoyé au visiteur. Ceci dit, attention, notamment sur les fichiers "inclus", à conserver une extension .php. J'ai déjà vu des problèmes se poser à un webmaster qui nommait ses fichiers en .inc, extension non traitée par son serveur web, et qui du coup pouvait être visualisés en les interrogeant directement.

C'est justement le principe GNU. Tu peux modifier le script comme bon te semble... La seule condition est de le produire avec la même license GNU, en mettant dans le "pot public" ta version avec les sources. Quant à l'aspect nom, je ne vois pas où est le problème, ça suis les mêmes règles.

Personellement je casse mes cookies en faisant : setcookie('pseudo', '', time(), '/'); Essai ça, si ça marche mieux

Ca vient de ton script chez Tradedoubler <!-- 250_250 --> <div align="center"> <script language="javascript"> var uri = 'http://impfr.tradedoubler.com/imp?type(img)g(16126324)a(992109)' + new String (Math.random()).substring (2, 11); document.write('<a href="http://clk.tradedoubler.com/click?p=19187&a=992109&g=16126324" target="_blank"><img src="'+uri+'" border=0></a>'); </script><br> <script language="javascript"> var uri = 'http://impfr.tradedoubler.com/imp?type(js)g(16392138)a(992109)' + new String (Math.random()).substring (2, 11); document.write('<sc'+'ript language="JavaScript" src="'+uri+'" charset="ISO-8859-1"></sc'+'ript>'); </script> </div> Regarde le contenu de : impfr.tradedoubler.com/imp?type(js)g(16392138)a(992109) Tu verra qu'il y a des appels à spacer.gif

Peut être qu'en regardant la tête de ton fichier exporté ça t'aiguillerais déjà pour savoir ce qui provoque ça : Si le fichier est bon c'est l'import, s'il n'est pas bon c'est l'export. Je sais que ça résoudra pas ton problème, mais déjà tu saurais quoi regarder de plus près

Deux solutions : un fichier .htaccess avec Options +MultiViews Ou alors tu nomme ton fichier sans l'extension .php et tu indique dans un .htaccess que tu veux que ce fichier soit traité par php avec la ligne suivante : <FilesMatch "^(toto)$"> ForceType application/x-httpd-php </FilesMatch>

Euh... comment dire ... Tu viens ici pour demander des conseils, qu'on te donne, mais au final tu prend ta solution à toi sans écouter la moitié de ce qui t'a été dis ... c'est dommage. Je continue à penser que tu aurais plus à gagner à changer ces liens javascript par des liens normaux, qui auraient non seulement l'avantage de fonctionner pour ceux qui n'ont pas les images ou le javascript, mais qui en plus seraient super bien vus par les moteurs. Pour ton problème de $_post pour tes variables, c'est simple, prévois dans tes scripts que les variables puissent être aussi bien passée en get qu'en post, et n'en parlons plus. Pour ce qui est de ton "astuce" avec les liens sur les images transparente, j'ai bien peur qu'à terme, ce ne soit pas "1 seule page" référencée par google ... mais 0 ! A mon sens, c'est du cloaking, et tu risque de très vite te faire tirer les oreilles et de te retrouver dans la blacklist Mais bon, tu es chez toi sur ton site, alors fais comme tu le sens

Hummm Tout d'abord, je vois pas vraiment ce que tu as changé sur ta page, elle n'a toujours aucun autre lien visible pour un moteur Ensuite, j'avoue n'avoir pas très bien compris tes deux nouveaux problèmes, tu peux nous en dire plus ? Tu veux voir quelles sont les pages que Google a indexé ? Si oui, il te suffit de taper "site:www.bfpme.com.tn" comme recherche Pour ce qui est des $post et $get, là par contre je vois pas du tout de quoi tu parles, du moins pas sans voir un exemple de ton code ou de l'erreur en question

Pour que cela fonctionne, il faudrait que tu sois sous IIS avec l'option "Authentification Windows intégrée" activé sur ton répertoire web partagé. Ensuite, tu obtien le nom d'utilisateur avec la variable prédéfinie : $_SERVER [ 'PHP_AUTH_USER' ] Par contre, c'est à tester, car selon la complexité du réseau de ton entreprise, le fait d'activer l'authentification "Windows" peut donner un résultat innatendu et assez désastreux sur les temps de réponse de ton site intranet

Non, ca ne résoudra pas ton problème puisque ton problème est qu'il n'y a aucun lien entre ta page d'accueil et le reste du site. Donc que le reste du site soit normal ou avec une réécriture d'url, ca résoudra pas ton soucis

Il n'y a aucun vrai lien sur ta page d'accueil, il est donc normal qu'un moteur qui analyse ta page ne voit rien d'autre. Désactive les images et le javascript dans ton navigateur préféré et rend toi sur ton site, tu le verra par toi même on ne peut pas aller plus loin que la page d'accueil. Fait des vrai liens et oublies les "onclick" ... tu verras que tout ira beaucoup mieux Edit : Ah ben Doud a été plus rapide que moi

Dans la requete suivante, si id_category, id_album et id_photo sont null c'est qu'il n'a rien SELECT u.id_user, c.id_category, a.id_album, p.id_photo FROM user AS u LEFT JOIN category AS c ON c.id_user = u.id_user LEFT JOIN albums AS a ON a.id_category = c.id_category LEFT JOIN photos AS p ON p.id_album = a.id_album WHERE u.id_user = ... Sinon, tu peux aussi te baser sur la catégorie simplement, car s'il a une catégorie c'est qu'il a au moins un album dedans, non ? s'il a au moins un album c'est qu'il a au moins une photo dedans, non ?

Tu vas être obligé de le faire avec deux requetes je pense. Mais je te conseille de voir le problème autrement : Tu garde tes deux tables, mais tu ajoute le prix dans la table des annonces. Quand une annonce change de prix, tu fais : UPDATE annonce SET prix = ... WHERE ID = ... INSERT INTO prix (ID_annonce, prix, date) VALUES (..., ..., ...) et pour afficher tes annonces ça devient donc super simple : SELECT * FROM annonces En fait, vu que tu as créé la table "prix" pour gérer un historique, va jusqu'au bout de l'idée, sert toi en uniquement d'historique

Un peu plus loin dans le même article, on peut lire : C'est donc bien qu'en vente à distance on a pas cette obligation de reprise, si ?

Ca a été pas mal répété aux infos : "Pour l'instant les ventes en lignes échappent à cette réglementation"

Le pb est que le code PHP n'est pas traité. A mon avis PHP n'est pas activé chez ton nouvel hébergeur, soit parce que tu as pris un hébergement sans PHP ou parce que tu ne l'as pas activé

Et il vaut mieux que tu colles la fonction de vérification dans le onSubmit du form plutot que sur le bouton ... car si on appuie sur Entree, ca ne lancera pas la fonction sinon

Idem, j'suis sur toulouse. Pour le web c'est à la fois amateur et professionel (intranets).

Disons aussi qu'il n'y a pas que le référencement. Exemple : est très fréquent que l'on tape dans l'url machin.net au lieu de machin.org enfin, toutes les erreurs de ce genre. Ou alors des mots clés, pour ceux qui tapent ce-qui-leur-passe-par-la-tete.com dans la barre d'adresse

ErrorDocument 401 http://monlogin.free.fr/acces_refuse.htm Serait mieux