Et en ce qui concerne le module userdir, l’as-tu activé?..
sudo a2enmod userdir
Question c.n de ma part!.. Oublies!.. Il est activé puisque tu consultait la configuration de ton PHP au début.
Ce module ne devrait pas être utilisé sur un serveur accessible publiquement.
Tout-à-fait d’accord avec toi Bruno1. Même en sécurisant l’accés, ça créé tout-de-même une faille. Néanmoins j’ai vu sur le Net pas mal de tuto ou on s’évertuait à l’utiliser.
Ma question venait du fait que franck67 m’a confirmé qu’il l’utilisait:
Attends!.. Je viens de penser à un truc idiot.
Franck67, avec quel navigateur tu interroges ton site SVP?..
<VirtualHost *:80> # The ServerName directive sets the request scheme, hostname and port that # the server uses to identify itself. This is used when creating # redirection URLs. In the context of virtual hosts, the ServerName # specifies what hostname must appear in the request's Host: header to # match this virtual host. For the default virtual host (this file) this # value is not decisive as it is used as a last resort host regardless. # However, you must set it for any further virtual host explicitly. #ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html/ # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf ServerName www.url.fr ServerAlias www.url.fr DirectoryIndex index.php index.html ProxyRequests Off ProxyPreserveHost On ProxyVia full <proxy> Order deny,allow Allow from all </proxy> RewriteEngine on #RewriteRule ^/?(.*) https://url.fr/$1 [R,L,NE] RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} </VirtualHost>
j’utilise firefox 89.0.2
Bon!.. Résumons:
1 - Quand tu as updaté ta distri, tu t’es retrouvé avec Apache qui utilisait PHP 7.0 plutôt que que PHP 7.3:
là, c’était normal. En effet, tu avais sur ta machine deux versions de PHP et ça, Apache sait pas faire sans bidouille plus ou moins fonctionnel sur laquelle on ne reviendra pas pour éviter les polémiques
2 - A priori, après une longue conversation entre les uns et les autres sur laquelle on ne va pas non plus s’étendre pour les mêmes raisons que ci-dessus, tu as nettoyé parfaitement ta config PHP . Les principaux protagonistes de la discussion évoquée sont d’accord sur ce point. la manip que je t’ai fait faire est radicale. Pourtant ça ne fonctionne pas plus que ça: tu as toujours les mêmes symptomes, à savoir quand tu passes en PHP 7.3 , ça lit pas PHP et ça te renvoie le code contenu dans la page uniquement.
3 - Après vérification de ton Vhost, je ne vois STRICTEMENT RIEN qui pourrait bloquer. Je pense que Bruno1 et autre seront d’accord sur ce point.: ton vhost ne possède que le strict minimum requis. Il y aurait un autre point à vérifier également ce serait la présence d’un fichier .htaccess qui bloquerait dans ton répertoire /var/www/html mais bon!.. Je ne pense pas que cela soit ça car le problème se trouve également sur la page situé dans ton répertoire personnel avec laquelle tu interroges le serveur pour vérifier la version de PHP qui tourne.
Du coup, je ne vois plus qu’une chose à vérifier, c’est pourquoi je t’ai demandé qu’est-ce que c’était ton navigateur: le cache de ce dernier. Remet ton site en PHP 7.0 (puisque je suis à peu près certain que tu l’as remis tel quel à partir de ton backup) et, avant de l’interroger, vide le cache du navigateur (manip ici: https://support.mozilla.org/fr/kb/comment-vider-le-cache-de-firefox)
Cela ne vient pas du cache non plus 
De plus, je pense que si c’etait le cache, mon php7.3 devrait s’afficher en forme de php7.0 non ?
je suis entrain d’installer une nouvelle VM directe en 10.10, et la, le php7.3 fonctionne.
Je me demande si je n’irai pas plus vite, a tout basculer de l’un a l’autre 
Ben non vu que PHP est interprété par le serveur et non le navigateur. Il afficherait la même page à savoir celle que tu as ouverte lors de tes premier essai… et dont l’affichage sous forme de code était normal à ce moment là étant donné que ta config était pas glop.
Voici une configuration des plus étranges.
À quoi servent les directives proxy ? Sans directives ProxyPass je ne vois pas leur utilité…
Peut-on voir l’hôte virtuel sur le port 443 puisque tout le trafic y est redirigé via une réécriture d’URL (bof…)
J’ai des proxypass plus bas dans la config, mais je vous ai épargnés, car il y’en a bcp et ca reste un peu sensible…
concernant la réécriture d’URL, n’est ce pas la bonne méthode pour forcer le traffic 80 ->443 ? si tu as mieux, je suis preneur, j’ai suivi un guide pour ca…
pour le vhost 443 :
<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html SSLCertificateFile /etc/apache2/certificats/www.url.fr.cert.cer SSLCertificateKeyFile /etc/apache2/certificats/www.url.fr.key SSLCertificateChainFile /etc/apache2/certificats/www.url.fr.interm.cer RewriteEngine on ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> </VirtualHost> </IfModule>
Désolé mais je ne comprends pas grand chose à ta configuration. Sans doute parce que tu n’en montre qu’une petite partie…
Tu as un hôte virtuel sur le port 80, bricolé à partir du fichier par défaut fourni par les mainteneurs Debian, qui redirige toutes les requêtes en HTTPS. Toutes les autres directives (que tu ne veux pas montrer) ne servent donc à rien.
Pour info une manière simple et efficace de « forcer » le HTTPS est :
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /srv/web/example.com/www
Redirect Permanent / https://example.com/
</VirtualHost>
Pour l’hôte virtuel sur le port 443, je ne comprends pas l’utilité des directives
SSLOptions +StdEnvVars
qui plombent les performances et ne pourraient être utiles que si les scripts de ton site sont interprétés en CGI. Or je n’ai vu aucun module cgi, fcgi, … activé.
J’ai enfin trouvé la solution…
sur php7.3, la variable short_open_tags est passée à Off par défaut avec la mise à jour.
Du coup, il faut absolument mettre des balises ouvrantes « <?php » au lieu des « <? ».
Toutes les pages sans ces balises ne fonctionnaient donc plus…
Incroyable d’avoir perdu autant de temps et d’énergie…
Merci beaucoup pour votre aide, j’ai appris plein de choses !
Effectivement c’était tout con!.. Bravo à toi!..
Ceci dit je m’étonne que ton site Davical n’avait pas été modifié en ce sens car cela fait longtemps que cette modification était prévue. C’était tellement basique d’ailleurs que personne n’y a pensé.
Si je puis me permettre un conseil: Si tu souhaites garder la config de PHP telle quelle, je te suggère plutôt que de modifier tout le site de valider la variable en question via un fichier .htaccess comme expliqué ici: https://electrictoolbox.com/php-disable-short-tags-apache-htaccess/
Je n’ai pas testé le davical.
J’avais testé uniquement que des sites / scripts maison, ou je n’ai pas du mettre partout les balises longues.
J’ai modifié la variable, directement dans le php.ini et cela fonctionne a nouveau.
Je vais pouvoir m’attaquer au probleme inital maintenant… davical !
Ok!.. je comprends mieux maintenant.
Bonne continuation Franck67 et à la prochaine.
1 J'aime
avec plaisir, merci pour l’aide, je kiffe debian !
j’aurai surement encore plein de problemes a venir 
Cette option est désactivée par défaut sur les environnements de production.
De toute façon il est déconseillé d’utiliser d’utiliser les balises courtes :
Depuis peu. Le manuel PHP dans sa version anglaise indique que PHP 7.4 devrait être la première version ou effectivement c’est comme ça. Je suppose que comme cette version est déja sous sid les autres dépots Debian se sont mis à la page sur ce point pour simplifier. En revanche:
ça, c’est vrai depuis très longtemps. Au moins 2011. A noter qu’il est prévu que la version 8 supprimera définitivement l’option short_open_tag d’ailleurs. En clair il est franchement temps d’arrêter de les utiliser.
Depuis longtemps. Cette option est désactivée par défaut depuis Debian 8 jessie.
Ah bon?.. J’ai jamais fait gaffe. Pourtant mon serveur est sous Debian depuis bien avant Jessie (mon premier monté était sur une Sarge)
Bon il est vrai que je n’ai jamais utilisé les balises courtes non plus…
A cause d’ailleurs de cet avertissement dans la page du manuel que tu as mis en ligne qui, quant à lui, a toujours existé depuis l’époque ou j’ai commencé à écrire moi-même mes scripts… Et ce malgré les différents cours sur lequel j’ai appris, notamment ceux du « site du 0 » (actuellement « openclassrooms ») qui disaient à l’époque qu’on pouvait écrire « <?php » ou « <? » comme on voulait.