I am using Sugar crm and i am new to this . I am trying to sync my leads with pardot . But the problem is when i add a prospects in pardot it is automatically added to the CRM . But if i am adding a lead from Sugar crm it is not adding to pardot . I don't know how to check the errors behind this .
what i have done till now .
1) Added a connector (Sugar Crm) in my pardot account . Followed this link
2) added pardot connector module in sugar crm by this link
3) Connector setting in Pardot is
When i am adding a record from crm the field pi_is_queued_c in tabel leads_cstm is always 1 while for the records added from pardot is 0
please help me to solve this issue .
There are a couple things you can try:
Make sure you have version 24 or higher of Pardot's Sugar plugin
Check to see if any field updates you make in your CRM are syncing over to Pardot. If not, there might be a problem with the permissions in the CRM
If all that looks good, then try contacting Pardot support. It could be a bug within the connector.
Related
I know there's an earlier question with this subject here, but the OP never reported if the one answer resolved the issue. And since
Internal Server Error
is about as user-unfriendly as you can get, I would love to change this to something that feels more like "a message" than "an anvil dropped on your foot".
I have found one other SO post that tangentially relates to this issue (about that disappearing "duplicate emails" switch), but the problem is indeed not about whether or not to allow duplicate emails (or how to revive hidden admin controls) but how a very ordinary issue is communicated to the user - well, like how Keycloak notifies the user when they try and register with an existing username.
We're currently using the Docker version of Keycloak 12.0.4 with some customisations (a custom BCrypt module, some logging changes) running in IBM Cloud, using a Postgresql DB. We also added a custom theme & internationalisation. The same error occurs also when using the default Keycloak theme, though.
Here are our Login settings:
It turned out to be a configuration issue, but so deeply hidden that even the Keycloak developer who looked into the ticket I created had glossed over it.
The perpetrator was in menu Configure > Authentication > tab: Flows > choose dropdown: Registration > Profile validation radio button [o REQUIRED | o DISABLED]
This was set to disabled, which in effect prevents the duplicate email check in the registration form that the Realm settings > tab: Login form suggest are active. But then, of course, the database won't like that, with above-mentioned result.
This combination of settings should at least issue a warning, of course. I hope this will be corrected.
I have did migration from magento 1.7 to 1.9 and i have saved same database , but whene testing the result i found this url (Catalog => Manage Products) gives empty page not show grid list product.
Any Suggestions to solve this error ?
At first you need to check the error logs (PHP error log, exception.log, system.log).
I think that this problem can be caused by third party extension, which is not compatible with new Magento version.
Try to turn off all extensions which are not the Magento core modules.
My company is using zend gdata 1.11.7, relatively old, but they havent had the ability to move to newer things yet. We have a program that adds events to a google calendar based on the forms submitted by the user.
This morning, we now get the error below:
Fatal error: Uncaught exception 'Zend_Gdata_App_HttpException' with
message 'Expected response code 200, got 403< HTML>< HEAD><
TITLE>Forbidden< /HEAD>< BODY BGCOLOR="#FFFFFF"
TEXT="#000000">< H1>Forbidden< H2>Error 403< /BODY>< /HTML>
' in
/homepages/26/d119734641/htdocs/app/ZendGdata-1.11.7/ZendGdata-1.11.7/library/Zend/Gdata/App.php:709
From everything I am reading, this is an authentication issue...but I have a problem, it was built so long ago that we do not have access to the google console for the API, what else could be the problem? Did google stop supporting this way of authenticating that is used in this zend gdata?
Please help as currently I have everything happening manually from our online database to the calendar.
Found this post
Zend google Calendar access not working anymore
Seems they discontinued it....
Back in November 2011, we announced the deprecation of the Calendar GData API (v1, v2) when the APIv3 was made available. We’ll now be shutting down these older versions on November 17, 2014.
https://developers.google.com/api-client-library/php/
seems to be the way to go. Still working on replacing my Zend_GData (Zend V1 project) with this but it seems promissing.
EDIT
I can confirm i was able to migrate all my zend_Gdata to google-api-php-client-master.
I can create event, update event, delete event, i work also with extendedProperties, all is fine. I've just one concern about the OAuth and the refreshToken, i hope that i understood how it work.
/EDIT
You can't use Zend anymore to list, add, delete events. You have to use google api v3. Here is an example of class you can use to manage events: Authentification Zend Gdata (403 forbidden)
I have an issue in Expression Engine using the Champagne Extension where it won't allow me to send out campaigns. This extension utilizes https://www.campaignmonitor.com/ api to send out mass emails.
The Error I get is "HTML Content URL Required" when I try to send out campaigns form the back end of the Expression Engine Install.
What could be causing this issue that relates to the expression engine install?
This error is received anytime the URL to your html or text content is not visible. More often this is seen when someone forget to include the text version. A good way to test is to click the preview HTML/TEXT button and make sure both give you the correct results.
They cannot be blank.
For an alternative solution, be sure to checkout my add-on Postmaster. It allows clients to publish email campaigns just by creating a new entry. You can setup any number of configuration, so you can even send draft email to a test subscriber list. And since everything is within channel entries, you can use whatever fieldtypes you like, and it works with MailChimp as well as CampaignMonitor.
https://objectivehtml.com/articles/postmaster-the-definitive-email-solution-for-expressionengine
My Magento Verison is - 1.4.1.1
I am having two problems:
1) When I am going through various steps of Onepage checkout (registration, billing, shipping, and payment tabs), sometimes during this process I am redirected to the cart page. There is no error, no exception, no report gets generated in var/report. I dont know how to debug it. Aren’t there any logs I can look for?
2) In same Onepage Checkout process after clicking on place the order (last step) , some times it redirects to the cart page, sends an email saying that the order failed with the message:
Quote totals must be collected before this operation.
To resolve it I commented this line in prepareRecurringPaymentProfiles in the file magento/app/code/core/Mage/Sales/Model/Quote.php, which solved the problem:
throw new Exception("Quote totals must be collected before this operation.");
I dont know if these 2 problems are related or not. But I am not having the 2nd problem now but having 1st one quite frequent. What could be the reason and how to resolve it?
further update-I checked the firebug trace, It is 500 internal server error which comes sometimes in any of the step in one page checkout. I was able to dig down into savebillingaction, saveshippingaction functions in onepagecontroller.php and found that error comes when $this->getRequest()->isPost() is blank , If it is 1 then it goes ahead, and goes to the next step else it redirects to cart, No I dont know why this is not 1 or is it because ajax is not able to send post data but I checked XHR request, Ajax send the post data every time (checked with firebug extension). Can Someone tell me What I could do next to troubleshoot. Where I can look for these Ajax Calls?
Shipping.phtml (any step.phtml) has JS at the bottom , How does it call OnePagecontroller saveshippingaction function ?
Since it's internal server error, try to access the error log of the server. Will tell you where is the problem. I' ve had the same problem in 1.7.0. In my example the problem was at /app/code/core/Mage/Usa/Model/Shipping/Carrier/Fedex.php
For anyone else coming across the "Quote totals must be collected before this operation." error, check your Apache logs for the reason of the 500 internal server error. If it's something like this:
mod_fcgid: read data timeout in 40 seconds
Premature end of script headers: index.php
process 26126 graceful kill fail, sending SIGKILL
..PHP is taking too long to respond. Usually its the onepage/checkout saveOrder action because it's quite heavy and often needs to connect to third party services (payment gateways, newsletter services like mailchimp, etc.). These calls to third party services can take a while, depending on the network state and might be the reason of PHP timing out.
You can start by increasing the timeout, but it's not a good permanent solution because you want to find out why this is happening in the first place.
New Relic is a good tool to monitor these calls (and a good tool to monitor your Magento store in general).
Firstly, commenting an error message is almost never the way to solve a problem, as you are just covering up some issue that may have severe consequences for your system.
Nailing down errors like this can be hard, but there are a few places to look first:
Did you install this system on a lower version and then upgrade? If so, how?
Are you using any extensions that modify the sales/checkout portion of the site?
Have you overridden any of the models concerned with this part of the site?
Have you changed the JS or HTML for the checkout?
If one of those is the case, you should review those changes for bugs. If not, try turning on the default theme for the site and checking out again. If the bug disappears, there is a problem with the theme that you are using. If it still appears, the problem is in code.
In that latter case, use Firebug to verify that the offending page requests result in Magento sending back "redirect" commands to the frontend. If that isn't the case, it may be some kind of JS error, but more likely you are ending up with invalid data in the system somewhere that causes Magento to choke during checkout.
Also (just thought of this, haven't tried it), try the multi-address checkout. As I recall, it uses regular page posts, and may even have more useful messaging than the OnePage checkout. Please edit your post with your findings from the above so that we can help more if that doesn't do it.
Hope that helps!
Just in case someone gets the "Quote totals must be collected before this operation." error, and none of these solutions fixes their particular problem, I'll mention that mine was an issue with this:
skin/frontend/base/default/js/opcheckout.js
var params = Form.serialize(payment.form);
There was a JS error unique to this site which was clearing the Payment form and preventing JS from reading it's contents. The module or theme that you use will differ, but check to make sure that the payment form can serialize correctly. If not, then that could be your problem.
I had the very same problem on my store Princessly:
It takes about 20 to 130 seconds or even longer for "Submitting order information ..." to go through and redirect to the payment gateway such as PayPal, if at all, after clicking the Place Order button, last step of one page checkout.
If it doesn't go through, very probably because something timed out since it took too long, it will redirect back to shopping cart, leaving the customer an empty cart and a Pending Payment order, OR, it will give the exception of:
Quote totals must be collected before this operation.
Since obviously, well, something timed out and the script ends before quote totals are collected (which is just my theory), thus sending the Payment Transaction Failed Reminder email.
After 12 hours of research and debug, I finally found the culprit and the solution.
Magento enables RSS stock and new order notification by default, so every time Place Order is pressed ('sales/order' resources are then saved), cache is refreshed so RSS will be published. Cache cleaning can be very time-expensive for Magento. Therefore the solution is simple. Just disable RSS notification for save of 'sales/order' resources.
Find /app/code/core/Mage/Rss/etc/config.xml and locate this block:
<sales_order_item_save_after>
<observers>
<notifystock>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterNotifyStock</method>
</notifystock>
</observers>
</sales_order_item_save_after>
<sales_order_item_save_after>
<observers>
<ordernew>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterOrderNew</method>
</ordernew>
</observers>
</sales_order_item_save_after>
Simply remove or comment it out and refresh Magento cache in System => Cache Management => Select All => Submit.
Now it only takes 1 second or even less for my store to go through Place Order and redirect to payment gateway.