Conversation
supportHi, I opened a bug in GitHub but have not seen a response yet and would love to get this issue resolved whether it’s user error or something else. I have no access to generating Google API keys for my customer but have tested with another plugin where the Google API Key worked successfully. https://github.com/sofyansitorus/WooCommerce-Shipping-Distance-Matrix/issues/108 Thanks Deirdra
Hi Deirdra, Thanks for reporting this, and sorry for the frustration here. Based on what you described, the most likely cause is that the Google API key passes in another plugin but does not meet WooReer’s specific requirement for the Google Routes API . In other words, a key can still work elsewhere for Maps/Geocoding/Places, but WooReer needs the Routes API enabled and billing active for validation to succeed. I have tried several common validation cases below: Routes API is not enabled Billing is not enabled on the Google Cloud project The API key is invalid The API key field is empty The API key has an IP address restriction The API key has an application restriction All of them are outputting the following error messages: Routes API not enabled Distance Calculator API » Routes API has not been used in project ... before or it is disabled ... Check the log for more details. Billing not enabled Distance Calculator API » This API method requires billing to be enabled ... Check the log for more details. Invalid key Distance Calculator API » API key not valid. Please pass a valid API key » Check the log for more details. Empty key Distance Calculator API » API Key field is required IP address restriction Distance Calculator API » The provided API key has an IP address restriction. The originating IP address of the call (xxx.xxx.xxx.xxx) violates this restriction » Check the log for more details. Application restriction Distance Calculator API » Requests to this API routes.googleapis.com method google.maps.routing.v2.Routes.ComputeRoutes are blocked » Check the log for more details. Please try the following 1. Confirm the API provider Make sure the provider used in WooReer is Google Maps Routes API . 2. Verify the Google Cloud setup In the client’s Google Cloud project, confirm: Routes API is enabled Billing is enabled The key is from the same project If Routes API or billing was just enabled, wait a few minutes and test again. 3. Check API key restrictions If the key has restrictions, please verify they are not blocking the request. In particular, check: Application restrictions API restrictions A key that works in another plugin may still be restricted in a way that prevents WooReer’s request from succeeding. 4. Enable WooReer logging and check the log output Please enable logging in WooReer, then try saving the key again. The log should usually contain the exact Google response, which will tell us whether this is: missing Routes API missing billing invalid key restriction-related 5. Test with a fresh API key if possible If the client can create another key in the same project with Routes API enabled and billing active , that would be a very useful comparison test. Important note Unfortunately, I can’t ask you to share the actual API key or site access in the public forum . So if the issue is specific to that one key/project, my ability to fully verify it here is limited. If you can’t generate a new key yourself, the best next step would be to ask the client to verify the Google Cloud configuration above, especially: Routes API enabled Billing enabled Key restrictions Project consistency For now, my best assessment is that this is most likely a Google Cloud/API configuration issue rather than a random save failure , though if you’re not seeing any admin notice at all, there may also be a UI/feedback bug worth investigating further. Best Regards, Sofyan
Additional evidence for the settings save bug: Confirmed the database only ever contains the manual test value, never anything saved from the UI: wp option get woocommerce_wcsdm_6_settings {"api_key":"test123"} Confirmed the API key itself is valid and working correctly from the server: curl -X POST -d '{ "origin":{"address": "1600 Amphitheatre Parkway, Mountain View, CA"}, "destination":{"address": "450 Serra Mall, Stanford, CA"} }' \ -H 'Content-Type: application/json' \ -H 'X-Goog-Api-Key: AIza********************' \ -H 'X-Goog-FieldMask: routes.duration,routes.distanceMeters' \ 'https://routes.googleapis.com/directions/v2:computeRoutes' Response: { "routes": [ { "distanceMeters": 10737, "duration": "1069s" } ] } I don’t believe the API key and server configuration are the issue — settings simply never write to the database from the UI regardless of what is entered and no log created on save. This reply was modified 2 months, 2 weeks ago by dstrangio .
Hi Deirdra, Thank you for the additional details, that is very helpful. Your latest test does suggest this may not be a Google API key issue after all. Since the API key works correctly in a direct request to the Google Routes API , and the database only reflects the manually inserted value, this points more toward a settings save issue in the shipping method instance UI rather than API validation itself. To help narrow that down, could you please check the following: 1. When you click Save, do you see the WooCommerce admin notice: “Your settings have been saved.” If yes , that would suggest the save request is completing, but the WooReer settings may not actually be persisting to the database. If no , that would point more toward the save flow itself not completing properly. 2. Are you able to create a brand new WooReer shipping method instance in the shipping zone and save it using the same API key ? If yes , that would suggest the problem may be specific to the existing instance/settings record. If no , and the new instance also fails to save, that would point more strongly to a general UI/settings save bug. If possible, it would also help to know whether there are any JavaScript console errors in the browser when clicking Save, or any relevant messages in the Network tab for the save request. If the request completes but the option is not updated, that would help isolate whether the issue is happening in the form submission, sanitization, or settings update stage. Since sharing site access or the actual API key is not appropriate on the public forum, I can’t directly inspect the environment from here, but your findings are enough to justify treating this as a potential save/persistence bug . If you can confirm whether a new instance behaves the same way, that would be the most useful next data point. Thanks again for the detailed testing. This reply was modified 2 months, 2 weeks ago by Sofyan Sitorus .
1 – No Admin message banner, just the WooReer Save button at the bottom of the fields is “Disabled” 2 – No, the new shipping method exhibits the same issue I don’t see any JS console errors or anything unusual in the Network tab (but that could be my eyes glazing over LOL) I do have a 14 MB HAR file for the Save action if that would help you (saved to my Google Drive) https://drive.google.com/file/d/1NBP0YDiCoab3HofeNnUtXKwMlvdRbe6Q/view?usp=sharing
Hi Deirdra, Thanks for reporting this, and sorry for the frustration here. Based on what you described, the most likely cause is that the Google API key passes in another plugin but does not meet WooReer’s specific requirement for the Google Routes API . In other words, a key can still work elsewhere for Maps/Geocoding/Places, but WooReer needs the Routes API enabled and billing active for validation to succeed. I have tried several common validation cases below: Routes API is not enabled Billing is not enabled on the Google Cloud project The API key is invalid The API key field is empty The API key has an IP address restriction The API key has an application restriction All of them are outputting the following error messages: Routes API not enabled Distance Calculator API » Routes API has not been used in project ... before or it is disabled ... Check the log for more details. Billing not enabled Distance Calculator API » This API method requires billing to be enabled ... Check the log for more details. Invalid key Distance Calculator API » API key not valid. Please pass a valid API key » Check the log for more details. Empty key Distance Calculator API » API Key field is required IP address restriction Distance Calculator API » The provided API key has an IP address restriction. The originating IP address of the call (xxx.xxx.xxx.xxx) violates this restriction » Check the log for more details. Application restriction Distance Calculator API » Requests to this API routes.googleapis.com method google.maps.routing.v2.Routes.ComputeRoutes are blocked » Check the log for more details. Please try the following 1. Confirm the API provider Make sure the provider used in WooReer is Google Maps Routes API . 2. Verify the Google Cloud setup In the client’s Google Cloud project, confirm: Routes API is enabled Billing is enabled The key is from the same project If Routes API or billing was just enabled, wait a few minutes and test again. 3. Check API key restrictions If the key has restrictions, please verify they are not blocking the request. In particular, check: Application restrictions API restrictions A key that works in another plugin may still be restricted in a way that prevents WooReer’s request from succeeding. 4. Enable WooReer logging and check the log output Please enable logging in WooReer, then try saving the key again. The log should usually contain the exact Google response, which will tell us whether this is: missing Routes API missing billing invalid key restriction-related 5. Test with a fresh API key if possible If the client can create another key in the same project with Routes API enabled and billing active , that would be a very useful comparison test. Important note Unfortunately, I can’t ask you to share the actual API key or site access in the public forum . So if the issue is specific to that one key/project, my ability to fully verify it here is limited. If you can’t generate a new key yourself, the best next step would be t...
Additional evidence for the settings save bug: Confirmed the database only ever contains the manual test value, never anything saved from the UI: wp option get woocommerce_wcsdm_6_settings {"api_key":"test123"} Confirmed the API key itself is valid and working correctly from the server: curl -X POST -d '{ "origin":{"address": "1600 Amphitheatre Parkway, Mountain View, CA"}, "destination":{"address": "450 Serra Mall, Stanford, CA"} }' \ -H 'Content-Type: application/json' \ -H 'X-Goog-Api-Key: AIza********************' \ -H 'X-Goog-FieldMask: routes.duration,routes.distanceMeters' \ 'https://routes.googleapis.com/directions/v2:computeRoutes' Response: { "routes": [ { "distanceMeters": 10737, "duration": "1069s" } ] } I don’t believe the API key and server configuration are the issue — settings simply never write to the database from the UI regardless of what is entered and no log created on save. This reply was modified 2 months, 2 weeks ago by dstrangio .
Hi Deirdra, Thank you for the additional details, that is very helpful. Your latest test does suggest this may not be a Google API key issue after all. Since the API key works correctly in a direct request to the Google Routes API , and the database only reflects the manually inserted value, this points more toward a settings save issue in the shipping method instance UI rather than API validation itself. To help narrow that down, could you please check the following: 1. When you click Save, do you see the WooCommerce admin notice: “Your settings have been saved.” If yes , that would suggest the save request is completing, but the WooReer settings may not actually be persisting to the database. If no , that would point more toward the save flow itself not completing properly. 2. Are you able to create a brand new WooReer shipping method instance in the shipping zone and save it using the same API key ? If yes , that would suggest the problem may be specific to the existing instance/settings record. If no , and the new instance also fails to save, that would point more strongly to a general UI/settings save bug. If possible, it would also help to know whether there are any JavaScript console errors in the browser when clicking Save, or any relevant messages in the Network tab for the save request. If the request completes but the option is not updated, that would help isolate whether the issue is happening in the form submission, sanitization, or settings update stage. Since sharing site access or the actual API key is not appropriate on the public forum, I can’t directly inspect the environment from here, but your findings are enough to justify treating this as a potential save/persistence bug . If you can confirm whether a new instance behaves the same way, that would be the most useful next data point. Thanks again for the detailed testing. This reply was modified 2 months, 2 weeks ago by Sofyan Sitorus .
1 – No Admin message banner, just the WooReer Save button at the bottom of the fields is “Disabled” 2 – No, the new shipping method exhibits the same issue I don’t see any JS console errors or anything unusual in the Network tab (but that could be my eyes glazing over LOL) I do have a 14 MB HAR file for the Save action if that would help you (saved to my Google Drive) https://drive.google.com/file/d/1NBP0YDiCoab3HofeNnUtXKwMlvdRbe6Q/view?usp=sharing