Tag "compatibility" et extensions sous J! 3.9

[RobertG]

Je ne me pose pas la question de savoir si les devs prétendent être compatibles, mais Akeeba backup par exemple l'est parfaitement tout en ayant ce missing tag.
Oublie Virtual domains : il ne fonctionne pas en J! 4, mais il y en a une version sur Github https://github.com/smehrbrodt/virtua...ses/tag/v1.4.1 (en plus de l'ancienne plus maintenue)

Tu peux tester LazyDbBackup (que je maintiens toujours) et qui fonctionne très bien tant en version MySQLi qu'en version PDO. https://www.joomxtensions.com/lazydbbackup.html
Et cette extension, comme je l'ai précisé plus haut comporte bien les tags "targetplatform", mais pas les versions de PHP et MySQL

Si je mets une version précédente de LDB, le fait que tu voies la mise à jour dans la page de mise à jour de Joomla! après recherche (je suis en mode nighty builds, je le rappelle), tu ne verras l'absence de tag s'afficher qu'après la mise à jour du plugin

[garstud]

Well, je viens de recuperer LDB en v3.7.1 (volontairement ancienne)

je l'ai installé sur mon J3.10...
j'ai lancé le pre-update check qui me dit (en orange) que LDB est compat J3.10.x si je met a jour LDB en v3.8.7

Extensions Pre-Update Check
Extension Name                                Compatible       Installed Version
Système - LazyDbBackup - MySQLi               Yes (3.8.7)      3.7.1

Du coup je mets a jour LDB via la detection de mise à jour
et quand je reviens sur pre-update check, il me dit (en vert) que LDB est compat avec cette version 3.8.7
Je ne vois pas ou est ton probleme ?

Extensions Pre-Update Check
Extension Name                                 Compatible         Installed Version
System - LazyDbBackup - MySQLi                 Yes                3.8.7

PS : les tags de version mini PHP et SQL sont des tags supplémentaires a mettre si on a besoin de demander une version minimale pour ces 2 moteurs

[RobertG]

Ici :

[garstud]

Robert, je ne peux pas aider si tu ne me donnes pas le contexte ...
- de quelle version joomla pars-tu ? quelle est ta version joomla cible ?
- quelle est ta config Joomla update (quelle custom url ? ... ou autre ?)

Au vu de la différence entre mon écran et ton ecran, je suppose que tu es en train de tester une "migration J3.10 vers J4.0", c ca ?
avec un custom url en "major.xml" ? c bien ca ?

Dans ce cas, au vu de ton updateServer :

https://updates.joomxtensions.com/lazydbbackup_upd.xml

J'ai l'impression que ce qui peut bloquer, c'est que tu definis 2 fois la v3.8.7, une fois pour J4, et une fois pour J3.x...
Généralement, on a 2 branches différentes pour 2 versions majeures (ex : LDB v3.8.7 pour J3 et une LDB v4.0.1 pour J4)
Ou si vraiment ton dev est compat avec les 2 alors il ne faudrait le definir qu'une seule fois dans l'updateServer, je pense !

[RobertG]

Je suis en 3.10 nighty builds, avec la custom URL de développement, les extensions sont installées ; je passe dans la page de mise à jour de Joomla! et je fais une recherche de mise à jour qui m'affiche ce pre-update check.

[garstud]

Ok, et pour ton Url , la fin c'est minor.xml ou major.xml ?


Je ne sais pas si c'est prévu dans Joomla Update, mais vu que ca a l'air d'etre du RegEx, je dirais que l'on peut tenter une compat multi-major avec un truc genre :

<targetplatform name="joomla" version="(3.[789]|10)|(4.[0])"/>

ou
<targetplatform name="joomla" version="(3.[789]|3.10)|(4.[0])"/>
(ma preference, voici ce que ca donne en detection simultanée de v3.x et 4.x : https://www.phpliveregex.com/p/vez )

ou
<targetplatform name="joomla" version="(3.[789]|3.10)|(4.0)"/>

Testes ca et dis nous si ca marche ?

[RobertG]

minor, puisque c'est une 3.10 nighty builds

Ce que je ne comprends pas, c'est qu'on n'ait pas plus d'infos (idem pour la création des packs de langue core, qui mintéresse).
https://docs.joomla.org/Deploying_an_Update_Server/fr précise que pour une compatibilité 2.5 et 3, il faut deux "update" (ce qui est mon cas pour LDB) :

Si votre extension est compatible Joomla! 2.5 et/ou 3.1, vous devrez avoir des définitions séparées de <update> pour chaque version à cause de la manière dans le moteur de mise à jour va vérifier la version

Reste à savoir si le moteur est le même en 3 et 4.

[garstud]

Minor ? pas forcement evident !
Si tu choisis le minor c'est que tu veux tester un passage de ta 3.7.x, 3.8.x, 3.9.x ou 3.10.x .... vers une 3.10.y
voir : https://update.joomla.org/core/night...minor_list.xml

Si tu choisis le major c'est que tu veux tester un passage de ta 3.10.x, 4.x .... vers une 4.y
voir : https://update.joomla.org/core/night...major_list.xml

Tout est détaillé sur https://developer.joomla.org/nightly-builds.html


Pour le coup des 2 updates, je crois bien que l'on est toujours dans la meme logique, mais à contrario de la 2.5, on a desormais besoin de preciser la targetplatform et ... sauf si tu arrives a faire fonctionner une des regex précédentes, alors on est obligé de fonctionner avec 2 branches de versions !
Ainsi on respecte bien ce que demande Joomla : "avoir des définitions séparées de <update> pour chaque version"
(mais pour que ca marche tu ne peux pas leur donner le meme numero de version (ex : 3.8.7 !)

[RobertG]

Non, minor c'est l'adresse pour les mises à jour nuighty builds de la 3.10 https://developer.joomla.org/nightly-builds.html
Je suis déjà sur une telle version depuis des mois et je mets à jour de temps en temps par réinstallation des fichiers.

Mais je crois avoir une idée : le serveur de mise à jour et son domaine ont été déplacés vers un autre hébergeur, et ce site 3.10 de test (je n'ai pas encore vérifié sur d'autres) est sur l'ancien serveur, et dans la recherche de mise à jour d'extensions, il me dit ne pas pouvoir ouvrir les xml distants, ce que pourtant je peux faire depuis l'adresse citée. Ce pourrait être la cause, puisqu'en ajoutant un "update" seulement pour la 3.10, la nouvelle version définie n'est pas reconnue.
Sur d'autres sites du même serveur, j'ai d'autres messages concernant la recherche automatisée de nouvelle version, qui semblent liées à une recherche du site localement, alors que le nom de domaine a lui aussi changé de registrar.

Il faut que je teste sur un site neuf, mais cette histoire m'inquiète pour les utilisateurs qui sont chez cet hébergeur.
Bon, après test rapide sur deux tests de clients, ils ne sont pas impactés. C'est déjà ça.

[garstud]

Hum, je vais insister pour le major ... car si tu veux tester un pre-check depuis J3.10 vers J4, alors c'est bien le major qu'il te faut !
Et au vu de tes precedents messages c bien une migration 3.10 vers 4 que tu veux tester.

Concernant ta remarque sur tes 2 serveurs avec probleme d'ouverture d'XML distant, j'avoue ne pas avoir tout compris !?
Mais je ne vois pas en quoi cela a un impact sur le test du pre-check sur LDB !

As-tu tenté de modifier le regex de ton targetplatform ? en ne laissant qu'un update pour la 3.8.7 avec le regex qui combine 3.x et 4.x

[RobertG]

Je viens de tester rapidement sur une 3.10 neuve en minor sur un autre site, et j'ai bien "oui" avec la nouvelle version, je n'ai pas le temps d'aller plus loin pour le moment, mais c'est bien une histoire de recherche de serveur chez l'ancien hôte qui est en cause.
Je vérifierai demain.

sauf mauvaise compréhension de ma part, le pre-update de la 3.10 teste si les extensions seront utilisables en 4

Merci de ton aide !

[garstud]

Y a un truc pas clair a creuser, car quand j'ai fait le test cet aprem, j'avais deja un "Oui" en vert !

sauf mauvaise compréhension de ma part, le pre-update de la 3.10 teste si les extensions seront utilisables en 4

C'est bien la ou je veux tenter d'etre clair. Regarde bien le contenu du major.xml et du minor.xml (mon post #23 ) ... ils sont bien differents et dans le cas que tu cites, c'est bien le major.xml que tu dois utiliser.

[RobertG]

Le truc pas clair est que les sites (sous un autre nom de domaine) encore sur le serveur où était celui d'update semblent continuer à chercher au moins un certificat SSL sur le même serveur, ce qui fait que Joomla! considère qu'il ne peut pas ouvrir le xml d'update.
Et l'hébergeur considère qu'il n'y a aucun problème à son niveau puisque les DNS ont d'abord été changés, puis le nom de domaine du site d'update transféré.

Manifestement, il n'y a que sur les sites restés sur ce serveur que le problème se produit. Et là, je ne vois pas quoi faire.
C'est tout aussi incompréhensible que le problème de DNS que rencontre GTmetrix sur des sites hébergés chez O2switch et où les tests des DNS ne montrent aucune anomalie... ça me dépasse !