Ernestine

Essaie plutôt :

if(preg_match('/^([0-9]+\,[0-9]*|[0-9]+)$/', $e))

Il me semble que les gens ont plus l'habitude de voir la recherche à gauche (type google map). Donc j'aurais effectivement choisi ta première option.

J'ai bien ce bug, effectivement, impossible de scroller après avoir cliqué sur l'image avec IE9.

La console d'erreurs me retourne cette erreur :

SCRIPT5007: Impossible d’obtenir la valeur de la propriété « getDimensions » : objet null ou non défini

magnifier.js, Ligne 100 Caractère 7

Il est possible que cette erreur soit à l'origine de ce bug. D'autant plus que la console de Chrome, elle, ne retourne pas cette erreur.

- Un script jQuery ($.ajax) qui interoge un chat.php toutes les n milisecondes et injecte les nouvelles données

Il ne serait pas plutôt là le problème ? Lancer des requêtes Ajax à un tel rythme (plusieurs fois par seconde), c'est énorme, et ne peut que causer de gros problèmes !

L'idéal serait de limiter au maximum la quantité de requêtes. Par exemple :que le navigateur lance une requête style "y a-t-il du nouveau ?", et que le serveur ne réponde que dans le cas d'une nouvelle réponse. Tant qu'aucune nouvelle contribution n'a été ajoutée, le serveur ne retourne rien. Il ne retourne sa réponse que lorsqu'un visiteur a écrit quelque chose. Le navigateur attend gentiment la réponse, pas la peine de lui retourner quelque chose si c'est pour lui dire qu'il n'y a rien de nouveau.

Mais bon, sinon, je te conseille plutôt de regarder du côté de http://nodejs.org/ , à condition que tu aies la main sur le serveur. Ça te permettra notamment de faire des sockets en javascript entre le client et le serveur, ce qui résout le traditionnel problème requête/réponse du web.

Salut Dino,

Le fond du fond n'a pas vraiment changé, c'est toujours le trio html/css/javascript côté client, et côté serveur php et mysql sont toujours bien d'actualité.

Par contre, les sites d'aujourd'hui n'ont vraiment plus rien à voir avec ceux de 2005. Utilisation intensive d'Ajax, de webservices, de syndication et autres. De nombreux frameworks quasi incontournables tant ils font gagner du temps, sans parler de tous les outils qui vont avec.

Les sites web n'ont plus la même tête également. La majorité d'entre eux sont très beaux aujourd'hui, c'est fini les horreurs qu'on avait dans le temps, ce qui demande du travail côté graphiste, et bien sûr côté intégration également.

Il y aussi la nécessité de s'adapter désormais aux navigateurs mobiles autant qu'aux écrans haute résolution.

Il y a peut être un <meta name="robots" content="noindex"> dans le head de la page.

Si ma mémoire est bonne, les portions spécifiques à Dreamweaver dans les fichiers .dwt servent juste à gérer l'inclusion des templates. Fais donc ton site en php : tu pourras remplacer tout ça par de simples include

Dans un éditeur de code/texte, tu peux ouvrir n'importe quel type de fichier texte, peu importe son extension. A priori, tu peux donc ouvrir n'importe quel fichier .dwt dans n'importe quel éditeur tel que Notepad++. Voila. Ensuite, dans la plupart des éditeurs de code, tu peux choisir le langage de ton code. Il faudra donc choisir HTML, car un fichier .dwt n'est rien d'autre qu'un fichier contenant du code html d'une part, et des portions de code utilisées par Dream pour gérer les templates.

Ca c'est pour l'éditeur de code, mais bien sûr, si tu veux que ton fichier soit interprété par un navigateur web, là c'est complètement différent : le fichier devra porter l'extenion .html ou .htm, et ne contenir que du code html (c'est à dire sans les portions qui y sont inclues par Dreamweaver pour la gesion des templates).

L'idéal serait de ne recalculer le cache d'une page que si celle-ci a été modifiée. Si une page change de contenu tous les trois mois, pas la peine de recalculer tous les jours. Inversement, si elle change tous les cinq minutes, il faut recalculer plus souvent.

Sinon, une tache cron qui exécurait un script faisant des file_get_contents() sur chaque url, ça répondrait à ce que tu cherches pour le recalcul automatique. Reste à savoir si c'est vraiment une bonne idée.

Bienvenue à toi

Tu peux créer des templates (html, css, javascript, images, etc) sur Dreamweaver puis les intégrer au CMS

A tous les coups, c'est parce que ton fichier était en UTF-8 alors que tu as paramétré l'iso-8859-1 dans la méta charset.

Donc trois solutions :

_ Soit tu utilises l'ANSI quand tu enregistres ton fichier et tu laisses iso-8859-1 pour la meta charset.

_ Soit tu choisis UTF-8 pour la meta charset (et tu laisses UTF-8 pour ton fichier)

_ Soit tu utilises des entités html pour toutes les lettres accentuées.

La deuxième solution est bien sûr la meilleure.

Dreamweaver ne peut pas être comparé à un CMS, ça n'a strictement aucun rapport

Un CMS, c'est en quelque sorte une base de site web "prête à l'emploi", capable de gérer une base de données, de fournir des templates de base pour les pages, une interface d'administration, la possibilité de gérer plusieurs utilisateurs (ceux qui mettent le contenu), etc...

Dreamweaver c'est fait pour produire du code html/css/javascript, c'est à dire que c'est vraiment consacré à développer le rendu final des pages.

Tu peux très bien utiliser les deux conjointement : utiliser par exemple SPIP (qui est un CMS orienté journal en ligne), et créer les pages web de ton site SPIP avec Dreamweaver

Je ne connais aucun pro qui utilise Dreamweaver (hormis dans le cadre d'utilisations précises et ponctuelles car il a quelques fonctionnalités pratiques telles que la création rapide de zones réactives sur des images) : la plupart se contentent d'un éditeur de code (style Notepad++) ou d'un IDE (Eclipse, Netbeans, etc).

Oui, savoir utiliser quelques CMS est très utile, et représente un gain de temps : après bien sûr, il faut choisir le bon CMS qui va correspondre à tel ou tel type de site, sinon c'est n'importe quoi. Voila pourquoi la maîtrise d'un seul CMS est souvent insuffisante.

Pour du e-commerce, deux CMS très utilisés sont Magento et Prestashop. Je ne peux pas t'en dire plus, je ne les ai jamais testés.

La plupart des logiciels d'édition mentionnent leur nom dans le code source, en général avec la balise meta generator, de même que les CMS, exemple :

<meta name="generator" content="eZ Publish" />

Peut-être que d'autres logiciels (et d'autres CMS) rajoutent leur nom dans un commentaire, ou autres techniques... tout est possible... Il suffit de regarder le code source généré pour le savoir

Tu dis que le problème survient sur IE8 et IE 9, donc le mieux que tu puisses faire, c'est plutôt de chercher dans ton code ce qui peut provoquer l'activation du mode de compatibilité : un code récent sur un navigateur récent (IE8 n'est pas si vieux que ça) doit fonctionner normalement.

Sinon, tu peux toujours désactiver cette fonctionnalité, comme expliqué ici : http://www.alsacreations.com/astuce/lire/1437-comment-interdire-le-mode-de-compatibilite-sur-ie.html

Ce qui se passe est tout à fait normal : toggle est fait pour gérer un cycle de deux clics (ou plus) sur un même élément.

Si tu cliques sur le header 1, ça déclenche la première fonction : ouverture du header 1 et fermeture de tous les autres headers (qui sont déjà fermés au début).

Tu cliques ensuite sur le header 2 : ça déclenche à nouveau la première fonction (puisque c'est le premier clic sur cet élément) : ouverture du header 2 et fermeture de tous les autres (et donc notamment du header 1)

Tu recliques sur le header 1 : ça déclenche la deuxième fonction (puisque c'est le deuxième clic sur cet élément) : fermeture de l'élément ( qui est déjà fermé donc rien ne se passe visuellement)

Tu re-re-cliques sur le header 1 et là il s'ouvre.

Bref, toggle n'est pas adapté à ce que tu veux faire.

Côté javascript : https://developers.google.com/youtube/js_api_reference?hl=fr

Bonjour et bienvenue parmi nous

Tiens, bonjour Gilbert, je me souviens de vous et de Deepindex, ça fait plaisir de vous revoir un peu

Bonjour,

Pour modifier le mot de passe root sans être root soi-même, il faudrait faire des manipulations directement sur le serveur (et donc avoir les droits qui vont bien sur le serveur).

Mais puisqu'à te lire (dans ce message et un autre sujet ouvert précédemment) tout le monde a disparu, on ne sait plus qui est le webmaster ni qui est l'administrateur, je suppose que tu ne vas pas non plus pouvoir te connecter en ssh au serveur.

Exige de ton client qu'il te donne tout ce dont tu as besoin, c'est tout.

Bonjour,

Si tu veux enregistrer les données du formulaire de mail (ce qui peut-être une sécurité, au cas où pour une raison ou pour une autre le mail ne parvenait pas à destination), alors tu dois impérativement utiliser php ou un autre langage côté serveur, mais HTML ne peut bien sûr rien enregistrer.

L'avantage du traitement côté serveur (pour enregistrer le mail et/ou pour l'expédier) est qu'il permet d'éviter d'inclure l'adresse email avec un mailto: dans le code html. Ok, toutes les adresses e-mails finissent par être spammées un jour ou l'autre, mais il ne faut pas tendre le bâton pour se faire battre, et limiter les dégâts dans la mesure du possible.

Reste un compromis : obfusquer ton adresse email dans le code html, en l'incluant avec une fonction php qui l'encrypte, puis, côté client, une fonction javascript qui va la décrypter en sens inverse (exemple : encodage/décodage en base64). Ainsi elle sera pleinement utilisable, mais restera cryptée dans le html.

Si tu parles du site qui est dans ta signature, il y a des petites erreurs javascript dues à du cross domain, ce n'est sûrement pas ça qui bloque ton site, mais bon ça ne peut pas faire de mal de les corriger.

Et sur IE8, quand je vais sur ton site, j'ai une fenêtre qui s'ouvre avec les erreurs suivantes :

TypeError: Error #1009: Il est impossible d'accéder à la propriété ou à la méthode d'une référence d'objet nul.

at cityblock.flash.flash10.feature.roomba.controls::ElevatorControl/handleNewConfig()

at cityblock.flash.flash10.feature.roomba.controls::ElevatorControl()

at cityblock.flash.flash10.feature.roomba::RoombaMaster()

at cityblock.flash.flash10.feature.roomba::RoombaModule/constructRoombaMaster()

at cityblock.flash.flash10.feature.roomba::RoombaStub/handleLoadComplete()

Et sinon, normalement, le font-face ne pose pas de problèmes particuliers quand il est utilisé correctement.

De nos jours, les dimensions d'écran ne veulent plus dire grand chose, surtout sur les navigateurs mobiles. Si tu prends l'iPhone 4, la largeur physique (device width) retournée par l'appareil est de 320 pixels en mode portrait, mais sa largeur d'écran constructeur (screen width) en portrait est de 640 pixels, et la largeur du viewport, qui est une largeur virtuelle, est de 980 pixels avec Safari. Mais si tu utilises un autre navigateur, la largeur du viewport sera différente : les navigateurs Opéra pour mobile fixent tous la largeur du viewport à 850 pixels, quelle que soit la largeur physique de l'écran, qu'on soit en mode portrait ou en mode paysage.

Ce qui compte réellement c'est la largeur du viewport, qui par ailleurs peut être modifiée dans les méta (on peut fixer que la largeur du viewport = celle du device, ce qui est l'idéal pour une intégration responsive).

Bref, on va des plus petites résolutions aux plus grandes et si tu raisonnes avec des valeurs fixes tu vas vraiment galérer. Il vaut mieux regarder du côté du responsive design comme le dit Dadou, et faire un site parfaitement fluide, avec un comportement différent selon la largeur de l'écran. Ce n'est pas forcément évident à mettre en place, ça demande notamment une bonne connaissance de la part du graphiste, qui doit savoir ce qu'il est possible de faire. Car faire un design responsive ne se résume pas à pondre deux versions (une petite et une grande).