Aller au contenu

[TUTO] Installer WordPress sans les paquets SYNOLOGY


DaffY

Messages recommandés

Bonjour,

Merci @D34 Angel pour les compliments, ça fait toujours plaisirs de voir que le tuto aide à la mise en œuvre attendue.

Voici mes réponses :

 

il y a une heure, D34 Angel a dit :

Est-ce normal que certaines commandes ne renvoient pas de réponse ?
Si oui, peut-être serait-il pertinent de le préciser dans le tuto car quand on est novice, on a tendance à se demander si on a bien fait ce qu'il fallait.

Selon les outils interpréteur de commandes que l'on utilise on obtient parfois un retour (parfois verbeux d'autres fois moins loquace) attestant de la bonne exécution.
Le retour au prompt (sortie de l'exécution de la commande) atteste de la fin de l'exécution de la commande.
Exemple : on demande la lecture du répertoire courant : ls, cela affiche les lignes des fichiers/dossiers présents et on récupère le curseur pour saisir une nouvelle commande.

il y a une heure, D34 Angel a dit :

Quel est l'intérêt de ce Super_Utilisateur ?   En quoi se différencie-t-il du User_Admin ?
Perso, je ne l'ai pas créé. D'une part, parce qu'il était noté [optionnel +] et, d'autre part (et surtout), parce que je n'ai pas compris le   @'192.168.1.%' 
A quoi correspond cette adresse ? Puis-je avoir quelques précisions ?

Par défaut la base de données dispose de sa propre administration d'utilisateurs, distincte de celle du NAS. Ainsi l'admin du NAS n'est pas l'admin de la base (même si...). root est l'admin des bases de données, 'toto' peut être l'admin de la base de données utilisée pour wordpress et tout ce petit monde vit de manière indépendante de l'admin du NAS.

L'exécution par défaut des droits de ces utilisateurs est situé SUR la machine hébergeant (host) donc localhost. Si on veut pouvoir accéder à la base de donnée depuis un autre 'lieu' au sens réseau, dans ce cas on précise l'origine IP de cet appel. % signifiant de "n'importe où", on peut limiter à son réseau local en insérant une bonne partie du masque et ainsi permettre à une machine du réseau local d'accéder via un requeteur SQL à la base.
Ainsi @'192.168.1.%' s'ajoute dans la définition d'un utilisateur pour une base de données, précisant que cet utilisateur pourra accéder à la base depuis une machine dont l'ip peut être 192.168.1.25 ou 192.168.1.150...

Pertinent si besoin, par exemple, d'intervenir via un requeteur SQL sur la base de donnée située sur le NAS, depuis un PC/mac du réseau local.

il y a une heure, D34 Angel a dit :

Donc question : Peut-on sans problème changer la version de PHP dans Web Station .... une fois tout installé ? (je présume que oui mais j'aimerais qu'on me le confirme).

L'installation manuelle s'appuie sur des paquets livrés par Synology  tels que WebStation et/ou PHP. La brique logiciel PHP est requise pour un CMS comme WordPress. L'idéal étant de toujours avoir la dernière version, parfois on peut passer outre la mise à disposition faite par Synology... Mais ces briques logicielles étant à un bas niveau il faut être sur que les configurations techniques soient parfaitement réalisées.

Lorsqu'une version de PHP est installée par les paquets Synology, des scripts sont exécutés pour signer correctement la configuration. (relation avec l'outil pour l'envoi de mail par exemple). Parfois il arrive que cela ne suive pas totalement... Ce fut le cas our une version de WebStation qui n'était pas en phase avec le dernier paquet de PHP... Aujourd'hui (10/12/2020) ce n'est pas le cas, Webstation est cohérent avec la version PHP 7.4 (pour information, la version PHP8 seule- hors paquet Synology -vient de sortir).

Enfin, on peut avoir différentes versions de PHP installées OU différentes optimisations selon ses souhaits et les serveurs vituels installés. D'où la possibilité d'avoir des profils PHP en conséquence (1 par défaut ou plusieurs à choisir par serveur virtuel créé)

Oui on peut changer de version par une nouvelle, en s'assurant que cette nouvelle version n'amène pas de régression.

il y a une heure, D34 Angel a dit :

Comment s'utilisent ces commandes : MORE ou CAT ?
Je devine à quoi sert MORE mais ... à quoi sert CAT ?

Pour résumer : les deux commandes affichent le contenu d'un fichier sur l'écran. More permet en sus d'avoir une pause automatique en fin d'écran, barre d'espace pour afficher la suite etc...

en espérant avoir apporter les réponses aux questions posées.

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, DaffY a dit :

en espérant avoir apporter les réponses aux questions posées.

Oui, DaffY, merci pour ces réponses ... j'ai à peu près tout capté.

Juste une précision supplémentaire :

il y a une heure, DaffY a dit :

L'exécution par défaut des droits de ces utilisateurs est situé SUR la machine hébergeant (host) donc localhost. Si on veut pouvoir accéder à la base de donnée depuis un autre 'lieu' au sens réseau, dans ce cas on précise l'origine IP de cet appel. % signifiant de "n'importe où", on peut limiter à son réseau local en insérant une bonne partie du masque et ainsi permettre à une machine du réseau local d'accéder via un requeteur SQL à la base.
Ainsi @'192.168.1.%' s'ajoute dans la définition d'un utilisateur pour une base de données, précisant que cet utilisateur pourra accéder à la base depuis une machine dont l'ip peut être 192.168.1.25 ou 192.168.1.150...

L'explication est claire et j'ai bien compris le caractère générique "%".
C'est le "1" que je ne comprends pas ( dans @'192.168.1.%'  )

Ce "1" correspond-il à la plage d'adresse définie dans le DHCP ?
Chez moi (dans le DHCP de la box), les adresses utilisables pour mon LAN sont 192.168.0.x   
(Euh ... je ne peux pas vérifier car depuis hier -ou avant-hier- il y a un pb de certificat pour accéder à mafreebox.freebox.fr donc, du coup, je m'abstiens d'aller vérifier).

Lien vers le commentaire
Partager sur d’autres sites

salut la compagnie,

 

je reste queque peu dubitatif sur l'installation de worpress sur synology.

Je l'ai déjà fait plusieurs fois dans le passé sans difficulté notable, mais je vois que c'est de plus en plus relou. Pour le coup, même en suivant pas à pas votre super tuto, je me tape une erreur critique dès que je valide les id de bases de données dans le formulaire wordpress.

pas encore réussi à trouver d'où ça vient, mais c'est relou de ce taper juste cette erreur :

 

  • Il y a eu une erreur critique sur ce site.

Qq'un aurait une idée ?

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Pour éviter la démarche technique présentée ici, il est possible d’utiliser les paquets et profiter des automatismes associés.

Sinon, il s’agit vraisemblablement d’un oubli de parametrage du genre
- Pas de base crée
- Pas de user crée
- Pas de droits sur la base donnée
- Pas le bon chemin spécifié dans les paramètres php
- Pas le bon port spécial iris d’à s les paramètres php
- Erreur de saisie...

Bonne investigation ou changement de braquet

Lien vers le commentaire
Partager sur d’autres sites

Il y a 4 heures, DaffY a dit :

Bonjour,

Pour éviter la démarche technique présentée ici, il est possible d’utiliser les paquets et profiter des automatismes associés.

Sinon, il s’agit vraisemblablement d’un oubli de parametrage du genre
- Pas de base crée
- Pas de user crée
- Pas de droits sur la base donnée
- Pas le bon chemin spécifié dans les paramètres php
- Pas le bon port spécial iris d’à s les paramètres php
- Erreur de saisie...

Bonne investigation ou changement de braquet

Pour le coup, j'avoue avoir tenté l'installation par paquet à la base, en mode fainéant 😄. Mais suite à une une erreur wp-json dès que je voulais enregistrer un article ou page (en l'absence de résolution malgré plusieurs test), j'ai supprimé le paquet, l'apache qui s'installé avec ainsi que mariadb en prenant soins de vérifier qu'il n'y avait plus de base. le problème de wp-json semblait venir que l'url du site était basé sur l'ip et que je ne pouvait changé la valeur manuellement. Pour ça que je me suis dis qu'en partant des sources, ça serait peut être plus propre, notamment sur la gestion des virtualhost que le paquet n'a pas l'air d'aimer non plus.

donc à priori, je suis reparti au propre, lorsque j'ai réinstaller mariadb et que j'ai lancé l'install en partant des sources original de wordpress.

Côté paramétrage, j'ai déjà revérifier plusieurs fois ces paramètres. j'ai créé plusieurs bases avec différents utilisateurs en suivant différentes méthodes, et ça coince toujours. Je me demandais s'il n'avait pas un soucis d'authentifications à la base depuis le service web, puisque depuis heidisql depuis mon poste (pour peu que je pense à indiquer le 3307 ^^).

Je me demande si je n'ai pas un soucis avec un service/package que j'ai pu installer dans le passé, mais en l'absence de logs...

Lien vers le commentaire
Partager sur d’autres sites

il y a 42 minutes, effaness a dit :

Pour le coup, j'avoue avoir tenté l'installation par paquet à la base, en mode fainéant 😄. Mais suite à une une erreur wp-json dès que je voulais enregistrer un article ou page (en l'absence de résolution malgré plusieurs test), j'ai supprimé le paquet, l'apache qui s'installé avec ainsi que mariadb en prenant soins de vérifier qu'il n'y avait plus de base. le problème de wp-json semblait venir que l'url du site était basé sur l'ip et que je ne pouvait changé la valeur manuellement. Pour ça que je me suis dis qu'en partant des sources, ça serait peut être plus propre, notamment sur la gestion des virtualhost que le paquet n'a pas l'air d'aimer non plus.

donc à priori, je suis reparti au propre, lorsque j'ai réinstaller mariadb et que j'ai lancé l'install en partant des sources original de wordpress.

Côté paramétrage, j'ai déjà revérifier plusieurs fois ces paramètres. j'ai créé plusieurs bases avec différents utilisateurs en suivant différentes méthodes, et ça coince toujours. Je me demandais s'il n'avait pas un soucis d'authentifications à la base depuis le service web, puisque depuis heidisql depuis mon poste (pour peu que je pense à indiquer le 3307 ^^).

Je me demande si je n'ai pas un soucis avec un service/package que j'ai pu installer dans le passé, mais en l'absence de logs...

bon  ben pour le coup, ça semble s'être débloqué après avoir désactivé les extensions PHP puis les avoir réactivé....

me laisse perplexe, mais ça tourne, donc je ne vous embêtes plus 😄 Merci pour la réponse rapide en tout cas @DaffY

Lien vers le commentaire
Partager sur d’autres sites

Super merci @DaffY

effectivement avec more au lieu de tail j'ai pu trouver mon bonheur

more /etc/nginx/app.d/server.webstation-vhost.conf

Il y a 3 heures, DaffY a dit :

Bonjour,

Un tail affiche les dernières lignes un more la totalité du fichier de configuration.
Ce qui devrait permettre de voir alors le service hébergé par webstation en référence au nom de domaine choisi.

Bonnes fêtes à toi et tes proches et à la communauté n'oubliez pas :

image.png.1702c4ebafc26756d0139c73187887e4.png

 

Modifié par Novioritum
Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

Question multisite, Synology, Nginx

Merci DaffY, ceci permet vraiment d'être à jour sur un Synology et les explications sont claires et m'ont permis de mettre en ligne mon premier site WordPress.  Bravo et MERCI !!!

Comme j'ai fait l'acquisition d'un premier nom de domaine, j'aimerais maintenant utiliser la fonction Multisite de WordPress pour créer des sous-sujets indépendants. Exemple

--> MonSite.com (le domaine que j'ai acheté)

--> MonSite.com/Sous-sujet1 (traité comme un 2e site Web, mais administré dans la même interface WP)

Il existe plusieurs informations sur le Web par rapport au multisite de WordPress, mais l'information devient pauvre ou non-fonctionnel lorsqu'on ajoute les mots clés "Synology" et "Nginx".

J'ai ainsi suivi les étapes normales, mais aux "réglages/Création du réseau" de WP, je ne sais pas quoi faire à l'étape "2. Il semble que votre réseau fonctionne avec un serveur web Nginx."  Est-ce possible d'avoir les étapes de configuration propre à l'installation ci-dessus svp?

Merci encore et bonne année 2021 à tous !!!

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

Bonjour, je m'appelle Dominique, je suis nouveau sur ce forum et je viens de trouver votre explication très détaillée pour l'installation manuelle de wordpress avec vhost. Simplement, je n'ai pas activé https car je ne comprends pas encore bien les certificats.

Ma configuration :

un NAS DS 212+ avec DSM 6.2.3-25426 Update 3

Paquet Webserveur installé et à jour
serveur Nginx
MariaDB 10 avec port 3307 et /run/mysqld/mysqld10.sock (mot de passe root ok)
une base de donnée créée avec utilisateur (et mot de passe) et ALL PRIVILEGES su la base

Installation du dernier wordpress (version 5.6) sans probème.

Avec PHP 2.2, tout fonctionne bien et je peux accéder à la page admin via wp-login.php
mais avec PHP 2.4 et aussi PHP2.3, j'ai une erreur d'accès 503 : une erreur s'est produite lors du traitement de cette demande.

J'ai bien coché Activer le cache PHP

Il y bien http:http comme propriétaire:groupe en récursif depuis /web.

D'où cela peut-il venir ? (j'ai même désactivé mon thème et pris celui de base de wordpress : rien n'a changé)

(Avec l'installation du paquet wordpress, tout fonctionne)

Ca fait plusieurs jours que je cherche mais je ne sais pas comment vérifier les erreurs PHP ou Nginx : où se trouvent les fichiers logs ?

Quand j'active le DEBUG dans le fichier wp_config.php, aucun fichier log ne s'écrit dans wp-content.

Ce serait chouette si vous pouviez m'aider d'une façon ou d'une autre.

Bien cordialement

Dominique

bien sûr, concernant PHP, il s'agit des versions PHP 7.2 (qui fonctionne) et PHP 7.3 et PHP 7.4 qui provoquent l'erreur au login.

Je viens aussi de me rendre compte qu'il y a erreur si on veut accéder à une sous-page d'une page du menu principal

D

Lien vers le commentaire
Partager sur d’autres sites

Bonjour @doprev

je pencherai pour un oubli ou mauvais paramètrage du fichier permettant de gérer correctement les redirection et les permaliens.

Section 4 - Adaptation spécifique pour WorpRess et serveur NGINX

Quant au certificat SSL même si en effet on peut imaginer qu'il ne soit pas obligatoire... Les différents navigateurs l'exigent. donc pour éviter un mauvais référencement ou une alerte du type "attention ce site n'est pas sécurisé" ce qui n'incite pas à rester... il est au final plus que conseillé....

Lien vers le commentaire
Partager sur d’autres sites

Pourtant j'ai recopié exactement votre fichier et l'ai placé au bon endroit en utilisant putty. Ca n'explique pas pourquoi ça fonctionne avec PHP 7.2 et pas PHP 7.7. Je vais tout de même regarder mais il ne me semble pas que ce fichier fasse référence à la version de PHP

Quant au certificat SSL, j'en ai fai un avec la méthode du NAS, mais le navigateur me dit qu'il ne connaît pas l'autorité qui l'a délivré. Faut-il utiliser le certificat synology.com ou en faire un nouveau ?

Merci d'être à l'écoute

Dominique

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Il faut bien suivre la démarche notamment en qui concerne l’affectation du certificat au service (partie sécurité certificat)
Ainsi le certificat (créé) est associer au virtual host créé pour le site réalisé sous WordPress.

Quant aux versions de php, la dernière en date est parfaitement compatible avec cette installation décrite au parametrage idoines réalisés (mysql et..)

Maintenant attention, si votre fai est sosh ou orange et que vous avez une lb4... la dernière mise à jour de décembre 2020 casse le routage correct des ports 80 et 443.

Lien vers le commentaire
Partager sur d’autres sites

exemples qui fonctionnent sous PHP 7.2 mais donnent une erreur sous PHP 7.4 :

wp-login.php?action=logout&_wpnonce=e39e316e8c

ou, après remise des permaliens à simple :

wp-admin/options-permalink.php

Et dè que je me remet sous PHP 7.2 et que je recharge la page qui affiche l'erreur, tout réapparaît correctement.

pour nginx, j'ai bien indiqué au bon endroit le try_files $uri $uri/ /index.php?args

Je reste perplexe. Où se trouve la différence entre PHP 7.2 et PHP 7.4 ?

 

Lien vers le commentaire
Partager sur d’autres sites

Lés delta sont réduits et ne sont pas, à mon avis, la source du pb.
(Sauf utilisation d’une extension ou d’un thème faisant appel à un élément abandonné en php 7.4)

Un problème de signature oui.
1/ si php 7.2 non requis par un autre module on le désinstalle
2/ on réinitialise le php.ini (webstation, profil php modifier on coche personnaliser base dir, appliquer, puis on revient et on décoche puis à nouveau appliquer)
3/ redémarrage du NAS.

Lien vers le commentaire
Partager sur d’autres sites

Désolé, j'ai suivi vos instructions (avec redémarrage du NAS) et ré installé wordpress : j'ai obtenu l'erreur nginx Not allowed llors de la connexion à l'admin (step 2), exactement comme une autre personne sur ce forum.

Et dès que je suis repassé à PHP2, il m'a suffi de rafraîchir la page et la connexion à l'admin s'est faite sans problème. (comme thèmes, il n'y a que les 2 proposés par wordpress et le seul plugin est Askimet)

Devrais-essayer de réinstaller PHP4 et comment procéder ?

Merci de votre patiente écoute

Dominique

à l’instant, doprev a dit :

Désolé, j'ai suivi vos instructions (avec redémarrage du NAS) et ré installé wordpress : j'ai obtenu l'erreur nginx Not allowed llors de la connexion à l'admin (step 2), exactement comme une autre personne sur ce forum.

Et dès que je suis repassé à PHP2, il m'a suffi de rafraîchir la page et la connexion à l'admin s'est faite sans problème. (comme thèmes, il n'y a que les 2 proposés par wordpress et le seul plugin est Askimet)

Devrais-essayer de réinstaller PHP4 et comment procéder ?

Merci de votre patiente écoute

Dominique

Il s'agissait bien sûr de PHP7.4 et PHP7.2 biensûr

Lien vers le commentaire
Partager sur d’autres sites

heu... dernier post en novembre 2020... soit c'est résolu soit c'est oublié...  😉

Bon très sincèrement en reprenant pas à pas y'a pas de raison que cela ne fonctionne pas.

  1. s'assurer que MariaDB est en version 10.
  2. s'assurer que le profil PHP utiliser en WebStation est bien paramètré
  3. s'assurer que l'hôte virtuel créé dispose du fichier de conf pour la bonne gestion des permaliens

Après si la chose était initialement gérée via les paquets Synology, la BD de paramètrage du site wordpress risque d'être en déphasage potentiel (nom de domaine, adresse du chemin) .

Soit AVANT on exporte les articles, les pages et autres éléments manuellement depuis le tableau de bord wordpress (y compris la bibliotheque média flux xml et dossiers et contenu mis de côté)

On repard from scratch et on réimporte les flux xml exportés avant et on redépose le contenu des média.

Soit on garde la base et on bidouille en sql dedans pour adapter les champs en conséquense.

bon courage

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.