Oui, c'est ce que je veyux dire, c'est l'offre commercial qui n'a pas de limite, mais physiquement, la bande passante est limitée sur le serveur, tout comme l'espace disque.
Quand aux données, ce n'est pas seulement une question d'être confidentielles ou pas. Même des données non confidentielles, si c'est moi qui les ai créé, c'est à moi qu'elles appartiennent, pas à un autre hébergeur.
J'autoheberge ces données pour garder cette propriétés.
En plus, avec tout ce qui se passe actuellement, ça ne me donne sérieusement pas envie d'aller héberger mes données je ne sais où.
Au moins, mes 3To de DATA, je sais où elles se trouvent, elle sont chez moi. Il n'y en a pas un bout en europe je ne sais où, un bout aux USA, plus une copie faite par l'hébergeur au canada...
Enfin, voilà moin point de vue.
Pour moi, la conservation de ce qui m'appartient est primordial. Je suis seul à devir accéder à mes données. Je n'ai pas envie que Roger (nom fictif), administrateur système chez OVH puisse voir mes données.
lut;)
j'arrive peut-être un peu après la bataille ... mais, pour différents tests, rien que ceci:
" Une version future aurait la correction mais c'est très facile de trouver les 2 endroits à l'intérieur du $format de 2 fonctions lastArtList qui se lisent " me coince, j'ai trouvé en fait 28 occurrences à ces références mais aucune qui ne soit véritablement 'exacte' ...
pourrais-tu soit mettre le thème à jour dans les ressources, soit nous donner, ici, le codage finalisé de la 'home', ce serait plus que bien @+
Il y avait peut-être 28 utilisations de la fonction, mais seulement 2 étaient incorrectement formatées.
Si tu installes le thème sur un site de nouvelles multi-canaux et que tu l'intègres avec ton contenu, il me fera plaisir de te pointer les deux endroits erronés qui devraient être très apparents visuellement.
Des douzaines d'autres adaptations manuelles sont nécessaires pour intégrer ce thème, il faut sérieusement installer un site pour s'en servir. Ce n'est pas un thème qu'on essaye pour quelques minutes avant de comprendre que notre contexte ne s'applique pas. Notre ami avait exactement la mission de créer un portail de nouvelles, il avait des défis à relever et récolte le fruit de son travail.
et pour une copie de la home.php, elle dépasse les 300 lignes...
et pour une copie de la home.php, elle dépasse les 300 lignes...
bon alors donc = laissons tomber, mais la réponse dans laquelle tu as donné une solution pour l'adaptation des images, je n'arrive donc pas à la mettre n place, ne trouvant pas la / les lignes concernées ... @+
Si tu mets le thème en ligne ça va simplement mal cadrer deux images, tu me donneras l'adresse et je te pointerai les deux endroits.
L'exercice n'est pas anodin, il faut installer un site sans plugin et passer des jours à préparer le thème pour ton contenu de toutes façons, cette anomalie est à peine visible mais je peux te la trouver en quelques minutes une fois en ligne.
Bonjour, depuis que j'ai installé le thème, mes visites augmentent énormément.
Je suis passé d'environ 6000 pages vues par mois à plus de 15700 déjà pour ce mois-ci, alors que le nombre de visiteurs stagne...
Quand je regardes dans les visiteurs actuellement en ligne, je tombe sur des choses comme celles-ci :
Si les pages vues augmentent avec un niveau de visiteurs relativement stable, c'est que les gens apprécient ton contenu et passent d'une page à l'autre sans s'endormir ou perdre l'intérêt. Le thème a sa part des choses mais c'est le contenu qui tient le visiteur par le cou.
Il faut pas s'en faire pour le plafonnement des visiteurs uniques, il est encore tôt, ces clients satisfaits vont probablement passer le mot, cliquer sur les like de Facebook et autres pour mousser ta pub par le bouche-à-oreille numérique. C'es dommage que tu aies retiré les gros boutons de réseaux sociaux dans la sidebar, ils auraient peut-être fait leur bout de chemin aussi.
Pour le fichier manquant, il faut que tu fasses un favicon avec ton nom/logo/quelque-chose pour le placer à l'endroit mentionné.
Je pense que tu m'as mal compris, Pierre.
Il ne s'agit pas d'un fichier manquant, mais de la page que visite en ce moment le visiteur dont j'ai masqué l'IP.
J'ai pas mal de visites sur des fichiers du thème au lieu des pages des articles en eux-même.
Pour les boutons des réseaux sociaux, je les ai retiré puisque je ne sais pas comment rattacher Vimeo, où je stocke mes vidéos au bouton YouTube.
Les petits robots parasites frappent à toutes les portes, c'est bien connu. Parce que le fichier se fait appeler textuellement par le header.php pour afficher le favicon, il est fiché par les DNS pour servir de favicon dans les fureteurs de tes visiteurs.
Les plateformes professionnelles de gestion des pages vues font abstraction des fausses pages vues pour ne pas donner une image erronée de la popularité d'un site, les publicitaires ne sont pas dupes, on doit leur dire quelque chose qui se rapproche de la vérité, même si c'est parfois difficile de discerner les humains des robots. Les règles de confidentialités sont plus importantes que de monnayer les pubs, on ne peut tenir la trace exacte d'un visiteur à répétition. Les publicitaires acceptent cette réalité tant que le calcul est équitable et fait par une firme indépendante.
Les petits plugins te guident un peu pour diriger ton énergie aux endroits qui manquent de visibilité, ce n'est pas une science exacte.
Merci pour ta réponse Pierre.
Cependant, celle-ci m'étonne puisqu'en principe les robots sont dissociés des visiteurs humains par SimpleStat dans mes statistiques.
Je sais bien que je n'ai pas réellement 15700 pages vues/mois, Pierre.
Mais les robots sont en principe dissociés, ça veut dire que certains passent quand même du coup.
Bonsoir,
J'ai publié un nouvel article il y a environ 45 minutes, et depuis la publication de cet article, j'ai un gros bug d'affichage sur ma page d'accueil : http://lolyangccool.ovh
A partir de la rubrique Critiques, présentations et tests.
Avant que je ne publie l'article sur Apple, tout allait bien.
J'ai pourtant pris soin de ne pas mettre de mise en forme dans le chapô.
Si tu me copies-colles la fonction lastArtList tirée de home.php à cet endroit, je peux y jeter un coup d'oeil. Je soupçonne que la chaîne de texte ne ferme pas comme il faut pour l'échantillon de chapo, le mot "inconditionnel" est coupé prématurément. Si un éditeur (plugin) est utilisé, il peut être la cause de la mauvaise coupure.
Et l'essai sans plugin? En remplaçant ton chapo par un bout de texte brut et court, tu verras probablement tout se régler.
C'est un test qui se fait en quelques minutes, évitant de garder son site dévisagé pendant des heures en attendant que quelqu'un trouve un problème causé par un code que tu as mis au travers du texte, si c'est le cas bien sûr.
et il est où ce test avec un chapo en texte brut? le chapô est le même depuis hier.
Il faudra ensuite essayer en elevant l'article, en le mettant dans une autre catégorie. C'est du quotidien de webmestre qu'on fait en quelques minutes quand un article casse tout.
C'est pratique pour moi d'avoir l'erreur en ligne mais c'est pas très marketing ni professionnel de laisser ça en production. Un environnement de développement serait peut-être une bonne idée pour parfaire la formation du webmestre sur les anicroches possibles causés par excès de plugin. Un setup classique est d'avoir un site de type "carré de sable" où on casse tout allègrement, un environnement de préproduction pour tester des machins comme aujourd'hui, et la version publique qui fonctionne comme un charme.
Regardes aussi les articles de la section précédente, on dirait que tu ne fermes pas la section du premier bloc avant de débuter le deuxième. Puisque les liens href ne fonctionnent plus à partir de cette première section (astuces et articles aléatoires), je soupçonne un lien A ouvert mais jamais refermé.
Pierre, après l'essai j'ai remis le chapô initial.
C'est bien malheureux si je dois publier mes articles d'abord sur un site de tests avant de les mettre en ligne.
Je ne pensais pas que la publication d'un nouvel article pourrait tout casser...
Pierre doit avoir raison, le problème doit vraiment venir de l'article. Si je dépublie l'article tout va mieux.
Pourtant en vidant complètement le chapô (chapô vide), le problème est toujours présent.
Ce n'est pas le fait de publier un article qui brise tout. PluXml récupère toujours son article de la même façon, quelque soit son contenu. Des mécanismes de sauvegarde remplacent les caractères ou les codes qui pourraient causer entrave et nous redonnent la version aseptisée. Parfois on a oublié quelques codes à attraper mais je ne commencerais pas là.
Les probabilités de causer un problème de mise en page se décuplent avec chaque ajout d'un plugin qui affecte le rendu html (ce qui veut dire tous les plugins). Ceux qui les installent deviennent responsables de leurs conséquences. Nous vivons dans un monde libre, tout le monde a le droit de passer sa vie les doigts croisés, moi je préfère les avoir pour travailler.
On ne parle pas d'installer tous les articles dans un environnement de test avant de les publier, on parle de laisser impeccable la façade publique et, quand on aperçoit un problème, on recule et on étudie ailleurs ce qui peut bien causer le problème. Parfois c'est rapide, parfois c'est long et pénible mais c'est certainement toujours éducatif, voire utile pour la postérité. Dans les cas extrèmes, on abandonne en se disant que c'est bien beau l'éducation mais qu'on ne passera pas un mois sur le cas. Quand on identifie le problème, on corrige la page de code ou autre. Si la cause est un caractère mal capté par un plugin ou le système core de PluXml, on avertit son auteur avec notre exemple bien compris et documenté, encore présent en environnement de test.
Pierre doit avoir raison, le problème doit vraiment venir de l'article. Si je dépublie l'article tout va mieux.
Pourtant en vidant complètement le chapô (chapô vide), le problème est toujours présent.
Personne ne sait l'origine, même pas moi. Enlever l'article est une étape diagnostique importante pour cerner la véritable cause. Dans bien des occasions, un contenu très spécifique et "rare" dévoile au grand jour une lacune logée ailleurs, le plugin d'édition, même le core de PluXml pourrait à la rigueur être pointé du doigt. On s'assure de faire un bon travail avant de déranger les pros, il faut battre le problème de tous les côtés pour aider les programmeurs qui se feront un plaisir de corriger leur bébé.
Un chapô vide, je vois ça comme une perte de temps puisqu'on exige d'en avoir un. Je préfère y mettre un bon vieux "ceci est un test" pour tenter de provoquer ce qui devrait être provoqué et voir si quelque chose d'autre se pointe à l'écran. Pas d'éditeur, pas d'accents, pas de guillements ou d'apostrophe, un texte brut qui ne pourrait être à blâmer. C'est pas drôle de jouer au Sherlock au lieu de faire sa journée de travail mais ça nous rendra plus rapide la prochaine fois qu'on verra un chichi sur cette grandiose page d'accueil.
Il faut jeter un coup d'oeil au corps de texte de l'article Apple, le chapo contient une fermeture de DIV à l'intérieur de la chaîne. La cause peut être un copier-coller qui en a pris un peu large ou un plugin d'édition qui s'invite dans la danse.
Chose certaine, ta retranscription de fonction fournie plus tôt se termine par deux fermetures de DIV et ta page en a trois.
Bon, j'ai avancé un petit peu.
En ajoutant une balise <div> tout au début du chapô de mon article, plus de problème.
Je n'ai pas trouvé de balise fermante dans l'article pourtant, ça doit donc être dans home.php que le soucis se situe, mais où ?
C'est bon, j'ai réussis à "corriger" le problème.
J'ai ajouté un <div> avant la fonction lastArtList, ici, et ça fonctionne (ligne 6 de la portion de code ci-dessous).
Seulement, je ne sais pas si c'est très propre ?
Aucune garantie à part la version initiale téléchargée, c'est la seule référence. Si celle-là n'est pas correcte, elle sera corrigée dans une prochaine version. Pour l'instant, rien ne bouge.
Réponses
Quand aux données, ce n'est pas seulement une question d'être confidentielles ou pas. Même des données non confidentielles, si c'est moi qui les ai créé, c'est à moi qu'elles appartiennent, pas à un autre hébergeur.
J'autoheberge ces données pour garder cette propriétés.
En plus, avec tout ce qui se passe actuellement, ça ne me donne sérieusement pas envie d'aller héberger mes données je ne sais où.
Au moins, mes 3To de DATA, je sais où elles se trouvent, elle sont chez moi. Il n'y en a pas un bout en europe je ne sais où, un bout aux USA, plus une copie faite par l'hébergeur au canada...
Enfin, voilà moin point de vue.
Pour moi, la conservation de ce qui m'appartient est primordial. Je suis seul à devir accéder à mes données. Je n'ai pas envie que Roger (nom fictif), administrateur système chez OVH puisse voir mes données.
j'arrive peut-être un peu après la bataille ... mais, pour différents tests, rien que ceci:
" Une version future aurait la correction mais c'est très facile de trouver les 2 endroits à l'intérieur du $format de 2 fonctions lastArtList qui se lisent " me coince, j'ai trouvé en fait 28 occurrences à ces références mais aucune qui ne soit véritablement 'exacte' ...
pourrais-tu soit mettre le thème à jour dans les ressources, soit nous donner, ici, le codage finalisé de la 'home', ce serait plus que bien
@+
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
Si tu installes le thème sur un site de nouvelles multi-canaux et que tu l'intègres avec ton contenu, il me fera plaisir de te pointer les deux endroits erronés qui devraient être très apparents visuellement.
Des douzaines d'autres adaptations manuelles sont nécessaires pour intégrer ce thème, il faut sérieusement installer un site pour s'en servir. Ce n'est pas un thème qu'on essaye pour quelques minutes avant de comprendre que notre contexte ne s'applique pas. Notre ami avait exactement la mission de créer un portail de nouvelles, il avait des défis à relever et récolte le fruit de son travail.
et pour une copie de la home.php, elle dépasse les 300 lignes...
@+
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
L'exercice n'est pas anodin, il faut installer un site sans plugin et passer des jours à préparer le thème pour ton contenu de toutes façons, cette anomalie est à peine visible mais je peux te la trouver en quelques minutes une fois en ligne.
Je suis passé d'environ 6000 pages vues par mois à plus de 15700 déjà pour ce mois-ci, alors que le nombre de visiteurs stagne...
Quand je regardes dans les visiteurs actuellement en ligne, je tombe sur des choses comme celles-ci :
J'utilise SimpleStat pour mes statistiques.
Il faut pas s'en faire pour le plafonnement des visiteurs uniques, il est encore tôt, ces clients satisfaits vont probablement passer le mot, cliquer sur les like de Facebook et autres pour mousser ta pub par le bouche-à-oreille numérique. C'es dommage que tu aies retiré les gros boutons de réseaux sociaux dans la sidebar, ils auraient peut-être fait leur bout de chemin aussi.
Pour le fichier manquant, il faut que tu fasses un favicon avec ton nom/logo/quelque-chose pour le placer à l'endroit mentionné.
Il ne s'agit pas d'un fichier manquant, mais de la page que visite en ce moment le visiteur dont j'ai masqué l'IP.
J'ai pas mal de visites sur des fichiers du thème au lieu des pages des articles en eux-même.
Pour les boutons des réseaux sociaux, je les ai retiré puisque je ne sais pas comment rattacher Vimeo, où je stocke mes vidéos au bouton YouTube.
D'autres exemples de visites curieuses :
Les plateformes professionnelles de gestion des pages vues font abstraction des fausses pages vues pour ne pas donner une image erronée de la popularité d'un site, les publicitaires ne sont pas dupes, on doit leur dire quelque chose qui se rapproche de la vérité, même si c'est parfois difficile de discerner les humains des robots. Les règles de confidentialités sont plus importantes que de monnayer les pubs, on ne peut tenir la trace exacte d'un visiteur à répétition. Les publicitaires acceptent cette réalité tant que le calcul est équitable et fait par une firme indépendante.
Les petits plugins te guident un peu pour diriger ton énergie aux endroits qui manquent de visibilité, ce n'est pas une science exacte.
Cependant, celle-ci m'étonne puisqu'en principe les robots sont dissociés des visiteurs humains par SimpleStat dans mes statistiques.
Mais les robots sont en principe dissociés, ça veut dire que certains passent quand même du coup.
J'ai publié un nouvel article il y a environ 45 minutes, et depuis la publication de cet article, j'ai un gros bug d'affichage sur ma page d'accueil : http://lolyangccool.ovh
A partir de la rubrique Critiques, présentations et tests.
Avant que je ne publie l'article sur Apple, tout allait bien.
J'ai pourtant pris soin de ne pas mettre de mise en forme dans le chapô.
Comment régler ce soucis très gênant ?
Merci.
Merci.
C'est un test qui se fait en quelques minutes, évitant de garder son site dévisagé pendant des heures en attendant que quelqu'un trouve un problème causé par un code que tu as mis au travers du texte, si c'est le cas bien sûr.
Il faudra ensuite essayer en elevant l'article, en le mettant dans une autre catégorie. C'est du quotidien de webmestre qu'on fait en quelques minutes quand un article casse tout.
C'est pratique pour moi d'avoir l'erreur en ligne mais c'est pas très marketing ni professionnel de laisser ça en production. Un environnement de développement serait peut-être une bonne idée pour parfaire la formation du webmestre sur les anicroches possibles causés par excès de plugin. Un setup classique est d'avoir un site de type "carré de sable" où on casse tout allègrement, un environnement de préproduction pour tester des machins comme aujourd'hui, et la version publique qui fonctionne comme un charme.
C'est bien malheureux si je dois publier mes articles d'abord sur un site de tests avant de les mettre en ligne.
Je ne pensais pas que la publication d'un nouvel article pourrait tout casser...
@zakar! : J'essaye ça, merci.
Pourtant en vidant complètement le chapô (chapô vide), le problème est toujours présent.
Les probabilités de causer un problème de mise en page se décuplent avec chaque ajout d'un plugin qui affecte le rendu html (ce qui veut dire tous les plugins). Ceux qui les installent deviennent responsables de leurs conséquences. Nous vivons dans un monde libre, tout le monde a le droit de passer sa vie les doigts croisés, moi je préfère les avoir pour travailler.
On ne parle pas d'installer tous les articles dans un environnement de test avant de les publier, on parle de laisser impeccable la façade publique et, quand on aperçoit un problème, on recule et on étudie ailleurs ce qui peut bien causer le problème. Parfois c'est rapide, parfois c'est long et pénible mais c'est certainement toujours éducatif, voire utile pour la postérité. Dans les cas extrèmes, on abandonne en se disant que c'est bien beau l'éducation mais qu'on ne passera pas un mois sur le cas. Quand on identifie le problème, on corrige la page de code ou autre. Si la cause est un caractère mal capté par un plugin ou le système core de PluXml, on avertit son auteur avec notre exemple bien compris et documenté, encore présent en environnement de test.
Personne ne sait l'origine, même pas moi. Enlever l'article est une étape diagnostique importante pour cerner la véritable cause. Dans bien des occasions, un contenu très spécifique et "rare" dévoile au grand jour une lacune logée ailleurs, le plugin d'édition, même le core de PluXml pourrait à la rigueur être pointé du doigt. On s'assure de faire un bon travail avant de déranger les pros, il faut battre le problème de tous les côtés pour aider les programmeurs qui se feront un plaisir de corriger leur bébé.
Un chapô vide, je vois ça comme une perte de temps puisqu'on exige d'en avoir un. Je préfère y mettre un bon vieux "ceci est un test" pour tenter de provoquer ce qui devrait être provoqué et voir si quelque chose d'autre se pointe à l'écran. Pas d'éditeur, pas d'accents, pas de guillements ou d'apostrophe, un texte brut qui ne pourrait être à blâmer. C'est pas drôle de jouer au Sherlock au lieu de faire sa journée de travail mais ça nous rendra plus rapide la prochaine fois qu'on verra un chichi sur cette grandiose page d'accueil.
Chose certaine, ta retranscription de fonction fournie plus tôt se termine par deux fermetures de DIV et ta page en a trois.
Edit : J'ai vérifié dans mon article, je n'ai pas vu de balise <div>.
En ajoutant une balise <div> tout au début du chapô de mon article, plus de problème.
Je n'ai pas trouvé de balise fermante dans l'article pourtant, ça doit donc être dans home.php que le soucis se situe, mais où ?
J'ai ajouté un <div> avant la fonction lastArtList, ici, et ça fonctionne (ligne 6 de la portion de code ci-dessous).
Seulement, je ne sais pas si c'est très propre ?
Pouvez-vous me dire si je peux laisser comme ça (si c'est propre) ?