Anonymus

Oui, mets l'ensemble du script (avec le javascript) dans le tableau php, et ca suffira : effet garanti

Bonjour, Il y a plusieurs solutions, l'une d'elles consiste à mettre chaque bannière / image dans un tableau, et à faire un random sur le tableau : par exemple.

Tu devrais faire les calculs en GMT. Ainsi, tu n'aurais plus ces contraintes de changement d'heure.

A propos de cette ligne, elle permet de voir qu'il y a un problème lorsque certaines lignes restent trop longtemps. Si tu as un programme qui utilise une connexion permanente, par exemple, il va générer un appel à la base de données, et rester 'ouvert'. Donc ca te fait déjà une connexion.. permanente

Ca sert à identifier l'erreur. Si ton serveur se contentait de dire : y'a une erreur, tu serais bien embété. Là, il te dis 'y'a une erreur, et cette erreur c'est xxx'. Ca te permet, sinon d'identifier le problème, au moins d'en connaitre la cause. Tu trouveras ici : http://www.webmaster-hub.com/outils/http-viewer.php la liste des erreurs courantes que tu est amené à rencontrer. Nico.

Pour autant, la taille est vraiment primordiale, c'est elle qui va déterminer le type de lecteur, voire le type de serveur. Certains seront suffisants pour 'lire' des fichiers de petite taille, alors qu'il t'en faudra un 'spécial' pour les gros fichiers. Essaie d'avoir une idée au moins estimative de la taille, stp.

Ok, alors tu stockes l'ID de l'user en cours, auquel tu rajoutes l'IP de l'user, tu mets le tout dans un cookie, que tu cryptes d'une manière ou d'une autre. Ca te fait des identifiants, que l'on ira pas cracker. Pour finir, tu autorises l'accès à l'IP uniquement.

La première question à se poser est celle du lecteur, pas du format. Le format, tu l'imposes à tes lecteurs après. De toute facon, tu auras toujours des membres insatisfaits. D'ailleurs, il y a des lecteurs capables de lire plusieurs formats, a priori. Par contre, le problème se pose pour le streaming : ce sont des fichiers de quelle taille, que tu veux mettre en ligne ?

Bonjour, Pour ce qui est de la session que certains sites arrivent à faire 'durer' : Simple, ils stockent les informations dans une base de données, au lieu de laisser le gestionnaire de sessions s'en occuper Pour ce qui est du problème de l'id de l'utilisateur. Le mien, pour ce forum, c'est 41. Simple, regardes : http://www.webmaster-hub.com/index.php?showuser=41 Pour autant, ca ne veut pas dire que tout le monde peut accéder à mon compte. Donc, le fait de stocker cet id dans un cookie n'est pas un risque en soi. Pour autant, cet id ne suffit pas, c'est clair

Cela veut dire qu'il te reste 4 heures pour enregistrer toutes les données pouvant être considérées comme 'archives'. Jusqu'à maintenant, google laissait un libre accès aux anciennes données, dorénavant, ils vont bloquer cet accès. Je ne pense pas qu'ils vont les supprimer, ils vont se contenter de ne plus nous les retourner. Ca leur coute cher (stockage et process), et comme de toute facon personne le fait... (j'veux dire : les conccurents)

D'un coté, oui. De l'autre, attention à ta qualification : Autant un journaliste pourra dire qu'il faisait son travail, autant on ne peut pas en dire autant d'un particulier.

La limite de taille des urls s'explique par la capacité de stockage dans les bases de données : Un champ varchar fait 255 caractères maximum, ce qui fait qu'un moteur de recherche ordinaire ne stockera pas plus de 255 caractères. Mais tu peux très bien créer des urls de plus de 255 caractères, et ils marcheront tout aussi bien Pour ce qui est de la prise en compte des mots, par contre, ils seront pondérés par le nombre de mots total présents dans l'url : S'il y a 2 mots, chacun aura la moitié du poids total. S'il y en a 10, chacun en aura un dixième.

Etonnant : Cette question reviendra constamment dans les discussions que tu auras avec tes clients. Ouvrir une entreprise de webmastering et ne pas savoir ce genre de choses m'étonne un peu, d'autant que la réponse se trouve à 2 clics sur google > http://www.google.fr/search?hl=fr&q=fi...rcher&meta= et donc ici : http://www.webmaster-hub.com/publication/L...r-htaccess.html Nico.

oui, à condition de voir le 'bon' script

Oui, oublies ton tableau. Bon, pour savoir s'il y a une autre possibilité d'écrire ce script, il faudrait que tu nous le passe entier, et non seulement un extrait. Mais déjà, un tableau ($object['property1']=.. ) de plusieurs millions d'entrées plantera à coups surs. Par contre, si c'est juste pour faire un insert derrière, a priori inutile de compléter le tableau, tu as juste à mettre les données retournées par le '$o' Enfin, tu devrais jeter un oeil aux fonctions 'insert into' pour copier une table entière: > INSERT INTO `base2`.`table2` SELECT * FROM `base1`.`table1`; etc..

Oui, voilà un bon lien

Tu peux aussi utiliser notre ami le 'Hub', puisqu'un certain nombre de publications parlent de ca, dans la partie 'publication' (justement ) > http://www.webmaster-hub.com/publication/ Nico.

Une autre solution (utilisée par phpmyadmin apparemment) est de vérifier que les données soient toujours celles qu'on pense.. Bon, un p'tit exemple : TOTO : SELECT * FROM produits WHERE produit_id = 1 AND stock = 1 DUPONT : SELECT * FROM produits WHERE produit_id = 1 AND stock = 1 Toto achète (puisque stock= 1) : TOTO : UPDATE produits SET stock=stock-1 WHERE produit_id=1 AND stock=1 Dupont achète, puisque quand il a vérifié, il y avait toujours '1' en stock : DUPONT : UPDATE produits SET stock=stock-1 WHERE produit_id=1 AND stock=1 Normalement, on se contente de dire 'produit_id=xx'. Avec la condition 'stock=1', on est sûr de l'intégrité des données. Mais on peut mettre aussi : UPDATE produits SET products_name='couteau WHERE produit_id=1 AND products_name='cuillere' AND products_description='une petite cuillere pour pitimonde' AND, AND.. En mettant tous les champs, on s'assure que l'enregistrement n'a pas été touché avant la modif. Par contre, il va falloir prévoir le cas où, effectivement, l'update ne retourne rien : pas de champs modifiés, donc l'update n'a pas eu lieu Mais.. c'était la question, non ? Nico.

D'autres pistes possibles : - Une requète qui bloque toutes les autres - un timeout non pas du serveur, mais du navigateur. Pour le 2, tu peux faire comme ceci : Affiches les requètes à l'écran (ou envoies juste un point echo ". ", et mets un 'flush' derrière. Ca aura pour effet d'envoyer en permanence quelque chose au navigateur, pour éviter le timeout de celui-ci. Pour le 1 : Mélanges les requètes : Par exemple, tu coupes le fichier en 2, et tu passes la 2e partie en premier, puis la 1ere en second. Tu verras ainsi, si ca bloque sur une requète. (si le fichier s'arrete à... 7-8 Mo, c'est qu'il y a très probablement un problème sur une requète.) Nico.

Et pour finir : Le libraire ne se soucie pas de la qualité du papier lorsqu'il met ses magasines sur le présentoir Le lecteur non plus, d'ailleurs Nico.

Postes nous le bon code, que l'on puisse t'aider. 1/ ta fonction, 2/ le code qui l'appelle. Nico.

? Non, pourquoi ? Tu appelles ta fonction plusieurs fois ? Alors la solution est par les tableaux > Tu stockes le résultat dans un tableau, et c'est celui-ci que tu appelles 2 fois

Il ne faut pas oublier que google est une société mercantile, et comme toutes sociétés, elle fait les choses en calculant le ratio cout/efficacité. Faire plaisir aux webmasters, je suis pas sûr que ca soit très.. profitable pour ses actions Par contre, utiliser les balises sémantiques pour aiguiller ses bots, c'est évident. Mais je doute que le pourcentage de sites construits correctement soit vraiment représentatif de quoique ce soit. A mon avis, vraiment très peu de sites (ou de pages) sont vraiment conformes à quelque chose. Et dire que c'est d'autant plus méritant pour celui qui code mal est.. tout aussi faux : moins il y a de sites bien codés, et plus ca coute cher de s'y intéresser

1/ Es tu sûr d'avoir un champ 'titre' dans la table 'article' ? 2/ Modifies la requète : $query = "SELECT * FROM article WHERE MATCH (keywords) AGAINST ('$mots')"; comme ceci : $query = "SELECT * FROM article WHERE keywords LIKE '".$mots."' ";

[joke] (en cours d'édition, j'attends la question pour fournir la réponse ) [/joke] Le raisonnement logique (à mon avis) aurait été de passer soit l'ensemble (requète + mysql_query) dans la fonction, comme le montre ton dernier exemple, mais éventuellement, tu pourrais passer la requète en paramètre, et laisser la fonction mysql_query dans la fonction showcalendar. Ca donnerait : $query = "SELECT * FROM truc"; echo showcalendar($query); function showcalendar($requete){ $r = mysql_query($requete); while($row = mysql_fetch_array($r)){ echo'plop'; } } Nico.