Dash

C'est une erreur de penser que les ecrans 17' se generalisent. A titre d'exemple : la majorite des portables vendus actuellement sont encore en 15'. Pour ce qui me concerne, mon blog est tout ce qu'il y a de blog personnel. Egoiste. Avec l'emploi du "Je" et du "moi". Je ne cherche pas a faire original, ni a faire accessible, "a l'ancienne", moderne ou autre. Je gere un blog qui me plait avec une charte graphique graphique qui me plait, une accessibilite qui me convient et des techniques qui me plaisent. Je prends le style qui me plait et je change de style si je veux. Ce n'est pas une question de mode. Si le public-cible principal etait different du "je" j'aurais probablement effectue des choix plus adaptes aux objectifs vises.

Chandon, il existe d'excellents CMS en java. OUbliez les servlets. Et tournez-vous du cote des JSP (/J2EE). Cette phrase a du sens. A l'heure actuelle les CMS en java sont probablement plus repandus dans les milieux professionnels que ceux en php.

A propos de tests, BrowserCam offre la possibilite de tester des pages web sous divers OS/navigateurs. Suite a un excellent billet publie sur Cybercodeur.net, je m'en suis par exemple servi pour tester une page XML. J'ai regrette de ne pas avoir connu cet outil plus tot

il existe (encore) des hebergeurs php gratuits... laposte, free, serveur4u, webdynamit, etc.

Il y a certainement moyen de faire des inclusions en javascript, a condition que les utilisateurs utilisent tous un navigateur adapte. Dreamweaver permet d'utiliser un systeme proche des inclusions, en local, pas sur un serveur. Peut-etre un solution a envisager. Cependant la meilleure solution reste de prendre un hebergeur avec autre chose que "rien".

Il me semble que 'Webbot' est un commentaire utilise par FrontPage... Le second correspond a une syntaxe SSI (server side includes). Cela ne fonctionne que sur des hebergeurs supportant le SSI. Si les instructions webbot et les commandes SSI ne sont pas supportees par le serveur, ces lignes de commandes sont simplement considerees comme des commentaires : rien ne se produit.

la fonction substr() devrait vous convenir

Cette ligne de code, placee en debut de script, devrait faire l'affaire

A propos de newsletter et d'ezmlm, je viens de decouvrir que l'on parle de mon blog sur dans newsletter Nexen.net de ce dimanche. Mince... C'est quand meme genial tout ce qu'on peut faire avec une newsletter

une solution simple en javascript :

http://www.phpnet.org/forum/ressources/faq_ezmlm.pdf A adapter a la configuration de celeonet

Un exemple flash que vous connaissez peut-etre... Flash CV en Français Flash CV in English C'est moche, c'est inaccessible, c'est long a charger, c'est irreferencable, c'est tout ce que vous voulez. Mais l'animation est pensee de maniere intelligente pour faire passer un message precis et dans un objectif precis. L'outil Flash est utilise de maniere pertinente. Resultat : plus de 500 000 personnes ont deja consulte cette animation flash ! cette animation fait parler d'elle, et son auteur a deja recu des propositions d'embauche par dizaines. En voila au moins un qui a depasse la question "Flash - pour ou contre ?" Comme tous les outils, tout depend en fait de la maniere dont on s'en sert.

Vous mélangez tout ! Pourquoi utiliser un charset US-ASCII ? Y a-t-il une raison qui justifie cela ? un coup vous utilisez des caracteres accentues (=> charset a utiliser : UTF-8), un coup vous utilisez les equivalents iso (=> charset a utiliser : iso-8859-1). Vous devriez choisir un format d'encodage et vous y tenir. A moins que vous ne teniez a donner le tournis aux lecteurs RSS Meme chose pour le reste du site. Si vous definisez vos pages HTML avec un charset iso-8859-1, alors vous ne devriez pas avoir de caracteres accentues (é, ê, è...) dans votre code HTML. La non plus ce n'est pas coherent

Je viens de faire un test avec des comptes bien distincts (celeonet/gmail/swing). Ces resultats devraient eclairer les choses. FROM : moi_AT_domain.com (moderateur de la liste) TO : newsletter-subscribe-username=localhost.com_AT_domain.com RESULTAT : un mail recu sur le compte moi_AT_domain.com (moderateur de la liste) le compte utilisateur ne recoit rien. Tout passe obligatoirement par le moderateur. A lui a gerer les inscriptions abusives... ----------------- FROM : toto_AT_gmail.com (simple utilisateur) TO : newsletter-subscribe_AT_domain.com RESULTAT : un mail recu sur le compte toto_AT_gmail.com le moderateur ne recoit rien, les inscriptions se gerent sans lui. C'est aux utilisateurs a confirmer leur inscription

La confirmation est envoyee au moderateur de la liste, pas a la personne inscrite !

Attention ! La methode est traitre. L'usage de ce javascript s'il est mal gere cote serveur peut faire plus de degats qu'autres choses... Variante de l'exemple indique : Si la fonction soumettreUneSeuleFois() desactive le bouton "submit" lors de la validation du formulaire, la variable $_REQUEST['submit'] n'existera plus ! Donc, ca n'aura plus aucun sens par exemple de faire le test suivant en PHP : Il faut y penser. Je me suis fait surprendre sur mon blog... Solution : un champs hidden (par exemple "copy_submit") qui servira de temoin en cas de besoin

Cette methode est plutot... agressive. La personne ne recoit pas d'email pour confirmation son inscription. L'adresse email indiquee est inscripte d'office. Porte ouverte aux abus...

google J'ai recupere la premiere classe PHP qui trainait sur internet et qui permet l'envoi des mails par SMTP

As-tu pense a faire des essais en ajoutant ton adresse en BCC ou CC ? J'ai eu moi aussi plusieurs problemes chez celeonet lors de mes tests avec ma newsletter : des mails qui semblaient ne jamais etre envoyes, qui arrivaient seulement apres plusieures heures. Surement un effet de l'antispam pour empecher les abus. J'ai regle le probleme en laissant tombe la fonction mail() au profit d'une methode SMTP. Plus fiable. Et plus rapide. Depuis, plus aucun soucis

Salut, ezmlm n'est qu'un "stupide" gestionnaire de listes Definir si un mail est du type "text/html" est independant du gestionnaire. Tu peux renseigner (inplicitement) le type HTML directement via une messagerie habituelle ou "construire" tes mails via un script PHP. Ensuite, envoyer le mail a travers ezmlm, via l'adresse de la liste. Le probleme des mails en HTML, c'est la possible mauvaise interpreration du mail en question. D'une part toutes les applications mails n'ont pas les memes performances (CSS, HTML, javascript, DHTML...). D'autre part, il faut savoir ou mettre les images, css et autres elements annexes : en piece jointe ou sur le serveur (online ? offline ?). Enfin, Thunderbird, par exemple, peut se montrer tres chatouilleux avec certains elements presents dans un mail au format HTML. Le message peut se voir deforme, ou pire...

Pour des applications comme DotClear, n'oubliez pas que c'est a vous a entretenir votre application (chmod, tables SQL, etc.). En cas de crash, vous serez seul responsable. Contrairement a Blogger par exemple (ou aceboard) ou vous n'avez pas acces au code source, ni a la base de donnees.

Il y a deja un sujet similaire : Recherche script pour creation de plan, Plan de site

je me permets une petite remarque, sans aucune mechancete : L'orthographe ca compte aussi! dommage, le message aurait pu etre meilleur

rand(), pseudo-aleatoire, 1°/ n'est pas equiprobable : il n'y a aucune raison d'avoir 50% de 0 et 50% de 1 2°/ n'a rien d'original par rapport aux autres langages de programmation : c/c++, java, etc... 3°/ est donc basee sur une suite dite chaotique, comme dans les autres langages. PHP n'a rien invente. 4°/ n'est pas influencee par le temps : vous obtiendez les memes resultats en commencant vos tests a differents moments. srand() permet de varier la suite utilisee. Et une utilisation de srand() en fonction du temps permet d'obtenir des resultats plus aleatoires. C'est a cet endroit que le temps intervient

Un exemple flagrant : je me suis apercu qu'avec PHP4, meme avec un doctype 'XHTML 1.0 Strict' Tidy rajoute systematiquement un attribut "name" au formulaire. De temps en temps, Tidy ne nettoit rien, au contraire il lui arrive de degrader la qualite d'un code HTML initialement correct... On aurait mieux fait de s'en passer.