pluriels

Ce n'est, il me semble, que du Lobbying. Cela a bien marché puisqu'on en parle. Plutôt que d'attendre que des "groupes éclairés" oriente les décisions des législateurs, les webmasters dans l'illégalité devraient aussi donner leur vision...

quel script utilise tu pour ton appel ajax ? certains frameworks empêchent l'execution de javascript dans les réponses Ajax.

Le terme en français est rédacteur si je ne m'abuse. Par contre, tout est souvent une question de prix pour la qualité.

<table class="spip" summary=""> <caption>Tableau</caption> <tbody> <tr class="row_even"><td>ISRAEL</td><td> Dan Ramer </td></tr> <tr class="row_odd"><td>ITALIE</td><td>Giancarlo Iannone </td></tr> <tr class="row_even"><td>SINGAPOUR</td><td>Christine Lee </td></tr> <tr class="row_odd"><td>ISRAEL</td><td> Dan Ramer </td></tr> <tr class="row_even"><td>ITALIE</td><td>Giancarlo Iannone </td></tr> <tr class="row_odd"><td>SINGAPOUR</td><td>Christine Lee </td></tr> </tbody> </table> Le code généré est très propre. tu as les classes row_even et row_odd que tu peux personnaliser (une ligne sur deux) Dans ton cas tu peux donner la même couleur aux deux classes si l'alternance de couleur ne te plaît pas. tu peux ensuite jouer sur la classe spip, par exemple pour une bordure: table.spip td{ border-left : solid 1px black; } Enfin, garde bien en tête que SPIP propose des raccourcis typographiques qui, d'habitude, suffisent pour la plupart des sites. A force de vouloir laisser trop de liberté au rédacteur, la charte graphique souffre pas mal... Tes demandes sont vraiment propres au design. Penche toi bien sur le CSS et normalement, tout ira bien.

je crois que le plus simple serait de faire un "calque" devant tout ton contenu. Celui-ci contient ton disclaimer et tu le caches avec un bouton OK.

si 1&1& le propose, ils doivent déjà avoir un tuto. En général, tu peux faire tes traitements en PHP et appeler avec CRON ta page traitement.php

est-ce un bug ou le fonctionnement normal de la fonction confirm ? Auparavant, les développeurs pestaient sur le fait que des événements javascript se déclenchaient avant la fin du chargement de la page. Si Firefox ne déclenche le javascript que lorsque la page est chargée, d'autres développeurs regretteront leurs anciennes habitudes...

Je ne suis pas un pro de la réécriture, mais je vois une différence là : RewriteRule ^(.*)$ index.php RewriteRule .* /index.php [L]

salut, pour éclairer ma phrase : 3 - Utilisateurs de CMS = Développeur web qui propose des CMS 4 - je ne comprends pas bien le débat : Je viens d'aller voir ton site avec le référencement haut de gamme. Je ne vois pas à quel moment un CMS empêche de faire tout ça correctement. Comme je l'ai précisé, je ne maîtrise pas tous les critères "online". Sans vendre ton fond de commerce, quels sont les critères "importants" que tu n'as pas pu traduire simplement dans un CMS ? Ma conclusion : Il est évident que si la personne ne connaît pas de CMS n'a pas d'intérêt à en vendre. D'un autre côté, quand les webmasters ont migré vers XHTML / CSS, certains sont restés aux tableaux, sous prétexte de perte de temps, et donc d'argent. Îls sont bien obligés maintenant de migrer, ne serait-ce que pour optimiser leur source pour les moteurs. Se priver des CMS, c'est se priver : - de mise à jour rapide du site, donc de fraîcheur du contenu, pour les moteurs - de contenu récent, susceptible de fidéliser les visiteurs et donc d'augmenter la visibilité(nouveaux visiteurs + visiteurs fidèles) On pourra toujours compenser en faisant appel à un référenceur. Mais pourquoi pas dès le départ, proposer un CMS avec du référencement ?

Quelles sont les limites des CMS d'un point de vue SEO ? J'ai l'impression que c'est plutôt dû à l'utilisateur qu'au CMS en lui même. (pour l'URL rewriting, ok tous ne sont pas au point) juste pour revenir à cette remarque : Il me semble que le référencement / SEO est à prendre en compte dès le début, même avec les CMS. En quoi les utilisateurs des CMS font un métier différent ? Je n'y connais pratiquement rien en SEO à part ce que j'ai lu sur le HUB mais ma pratique de SPIP ne m'a jamais empêché de suivre les recommandations proposées.

je viens de tous les acheter, tu veux m'en racheter un ?

Par rapport à ton intervention de tout à l'heure, il faut donc que tu atteignes au moins 21000 euros de CA par mois. Avec des produits à 200 euros de moyenne, il va falloir que tu vendes 105 pièces par mois. Avec une conversion de 1%, il te faut 10500 visiteurs uniques par mois. Il faudrait te renseigner pour obtenir des taux de conversion réalistes. // ajout par rapport au message d'Arlette : Aussi te renseigner pour avoir des taux de ventes annulées ou autres incidents. Si l'internaute sait qu'il passe par un intermédiaire, il risque de vouloir te court-circuiter en découvrant la véritable identité du vendeur... Les ventes privées, vraiment pertinentes, peuvent aussi être une clé du succès. Quand les spécialistes de l'ecommerce passeront, ils te donneront surement plus de détails ou de pistes. Tu devrais travailler sur ton positionnement : - faire une préselection chez chacun de tes fournisseurs peut vraiment te permettre de te différencier. - jouer sur l'exclusivité ou la rareté de ton produit Tout ça pour te dire : quelle va être la différence entre ta boutique et toutes les autres ? (je ne veux pas faire l'avocat du diable, mais si mes réponses sont assez négatives, c'est que ça me ferait un peu mal de voir quelqu'un travailler sur un projet 2 ans pour s'apercevoir que dès le départ, les bonnes questions n'ont pas été posées.)

finalement je préfère avoir un h2 dans un span que des spans partout ! N'oublie pas le sens des balises : h2 indique un titre ce qui est le cas de "titre bloc rouge", alors que span n'indique rien. tu peux aussi faire : <h2 class="blocrougetitre"> Titre bloc gris </h2>

Piste 1 : pourquoi utilises tu une balise <span> plutôt que <div> ? Une balise "span" inline n'est pas censée contenir de balise <hn> ou <p>, block. Ce qui pose peut-être un soucis d'interprétation pour le moteur CSS3. Piste 2 : On dirait que ton bloc <p>(celui qui suit 'blocrouge') passe devant le bloc <span>....

si tu pars sur une base de smic (sans les éventuelles aides de l'état) : 2 salaires : 2 * 2800 euros : 5600 euros. Si tu prends une commision de 20%, il faut que tu aies 25000 euros/mois de CA. A moins de vendre du matériel haut de gamme avec des marges et des tarifs élevés, ça me paraît difficile.

Peut-être bien préciser que le site est un service de mise en relation entre le client et le commerçant ? Pour toute réclamation s'adresser directement au commerçant. Les principaux futurs soucis : - les retours - les impayés - les marchandises égarés ou abimées pendant le transport Si les commerçants partenaires acceptent de jouer le jeu, ça peut se faire. Financierement, ça me paraît tendu tout de même.

Tu peux utiliser simpleXML pour parser le fichier et xpath, un fonction de SimpleXML qui permet d'effectuer une requête "XPATH" un peu d'aide sur SimpleXML

le projet est assez original. - comment bloquer la commande en sachant que je ne sais pas si le produit est dispo ? tu as employé le mot "réservation", je crois que c'est le bon terme. J'imagine cela : - L'internaute réserve un ou plusieurs articles - le "webmaster" vérifie les dispos, avertit l'internaute et prépare le bon de commande. - l'internaute valide la commande et effectue son paiement en ligne Plus tu seras réactif, plus tu auras de chance de "vendre" - la commission : elle dépend du volume, du salaire que tu veux, des frais engagés... Tu risques d'avoir des activités "chronophages", comme tenir à jour ton catalogue (photos, saisie etc...) Ne sous-estime pas ce temps passé Il me semble que tu as déjà bien mûri ton projet.

Bonjour, quel SGBD utilises tu ? Dans l'ordre : IN() X IN(ma requete) X doit être égal à l'une des valeurs renvoyée par la requete Equivalent X = any(ma requete) EXISTs(ma requete) Il faut que ma requete renvoie au moins une ligne ANY : X >= any(ma requete) X doit être supérieur à au moins UNE valeur renvoyée par la requete ALL : X >= any(ma requete) X doit être supérieur à au moins TOUTES les valeur renvoyée par la requete

Bonjour à tous. L'article rédigé à 3 plumes par Arlette, Karak, et moi-même devait être un point de départ pour ceux qui voudraient "devenir webmaster". Webmaster étant devenu un fourre-tout désignant un personne travaillant sur un site Web, il cache une multitude de métier. Par exemple, le sujet pour devenir ergonome web est une belle illustration des nouvelles compétences que devrait avoir notre webmaster "idéal". Le but du sujet est donc de venir compléter l'article par vos propositions. Enfin, pour expliquer pourquoi Java et non pas javascript, avant la retouche finale de l'article, je voulais insister sur le fait que pour faire des sites, il n'y a pas que PHP, XHTML, CSS, Javascript Malheureusement, un cafouillage a glissé Java dans la section Intégration/Templating.

Vous pouvez aller voir PHPmotion. Il semble très bien fait. En plus, il y a des hébergeurs conseillés sur le site. Sinon il est clair qu'il y a peu de chances qu'un hébergeur gratuit propose ce genre de services, - la vidéo est gourmande en espace disque et en bande passante - l'encodage à la volée est gourmand en ressources Bonne recherche

Il me semble que dans le cas du "sous-traitant" de Touane, le service acheté n'est pas un site Internet, mais la mise à disposition d'un site Internet. Si nous faisons l'analogie : - le site coûte 8000 euros, sources compris et hébergement libre - le site coûte 1500 euros, sans les sources ni le choix de l'hébergement. en cas de changement, vous payez les 6500 restants. Enfin pour revenir à la question de Touane : - il existe une multitude de prestataires, soit autant de pratiques et tu es tombé sur un cas particulier. - tu peux faire le tour de 4-5 pretstaires pour affiner ton choix. - garde bien en mémoire que tu envoies TES clients vers un sous-traitant. Il te faut une certaine qualité, sinon c'est toi qui aura les soucis.

Il y a deux choses à traiter : - a-t-on le droit d'imposer un hébergement ? pour ma part, je répondrais oui, par contre il faut bien préciser ce qui est vendu. Cela s'appliquerait aux fameux CMS mutualisés dont le prestataire ne veut pas rendre le code public. Peut-être aussi des accords commerciaux avec les hébergeurs mais aussi une habitude technique. Par exemple DAN vend de l'infogérance exclusivement chez OVH. Certains hébergeurs sont vraiment galère à gérer et la migration de la plateforme de test / développement peut même être impossible avec certains hébergeurs. Si vraiment vous souhaitez pouvoir choisir votre hébergeur, il y a quand même beaucoup de webmaster qui seront moins stricts. - le sous-traitant a-t-il un droit de regard sur les tarifs pratiqués ? En pure théorie, non car ce n'est pas son problème. On pourrait se cacher d'ailleurs derrière la libre concurrence. C'est un peu comme si les marques de lait imposait un certain prix de vente aux grandes surfaces Comme je suis pour le commerce équitable, j'aime cependant avoir une transparence des prix, du sous-traitant jusqu'au client final. Le rôle des intermédiaires est bien défini. Pour les affaires apportées et le travail fourni, il est normal qu'ils gagnent une commission. La limite "équitable" est le montant de cette commission.

Il ne faut pas trouver leur comportement bizarre. Dans nos métiers, nous trouvons régulièrement des "intermédiaires" pour apporter des affaires. Dans mon cas, si l'apporteur d'affaires gagne plus de 25% de la facture, je trouve que je me fais avoir. De plus, cela montre que le client n'a pas payé le "juste prix". Sans l'intermédiaire, il aurait payé 1000, avec un intermédiaire équitable 1250 et enfin avec un intermédiaire vraiment gourmand 1500. On veut du commerce équitable, commençons par le webmastering !

Certaines entreprises développent des CMS payants. Choisir leur propre hébergeur ou encore mieux, héberger les sites de leurs clients permet de garantir la qualité de leur service. Dans le cas d'un moteur mutualisé de CMS, une amélioration se répercute immédiatement sur chacun des sites hébergés(correctif, patch de sécurité ou amélioration fonctionnelle....) Il n'y a donc pas que des aspects négatifs à ces pratiques. L'envers de la médaille est que si le client final ne paie plus ou part ailleurs, il ne peut pas "récupérer" son site. Pour le reste, ils te considèrent comme apporteur d'affaires, ce qui est tout à fait légal. Pour les tarifs, je suppose qu'ils veulent éviter les apporteurs qui vendent un site 4000 euros et qui leur reverse 2000. Je trouve ça plutôt normal, mais pour un vrai commercial qui calcule en marge, c'est un peu frustrant