Loupilo

Ça va aller avec WRI maintenant ; le blog d'Olivier Duffez est une meilleure source d'informations sur ce sujet, je t'oriente donc vers ses billets les plus récents pour trouver une réponse à tes questions !

SPIP dans l'état ne ferait pas ce dont tu as besoin, mais il faudrait que tu jettes un oeil à l'excellent plugin Forms v2 !

Il permet de créer des formulaires plutôt facilement et d'exploiter les données de pas mal de façons. Il faudrait bien sûr faire quelques retouches pour adapter ça à ton usage, mais va voir de ce côté !

J'abonde dans le sens de klelugi, SPIP est tout particulièrement adapté aux sites multilingues qu'il gère très bien.

C'est aussi facile de traduire les articles que les squelettes, et tu peux tout à fait avoir des réglages spécifiques à chaque langue.

J'essaie et je te dis. Mais mon menu ne fait pas partie de ma div #page, donc je ne sais pas si ça changera quelque chose.

Edit: Nickel, ça marche sous firefox, epiphany et opera. Si quelqu'un-e peut me dire ce que ça donne avec IE?

Avec IE, ça pose un problème, le cadre gris ne dépasse pas la limite gauche du menu horizontal. Essaie de n'appliquer le float que pour les navigateurs modernes (même problème avec IE7), donc quelque chose genre

html>/**/body #page {float:left}

Tu peux résoudre ça sur Firefox en ajoutant un float:left à #page, pour le séparer du menu, mais ça introduira peut-être des incompatibilités avec d'autres navigateurs...

tribords : je ne sais pas si ça marchera vu que son div est en positionnement absolu.

De mémoire, quelque chose du genre fonctionne (avec largeur/2 la largeur du div... divisée par 2) :

#div {
left:50%;
margin-left:-largeur/2;
width:largeur;
}

Pour respecter la norme, il faut aussi :

* envoyer du contenu en XML bien sûr

* envoyer le type mime 'text/xml'

* ajouter un entête 'Content-length' qui contient la taille (en caractères) de la réponse

Mais ça marchera bien aussi si tu ne fais qu'envoyer des données formatées en XML, le reste c'est du perfectionnisme

"Pour cela, tu dois déclarer ton entreprise individuelle auprès de l'URSSAF puisqu'il ne s'agit pas de eCommerce"

quelles differences pour ouvrir un ecommerce?

entreprise individuelle , plus declaration ursaff ne suffisent -elles pas?

Je pense qu'il faut s'adresser à la Chambre de Commerce et d'Industrie, si c'est du commerce... L'URSSAF est plutôt destiné aux professions libérales, etc (je dis plutôt car c'est un peu du cas par cas).

Je ne connais pas le cas précis d'OVH, mais normalement c'est ça, il faut voir les mails de l'adresse qui est spécifiée comme "Expéditeur"...

Si l'adresse mail est gérée par ton serveur, tu devrais même pouvoir faire quelque chose de ces retours !

Je m'en doutais un peu, mais qu'est-ce qui est lent ?

Les pages sont pas lourdes, donc c'est le temps de réaction (ou de communication) entre les pages et la BDD ?

Que faire pour l'améliorer ?

Je suis engagé pour un certain laps de temps donc quelle solution pourrais-je demander à celeonet pour améliorer la vitesse du site ?

C'est l'ensemble qui est lent, rien de particulier !

Mais comme l'a fait remarquer Magali, c'est maintenant assez rapide : preuve que ça vient bien de l'hébergeur, qui est tout à fait capable, par moments du moins, de faire tourner SPIP correctement !

Non, migrer n'améliorera pas les performances de SPIP. SPIP n'est pas tout léger, et même si tu n'as pas besoin d'une bête de course pour le faire tourner, il vaut mieux un serveur réactif. Apparemment, ce n'est pas ce que ton hébergeur propose... Même si, c'est vrai, SPIP est parfois un peu lourd, c'est une solution extrêmement reconnue qui a toujours bien fonctionné (sauf chez 1&1, mais c'est car leur offre mutualisée n'est pas suffisamment performante) : la faute incombe à Celeonet.

Phobos, c'est sûrement car la sortie est en PNG. Donc pour les photos, ça donne un fichier très lourd !

Je suis impressioné !

Tu peux en dire plus sur le fonctionnement de tout ça ?

Je testerai bien, mais les accents de mon site en UTF-8 ne sont pas correctement importés, et le correcteur trébuche !

Quand tu te connectes à l'administration, dans le cadre "Accès direct", tu as "Gérer mes accès FTP". Tu vois ton nom d'utilisateur et ton mot de passe, il suffit ensuite de se connecter à identifiant:mdp@s1234567890.domainepardefaut.fr ou à identifiant:mdp@tondomaine.com.

C'est étrange...

Moi, j'ai quelque chose du type s186457855.online.fr !

Dans la première colonne, "Nom", qu'as tu exactement ? En théorie, c'est forcément le nom de domaine...

Même les mutualisés, effectivement, ont une URL temporaire chez 1&1...

Quand tu te connectes à l'interface d'administration, clique sur "Configuration des domaines", et tu pourras normalement y voir l'adresse.

Le flv est un format plus universel que le wmv pour le format Web : tout le monde n'a pas de lecteur de vidéo intégré à son navigateur, et statistiquement leur nombre doit être plus faible que ceux qui ont Flash. Ceci dit, les rares personnes qui n'ont pas Flash ne l'ont pas :

• car ce n'est pas libre, mais le format wmv l'est encore moins, donc ils ne pourront pas le lire non plus
  
• car il n'est pas dispo sur leur plateforme (typiquement linux 64 bits), mais les codecs vidéos sont alors aussi très dur à installer
  
• parce que leur entreprise ne l'autorise pas, mais alors quid d'un lecteur vidéo ?
  
• parce qu'ils ne connaissent pas grand chose à l'informatique et n'arrivent pas à l'installer, bien que ce soit enfantin, mais dans ce cas, que penser du téléchargement et de l'ouverture d'une vidéo ? c'est du pareil au même !
  
• autre chose ?
  

Flash permet également un streaming simple et efficace beaucoup plus avantageux qu'une ouverture classique de fichier wmv.

Ensuite, rien ne t'empêche d'offrir un lien vers une vidéo classique...

Bref, le Flash reste pour moi la solution absolument indétrônable dans le domaine de la vidéo sur le net.

Essaie dans le .htaccess d'indiquer le chemin absolu vers le .htpasswd (un truc peut-être du genre /home/a/5/site15245/.htpasswd (j'invente)) au lieu du chemin relatif.

Et vérifie que tu ne mets pas d'espace :

pseudo:mdp

Si tu touches un peu en PHP et que tu utilises la version 5, je te conseille simplement de lire la documentation du module SimpleXML.

C'est de loin le moyen le plus simple et le plus puissant pour exploiter un flux RSS !

Si tu utilises PHP4, il te faudra trouver un parseur XML, mais je n'ai pas de nom en tête, il faudra chercher

Je te conseille de faire attention, quelque soit l'hébergeur choisi, à leur méthode anti-spam.

En effet, certains paramètrent leurs serveurs de mails pour que les courriers soient refusés à leur première présentation, avant d'être acceptés à la seconde. Le résultat est simple : les spams les moins performants ne reviennent pas après avoir été refusés (alors que les "vrais" mails réessaient) ; et la conséquence limpide : il faut attendre pour recevoir ton courrier, en fonction du temps qu'il met pour se présenter une nouvelle fois.

C'est du greylisting.

Le problème vient du code que tu utilises pour l'afficher.

Les attributs de taille sont bien renseignés dans <object>, qui est lu par IE, mais pas dans <embed>, qui est lu par les autres.

Il te suffit donc de passer les width="30" et height="30" dans <embed> aux dimensions que tu as choisis, c'est à dire respectivement 468 et 70

Oui, le mélange de la couche de comportement de la couche de présentation est gênant dans la mesure ou cela nuit justement à facilité de la maintenance... mais c'est un choix, comme ont peut choisir de mélanger la couche du contenu et de la présentation et on se retrouve avec les mêmes problèmes Je ne vais pas trop débattre sur ce point car c'est un peu hors-sujet et je n'ai pas vraiment d'argument plus probant à t'apporter (d'ailleurs je doute qu'il y en ait besoin).

Je suis d'accord sur le principe, mais ce JavaScript là est assimilable à la couche de présentation, donc ça ne rentre ama pas dans tes considérations de séparation

Et je ne vois pas en quoi un tel système ne serait pas accessible aux utilisateurs, du point de vue de la compréhension. Du point de vue de la maintenance et de l'évolutivité, il est clair que cela demande un peu plus de travail à la conception. Mais en admettant que, comme dans l'exemple ci-dessus, on tire avantage des feuilles de styles et qu'on ne définit que les styles qui changent d'un layout à l'autre (flexible, et largeur fixe) et que les autres styles se trouvent dans une feuille de styles commune, ces problèmes sont tout à fait surmontables.

Pourquoi pas. Mais c'est assez gadget pour la difficulté de maintenance que ça comporte... Et pour le rapport utilisateurs/utilisateurs qui s'en servent, aussi.

Pour ce qui est de la mise en place du système ce n'est pas vraiment une difficulté, il existe des style switcher de plusieurs natures: Javascript seulement, PHP (ou langage interprété côté serveur) uniquement, mélange des deux. Si le site est bien conçu l'entier du code agit simplement sur l'en-tête HTML des pages (liaison des feuilles de style).

Tout à fait d'accord.

Maintenant il est clair que si l'investissement que cela représente ne vaut pas selon toi le gain en usabilité c'est ton droit, j'exposais juste la manière que je préfère utiliser

L'idée peut-être séduisante sur le papier, mais pour moi, ça apporte plus de problèmes que ça n'en résoud... Après en effet, chacun peut l'utiliser s'il trouve que ça vaut le coup.

Je ne suis pas d'accord, une page totalement flexible peut se dégrader et/ou nuire à l'usabilité lorsque la la taille a disposition devient plus large ou moins large que les valeur "habituelles"... c'est pour cela que je propose un compromis. Ce que propose Leonick est un début, mais le problème est que cette solution mélange la couche de présentation et la couche de comportement en incluant du Javscript dans la feuille de style (ce n'est pas un hack, c'est une fonctionnalité). C'est pour cela que je suis plutôt pour un système de changement de feuille de style qui ne pose pas ce problème de conception.

Je parle bien entendu de flexibilité accompagnée de max-width, comme l'indique Leonick. Perso, le mélange CSS/JS ne me gène absolument pas ; et le système de changement de feuille de style, en plus d'être assez contraignant à maintenir, est loin d'être accessible niveau utilisation à un internaute lambda. Demander à un public "de base" de choisir entre 800*600 et 1024*768 me semble être assez audacieux. Enfin, c'est au site de s'adapter à ses visiteurs, et non pas l'inverse.

Mais ce n'est que mon avis

Bon ben, je suis d'accord avec Dudu

J'ajouterai quand même que quitte à vouloir proposer une maquette fixe, le choix de ses dimensions doit alors se faire en fonction de son public... Une cible âgée, par exemple, aura tendance à utiliser des résolutions plus faibles que celles permises par leur écran, et la population de 800*600 risque de ne pas être négligeable.

Par contre, pour une cible jeune ou branchée, les 17" sont de loin les plus répandus sur les ordinateurs de bureau (et les 19" percent), et permettent une résolution de 1024*768 ; les portables sont en 17" et ceux avec avec petits écrans ont bien souvent un format 16:9, avec plus de 1200px de largeur : choisir le 1024*768 n'est pas un pari risqué.

Ça dépend vraiment des utilisateurs.

Mais les maquettes étirables restent quand même le choix le plus flexible et le plus universel