Comme suggéré, j’essaie de garder mon/mes ancien(s) forum(s) « en place » tout en utilisant discourse sur le même domaine. J’ai réussi à faire fonctionner nginx pour le proxy et à contourner tout conflit avec les URL de discourse, donc tout fonctionne parfaitement lors du chargement initial de la page (et pour le référencement).\n\nMon problème concerne les liens vers ces anciennes URL au sein de discourse. Le routage de l’application discourse intercepte ces URL comme des liens internes et provoque donc un 404. J’ai essayé de nombreuses façons de contourner ce problème avec les outils à ma disposition, mais rien ne fonctionne avec les URL ou le même domaine. (Je ne veux pas non plus mettre discourse dans un sous-dossier).\n\nSi seulement je pouvais ajouter au tableau SERVER_SIDE_ONLY pour imiter ce que je fais dans nginx, cela devrait fonctionner. Quelqu’un a-t-il des suggestions sur la façon de faire cela, ou autre chose ?
Ce n’est pas du tout ce que ce sujet recommandait. Vous devriez démarrer votre nouveau forum sur un nouveau sous-domaine et laisser l’ancien derrière vous.
Je pense que c’est exact. Si vous voulez vraiment que l’ancien forum et le nouveau soient sur le même domaine (ce qui, encore une fois, semble être une idée horrible pour les problèmes que vous avez déjà décrits), vous pourriez éventuellement avoir un autre domaine qui est un CNAME pour l’ancien et faire en sorte que Discourse y renvoie, il penserait alors que c’est un serveur différent et n’essaierait pas de gérer ces liens lui-même et lorsque nginx recevrait le lien, il servirait simplement les données de l’autre domaine ou redirigerait le navigateur vers le bon.
J’ai envisagé de mettre les anciennes choses sur un sous-domaine archive (risquant d’impacter le SEO), mais même dans ce cas, je ne pense pas qu’il y ait un moyen pour Discourse de modifier le lien fourni par un utilisateur, autre que de créer un permalien pour chaque page possible. Je suppose que l’utilisation du sous-domaine archive finirait par s’imposer, car les gens en auront connaissance et copieront/colleront depuis la barre d’adresse du navigateur.
Si vous aviez simplement fait une importation, il y aurait des permaliens pour tout cela, mais ce n’est pas très utile. Et le genre de chose qu’une personne qui gagne une part considérable de sa vie à faire des importations pourrait penser.
La chose la plus simple serait de déplacer le nouveau forum vers une nouvelle URL (en espérant que vous n’ayez pas trop endommagé le référencement), ou de déplacer l’ancien forum vers une autre (et perdre le référencement pour les anciens contenus, bien qu’il soit possible de faire une normalisation de permalien ou de la magie NGINX pour faire des redirections). Le nouveau site est-il en place depuis longtemps ?
Vous pourriez peut-être créer une normalisation de permalien. . . non. Je pense que les normalisations de permaliens ne fonctionnent que pour les permaliens et qu’ils ne peuvent pas être externes. Il serait possible d’avoir un composant de thème qui trouve les URL correspondantes et les réécrit avec le nom d’hôte fictif/cname, mais je ne suis pas sûr de ce qui arrive au message cuit (est-ce l’URL complète avec le nom d’hôte, ou le processus de cuisson supprime-t-il le nom d’hôte ?).
Si l’URL complète est dans le message cuit, alors vous pourriez faire quelque chose comme ce que je fais dans GitHub - literatecomputing/runners-onebox-theme: Custom oneboxes for Garmin and Strava.
! Je peux gérer cela sur la page 404 via un script dans le HTML du thème…
J’ai fait en sorte que la page 404 recharge la fenêtre du navigateur vers l’URL « manquante », ce qui atteindra le serveur. Ça marche ! Le seul inconvénient que je vois est que la redirection est perceptible et que vous quittez l’application pour tout vrai 404 (en perdant la barre latérale/l’en-tête).
<script type="text/discourse-plugin" version="0.8">
api.onPageChange((url, title) => {
const router = api.container.lookup('service:router');
var is404 = document.getElementsByClassName("page-not-found");
if (is404.length) {
const params = new URLSearchParams(router.currentRoute.queryParams).toString();
let q = "";
if (params){ q = "?"+params; }
window.location.replace(window.location.origin + url + q);
}
});
</script>
Je pense que vous devriez pouvoir les attraper côté client comme je l’ai suggéré auparavant. Les liens vers l’ancien site dans le HTML incluent-ils le nom d’hôte ?
Oui, l’URL complète est là. Je vais regarder comment créer un composant de thème, merci !
Composant de thème créé ! Il recherche tous les href vers le hostname avec un chemin qui correspond à vos expressions régulières fournies, puis ajoute un événement click pour définir window.location afin de contourner le routage interne.
Je suis curieux, si (inline) oneboxing fonctionne dans ce scénario.
Les URL du même domaine sont bien intégrées et présentent toujours le même problème qu’un lien simple. Mon composant de thème s’appliquera à tous les liens <a> href dans le message, donc il fonctionne également pour les liens intégrés.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.