Aller au contenu

Cariboo

Membre+
  • Compteur de contenus

    3 376
  • Inscrit(e) le

  • Dernière visite

Messages postés par Cariboo

  1. A force de déboguer les scripts écrits par d'autres (notamment les stagiaires, qui sont de super bêta-testeurs de tout ce qu'un développeur peut inventer comme trucs non prévus par les concepteurs d'un langage), je me suis rendu compte que de nombreux bogues très gênants tiraient leur origine dans le comportement totalement non intuitif du langage sur les égalités entre valeurs de type différents.

    Voilà un article résumant ce qu'il faut savoir pour éviter de créer des programmes qui ne marchent que dans 90% des cas...

    Tester correctement variables et valeurs en php · LES PROBLÈMES DE TYPAGE ET DE TRANSTYPAGE

  2. En tout état de cause, SPIP ne doit générer qu'une page en cache pour chaque article.

    Pour 800 articles, cela doit faire 800 x 20 = 16000 ko.

    Donc il y'a bien un problème. :blink:

    Deux explications possibles :

    1°) lorsque spip cherche la page en cache existante, il ne la trouve pas, et la recrée systématiquement. Comme il change le nom et l'emplacement du fichier en cache à chaque fois, cela créée potentiellement une page de plus à chaque visite (ouïe) :wacko:

    Il faudrait que tu vérifies si tu as plusieurs occurrences de la même page dans ton cache. Si c'est le cas, cherche de ce côté là

    2°) tu as créé un script qui combiné avec spip est capable de générer beaucoup plus de pages différentes que tu ne crois. Dans ce cas, c'est normal, il faut que tu modifies le script en cause pour éviter la multiplication des petits pains...

    Cela n'arrive que si ton script entre en conflit avec le code SPIP : une page annuaire dans un script réalisé avec SPIP, même si elle change à chaque fois, ne produit qu'une seule page en cache...

  3. En fait si, j'ai été étonné au début, mais pour ajouter des articles dans spip, il suffit d'inserer des enregistrements dans la table spip_articles. Pourvu que l'ID n'existe pas déjà, cela marche du premier coup.

    Si on veut créer l'arborescence automatiquement, il faut bien renseigner l'id de rubrique dans l'enregistrement mais c'est tout.

    J'ai fait cela souvent, il n'y a pas de pb.

    Le reste (indexation etc...) est automatique

  4. Il faut peut etre mettre ce post dans php/programmation, non ?

    :nono:

    Je pense qu'on peut le laisser là. C'est une solution en php à un problème SPIP, d'ailleurs assez courant. J'ai reçu pas mal de messages l'année dernière pour me demander comment j'avais fait pour transformer ma base d'articles Lotus Domino en articles SPIP.

    Il a donc bien sa place ici.

  5. En fait, tu peux mettre ce que tu veux comme données issues de ta base au niveau de ta balise title, à la condition que ta requête SQL soit placée avant la ligne où tu génères la balise title.

    Si ton include ne contient que la requête : il suffit que tu le places avant la balise <TITLE> et tu pourras exploiter le contenu des variables qui ont servi à récupérer le résultat de ta requête dans la balise title.

    Si ce n'est pas le cas (il y'a aussi du code qui sert à générer du HTML) tu extrais la requête SQL de l'include pour la mettre dans la page, ou tu écris une deuxième requête SQL que tu places avant title.

    Bref, ce ne sont pas les solutions qui manquent

  6. La version bêta de PHP 5 (5.0.0 Beta 1) peut-être téléchargée sur le site php.net depuis le 29 juin. La version de production est annoncée pour la fin de l'année. Mais quels sont les changements qu'apportent cette nouvelle version du langage ?

    Vous trouverez les réponses dans ce nouvel article de webmaster-hub.com :

    Les nouveautés de la version 5 du PHP.

    Si vous avez des commentaires, des questions, des corrections ou des compléments à apporter, n'hésitez pas à les poster dans ce forum.

  7. Le langage PHP en sera bientôt à sa version 5, qui le dotera de nouvelles possibilités et le transformera en un langage de programmation complet... Devenu un standard du web, son extension rapide dans le monde de l'internet a fait oublier ses origines modestes...

    Lire l'article dans la zone publication :

    Article : Les origines du PHP

  8. De mémoire, je croyais qu'elle fixait aussi la responsabilité des éditeurs de contenu. On en a assez entendu parlé concernant la responsabilité du webmaster sur les propos tenus sur un forum.

    Je me suis très mal exprimé. La LEN contient pas mal d'autres choses, mais je faisais allusion à la partie que tu avais mise en lien : sous des dénominations inexactes (non définies clairement dans le texte, ce qui laisse la porte ouverte à pas mal d'interprétations erronées), elle vise seulement les fournisseurs d'accès et les hébergeurs.

    Pour l'affaire Lorie, un lien vers les attendus :

    Les attendus en pdf

    Bon c'est juste une décision de référé dans un TGI, donc cela ne vaut pas grand chose dans la hiérarchie de la jurisprudence...

  9. Voilà une bonne idée, Mirgolth... Donner le lien vers le texte de la LEN. Une lecture que je conseille à tous les webmasters. ;)

    La LEN précise les limites de responsabilité des hébergeurs et des fournisseurs d'accès, mais n'a pas de conséquences sur la responsabilité des moteurs de recherche.

    Par ailleurs, cette loi n'a pas encore été adoptée, et a fortiori n'est pas encore en vigueur. Mais elle devrait être promulguée dans sa rédaction actuelle (à une virgule près).

    Pour répondre à Ernestine, dans l'absolu, la mise en cause d'un moteur qui facilite l'accès à un contenu illégal n'est pas exclue. :(

    La question ne s'est pas encore posée sérieusement à ma connaissance en France, donc il n'y a pas de jurisprudence claire. Les juristes ne sont pas tous d'accord, et les décisions de justice vont dans les deux sens (responsabilité ou non).

    Car il y'a le précédent Yahoo, mais aussi des cas comme l'affaire Lorie vs. Voila.fr...

×
×
  • Créer...