tristanleboss

Done, I created a support request on your website.

When I say your plugin reset the robots.txt, it’s because the return of your filter is the content from core function do_robots : https://developer.www.ads-software.com/reference/functions/do_robots/

I also discovered your code is not even up to date… and correct. Indeed, the WP core function handles cases where wp-admin folder is not in the root directory. Your plugin don’t bother with this and probably create incorrect robots.txt file for some sites. A really god reason to fix your plugin ??

Hello,

Yes, for sure, I can use priotity 100 but I shouldn’t have to bother with priority. When you use filters in your plugin, you almost always use priority 10.

But, the problem is that your robots_txt filter should not overwrite all existing robots.txt contents. If you want to get rid of things, you can just alter the content of $output (using regexp, …). Indeed, you have no way to know how other plugins interacted with this filter before yours is run. With your code, all updates to the robots_txt output done by filters with priority < 100 is lost… All plugins authors using robots_txt filter won’t start using priority 100 because they have to deal with this incorrect behavior of your plugin. Robots.txt file is not just about sitemap.

Especially, I don’t really understand why it does reset the robots.txt content anyway? My only guess was that you wanted to get rid of the Sitemap: line that get inserted by WP because you hook wp_enable_sitemap too late? Indeed, the only line you add later in your do_robots filter is the Sitemap:

And, if one day WordPress decides to change the default content of the robots.txt file and you don’t notice it, your plugin will keep reseting the robots.txt content to the old version.

At least, if you don’t intend to fix this code, can you use a method as callback for the filter so people can remove it? Because using an anonymous function makes it impossible to remove… I had to comment your code.

Replace :

// Create dynamically generated robots.txt
if (get_option(‘sm_options’)[‘sm_b_robots’]) {
add_filter(‘robots_txt’, function($output, $public) {
$output = “User-agent: \n”; if (‘0’ == $public ) { $output .= “Disallow: /\nDisallow: /\nDisallow: /*?\n”;
} else {
$output .= “Disallow: /wp-admin/\nAllow: /wp-admin/admin-ajax.php\n”;
}
return $output;
}, 99, 2);
}

with

// Create dynamically generated robots.txt
if (get_option(‘sm_options’)[‘sm_b_robots’]) {
add_filter(‘robots_txt’, array($this, ‘reset_robots_txt’, 99, 2);
}

public function reset_robots_txt($output, $public)
{
$output = “User-agent: \n”; if (‘0’ == $public ) { $output .= “Disallow: /\nDisallow: /\nDisallow: /*?\n”;
} else {
$output .= “Disallow: /wp-admin/\nAllow: /wp-admin/admin-ajax.php\n”;
}
return $output;
}

Thanks,

If I comment this function, I get two sitemap entries in the robots.txt: yours and the one from WP.

But WP one can be disabled using wp_sitemaps_enabled filter. I see there is some code just before the function to disable it but it doesn’t work 100%. So I continued to debug…

The WP sitemap entry is added by a robots_txt filter added by a method init of a core class wp-includes\sitemaps\class-wp-sitemaps.php Before adding this filter, the method checks if WP sitemap is enabled and calls the filter wp_sitemap_enabled

This code is probably called before yours because it returns true for me even if your plugin added a _return_false filter on wp_sitemap_enabled in enabled method of class ./google-sitemap-generator/class-googlesitemapgeneratorloader.php .. which would explain the WP Sitemap entry is still added.

This WP_Sitemap class is instantiated by a core function wp_sitemaps_get_server hooked on the init action with priority 10 in wp-includes\default-filters.php

I then discovered your enable method of class ./google-sitemap-generator/class-googlesitemapgeneratorloader.php is registered on init with priority 15… end of the game, it’s too late.

To be safe, I commented your code reseting the robots_txt output and I changed priority 15 to 9 for init action so I’m sure your plugin executes enable method before WP instantiate WP_Sitemap class and it solved the problem.

• This reply was modified 10 months, 3 weeks ago by tristanleboss.

Ok, le souci est le même : les serveurs de test Mondial Relay ne se comportent pas comme les serveurs de production.

Sur le serveur de test, le webservice ne vérifie pas que la longueur est un integer… alors qu’il vérifie sur le serveur de production.

De toute fa?on, pour être conforme à la documentation, 1) il faut additionner longueur + hauteur + profondeur, 2) il faut fournir un integer donc le plugin doit être modifié pour faire un round ou un ceil.

TROUVé !

Vous utilisez les identifiants de test (BDTEST13) pour vos développements / tests….

Malheureusement, le webservice ne se comporte pas de la même fa?on que les serveurs de production ! Quelle merde de la part de Mondial Relay !

Je viens de tester exactement la même requête avec SOAP UI en changeant seulement les paramètres Enseigne et Security et, en effet, les points relais ne sont pas exactement les mêmes et surtout, j’ai bien les ‘0000’ => https://ibb.co/4VCRvsW

Bon, du coup, suffit de changer les === '0000' par des === '0000' || === '' pour que le plugin fonctionne aussi bien avec les identifiants de test que des identifiants de production.

?a doit être exactement le même soucis avec l’histoire de la longueur avec des décimales… le webservice de test doit pas checker que c’est un integer alors que sur la production la vérification doit être faite.

• This reply was modified 2 years, 10 months ago by tristanleboss.

Question bête mais vous utilisez des identifiants de PROD pour vos tests ? Si ?a se prouve, leurs identifiants de tests ne tombent pas sur les mêmes versions que les versions de PROD.

Pour être bien certain, j’ai même retesté avec le logiciel SoapUI en utilisant exactement les mêmes paramètres que le plugin et je n’ai pas les zéros… https://ibb.co/SKJ3hhW

Je vois vraiment pas pourquoi vous les auriez… à part que les identifiants conditionneraient une version du webservice.

Après, moi, je ne comprends pas la documentation comme vous. Pour moi, “Tableau de chaines de caractères de dimension 4” veut dire que le tableau a une dimension de 4 (ce qui est le cas) et ils ne donnent aucune info sur le contenu réel des chaines de caractères. D’ailleurs, on parle plus de dimension pour un tableau et de longueur pour une chaine de caractères.

Je vais essayer d’avoir des infos auprès de Mondial Relay car bon, ?a rend le plugin inutilisable pour moi et, probablement, pour d’autres.

• This reply was modified 2 years, 10 months ago by tristanleboss.
• This reply was modified 2 years, 10 months ago by tristanleboss.

Oui, lisez ma réponse à mon autre post et faites le test… on sera fixé ?? Si vous avez un retour API avec les fameux ‘0000’ (seule possibilité pour que votre code marche chez vous), c’est qu’on a un retour de l’API différent tous les 2.

Idem pour cette histoire de Longueur qui ne retourne pas d’erreur chez vous alors que moi, j’ai une erreur 21… qui disparait dès que j’enlève le “.3”.

L’hypothèse la plus probable semble qu’on ne tombe pas sur la même version / machine WebService Mondial Relay en fonction des identifiants car le code qui marche pour vous ne peut absolument pas marcher pour moi. Mon compte a été créé récemment mais n’a rien de spécial… c’est le compte de base.

• This reply was modified 2 years, 10 months ago by tristanleboss.

Le problème est assez fantastique.

J’ai modifié l’appel au SOAPClient dans la méthode get_pickup_point du fichier inc\admin\classes\mondial_relay\mondial_relay_api_helper.php pour pouvoir utiliser les fonctions de débogage du SOAPClient et je ne vois absolument pas comment le code du plugin qui affiche les horaires peut marcher avec le retour de l’API.

Dans le retour brut XML de l’API, j’ai bien <Horaires_Lundi><string /><string /><string /><string /></Horaires_Lundi><Horaires_Mardi><string>1000</string><string>1800</string><string /><string /></Horaires_Mardi> qui implique bien, que dans l’objet PHP, j’ai des chaines de caractères vides et non une série de 4 zéros comme l’attend le code qui affiche les horaires.

Ce code, dans la méthode get_pickup_point du fichier inc/front/pickup/mondial_relay/mondial_relay_pickup_widget.php, ne laisse aucune ambigu?té : il attend bien ‘0000’ soit dans l’index 1, soit dans l’index 3, il y a même une égalité stricte. C’est bien ?a qui va permettre de faire disparaitre un jour (continue) s’il n’a aucun horaire ou une plage horaire (if) si elle est vide.

 foreach ($days as $day_num => $one_day) {
                if ('0000' === $one_pickup->$one_day->string['1']) continue;

                if ('0000' === $one_pickup->$one_day->string['3']) {
                    $additional_pickup['opening_time'][] = wms_display_value(substr_replace($one_pickup->$one_day->string['0'], ':', 2, 0).' - '.substr_replace($one_pickup->$one_day->string['1'], ':', 2, 0));
                } else {
                    $additional_pickup['opening_time'][] = wms_display_value(substr_replace($one_pickup->$one_day->string['0'], ':', 2, 0).'-'.substr_replace($one_pickup->$one_day->string['1'], ':', 2, 0).' - '.substr_replace($one_pickup->$one_day->string['2'], ':', 2, 0).'-'.substr_replace($one_pickup->$one_day->string['3'], ':', 2, 0));
                }
            }

Avez-vous la même chose ? Si vous avez bien des <string>0000</string> au lieu de mes <string /> c’est que l’API se comporte différement selon les identifiants…

Paramètres envoyés (en plus de Enseigne et Security) :

["Pays"]=>
  string(2) "FR"
  ["Ville"]=>
  string(0) ""
  ["CP"]=>
  string(5) "69003"
  ["Poids"]=>
  string(3) "100"
  ["NombreResultats"]=>
  string(2) "10"

Voici le code dirty pour récupérer toutes les données brutes :

$client = new SoapClient(self::API_URL, array('trace' => 1));
$result = $client->WSI4_PointRelais_Recherche($params);

echo "====== REQUEST HEADERS =====" . PHP_EOL;
var_dump($client->__getLastRequestHeaders());
echo "========= REQUEST ==========" . PHP_EOL;
var_dump($client->__getLastRequest());
echo "========= RESPONSE HEADERS =========" . PHP_EOL;
var_dump($client->__getLastResponseHeaders());
echo "========= RESPONSE =========" . PHP_EOL;
var_dump($client->__getLastResponse());
echo "========= RESPONSE OBJECT =========" . PHP_EOL;
var_dump($result->WSI4_PointRelais_RechercheResult);
var_dump($params, phpversion());
die;

• This reply was modified 2 years, 10 months ago by tristanleboss.

Je ne re?ois plus vos mails sur mon adresse protonmail.com depuis un certain temps (pas dans mes spams non plus).

Intéressant que le problème ne soit pas reproductible chez vous. J’ai bien la dernière version 1.8.6

Le point d’entrée est pourtant le même dans les 2 cas vu qu’il est en dur dans le plugin… Peut-être que la version de PHP et donc du SoapClient utilisé pour les appels API Mondial Relay a un impact sur le résultat… Ou alors, ce sont les identifiants qui font différer la version de l’API chez eux mais le compte Mondial Relay que j’utilise est un compte des plus banals mais très récents.

Parceque, concrètement, il n’y a pas mille possibilités pour que je ne re?oive les ‘0000’… Idem pour le problème de la profondeur avec décimale.

Bon, le service technique Mondial Relay vient de me répondre.

Question :

Bonjour,

J'ai une question technique concernant l'utilisation du webservice. La documentation de <code>WSI2_CreationEtiquette</code>, page 22, indique que la donnée <code>Longueur</code> est la "longueur développée". De quoi s'agit-il ? Est-ce juste la longueur du plus long c?té d'un paquet (profondeur OU largeur OU longueur) ? Est-ce la somme de tous les c?tés d'un paquet (profondeur + longueur + largeur) ?

Merci de transmettre au service concernée ou de m'indiquer comment contacter un technicien. Cordialement,

Réponse :

Bonjour Monsieur XX, 

Je vous remercie pour votre demande. En effet, il s’agit du développé du colis qui doit être en CM , soit la Longueur + largeur + hauteur.

Je reste à votre disposition pour toutes demandes. 

Bien cordialement.

Donc, soit virer l’envoi de la Longueur soit la corriger car, en l’état, ?a n’est absolument pas correct.

Après, le plugin Prestashop officiel (le seul téléchargeable gratuitement sur leur site : https://www.mondialrelay.fr/solutionspro/documentation-technique/documentation-techniquemodules/) n’envoie carrément pas la Longueur vu que c’est, d’après la documentation, un champ facultatif…

La dernière documentation du webservice disponible sur le site de Mondial Relay ( https://www.mondialrelay.fr/media/123335/solution-web-service-v572.pdf ) précise pourtant, page 22, que la donnée Longueur doit être “3 caractères numériques” et donne même une expression régulière pour valider “^[0-9]{0,3}$”.

Moi, si je mets Profondeur = 18.3 dans le formulaire et que je soumets, je me retrouve avec ["Longueur"]=> float(18.3) dans le tableau $mondial_relay_label_class->payload au sein de la fonction register_parcels_from_order et le retour de l’API Mondial Relay qui est dans la variable $api_result est bien ["STAT"]=> string(2) "21" qui correspond bien à un problème avec la taille. Ce qui parait pas illogique vu que le plugin envoie un float alors que leur API s’attend à un integer.

Du coup, il y a bien un problème voire même deux. En effet, la documentation n’est pas hyper claire et ne donne aucun exemple mais la “longueur développée” dont il parle dans la documentation, pourrait être la somme “profondeur + hauteur + largeur” (je vais demander à leur équipe technique). Or, là, le plugin prend juste la profondeur (fonction with_packages dans inc/admin/classes/mondial_relay/mondial_relay_label.php qui n’additionne que les index length des éléments du tableau $parcels_dimensions). Ce qui ne serait pas incohérent si l’on considère qu’un des critères pour pouvoir envoyer un colis Mondial Relay est que la somme des 3 soit inférieure à 150 cm comme on le voit sur le petit schéma de la rubrique Je saisis le poids de mon colis de la page suivante : https://www.mondialrelay.fr/envoi-de-colis/

EDIT: Le développée est bien la somme “longueur + largeur + hauteur” comme indiqué sur leur site ici https://www.mondialrelay.fr/faq-pro/envoyer-un-colis/quelle-est-la-taille-maximale-pour-envoyer-un-colis/ et dans les CGV https://www.mondialrelay.fr/envoi-de-colis/conditions-generales-de-vente/#:~:text=%2D%20Dimensions%20maximales%20%3A%20le%20d%C3%A9velopp%C3%A9%20(,Dimensions%20minimales%3A%2015cm%20x%2010cm.

• This reply was modified 2 years, 10 months ago by tristanleboss.
• This reply was modified 2 years, 10 months ago by tristanleboss.
• This reply was modified 2 years, 10 months ago by tristanleboss.

C’est le code dans inc/front/pickup/mondial_relay/mondial_relay_pickup_widget.php au sein de la fonction get_pickup_point qui n’est pas bon.

Apparemment, dans le foreach le code s’attend à avoir des ‘0000’ dans les index [‘1’] et [‘3’] du tableau string mais ?a n’arrive jamais. Si je fais un bon vieux var_dump de la variable $one_pickup, j’ai juste des variables vides quand le point relais n’est pas ouvert.

["Horaires_Lundi"]=>
  object(stdClass)#41709 (1) {
    ["string"]=>
    array(4) {
      [0]=>
      string(0) ""
      [1]=>
      string(0) ""
      [2]=>
      string(0) ""
      [3]=>
      string(0) ""
    }
  }
  ["Horaires_Mardi"]=>
  object(stdClass)#41708 (1) {
    ["string"]=>
    array(4) {
      [0]=>
      string(4) "1000"
      [1]=>
      string(4) "1800"
      [2]=>
      string(0) ""
      [3]=>
      string(0) ""
    }
  }