Differentes versions de PHP

ok je fais ca ce soir :
du coup
1 - apt autoremove --purge *php*
2 - apt install php libapache2-mod-php php
3 - commenter les lignes relativex aux repertoires perso dans php7.3.conf
4 - service apache2 restart

pour répondre à ta deuxieme question… transmission de pensées :wink: je n’avais pas commenté ces lignes.
Lors de mes tests, je tente d’afficher mon site principal (/var/www/html) et le phpinfo qui est dans mon repertoire perso.
Mais même en commentant ces lignes et en réactivant le mod php.7.3 aucun php ne s’affiche (ni dans mon repertoire perso, ni dans le /var/www/html). Dommage, on a eu la meme idée, mais elle n’a rien donné :confused:

Malheureusement, toujours le meme probleme…

Ce n’est pas normal, surtout avec les commandes proposées par @fanch24.
Il y a un truc qui nous échappe dans ta configuration. Est-ce que tu peux nous montrer le fichier de configuration de ton hôte virtuel ?

Oui!.. Là ça m’échappe!..

Verifies également la présence d’un .htaccess dans le répertoire de ton site et s’il l’est, donnes nous en le contenu SVP

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 :frowning:
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 :wink:

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 :smiley: