Bien, j’ai installé le composant de Lilly et après avoir dû changer ce paramètre, cela a bien fonctionné !
Je suis ravi que cela ait fonctionné comme solution pour vous. Cependant, ce ne sont pas des composants de ma part - c’est le beau travail de @Don
![]()
Bonjour,
La taille de la police peut-elle être ajustée sur l’écran d’affichage ? Si le message est long, tout ne s’affiche pas sur un appareil mobile.
Merci
ne pouvons-nous pas rediriger les utilisateurs vers l’URL du sujet d’origine, après la connexion/l’enregistrement ?
Excellent composant
et un très bon début.
Une certaine granularité serait utile, dans la lignée d’options telles que
- Autoriser la lecture complète du premier article, puis *
- Autoriser la lecture des X premiers articles, puis *
- Autoriser la lecture d’un nombre X de lignes de contenu, puis *
*afficher le message restreint
Peut-être quelques options pour contrôler la taille et même le style de base de la restriction, comme la hauteur, voire la largeur.
Je suis intéressé par les mêmes fonctionnalités ! Je suis actuellement en train de configurer un cours sur mon instance WP qui offre du contenu verrouillé pour les utilisateurs payants via le plugin Wishlist member.
Idéalement, j’aimerais utiliser une sorte de shortcode [gated group=premium] pour envelopper le contenu afin de le restreindre uniquement aux membres de groupes spécifiques.
Excellente idée, désactiver les scripts dans le navigateur le casse complètement cependant.
Malheureusement, c’est le mieux que l’on puisse faire avec un composant front-end comme celui-ci (je pense).
Tout ce qui est plus robuste nécessitera un plugin officiel.
Cela semble être un plugin très puissant pour ceux qui dépendent de tout type d’abonnement ou de paiement. Pour l’instant, les catégories sont soit complètement visibles, soit complètement invisibles sur la base d’un groupe, mais ce serait certainement bien d’avoir quelque chose entre les deux pour donner ce sentiment de « FOMO » (peur de manquer quelque chose) et encourager l’abonnement.
Je recommanderais vivement de transformer cela en une demande de fonctionnalité.
Salut : ça fonctionne très bien. Je me demande si quelqu’un a mis une image derrière ? Pour que cela corresponde un peu plus à la marque ? Bronwyn
En lisant ci-dessus, « désactiver les scripts dans le navigateur le casse cependant » - je suppose que cela signifie que quelqu’un obtient un accès gratuit à ce point ? Pourriez-vous me le faire savoir car ce serait un problème.
Avez-vous essayé d’ajouter quelque chose via CSS ?
Je ne suis pas sûr de ce que vous entendez par accès gratuit, mais cela signifie qu’ils peuvent voir le contenu de la page. À vos risques et périls si c’est un problème ou non. Personnellement, nous utilisons cela dans nos catégories d’annonces pour exiger une connexion, en partie pour pouvoir démontrer que les clients ont consulté les sujets d’actualité (à des fins de responsabilité).
Si vous désactivez javascript dans votre navigateur, vous pouvez voir le contenu d’un sujet.
Je suppose alors que les scrapers LLM-IA peuvent faire de même et accéder au contenu que l’administrateur/propriétaire d’un site pourrait ne pas souhaiter.
Y a-t-il un moyen d’empêcher les robots d’entrer avec javascript désactivé et d’aspirer le contenu d’un site Discourse pendant que les vrais utilisateurs subissent cet inconvénient ?
Si ma mémoire est bonne, les robots vérifiés comme Google reçoivent les pages sans javascript à partir des vues de page et d’Adsense (comptage de pages dans un monde de défilement infini)
Peut-être que la façon de gérer cela est via CF à la place ?
J’utilise cette solution depuis un moment et elle est excellente. Je me demande simplement si elle utilise la propriété isAccessibleForFree mentionnée sur Subscription and Paywalled Content Markup | Google Search Central | Documentation | Google for Developers. Ou bien permet-elle aux moteurs de recherche d’accéder au contenu d’une autre manière ?
Je ne sais pas si c’est seulement chez moi, mais sur le bureau, la photo de profil reste, eh bien, sans photo de profil, vide, alors que la photo réelle se trouve juste en dessous, créant ainsi l’impression d’un bug.
topic-avatar,
.topic-post.sticky-avatar>article>row>topic-avatar {
position: relative !important;
top: auto !important;
}
}
.post-stream {
max-height: 150vh;
overflow: hidden;
Lorsque le top cédait la place au sticky pour une raison quelconque, l’avatar se retrouvait au mauvais endroit. C’est une solution de contournement, et j’espère que le mainteneur original vérifiera s’il s’agit d’un problème spécifique ou d’un bug visuel général.
Merci pour ce signalement ! Je viens de fusionner une mise à jour qui modernise le modèle du composant et inclut une correction pour la position de l’avatar :
Une autre question : je jurais que ce composant masquait le contenu HTML lorsque JavaScript était désactivé. Était-ce la norme ou cela venait-il spécifiquement de mon navigateur ?
Au passage, merci pour la correction ![]()
