Hello tout le monde

Bon après deux journées entières à essayer de déployer mon site, lire la doc et parcourir les forums je ressors avec plus de questions que j'en avais à la base haha, j'appelle à l'aide^^

J'ai réservé mon nom de domaine sur ovh et j'ai pris l'offre hébergement perso avec serveurs mutualisés, que je déploie en FTP avec Filezilla, sous symfony 4, php 7 et apache. J'ai finis par tout supprimer et revenir au dernier commit à force de faire trop de manips, le point le plus loin où je suis allé était une erreur 404 de Symfony. Bon j'espère ne pas être trop relou j'ai pas mal de question^^

1. Déjà, j'hésite à passer par SSH parce que FileZilla c'est vraiment de la m** haha. J'ai des retours contradictoires de ce que je lis, sachant que mon niveau sur la mise en place d'un serveur etc un joli zero tout pointé. Est-ce abordable pour un débutant ? Sachant aussi qu'à priori, je vais faire souvent des mises à jour sur le site.

2. J'ai vu qu'il existait des outils comme deployer, est-ce que je devrais me diriger vers ça ?

Bon sinon dans le cas où je décide d'aller jusqu'au bout en FTP, voici un peu ce que j'ai fait. J'ai suivis surtout les recommandations de Ymox dans ce fil de discussion :

https://openclassrooms.com/forum/sujet/deployer-son-projet-synfony-avec-filezilla-sur-ovh#message-93985673

J'ai déplacé tous les fichiers et dossiers à l'endroit indiqué, à savoir une partie dans la racine, et le contenu de public dans www et fait la commande

symfony/apache-pack

3. je suis passé en prod dans le fichier .env, j'ai "raccordé" la base de données que j'ai créé sur OVH avec mon fichier .env.local (déjà, en y réfléchissant, est-ce que c'est pas un non sens de faire ça ? c'est pas mon fichier .env quoi doit envoyer les infos ? C'est en faisant ça que je suis tombé sur l'erreur 404 de symfony (après être repassé en dev). Aussi, est-ce que la ligne à écrire pour la bdd ressemble bien à ça : 

DATABASE_URL="postgresql://db_user:db_password@ADRESSE_SERVER_DONNE_PAR_OVH/db_name?serverVersion=13&charset=utf8"

4. Ne voyant que ça marchait pas, j'ai fait un pour créer mon htaccess

composer require symfony/apache-pack

Et j'ai créé le deuxième à la main... Un à la racine de mon projet, l'autre dans le dossier public. Bon vous comprenez qu'à partir de là je m'arrache les cheveux haha

999. Puis j'ai aussi fait cette commande que j'aurais dû faire avant je suppose (j"ai quand même fait attention à transférer les fichiers modifiés à chaque fois sur mon serveur)

APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear

Bref je suis perdu... Il y a aussi cette histoire d'hôte virtuel et de lien symbolique que j'ai juste survolé pour l'instant.

Ah oui j'ai finis en beauté avec la doc de symfo :

https://symfony.com/doc/current/deployment.html

Mais pareil la page me retourne la même erreur. Bref je suis en PLS, auriez-vous des petits (gros) conseils pédagogiques à me donner ? Merci par avance en tout cas (si t'as lu jusque là c'est déjà beaucoup haha)

Salut

• c'est bien le .env qui va contenir les informations du serveur de production. Idéalement, il faudrait déclarer des variables d'environnement Apache, mais je ne sais pas si OVH propose autant de latitude.
• est-ce que tu as uploadé le cache, par hasard ?
• est-ce que tu comptes utiliser PostgreSQL ou MySQL ?

Ymox a écrit:

Salut

• c'est bien le .env qui va contenir les informations du serveur de production. Idéalement, il faudrait déclarer des variables d'environnement Apache, mais je ne sais pas si OVH propose autant de latitude.
• est-ce que tu as uploadé le cache, par hasard ?
• est-ce que tu comptes utiliser PostgreSQL ou MySQL ?

• D'acc. Du coup le .env.local ne sert plus à rien je suppose ?
• non, enfin je ne sais pas haha. Est-ce qu'il faut faire une manip pour l'uploader ? J'ai précisé globalement toutes les manips que j'ai fait...
• Pour la dernière question, ça fait aussi parti des questions que je me posais. Sur OVH c'est précisé mysql. Mais en local dans le fichier .env c'est bien postgreSQL qui était écrit. Que dois-je faire ?

• Non, pas pour l'environnement de production.
• Alors tente de savoir. Normalement il ne faut pas l'uploader.
• Savoir quelle base de données tu vas utiliser chez OVH et faire ce qu'il faut. En règle générale, on utilise la même base de données en local et en distant.

Ymox a écrit:

• Non, pas pour l'environnement de production.
• Alors tente de savoir. Normalement il ne faut pas l'uploader.
• Savoir quelle base de données tu vas utiliser chez OVH et faire ce qu'il faut. En règle générale, on utilise la même base de données en local et en distant.

• ah mais oui je suis naze trop de fatigue hier hehe. J'ai juste fait la commande du point 999 de mon premier message il me semble... Bon du coup je suppose qu'il faut faire plutôt

php bin/console cache:clear

et

php bin/console cache:clear --env=prod

• Ok, je comprends mieux sur ce point pourquoi j'hésitais. Dans mon .env.local j'ai bien mysql, mais pas dans le .env où c'est la ligne postgresql qui est décomentée. C'est pas censé faire un conflit ? La ligne DATABSE_URL ne sert à rien dans le .env quand je suis en local ? De toute façon je n'ai pas postgre sur ma machine. J'ai aussi une autre question sur la BDD. Sur OVH ils mettent la version 5.6 pour mysql alors que je suis en version 8 : est-ce qu'il faut que je downgrade mysql ?
• Et pour répondre à ton point sur les variables d'environnement apache plus haut, il semble que mon offre ne le permette pas. Est-ce que c'est facultatif ? Sinon sur ce fil de discussion il semble qu'il est possible de passer par une méthode un peu "sale" en fixant les variables au travers d'un fichier mais la méthode n'est pas précisée, ça reste assez obscur pour moi pour l'instant.

• Ah oui, autre question importante : dans le fichier ovh.config on est d'accord qu'il faut que je renseigne ma version de php ?

• Ah, haha, t'avais pas précisé dans ton message sur la conv de 2021 citée plus haut. A la racine de mon projet, j'ai les fichiers
  
  • phpunit.xml.dist
  • docker-composer.override.yaml
  • .env.test
  • docker-compose.yaml
    * edit : Je viens de regarder ce qu'il y avait dans ce fichier, et je vois postgres partout haha là je comprends pas... En faisaint en postgres -V je n'ai rien... J'ai pas des conflits ? Je sais pas si c'est utile comme info mais dans les requêtes de mes migrations j'ai bien des  $this->addSql...

       Il faut bien les envoyer à côté des .env, composer.json ? Et on est d'accord, le .gitignore je ne l'envoie pas ? C'est pas là où le htaccess intervient ? D'ailleurs la manip pour le htaccess est-elle obligatoire ? Trop d'infos haha... Bon je vais peut être déjà réessayer en suivant les conseils que tu m'as donné et en faisant les trucs qui me semblaient logique que je t'ai demandé dans ce (énième) long message haha. Merci pour ton aide en tout cas !

** edit Bon petite évolution. J'ai maintenant l'arborescende de mon dossier www qui apparaît, à savoir mon dossier img, js et css. Je continue de me renseigner

-
Edité par ClémentakaJohn 19 mai 2022 à 14:29:35

Pour ce qui est de MySQL, je ne sais pas trop. Normalement, il faut renseigner dans la variable DATABASE_URL la plus petite version, et souvent ça ne pose pas de problème pour la plus grande. L'inverse est moins certain, ça peut passer comme ça peut ne pas passer.

Pour les variables d'environnement, j'avais dit que c'était la solution idéale. Reste à voir si c'est à portée. En ce qui me concerne, j'en suis resté aux .env et .env.local.php.

Le fichier .ovhconfig devrait permettre de spécifier la version de PHP afin que tu aies la même version en distant et en local. Attention à bien vérifier que tu as aussi cette version avec la ligne de commandes, vu que tu lances des php bin/console.

Concernant les fichiers que tu mentionnes afin de savoir si tu dois les envoyer aussi, je te propose une piste de réflexion : à quoi servent-ils, et du coup sont-ils nécessaires à un environnement de production ?

Si tu vois la liste du dossier, il te manque encore le .htaccess fourni par symfony/apache-pack et le index.php fourni avec Symfony dans le dossier initial /public.

• Ok. Si jamais ça ne passe pas, est-ce que j'aurais des éléments visuels qui me l'indiqueront ? Comment faire pour le débuguer ? Sinon, j'ai cru comprendre que Docker pouvait aider à avoir deux versions différentes de mysql ça pourrait être éventuellement une porte de sortie...  je suis censé aussi avoir un .env.local.php...?^^

• Je vois, pour l'instant je pense que je vais essayer la méthode simple haha

• J'ai bugué avec l'emploi de "php bin/console" on est d'accord qu'il s'agit juste de faire un php --version ?

• Bon du coup j'ai regardé un peu pour les fichiers tu me dis si je me trompe.
  
  • phpunit.xml.dist et .env.test sont des fichiers qui servent pour les tests unitaires. N'ayant pas du tout vu les tests unitaires avant me vient la question : faut-il les faire avant la prod ? ça paraîtrait logique (du coup les tests fonctionnels c'est seulement pour la prod ?). Bon du coup, je n'envoie pas ces fichiers puisque de toute façon j'ai pas fait de tests hehe..
  • Concernant les fichiers de Docker je dirais qu'il faut les envoyer (même si ça a l'air d'être facultatif ?) étant donné que de ce que je comprends, cela permet de faciliter l'installation des librairies dont mon appli a besoin pour fonctionner, à savoir mysql, apache, php (je comprends pas trop le terme librairies pour parler d'apache et de mysql, là je récite un peu la leçon haha)... La question qui vient du coup c'est comment on le configure. J'ai trouvé ce site : https://www.bgs-associes.com/configurer-une-application-avec-apache-php-mysql/ est-ce que c'est ok si j'utilise ces recommandations ?
  • sur le gitignore par contre je sais pas trop : l'hébergeur est capable de le lire ? Pour moi ce fichier sert pour ne pas envoyer d'infos compromettantes lorsque je déploie mes projet via git. Mais est-ce qu'il existe un système similaire sur l'hébergeur pour protéger certains fichiers ? 
• Oui ok, j'avais supprimé le htaccess étant que ça me retournait une page d'erreur. Je commence un peu plus à comprendre à quoi sert ce fichier, mais pas trop encore comment le configurer, je me penche là-dessus aujourd'hui. Déjà, je comprends pas trop quel dossier doit être ciblé pour lancer mon appli, je vois beaucoup sur les tutos que les gens balancent tout dans le dossier public, que je n'ai plus étant donné que j'ai envoyé son contenu dans mon dossier www. Déjà je ne comprends pas trop l'utilité d'avoir séparer l'envoie de ces fichiers ? Bref, je suppose en tout cas que le fichier htaccess dans public doit pointer vers mon dossier au dessus pour faire le lien. Ensuite il me faut un deuxième fichier htaccess non ? Celui de public sert uniquement à faire le lien avec mon dossier au dessus, tandis que celui qui serait à la racine de mon projet servirait plutôt à faire mes redirections c'est ça ? Dans ma logique, jme dis aussi qu'il faut bien un endroit où est dit : vas-y lance mon fichier base.html.twig non ? C'est fait automatiquement ou c'est justement dans ce deuxième htaccess que je l'indique ?

Bon j'ai aussi des questions sur mes routes mais on verra après j'ai encore écrit un pavé Merci beaucoup en tout cas !

-
Edité par ClémentakaJohn 20 mai 2022 à 12:06:34

Utilise des listes numérotées, ce sera plus simple pour s'y retrouver dans les réponses.

• Tu verras très vite quand tu lanceras les migrations.
• -
• Non, c'est bien la commande que je mentionne, qui est une reprise de celle que tu mentionnes. Mais on ne doit pas parler de la même chose.

• Réfléchis un peu plus :

  • est-ce que tu fais des tests complets sur le serveur de production ?
  • est-ce que tu utilises Docker sur le serveur de production ?
  • est-ce que tu utilises git sur le serveur de production ?

  En fonction des réponses, tu devrais pouvoir comprendre si tu les envoies ou non. Indice : non.

• Tu n'as rien à y toucher, tu installes le pack qui te créés un fichier adapté. Par contre si cela te génère une erreur obscure, il faut prendre le réflexe d'aller voir dans les journaux serveurs quel est le problème si tu ne vois rien d'utile à l'affichage web.

-
Edité par Ymox 20 mai 2022 à 13:50:00

1.Bon du coup après avoir transférer le htaccess, je suis retombé sur la page que j'avais eu, à savoir

Oops! An Error Occurred

The server returned a "404 Not Found".

Something is broken. Please let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.

Puis j'ai modifié la ligne du ovh.config :  app.engine.version=7.4 par app.engine.version=7.4.9, et j'ai maintenant une erreur qui me dit :

Not Implemented

GET not supported for current URL.

Additionally, a 501 Not Implemented error was encountered while trying to use an ErrorDocument to handle the request.

2. Tu ne me demandais pas la version de php ? La commande donne :

Symfony 5.3.16 (env: prod, debug: false)

 D'ailleurs, je devrais pas être en mod dev avec debug true (et mon ovh.config en development) tant que je ne suis pas sûr que ma config soit bonne ?

3. Aussi, je sais pas si il faut le modifier, mais sur l'onglet multisite d'ovh, mon dossier racine pointe sur www. Je devrais pas plutôt le faire pointer sur le niveau au dessus ? En parlant de cet onglet, il faudrait pas aussi que j'active les logs séparés ainsi que le firewall ?

4. Tu me parles bien des journaux serveur d'OVH et pas de Apache ? Est-ce que je peux les publier ici ça craint pas niveau sécu ? Je mets une partie pour l'instant. Quels sont les trucs que je dois particulièrement regarder ?

AH01630: client denied by server configuration: /homez.1710/blabla/.ovhconfig
AH00687: Negotiation: discovered file(s) matching request: /homez.1710/blabla/templates/index.html (None could be negotiated)
[host blabla.fr] engine php version 7.4.9 not available at /var/lib/fastcgi/php//images/legacy/7.4.9
[host blabla.fr] engine php version 7.4.9 not available at /var/lib/fastcgi/php//images/legacy/7.4.9, referer: https://blabla.fr/

Bon normalement je suis repassé en 7.4 dans ovh.config mais le log n'a pas l'air de le prendre en compte pour l'instant...

*edit Bon du coup visiblement ça vient de la config d'apache mais y'a un truc que je comprends pas. Les fichiers à modifier sont sur ovh ou sur ma machine ? Si c'est sur ma machine, il faudrait pas que je déplace mon site dans var/www ? Certains conseillaient de modifier le virtual host... Ou c'est qu'il me faut un VPS...?

5. Ah oui aussi je sais pas si ça sert à grand chose mais j'ai cru comprendre qu'il essayait de choper index.html.twig (fichier que je n'avais pas donc j'ai rajouté une route sur mon Controller et un fichier dans templates

6. Ah j'avais pas vu j'ai aussi un onglet awstats, qui me renvoie ce message d'erreur :

Error: Plugin init for plugin 'geoip' failed with return code: Error: Failed to create gi object for datafile=/usr/share/GeoIP/GeoIP.dat

Setup ('/home/awstats-osl/blabla.cluster031.hosting.ovh.net/awstats.blabla.cluster031.hosting.ovh.net.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory). 

 7. Sinon une des solutions plus simples ça serait pas de passer par une PaaS ?

-
Edité par ClémentakaJohn 20 mai 2022 à 21:52:56

1. Les versions disponibles de PHP dans le .ovhconfig ne prennent que les deux premiers chiffres en compte. 7.4.9, ça en fait 3.
2. Non, je te disais juste qu'il fallait bien s'assurer que là aussi c'était la bonne/même version vu que tu lançais des commandes. En l'occurrence, si tu continues à lancer des commandes avec PHP 5.3 (!) alors que le serveur fonctionne avec une version 7.4 selon ton .ovhconfig, tu vas au-devant de problèmes.
3. Non, la racine est correcte. Je ne crois pas avoir dit dans l'autre sujet qu'il fallait la modifier, si ?
4. Les journaux serveurs peuvent mélanger des messages de PHP, d'Apache et éventuellement de MySQL. Là, ce qui nous intéresserait, c'est Apache, ce que tu fournis. Je ne comprends pas le moins du monde pourquoi une requête voudrait aller directement sur un fichier de template dans le dossier des templates, cela n'a AUCUN sens. Tu es certain que cela fonctionnait correctement sur ta propre machine avant d'envoyer ? Tu as bien envoyé le fichier index.php dans le dossier www d'OVH, au moins ?
5. Je répète une de mes question de ci-avant vu que c'est aussi pour ce point : tu avais quelque chose de fonctionnel avant d'envoyer sur ton serveur OVH ? Si oui, comment cela fonctionnait-il exactement ? Parce que tu me fiches de plus en plus de gros doutes.
6. Ne mélange pas tout, ce n'est même plus une salade de fruits, là. AwStats, c'est pour faire des statistiques sur les visites, cela n'a pour l'instant rien à voir avec ton problème.

-
Edité par Ymox 20 mai 2022 à 23:54:10

haha je sature un peu j'avoue^^

2. Là j'avoue je comprends rien c'est de pire en pire haha. Quand OVH parle de version de PHP c'est en fait la version de symfony ? pourquoi cette commande me donne-t-elle symfony 5.3 ? D'ailleurs avec un symfony -v j'ai ça Symfony CLI version v4.26.8... Et pire encore, je viens de regarder mon composer.json et là je vois php version 7.2 hahaha, chose que je ne comprends pas puisque comme j'ai dit quand je fais un php --version j'ai 7.4.9... Voici mon fichier composer.json

{
    "type": "project",
    "license": "proprietary",
    "minimum-stability": "stable",
    "prefer-stable": true,
    "require": {
        "php": ">=7.2.5",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "1.11.99.4",
        "doctrine/annotations": "^1.0",
        "doctrine/data-fixtures": "@dev",
        "doctrine/doctrine-bundle": "^2.4",
        "doctrine/doctrine-migrations-bundle": "^3.1",
        "doctrine/orm": "^2.10",
        "phpdocumentor/reflection-docblock": "^5.2",
        "sensio/framework-extra-bundle": "^6.1",
        "symfony/apache-pack": "^1.0",
        "symfony/asset": "5.3.*",
        "symfony/console": "5.3.*",
        "symfony/dotenv": "5.3.*",
        "symfony/expression-language": "5.3.*",
        "symfony/flex": "^1.3.1",
        "symfony/form": "5.3.*",
        "symfony/framework-bundle": "5.3.*",
        "symfony/http-client": "5.3.*",
        "symfony/intl": "5.3.*",
        "symfony/mailer": "5.3.*",
        "symfony/mime": "5.3.*",
        "symfony/monolog-bundle": "^3.7",
        "symfony/notifier": "5.3.*",
        "symfony/process": "5.3.*",
        "symfony/property-access": "5.3.*",
        "symfony/property-info": "5.3.*",
        "symfony/proxy-manager-bridge": "5.3.*",
        "symfony/requirements-checker": "^2.0",
        "symfony/runtime": "5.3.*",
        "symfony/security-bundle": "5.3.*",
        "symfony/serializer": "5.3.*",
        "symfony/string": "5.3.*",
        "symfony/translation": "5.3.*",
        "symfony/twig-bundle": "5.3.*",
        "symfony/validator": "5.3.*",
        "symfony/web-link": "5.3.*",
        "symfony/yaml": "5.3.*",
        "twig/extra-bundle": "^2.12|^3.0",
        "twig/twig": "^2.12|^3.0"
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.4",
        "phpunit/phpunit": "^9.5",
        "symfony/browser-kit": "5.3.*",
        "symfony/css-selector": "5.3.*",
        "symfony/debug-bundle": "5.3.*",
        "symfony/maker-bundle": "^1.34",
        "symfony/phpunit-bridge": "^5.3",
        "symfony/stopwatch": "5.3.*",
        "symfony/web-profiler-bundle": "5.3.*"
    },
    "config": {
        "optimize-autoloader": true,
        "preferred-install": {
            "*": "dist"
        },
        "sort-packages": true
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "App\\Tests\\": "tests/"
        }
    },
    "replace": {
        "symfony/polyfill-ctype": "*",
        "symfony/polyfill-iconv": "*",
        "symfony/polyfill-php72": "*"
    },
    "scripts": {
        "auto-scripts": {
            "cache:clear": "symfony-cmd",
            "assets:install %PUBLIC_DIR%": "symfony-cmd",
            "requirements-checker": "script"
        },
        "post-install-cmd": [
            "@auto-scripts"
        ],
        "post-update-cmd": [
            "@auto-scripts"
        ]
    },
    "conflict": {
        "symfony/symfony": "*"
    },
    "extra": {
        "symfony": {
            "allow-contrib": false,
            "require": "5.3.*"
        }
    }
}

Info probablement inutile mais j'avais rajouté dans ce fichier cette ligne car je n'arrivais pas à installer doctrine-fixtures-bundle

"doctrine/data-fixtures": "@dev"

4. J'en sais rien je suis en roue libre quand je fais ça j'essaie tous les trucs qui me paraissent logiques :/ Mon projet tourne quand un symfony server:start (enfin tournais, j'ai voulu le relancer ce matin page blanche mais ça doit être à cause de commandes que j'ai lancé je suppose...). Par contre si la question c'était est-ce que t'as mis des trucs (je suis sous ubuntu) dans var/www et/ou modifiés des trucs dans etc/apache/sites-available etc la réponse est non (pour moi ici c'est pour lancer mes projets qui tournent en local sur du php natif...). J'ai mon projet qui est dans un dossier lambda sur mon bureau. Oui le fichier index.php est bien envoyé. Il ressemble à ça :

<?php

use App\Kernel;

require_once dirname(__DIR__).'/vendor/autoload_runtime.php';

return function (array $context) {
    return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};

Tant qu'on y est voici aussi le htaccess

<IfModule mod_negotiation.c>
    Options -MultiViews
</IfModule>

<IfModule mod_rewrite.c>
    RewriteEngine On


    RewriteCond %{REQUEST_URI}::$0 ^(/.+)/(.*)::\2$
    RewriteRule .* - [E=BASE:%1]


    RewriteCond %{HTTP:Authorization} .+
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%0]


    RewriteCond %{ENV:REDIRECT_STATUS} =""
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]



    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ %{ENV:BASE}/index.php [L]

</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>

        RedirectMatch 307 ^/$ /index.php/

    </IfModule>
</IfModule>

 (déso c'est un peu illisible j'arrive pas à savoir quel langage utiliser pour la balise)

5. Bah ah moins que je devienne fou ou alors que je me plante complètement dans ma manière de procéder...

• Je lance symfony server:start, ça me lance le serveur local
• Je réccupère l'adresse 127.0.0.1:33735/ Pour je ne sais plus quelle raison je change le port à 8000 pour donner un truc comme ça 127.0.0.1:8000/ma_route

-
Edité par ClémentakaJohn 21 mai 2022 à 18:16:44

1. Je n'ai pas été assez clair : il faut mettre seulement deux chiffres dans le .ovhconfig, si tu mets autre chose, ça va planter.
   Si tu lances des commandes sur le serveur OVH, renseignes-toi sur la manière de spécifier la version de PHP pour cet environnement, c'est indépendant du .ovhconfig, peut-être que c'est php74 au lieu de php tout simple.
   Note que suivant ta formule d'hébergement, il peut y avoir diverses manières de faire.
2. Non, je ne fais que parler de versions de PHP. Il faut que tu utilises la même pour le Apache OVH (cf. point 1) et pour la ligne de commandes OVH si tu l'utilises, ainsi qu'en local pour la ligne de commandes. Donc trois endroits à faire coïncider, dont deux chez OVH — toujours si tu y lances des commandes.
3. -
4. -
5. C'est un des trucs que je pourrais ajouter à la liste des reproches que j'ai envers cet outil que fournit "Symfony". Mais là, sans cela, il y a fort à dire.
   Tu dis lancer le serveur qui te donne un port, et tu le changes. Comment, et pourquoi ? Parce que c'est encore un truc qui risque de causer des différences (un quatrième endroit où vérifier la version de PHP utilisée). Tu as une pile serveur comme XAMPP d'installé, ou tu as installé séparément Apache, PHP et MySQL sur ton Linux ?
   Note bien que si tu as installé Apache d'une quelconque manière, tu n'as pas besoin de la commande server:start, il faudrait juste paramétrer correctement Apache, et la mise en ligne devrait justement être plus simple parce que c'est au moins la même infrastructure. Mais c'est plus pratique pour "Symfony" de vendre leur outil et choisir avec cela leurs utilisateurs cibles, apparemment.
6. -
7. Tiens, il s'est perdu en route, celui-ci.
8. Il est possible que les logs soient lus avec un outil qui utilise la version de PHP spécifiée dans le .ovhconfig, revoir le point 1 pour vérifier, et peut-être attendre un peu après.
9. Heroku ne propose pas gratuitement MySQL si je ne m'abuse, c'est PostgreSQL. Or, les migrations effectuées pour MySQL ne passeront pas sur PostgreSQL, il te faudrait les refaire en local avec le même SGBD.
   Tu peux tenter platform.sh, mais je ne suis pas certain que ce soit plus simple qu'ailleurs.
10. Au fait, quelle version de Symfony (et je ne parle pas ici de l'outil en ligne de commandes) utilises-tu ?

Le fait que tu partes « en roue libre » alors que tu as des étapes à suivre dans le message que tu as cité (je me suis permis de le compléter quelque peu avec ce sujet) tout comme dans la documentation officielle me fait me demander si tu n'as pas visé un peu haut, ou si vraiment l'outil Symfony CLI est une encouble à ce point.

1. Si si j'avais bien compris, c'est juste qu'au moment où tu m'a demandé d'aller voir les logs il était resté sur la 7.4.9 alors que j'avais déjà remodifié le fichier en 7.4 depuis un moment... Je me suis rendu compte de ça ce matin quand je suis repartis de zéro..

2. Bon je viens juste de regarder vite fait pour lancer les commandes sur le serveur OVH, j'ai pas vraiment trouvé l'info. Sinon, bah du coup sur OVH (jusqu'à il y a 5 min, encore un truc bizarre), sur l'onglet information générale / configuration / version php globale, j'étais en 7.4 (maintenant je suis en auto pour je ne sais quelle raison). Donc en théorie les deux trucs à faire coïncider sur OVH sont bons non (ovh.config + ce paramètre) ? En revanche je ne comprends toujours pas pourquoi je lancerai des commandes en php 5.3 quand je fais php bin/console..

5. Comment, bah juste en changeant le port quand je rentre l'url dans le navigateur ; pourquoi, parce qu'on m'a appris comme ça et que je n'ai pas remis cette pratique en question. Oui, c'est Lamp que j'utilise. Hm je vois, donc comme je l'ai dit plus haut il faudrait que je transfère mon site dans le dossier approprié d'apache sur ma machine ?

8. Oui probablement, voir mon point 1.

9. OK de toute façon j'ai laissé tombé heroku j'ai pas réussi à m'inscrire, j'ai tenté platform.sh cet aprem. Je tente les deux comme ça le temps que tu réponde je reste pas sans rien faire haha (optimisation de mon arrachage de cheveux)

10. Maintenant quand tu poses un question comme ça j'ai peur..^^ qu'est-ce que je dois comprendre par (je ne parle pas de l'outil en ligne de commandes ?) En lançant, symfony -V,  j'ai Symfony CLI version v4.26.8. Si c'est pas ce que tu demandais je ne vois pas ce qu'il faut faire.

De quel site tu parles ? https://symfony.com/doc/current/deployment.html ? Oui bah après c'est sûr que sur tout ce qui est serveur et tout je n'y connais vraiment rien. La formation que j'ai faite était courte, on a même pas ne serait-ce qu'effleurer le sujet de la mise en prod. Après le truc c'est qu'il y a pas moyen que j'abandonne haha ça fait plus d'un mois que je bosse dur tous les jours pour que mon site voit le jour je peux pas laisser tomber, et puis je suis quand même content du résultat. Je pense que j'ai fait un peu l'erreur de partir trop tête baissée (même si j'ai regardé des tutos et tout avant de me lancer). Pourtant j'aime bien justement quand les étapes sont expliquées point par point (j'avoue j'ai peut-être un peu tendance à favoriser les tutos à la doc - j'y jette un œil, mais s'il y a un tuto qui semble l'expliquer je vais plutôt me diriger vers ça). Mais au final à force de regarder des trucs je m'y perds un peu, et puis il suffit aussi qu'un détail (qui va de soit en principe) ne soit pas précisé pour que je galère, d'où mes questions souvent "idiotes"... Enfin bref, merci en tout cas ça m'aide quand même tout ça j'ai appris des trucs. Espérons que demain soit plus productif ! 

1. OK, cela peut être une partie de l'explication.
2. Donc j'en déduis que tu ne lançais pas de commandes sur OVH. Attention, j'espère que tu n'as pas changé le nom du fichier, parce que c'est bien .ovhconfig, et non ovh.config. Pour la ligne de commandes sur OVH, du coup, on va s'en passer.
3. -
4. -
5. Donc en gros, tu lances une centrale nucléaire (peut-être automatiquement au démarrage de la machine) avec LAMP, centrale qui accepte des connexions sur un port quelconque (habituellement 80, mais au vu de ce que tu me dis, il se pourrait que ce soit le 8000), tu lances une dynamo de bicyclette en ligne de commandes (server:start) qui te dit permettre une connexion sur un port 33725, et ensuite tu te branches sur on ne sait exactement quoi en changeant le port fourni par la dynamo par le 8000… En tout cas, la dynamo ne semble servir à rien, ce qui me rassure un peu. Par contre, si le port 8000 est celui de l'Apache de LAMP, tu n'as normalement rien à changer étant donné que tu me dis que ça fonctionnait pendant un moment (le souci pouvant provenir de l'installation de symfony/apache-pack).
6. -
7. -
8. -
9. -
10. Justement, ce que tu me donnes est la version de l'outil binaire Symfony CLI (c'est d'ailleurs noté dans ce que tu cites), et non celle du framework sur lequel tu as basé ton code. Normalement tu dois pouvoir voir cela dans la barre de débogage en survolant le logo Symfony. D'après le composer.json que tu montres, ce serait Symfony 5.3, et d'après le résultat d'une quelconque commande, résultat que tu as fourni, ce serait même 5.3.16.

Reprends le message de l'autre sujet attentivement, tente d'accéder à ton site, et donne l'URL et l'éventuel message d'erreur. On va y aller pas à pas.