I have recently started working on nop commerce 4.2 version.
I have added FedEx plugin for the shipping. refer the following link
https://www.nopcommerce.com/shipping-plugin-for-fedex
while calling the rate service I am getting "Rating is temporarily unavailable, please try again later." error
My App Rate service URL is https://wsbeta.fedex.com:443/web-services/rate
Please help me with a solution.
Thanks in advance.
First, you need to figure out if the response comes from FedEx or generated by the plugin. You need to intercept the communications between the plugin and FedEx. One of the recording proxies should help (f.ex. Fiddler).
Then review is request and response trying to figure out who's wrong. Wrong credentials? Request data? Or maybe the FexEx service is truly down and nobody mans it due to the COVID.
Related
I'm getting this error in the Query monitor. Because of this error, the WordPress admin panel speed has been reduced. Please tell me how to fix this?
I'm using the Google Cloud and Litespeed server. The API is working correctly but maybe it's a hosting problem.
Just tried to check several settings with woo-commerce and Query monitor, this issue is possible due to the network latency. If your server is in the Asia region, the curl timeout happens easily. If we launch the server in the US region, no timeout issue.
Since 1000 milliseconds = 1 second is quite short, you might want to try the following method that I found from the Google search to avoid such issue, hope this helps.
https://kb.mailpoet.com/article/311-curl-issue-28-timeout
https://gist.github.com/sudar/4945588
I'm having an issue with an Analytics API batch request that I am doing, it was working and now it isn't without me changing anything. I know Google are making changes to their batch endpoints and I believe this is what is causing my errors.
https://developers.googleblog.com/2018/03/discontinuing-support-for-json-rpc-and.html
I am using the .NET client library with the AnalyticsService. Having read through the link above I'm fairly certain I've done what is needed for my batching to continue to work.
Here is a screenshot of the .NET instructions
I've upgraded all Google libraries to the latest versions, I've checked the AnalyticsService object and can confirm the BatchURI is no longer the Global HTTP Batch endpoint www.googleapis.com/batch, it is showing as https://www.googleapis.com/batch/analytics/v3, but I am still getting 400 Bad Requests. Is there something else that I am missing, or do I have to wait until the 12th of August when Google say the switch will be complete?
Thanks
Update: I created an issue on GitHub, apparently it is an internal issue, currently waiting for a fix, see here to keep updated:
GitHub Issue on .NET client library
I'm using WooCommerce Authorize.net AIM Gateway in WP 4.0.1
it doesn’t tell specifically what the error is. Instead it gives you a generic “An error occurred…” error and the user doesn’t know for sure what is wrong and what to re-enter.
OR
An error occurred, please try again or try an alternate form of payment
But not telling the actual cause of error.
We have contacted WooCommerce and the vendor SkyVerge and asked about this. SkyVerge said they are working on a new version that does a better job with this. But, those changes are at least a month away.
So I want to grab the response code that Authorize.net returns and show the proper message to end users.
Like here Authorize.net is returning.
Is there a way to set up Alfresco to send email to admins on each server error as in Python Django Error reporting via e-mail?
Thanks in advance for any hint.
The first thing I would say is that you need to really look in to the viability of using e-mails to help admins spot problems with servers. Sending an e-mail can be a heavy operation and as such, particularly with many repeated errors, can make an existing problem worse. And what about the cases where the ability to send e-mails goes down or a problem so severe happens that it simply cannot send e-mails?
For properly setting up reporting on your servers you might want to look at Logstash + Kibana:
http://alfresco.blog.redpill-linpro.com/2014/07/01/alfresco-logging-with-logstash-and-kibana-part-1-the-basics/
That being said, it should be possible to configure log4j to use an SMTP appender if that is the route you want to go down:
What is the proper way to configure SMTPAppender in log4j?
In Alfresco 4.2 you should need to add something such as the following to the log4j.properties in tomcat/webapps/alfresco/WEB_INF/classes/:
#CONFIGURE SMTP
log4j.appender.email=org.apache.log4j.net.SMTPAppender
log4j.appender.email.SMTPHost=mail.mydomain.com
log4j.appender.email.SMTPUsername=myuser#mydomain.com
log4j.appender.email.SMTPPassword=mypw
log4j.appender.email.From=myuser#mydomain.com
log4j.appender.email.BufferSize=1
log4j.appender.email.EvaluatorClass=TriggerLogEvent
log4j.appender.email.layout=org.apache.log4j.PatternLayout
log4j.appender.email.layout.ConversionPattern=%m
We’re running into an issue sending duplicate notifications to our users using the Notifications module on our Mercury Pressflow implementation. The duplicate messages are identical save one thing- the [node-url] token is being replaced with ‘default’ in one of the messages. All the other tokens in the message are being replaced correctly.
The duplicate emails do not happen consistently, maybe 10-15% of the notifications sent out, however a duplicate message always has the proper url & the ‘default’ url.
The only major modification we’ve made to Mercury was spinning off MySQL to it’s own server and adding replication. We currently have the reads set up to round robin between the 2 MySQL instances.
I have done the following troubleshooting based on finding similar issues
made sure the cron job is calling the correct url
replaced all configurations named ‘default’ with the site name (Memcached, Varnish, and Apache configs)
disabled caching in an init_hook in the notifications module
Has anyone out there experienced anything similar with Notifications and Mercury? Any and all advice is greatly appreciated.
The "Mercury" stack is external to Drupal and doesn't affect how email is queued or sent. Something within your messaging/notifications configuration or use is causing multiple messages to be created.
If you have any custom code here, I would look at that and try to trace the token variance.