Jump to content

TheRec

Hubmaster
  • Content Count

    1777
  • Joined

  • Last visited

Everything posted by TheRec

  1. Un article très intéressant Merci ! Je me réjouis de lire la suite prochainement. Mon passage préféré c'est sans doute celui-ci : C'est tout de même bien qu'une cour de justice puisse définir ce que les professionnel de la branche, après des années, n'ont pas défini et ne pourront sans doute jamais définir vu la foultitude de paramètres qui définissent un internaute et ses capacités/compétences sur Internet Je en droit suisse nous avons la particularité de recourir au principe de la "bonne foi", est-ce que c'est pareil au niveau européen (je serais très étonné si c'est le cas) ?
  2. Tous mes vux de bonheur et de succès aux membres du Hub pour cette année 2010
  3. Du bon usage des sauvegardes Bien joué et merci pour ta réaction rapide ! Bon c'est pas si grave pour ces messages perdus, les gens sont tous occupés à vider les étagères des magasins ces derniers samedis avant Noël
  4. Super Dan, merci pour ce boulot Tout semble fonctionner comme annoncé
  5. Très bonne interview Arlette comme d'habitude, merci à tous ceux qui ont participé à sa réalisation
  6. Bonjour, Tu as également la possibilité d'ajouter la propriété CCS "overflow" au conteneur de ton tableau : #contenu { overflow: auto; } Cette propriété permet de contrôler la méthode appliquée par le navigateur lorsqu'une dimension d'un conteneur est dépassée par celle de son contenu. En définissant une largeur à ce conteneur et cette nouvelle propriété avec comme valeur "auto", le conteneur aura une barre de défilement horizontale lorsque le contenu sera trop long. Lorsqu'il sera plus court, il n'y aura pas de barre de défilement... seul bémol, tu n'as pas de contrôle sur la mise en forme de ses barre de défilement et la barre horizontale est affichée en bas du conteneur. Bonne continuation.
  7. Salut, Lorsque tu essaies de glisser l'icône de la page courante dans ta barre personnelle afin de l'ajouter à ta barre, où se retrouve-t-elle lorsque tu consultes tes maques-pages par le menu "Marque-pages" ? Est-ce que tu as plusieurs dossier nommés "Barre personnelle" dans ce même menu ?
  8. Bonjour, La commande SQL est "INSERT INTO dc_article_post" ... si tu n'as pas de table nommée "dc_article_post" dans la base de données dans laquelle tu souhaites importer ces données tu reçois logiquement une erreur. Change le début de cette commande en "INSERT INTO dc_post" et bien sûr fais ton "Import" (dans PHPMyAdmin, je suppose) lorsque tu te trouve sur la base de données "db255274416". Si la table "dc_post" n'existe pas dans cette base de données ("db255274416") tu devras la créer... les tables ne se créent pas toutes seules
  9. Salut, N'aurais-tu pas l'option "MultiViews" qui serait activé sur ton serveur par hasard ? Essaie d'ajouter la ligne suivante au début de ton fichier .htaccess dans le répertoire racine de ton site : Options -MultiViews Bonne continuation.
  10. Salut, Pour ce qui est d'enlever les messages, à moins qu'il y ait des données personnelles dans cette discussion, tu n'as pas vraiment de raison (légale) de supprimer ces messages... et même dans ce cas tu n'a pas vraiment à supprimer les messages en eux-mêmes, mais à éditer leur contenu. S'il s'agit de diffamation etc. c'est le même principe, du moins c'est ainsi que nous procédons de manière générale sur le Hub et il n'y a pas eu de problème sérieux à ma connaissance Peut-être qu'en demandant à ces membres en quoi discuter d'un membre banni est constructif tu auras ta réponse... à mon avis il ne trouveront pas de motif constructif. Si le but de la discussion est d'essayer de réintégrer le membre en question (donc se substituer à l'équipe de modération) ou s'il s'agit de "charger" encore plus le membre en question, je ne vois pas en quoi c'est constructif. Maintenant, dans tous les cas, comme l'a dit georges, si la discussion n'entre pas dans le cadre de ce que tu veux (en tant que membre de l'équipe de modération... tu n'est pas arrivé(e) à ce poste par hasard je suppose ) sur le forum, c'est logiquement ton travail de modérer ce sujet. Si les règles "brisées" par les membres ne sont pas exactement définies, c'est sans doute le moment de les établir. Typiquement, "on ne montre pas du doigt", règle présente sur le Hub, pourrait s'appliquer sans souci. Bonne continuation.
  11. Salut, Depuis la version 3.2.3, le plugin paste permet de coller et nettoyer du contenu en provenance de Word. Il y a également un bouton "Paste from Word" si nécessaire. Avant cette version les plugins de "collage" étaient séparés donc il fallait activer le bouton "Paste from Word" et coller le texte dans la fenêtre de popup qui apparaissait et confirmer.
  12. TheRec

    Listage de table SQL

    Salut, Vraiment pas regardant C'est juste un SELECT pour le moment... mais s'il venait à remplacer ça par des instruction destructives (TRUNCATE TABLE, DELETE FROM, etc.), je pense que tu tiqueras plus (même avec des backups réguliers ) Cela s'appelle une injection SQL, tu trouveras énormément d'aide à ce sujet en cherche un peu. Suis le conseil de SStephane utilise mysql_real_escape_string sur ta variable $_GET['id'], c'est un très bon début. De manière générale, ne jamais utiliser de données fournies potentiellement par un utilisateur (même des en-têtes HTTP) directement dans une requête SQL sans les avoir assainies préalablement. Bonne continuation.
  13. On ne s'est sans doute pas compris, tu ne souhaitais pas que le bloc #page soit centré sur la page ? C'est ce que j'avais compris suite à la réponse de captain_torche, donc si tu ne veux pas qu'il soit centré, effectivement ma réponse n'est pas appropriée, tout comme la sienne. Ton problème est donc le fait que la le bloc #column2 est affiché en dessous du bloc #column1 sous IE6. En fait tes deux colonne n'ont pas à être en float, tu peux définir le float: left; uniquement sur #column1 et sur #column2 définir une marge à gauche suffisante qui permet de "simuler" la largeur de la première colonne lorsque le contenu de la deuxième est plus long. Donc ton code CSS pour ces deux colonnes devient : #column1 { float:left; margin:0 0 0 20px; width:240px; display: inline; } #column2 { margin:0 0 0 260px; width: 600px; } Le display: inline; sur #column1 corrige un bogue de Internet Explorer 6 qui double la marge d'un élément en float En fait en ajoutant simplement cette ligne ça réglerais ton problème, mais je trouve toujours plus facile de gérer du contenu qui n'est pas déjà en float, après c'est à toi de voir ce qui te convient le mieux
  14. Pas plus que ma première réponse, qui est complémentaire à celle de captain_torche, je t'invite à la relire, elle règle ton problème alignement au centre pour IE6. Au passage tu n'a pas défini de DOCTYPE pour ta page, c'est tout de même important pour que certains navigateurs ne passent pas d'office en mode compatibilité (quirks). Et si tu peux, essaie de corriger les erreurs de validation sur ta page (doublons pour les "id", tags <body> et <html> fermés deux fois, etc.), tu y gagnera lors de ce genre de "debug" de ta charte graphique. Bonne continuation.
  15. Salut, Et sous IE6, que le conteneur parent de celui qui doit être centré doit également avoir la propriété text-align à la valeur center (ensuite définir à nouveau cette valeur pour les enfants à ce qui te convient). Donc dans ton cas : body { text-align: center; } Au passage, ce n'est pas logique et ça ne suit pas les recommandations du W3C quant à la fonction de text-align, mais IE6 fonctionne ainsi malheureusement.
  16. Selon l'usage on a tout le mois de janvier pour se les souhaiter ces vux Bonne et heureuse année 2009, santé et succès à tous !
  17. Par l'URL, avec la méthode GET de HTTP donc. <link rel="stylesheet" type="text/css" href="style28.php?fontsizeem=<?php echo $fontsizeem; ?>" />/ Dans le script PHP (style28.php) tu peux récupérer cette valeurs grâce au tableau $_GET : echo $_GET['fontsizeem']; Sois bien conscient que cela fait office d'une requête HTTP différente de celle de ta page d'appel et donc les autres variables déclarées dans celle-ci ne sont pas disponible (à moins de les passer par l'URL de la même manière).
  18. As-tu suivi le lien que t'as proposé captain_torche ? La page contient un exemple de code PHP pour l'utilisation de cette fonction.
  19. C'était mon propos captain_torche, merci de l'avoir clarifié. Je ne vois pas en quoi proposer cette fonctionnalité, qui n'influence que le choix de la langue lorsqu'elle n'est pas spécifiquement définie par l'utilisateur (par un sous-domaine, un prefix dans le chemin et en dernier ressort une variable de session)... mais bon si tu trouve plus ergonomique de le laisser arriver sur un langue par défaut dans tous les cas ou un sélecteur de langue à l'entrée du site, pourquoi pas Mon optique est de faire "au mieux", vu que l'information transmises par les en-têtes HTTP n'est pas une garantie de la langue de l'utilisateur. Et dans tous les cas, sans négociation, tu ne pourras pas présenter de page dans la langue de l'utilisateur... donc le choix se résume à soit essayer de proposer quelque chose qui correspond à l'environnement de travail de l'utilisateur (si le choix n'a pas été fait avant selon la décision de l'utilisateur avec les moyens évoqués précédemment !) ou ne pas s'occuper de la langue de l'utilisateur et le laisse changer la langue quand elle ne lui convient pas. Le fait que la négociation de langue "casse" l'historique tient plus du fait du développeur que de la technique en elle-même, il est tout à fait possible de développer la négociation de façon à ce qu'elle soit une simple redirection par en-tête. Le cas que tu expliques correspond justement à une redirection effectuée en contradiction avec les recommandations du W3C, forcément tu t'expose à ce genre de problèmes. Et évidemment que laisser le choix à l'utilisateur, sur toutes les page du site est primordial... négociation de langue ou non P.S. : Pour ce qui est d'arriver sur le site depuis un moteur de recherche, le seul problème (outre une mauvaise redirection) se pose pour les pages qui n'ont pas une URL spécifique en fonction de la langue (ce que le W3C ne recommande pas), entre autre la page d'accueil du site généralement... après c'est clair que si tu laisses l'accès aux autres contenus sans discriminer leur langue au moyen de l'URL tu te retrouve dans la même situation. Un site multilingue implique donc une gestion stricte des URL de chaque page, pour limiter l'usage de négociation de langue à la seule page d'accueil.
  20. Bonjour, Et si tu veux faire cela directement dans une requête SQL (étant donné la section où tu as posté ton message) tu peux utiliser la fonction LAST_INSERT_ID. Il faut juste faire attention à cela : Source: Documentation MySQL 5.0
  21. Bonjour, Je ne suis pas totalement d'accord avec Dadou concernant la négociation de langue, elle n'est pas nécessaire mais en même temps elle ne pose aucun problème si par la suite il est possible à l'utilisateur définir lui-même la langue dans laquelle il souhaite utiliser le site (dans le cas où la négociation n'aurait pas été efficace). De plus, si tu ne proposes pas ce genre de négociation cela implique d'avoir une langue par défaut ou un sélecteur de langue à l'entrée du site, ce qui du point de vue de l'utilisabilité ne se justifie pas plus qu'une simple négociation de langue. Même si un utilisateur est forcé à utiliser un navigateur dont l'interface n'est pas dans la langue dans laquelle il veut consulter le contenu, il a la possibilité de définir, dans la majorité des navigateurs modernes, une liste de priorité des langues qui est justement utilisée dans la négociation de contenu. Certains répondront que cette fonctionnalité des navigateurs n'est pas très "connue" et à cela je répondrai que c'est exactement la même problématique que les liens avec target="blank", les développeurs n'ont pas à corriger ou forcer le comportement de l'utilisateur face au navigateur et à sa configuration.
  22. C'est un peu ce que j'ai dit en première page Dadou Mais avec le code déjà prêt Merci ... je n'ai pas creuser dans le code de cette extension, mais je suppose que la détection suit le même schéma logique, on tente de détecter la longueur des caractères et leur type, mais on arrive vite au limites de cette méthode... lorsqu'on utilise des caractères des alphabets russes, chinois, etc. Et malheureusement, bon nombre d'hébergements mutualisés ne proposent pas mbstring par défaut et pourtant cette extension est très utile et je doute qu'elle consomme tant de ressources que cela, dommage
  23. Très bien cet article captain_torche, merci Joli coup pour le remplacement des accents, je n'y aurais pas pensé. Concernant la fonction is_utf8, c'est une détection d'octets longs assez approximative... en fait il n'est pas possible de détecter efficacement (sans BOM ... et encore c'est une indication uniquement) si une chaîne est encodée ou non en UTF-8 (ou un autre chartset). Pour information il existe également une extension de PHP qui permet de faire le même travail que cette fonction qui s'appelle mbstring (pas toujours disponible car il faut l'installer, elle n'est pas présente par défaut) et la détection peut se faire grâce à mb_detect_encoding. Maintenant, rien qu'en lisant les commentaires on s'aperçoit que la détection doit se faire sensiblement de la même manière vu les bugs liés à divers caractères étendus. Mais c'est tout de même mieux que de simplement ignorer l'UTF-8 et je ne vois de toute façon pas de solution viable... c'est pour cela qu'il n'est pas recommandé d'avoir des charset différents dans un même système Encore une chose, urlencode ou plutôt rawurlencode (une des différences entre ces deux fonction est l'encodage des espaces, respectivement "+" et "%20") suit la RFC1738 et s'applique aux données passée dans la querystring. Pour ce qui vient avant la querystring, il faut procéder à un double encodage, cela correspond à la RFC3986, section 2.5). Mais cela pose d'autres problèmes au niveau des moteurs de recherches qui ne semblent pas respecter cette RFC3986 en stockant des URL décodées, comme je l'avais évoqué précédemment.
  24. Comme d'habitude, une très bonne interview. Merci à tous les intervenants
  25. Bonjour, Tu peux le faire en utilisant une page "intermédiaire" qui effectue une redirection (de préférence avec les en-tête HTTP et donc à priori la fonction header et le type de redirection HTTP de ton choix, 301 fera l'affaire) vers l'URL réécrite en se basant sur la paramètre passé en POST ou en GET (en fonction de ton choix) pour la composer. cyberlaura> Si des utilisateurs publient une URL pointant vers des résultats de recherche dans un forum par exemple, cette URL non réécrite sera éventuellement indexée, je suppose que c'est cela que tribords souhaite éviter. Sinon effectivement, comme tu le dis, les moteurs de recherche ne soumettent pas les formulaires à l'heure actuelle.
×
×
  • Create New...