Afficher un Live Twitch sur WordPress

 

Pour résumer : ne touchez pas aux extensions WordPress qui proposent d’afficher un live Twitch. En tout cas à ce jour (fin août 2018), aucun n’est fiable : nombreux sont ceux qui ne fonctionnent tout simplement pas, et le seul qui fonctionne occasionne une surcharge du serveur en faisant des appels continus auprès de l’API twitch pour connaître l’état des streams.

Reste donc la solution maison !

L’intégration à WP passe par du html et du javascript. Si vous voulez intégrer le stream à une barre de widget, vous aurez besoin d’un widget de html basique. Sinon ça peut-être imaginé sur un article ou une page.

Ensuite, le code à intégrer.

Pour quelque chose de très basique qui se contente d’afficher le stream quelque soit son état (connecté ou non), on peut se contenter de ça :

<div id="twitch-embed"></div>
<script src="https://embed.twitch.tv/embed/v1.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js" </script> <script> new Twitch.Embed("twitch-embed", { width: 250, height: 140, channel: "nofrag_official", layout: "video" }); </script>

Avec ça, vous affichez le stream de Nofrag, sans la zone de chat, dans une zone de 250 par 140. Ça conviendra parfaitement si vous n’avez aucun soucis avec le fait d’afficher le stream même s’il est déconnecté.

Chez Nofrag on a voulu aller un peu plus loin en affichant autre chose que le stream lorsqu’il n’est pas connecté.

Pour cela vous avez besoin d’un jeton d’accès à l’API twitch, que vous pourrez créer à partir de https://dev.twitch.tv/ puis en créant une « App ». Vous aurez alors un identifiant client, qui servira par la suite.
Le code à insérer :

<script src="https://embed.twitch.tv/embed/v1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.0/jquery.min.js"></script>
<div id="twitch-embed"></div>
<script>
$.getJSON('https://api.twitch.tv/kraken/streams/nofrag_official?client_id=<IDENTIFIANT_CLIENT>', function(channel) {
if (channel["stream"] == null) {
/* le channel est déconnecté, je définis ce que je vais
 afficher dans le div "twitch-embed". Ici, on appelle
 une iframe avec un petit widget qui indique l'état du stream Nofrag,
 mais on pourrait afficher une image, tout simplement.*/
$('#twitch-embed').html('<iframe src="https://svinkle.github.io/twitch-tv-widget/?username=nofrag_official" width="100%" height="64" frameborder="0" allowtransparency="true"> </iframe>');
} else {
// le channel est connecté, j'affiche le stream de Nofrag
new Twitch.Embed("twitch-embed", {
width: 250,
height: 140,
channel: "nofrag_official",
layout: "video"
});
}
});
</script>

Cette solution permet de ne pas faire reposer l’appel à Twitch sur le serveur mais sur le navigateur de l’utilisateur. On pourrait aller plus loin en interrogeant régulièrement l’API twitch par javascript sans avoir à rafraîchir la page, mais en ce qui nous concerne, nous n’en avons pas ressenti le besoin.

Point Dev – Comment configurer le cache sur WordPress ?

Dans ce Point Dev, voyons comment configurer correctement le cache sur WordPress.

Pourquoi un cache ? Décharger le serveur web et la base de données (et donc payer moins cher Amazon), éviter que le nombre de visiteurs ait un impact sur les performances du site. Tout cela n’a de réel intérêt qu’à partir du moment où le site a un nombre important de visites quotidiennes.

Alors c’est parti. On installe WP Super cache, activation, et rendez-vous dans réglages / WP Super Cache.

Dans Avancé, voici nos réglages :

  • Mise en cache : coché
  • Cache Delivery Method : simple
  • Dans divers sont cochés :
    • Ne pas mettre en cache les pages pour les utilisateurs connus
    • Don’t cache with GET parameters
    • Compresse les pages afin qu’elles soient servies plus rapidement aux utilisateurs
    • Reconstruction du cache
  • Dans avancé sont cochés :
    • Mobile device support
    • Clear all cache files when a post or page is published or updated.
    • Rafraîchir uniquement la page courante lorsqu’un commentaire est effectué.
  • Dans cache location : saisir le répertoire sur le serveur où le cache sera stocké. Attention à ne pas oublier le / de début.
  • Dans cache Location :
    • Cache timeout est fixé à 600s. Cela signifie qu’un visiteur non connecté verra une page ayant un âge de maximum 15 minutes.
    • Scheduler : on l’a fixé également à 600s.

En ce qui concerne les autres onglets, on n’a rien activé. Attention au  choix  d’activer le préchargement (dans l’onglet du même nom) qui est potentiellement très gourmand en CPU.

Avec ces réglages, vous bénéficierez d’un premier niveau de cache permettant de limiter les impacts en performance ou financiers d’un nombre de visites important.

 

La genèse de Nofrag V2 – Présentation de l’Architecture Applicative

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Dans l’article précédent, nous avons vu l’architecture technique sur le cloud Amazon. Maintenant, intéressons-nous à l’architecture applicative.

Continuer la lecture de « La genèse de Nofrag V2 – Présentation de l’Architecture Applicative »

Point Dev – Comment unifier WordPress et PhpBB ?

Elle est bien moche mon image, hein ?

Dans ce premier Point Dev nous allons voir comment permettre à un forum PhpBB de se connecter à WordPress. Ces deux produits ne sont absolument pas prévus pour communiquer ensemble à l’origine.

Pour cela, on utilise l’extension WordPress BridgeDD, qui est la seule à proposer ce service. Les autres extensions existantes généralement la l’unification des utilisateurs, mais pas la création d’un topic depuis WordPress ni l’affichage de commentaires issus du topic du forum (fonctionnalité appelée Cross-Posting).

Continuer la lecture de « Point Dev – Comment unifier WordPress et PhpBB ? »

La genèse de Nofrag V2 – Introduction et Architecture Technique

Il y a quelques semaines, DrLoser  m’a suggéré de rédiger un papier sur le développement de la V2 de Nofrag, qui s’est étalé de début septembre 2017 avec un gros chantier sur le forum, suivi par le nouveau site de news, jusqu’à l’ouverture des nouveaux blogs courant janvier 2018.

L’idée est de rédiger une série d’articles présentant l’architecture technique et applicative, ainsi que des tutoriaux détaillant chaque composant.

A la fin de cette série d’articles, vous aurez à votre disposition un socle logiciel permettant de faire de la publication d’articles sur un site de news, l’hébergement d’un forum, de blogs pour les besoins d’une communauté.

On va commencer par une description de l’infrastructure, résumée par ce schéma.

Nous avons créé une machine virtuelle fonctionnant sur Ubuntu et dont l’image est positionnée dans une AMI. Cette AMI est un cliché de la machine à un instant T, qui a besoin d’être associée à une instance EC2 pour prendre vie. L’EC2, c’est le terme choisi par Amazon pour parler d’une machine virtuelle. La configuration de l’EC2 est de type t2.medium : 2CPU et 4Go de RAM. Cette EC2 est positionnée dans une Auto Scaling Group, qui est un composant permettant de paramétrer le nombre d’instance EC2 simultanées et du même coup protège notre infrastructure des plantages : si une EC2 plante, l’Auto Scaling Group se charge de redémarrer une instance avec son contenu d’origine dans l’AMI et une configuration lui permettant de récupérer le contenu qui a évolué depuis la création de l’AMI.

Car oui, si nous nous arrêtions là, à chaque redémarrage d’une instance, tout le contenu de la machine qui aura évolué entre temps est perdu. Il est donc nécessaire de gérer le stockage du contenu qui évolue et qu’on doit conserver.

Ainsi, pour le contenu des différents sites (Nofrag, Forums, Wiki, Blogs) , nous utilisons le produit S3 de Amazon, qui permet le stockage de données sur le cloud. Nous synchronisons régulièrement le contenu des sites sur S3, et lors d’un redémarrage de l’EC2, ce contenu est redescendu sur l’instance afin d’avoir les fichiers les plus récents.

L’adresse IP de nofrag.com est affiliée à l’Auto Scaling Group pour avoir accès en permanence à l’instance EC2 en cours depuis l’IP associée au nom de domaine.

Concernant la base de données, RDS (managée sous AWS), et sous MariaDB, elle n’est pas hébergée sur l’EC2 mais sur une machine dédiée, elle n’est pas dans l’Auto Scaling Group car elle se gère toute seule, notamment en terme de maintenance. Ce choix s’est fait pour des raisons de performances et de sécurité. Il s’agit d’une  t2.small : 1CPU et 2Go de RAM. De par l’utilisation de plusieurs caches, son taux d’utilisation est relativement faible.

Tout ce petit monde est défini dans une Availability Zone, qui permet de choisir le datacenter sur lequel sera stocké nos composants. On trouve également la notion de region, qui est la zone géographique où l’on héberge nos composants. Ces deux parties ne sont pas neutres car elles ont de l’influence sur la manière dont sont traitées les données légalement, et sur le montant de la facture. En effet, il est important de définir des zones et datacenters communs.

Rassurez-vous, nos données sont en Europe.

Bilan

Me concernant, j’ai trouvé hyper enrichissant l’utilisation du cloud Amazon, d’un point de vue personnel mais aussi professionnel. C’est très performant, quoique pas toujours clair.

Nous n’utilisons qu’une infime partie des fonctionnalités proposées, comme vous pouvez le voir dans cette petite liste. Si un jour on veut se lancer dans les learning machine, on a ce qu’il faut !

Voilà pour l’infrastructure technique, prochain article sur l’architecture applicative.