angel-dust-web

angel-dust-web je ne suis pas du tout d'accord avec ta vision des choses, aujourd'hui, il est quasiment incontournable de laisser la main sur le rédactionnel du site au client, mais bien sûr cela se fait intelligemment.

Pour ma part j'utilise un TinyMCE customisé par mes soins pour ne pas laisser trop de possibilités dévastatrices à l'utilisateur.

Sur le rédactionnel oui, mais de là à le laisser faire de l'html... Aucune chance de le faire utiliser les styles définis, grand risque de faire du code qui n'est plus valide... Je vois surtout des inconvénients. Sans même parler du fait que si le client modifie lui même ses pages, je sers à quoi, moi ?

Lui laisser entrer du texte, en mettre des bouts en gras ou insérer des liens, oui, mais faire de l'html, non, je ne trouve pas que ce soit une bonne idée. Toujours avec mon garagiste, je ne pense pas qu'il m'aiderait à me passer de lui pour des grosses réparations sur ma voiture. L'entretien courant oui, mais pas plus.

Mais cela n'engage que moi, et je me tiens a disposition des clients qui ont cassé leur site en voulant en faire trop, je leur ferai un devis du coût des réparations.

Bonjour,

autant demander à un garagiste ce qu'il dit à un client qui veut lui même remplacer l'embrayage de sa voiture... Il dit "allez-y, faites le, quand ça sera cassé, je vous réparerai tout ça"

Faire du code pour un site, c'est un métier, ça ne s'improvise pas, si un client veut modifier tout seul, il faut bien lui expliquer que si il y a des professionnels pour faire ça, c'est qu'un novice ne peut justement pas le faire (même si il peut avoir l'impression de bien le faire).

Je vais tenter le micro-paiement pour des prestations de niveau 1, 1.5 ou 2 euros.

Je possède déjà Paypal pour les sommes plus importantes, je vais créer un nouveau bouton.

Je n'ai pas l'expérience Allo-Pass. Est-elle simple à gérer ? A quelle répartition puis-je m'attendre entre les deux modes de paiement.

La différence entre les 2 systèmes étant qu'AlloPass ne requiert pas d'inscription, un simple coup de fil suffit.

Merci d'avance pour les conseils et comptes-rendus d'expérience.

Perso, j'ai trouvé AlloPass très simple à intégrer. Le gros problème , toujours selon moi, c'est leur gros pavé à intégrer dans la page qui "salit" ton design. Si c'était un peu customisable, ne serait-ce qu'au niveau des polices et des couleurs, ce serait bien. Autre problème, si je me souviens bien, ma page écrite en xhtml ne passait plus la validation w3c avec leur code. Après pour ce qui est de la gestion, c'est simple et plutôt bien fait.

Bonjour,

Je pense que Vespa voulait parler d'équivalence de date, et non de "jour" uniquement...

Je pense que ça devrait marcher comme ça :

$rq = 'SELECT champ FROM table WHERE ladate LIKE "'.date('y-m-d').'%"';

Sinon, tu peux utiliser la fonction substr en SQL, mais ce doit être plus lourd :

$rq = 'SELECT champ FROM table WHERE SUBSTR(ladate, 10) = "'.date('y-m-d').'"';

dans ce cas,

select * from MA_TABLE where to_char(MON_CHAMP_DATE, 'dd-mm-yyyy')='13-10-2009';

en régle générale, je préfère convertir une date en chaine qu'une chaine en date. Ce n'est pas pasqu'on voit affiché "2009-10-10 18:42:33" sur son phpMyAdmin ou autre qu'on doit estimer qu'en SQL, la vue sera la même (les préférences d'affichage peuvent formater la date différemment, genre format fr, etc...). Il me parait plus prudent de demander a SQL de s'occuper de la conversion au format demandé, plutôt que d'essayer de gérer soit même. Sans compter qu'un débutant pourrait comprendre qu'une date et une chaine sont la même chose, et une fois arrivé dans un langage fortement typé, chercher pendant des heures pourquoi son test ne marche pas...

// exemple en java : 
      Date date = new Date();
      if (date.equals("13/12/2009")) { // Syntaxe ok, mais ne fonctionnera jamais 
      ....

Attention, je ne veux pas dire qu'en java, on doit convertir les dates en chaines pour les comparer, hein ?

voilà :

select * from MA_TABLE where to_char(MON_CHAMP_DATE, 'dd')='12'; -- Avec '12' à remplacer par la date du jour

Je pense que je vais adopter cette solution.

Je m'étais dit que les internautes intéressés auraient plus de facilité à voir une page à imprimer plutôt qu'un pdf à télécharger.

J'ai l'art de me compliquer la vie

Merci pour ta réponse.

Sans compter que souvent les PDF s'affichent directement dans une fenêtre adobe reader intégrée au navigateur, ce que personnellement je déteste, mais qui est bien pratique pour le surfeur "moyen" (ou moyen--).

Eclipse (PHP)

A mon avis, les textes sont bien centrés mais les span ne prennent pas toute la largeur, ce qui donne donc l'impression que le texte est aligné à gauche. Un bon truc que j'utilise quand je travaille avec des div ou des span, c'est de leur mettre une couleur de fond pendant la construction pour bien visualiser comment ils s'agencent dans la page. J'espère que ça peut t'aider...

Bonjor,

cherche "Div transparent" sur google, tu devrais trouver pas mal de choses.

Par exemple : http://www.lephpfacile.com/forum/2-html-cs...e-superposition

Bonjour,

la partie ([a-zA-Z0-9-]+) de ton expression régulière ne matche pas %2B...

essaye plutot

RewriteRule ^achat-de-([a-zA-Z0-9]+)%2B-a-prix-reduits\.html$ /boutique/boutique.php?art=$1 [QSA,L]

Merci pour vos réponses. Je dois tout modifier, donc.... :-s Bon, ben j'ai du travail...

Bonjour,

mon site est dynamique et utilise par défaut la langue du navigateur. Cette langue est stockée en session et peut être changée par un clic sur un petit drapeau (soumission de la nouvelle langue en POST via JS).

Mon problème est qu'à cause de cette architecture, les robot ne référencient que les pages en anglais. Je souhaiterais éviter de devoir modifier toutes mes pages pour gérer un paramètre &lg=fr, surtout que je fais plutot du POST. Je souhaiterais aussi éviter de devoir dupliquer toutes mes pages dans un répertoire /fr.

Quelqu'un connait-il une solution simple et rapide à ce problème ?

je ne comprends plus rien....

effectivement si je remplace 'tgpp' par 'abcd', ca fonctionne très bien. la seule raison que je voie, c'est que j'ai une page qui s'appelle tgpp.php (même si je comprend pas pourquoi le fait d'avoir une page du même nom que ce qu'il devrait considérer comme un répertoire fait qu'il renvoie la page AVANT la ré-écriture).

Si je remplace mon 'tgpp' par n'importe quel nom de page, genre 'index', il m'affiche la page du même nom ('index.php').

=> J'ai donc ma solution. renommer ma page tgpp.php en autrechose.php et tout ira bien....

merci à tous pour votre aide

si, sans problème avec

  ini_set("session.use_cookies", 1);
  ini_set("session.use_trans_sid", 0);
  ini_set('session.use_only_cookies', 1);

placé en début de code

Merci Leonick, je vais essayer ça. Question subsidiaire, comment faire pour que disparaissent tous les ?PHPSESSID des pages indexées par googlebot ? (Et comment se fait-il qu'un bot si évolué ne sache même pas reconnaitre qu'il est sur la même page ? )

Cela devrait marcher effectivement...

Remonte dans l'arbre de ton hébergement pour voir s'il n'y a pas d'autres htaccess qui interfèrent (même en multidomaine, tous les htaccess au dessus sont pris en compte).

Sinon essaie avec abcd/ au lieu de tgpp/ au début du premier paramètre.

Remi, c'est mon htaccess racine... :-( Je vais essayer de changer ma redirection comme tu dis, je te dirai

de toutes façons, il faut paramétrer php pour que les PHPSESSID passent par cookie

En mutualisé, difficile de paramétrer php... Et là, ils sont en session donc en cookie.

Problème : googlebot ne prend pas les cookies, donc il met ça en url

Solution : se passer des sessions, ça devrait être possible pour moi

Pour info, ta règle :

RewriteRule (.*)(\?PHPSESSID=.*) $1 [R=301,L]

ne passera JAMAIS !

Lorsqu'on veut traitre le %{QUERY_STRING} il faut utiliser une règle conditionnelle, et non une règle classique.

Merci Dan, sans doute pour ça que google me liste toujours des milliers de pages avec des ?PHPSESSID... Je vais fixer ça.

merci, mais en fait j'avais bien mes + sortis des parenthèses. En fait, c'est exactement là règle que tu donnes qui ne fonctionne pas. Pour résumer :

tgpp([0-9]+)/([0-9]+)/index\.html /tgpp.php?gal=$1&type=$2  [NC,L]

fonctionne avec une adresse tgpp1234/1/index.html

mais

tgpp/([0-9]+)/([0-9]+)/index\.html /tgpp.php?gal=$1&type=$2  [NC,L]

ne fonctionne pas avec une adresse tgpp/1234/1/index.html

sinon, je suis bien d'accord qu'elle devrait fonctionner. quelqu'un de très aimable ayant un hébergement mutualisé chez ovh pourrait essayer et me faire part de ses conclusions ? ca serait vraiment sympa (vu qu'ovh ne fait rien à part m'envoyer des liens sur leur pauvre page d'aide, qui ne dit rien...)

regards

A priori, non

Options -Indexes
Options +FollowSymlinks
SetEnv SESSION_USE_TRANS_SID 0 
RewriteEngine on
RewriteRule (.*)(\?PHPSESSID=.*) $1 [R=301,L]
RewriteRule ([a-z]+[A-Z]+)-([a-z]+[A-Z]+)-([a-z]+[A-Z]+)\.htm /hide.php?mot1=$1&mot2=$2&mot3=$3  [NC,L]
RewriteRule tgpp([0-9]+)/([0-9]+)/index\.html /tgpp.php?gal=$1&type=$2  [NC,L]

toujours pas avec le '/'. Si je met une adresse tgpp_1234/1/index.html ça fonctionne, mais pas tgpp/1234/1/index.html..... (je précise que je n'ai aucun répertoire tgpp qui mettrait le grouille)

je suis pas fou ? y'a un bug ?

Dan,

je veux réécrire

monsiteweb.com/tgpp/0715/1/index.html

en

monsiteweb.com/tgpp.php?id=0715&type=1

Merci Jean-Luc, j'ai essayé, ça ne change rien. Les '/' n'ont, à priori, pas besoin d'être escapés. Quant aux ([0-9]+) - (mal écrits dans mon premier post comme tu l'as remarqué ), j'ai essayé plusieurs choses, y compris (\d*), (.*) et ça ne change rien.

Il est intéressant de constater que si j'écris

RewriteRule tgpp(.*)/etc.....

tout fonctionne. Ce sont les '/' avant le premier groupe de regexp qui causent le problème.

Ce qui me surprend, c'est d'être le premier chez ovh qui fasse une telle redirection... elle ne me paraît pas si originale que ça...

Bonjour,

je rencontre un problème avec là régle suivante chez OVH mutualisé :

RewriteRule tgpp/([0-9])+/([0-9])+/index.html /tgpp.php?id=$1&type=$2 [NC,L]

elle fonctionne très bien en local (Mac OS + MAMP et WinXP + EasyPhp) mais sur ovh, les paramètres ne sont pas remplacés (cad que c'est bien la page tgpp.php qui est affichée mais sans id et sans type).

J'ai essayé pas mal de trucs. Si je remplace les '/' par autre chose (genre '_') ça fonctionne très bien. En fait, c'est juste le premier '/' qui pose problème car la régle suivante fonctionne :

RewriteRule tgpp([0-9])+/([0-9])+/index.html /tgpp.php?id=$1&type=$2 [NC,L]

Quand je contacte le support technique d'ovh, ils me renvoient sur leur aide sur les réécritures d'url, ce qui ne sert à rien vu la vacuité de celle-ci.

Ma question : c'est moi qui fait une erreur grosse comme une maison que je ne vois pas ? Quelqu'un a déjà rencontré le probléme ?

Bonjour,

me voici, 33 ans, 11 ans de développement d'applications en tous genres pour des clients.... en tous genres.

J'ai commencé en basic sur CPC 6128 et j'en suis à Java/J2EE sur des machines un peu plus modernes et puissantes. Mon site est en php/MySQL (pour être un peu original).

Mes passions, le heavy metal (guitariste depuis une quinzaine d'années), la photographie et bien sur le web