Jump to content

awmawm

Members
  • Posts

    36
  • Joined

  • Last visited

1 Follower

Profile Information

  • Activity
    User/Merchant

awmawm's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I am posting this as a new topic because another topic I posted a message is flagged as "SOLVED" even though it is not for me and at least another user. Problem: Despite having Prestashop installed in the local language (German) and the default language set as German, PayPal Express Checkout is in English for local buyers with computer language set to German. This is causing potential buyers to abandon the cart. As it was suggested in some previous threads about this topic, I attempted unsuccessfully various ways to force PayPal to open in German; this is one of the threads: http://www.prestashop.com/forums/topic/233060-paypal-express-checkout-in-wrong-language/ I attempted to resolve the situation with PayPal directly but they tell me that they do not support code from third parties and referred me to the Prestashop forum. One hint they gave me was the following: ============================================ Action to take: Add a LC Variable: ---------------------------------------------- e.g. <input type="hidden" name="lc" value="xx_XX"> ---------------------------------------- allowed: en_US en_GB fr_XC ja_JP pt_BR tr_TR da_DK es_XC he_IL nl_NL ru_RU xp_EA de_DE fr_CA id_ID no_NO sv_SE zh_CN en_AU fr_FR it_IT pl_PL th_TH zh_HK ============================================= Hence, my questions are: - In which file and on what line do we need to add above "LC variable"? - Who is the person in charge at Prestashop for the European PayPal Module 3.6.1. (he/she might shed some light on this very problematic situation.
  2. PayPal tells me that they cannot support codes from third parties... All they gave me is the message to add the "LC variable" as follows: ============================================ LC Variable: ---------------------------------------------- e.g. <input type="hidden" name="lc" value="xx_XX"> ---------------------------------------- allowed: en_US en_GB fr_XC ja_JP pt_BR tr_TR da_DK es_XC he_IL nl_NL ru_RU xp_EA de_DE fr_CA id_ID no_NO sv_SE zh_CN en_AU fr_FR it_IT pl_PL th_TH zh_HK ============================================= Countries and Regions Supported by PayPal https://developer.paypal.com/webapps/developer/docs/classic/api/country_codes/ So, my question is, in WHICH file and on WHAT line should we add above code? Also, who within Prestashop is in charge for the PayPal Module 3.6.1.? Since PayPal does not support third party code, that person may be the only one who could shed some light on this very problematic situation.
  3. Same issue here with PS 1.5.6.0. and PayPal module 3.6.1. Attempted to change default country in paypal/paypal.php and paypal/express_checkout/process.php as suggested in other posts on this forum but nothing works. Local customers are still greeted by PayPal in English which increases the risk of cart abandonment. I wrote to PayPal a number of times but they link back to past suggestions on this forum...
  4. @Dolke: Sorry to hear that. Has a2hosting assisted you with the restoring of your own cPanel backup and are they able to tell you why you receive the 500 error? Could it be that they changed some settings on the restored server that are no longer compatible with your backup?
  5. @Xavier: Thanks. @Pascal: After they told me that it will take "1 hour or so" to get the SQL server back up and running and it was still down 12 hours later (48 hours of ongoing outage) with support telling me that they do not have an ETA anylonger, I decided to migrate to another server (still with a2hosting to avoid any DNS/redirecting issues for a few hours). Hence, at this point I do not know whether they are fully up and running with the Iceland server but based on what Dolke and others were mentioning in other threads, it appears that they still have some trouble with SQL.
  6. So much about bringing MySQL back online "within the next hour or so" (that was 8 1/2 hours ago when they sent me an email). As of now, neither email nor Prestashop installation are working... 45+ hours plus outage and still counting... The level of incompetence at a2hosting is mind blowing...
  7. @Dh42 I fully understand that Prestashop has no control over the hosting providers but I think this event should give Prestashop second thoughts about recommending a2hosting going forward. I also understand that hardware failures happen but forgetting for 16 days to check whether data is backed up has nothing to do with that and one has to wonder what else they are missing. It would not surprise me if the time of this outage was extended because a2hosting was erratically running around looking for a more recent backup...
  8. @Pascal This is what I just got from a2hosting: "We apologize greatly. The backup the engineers had to restore to was November 8th. Unfortunately the data after that point is unrecoverable. We will be publishing a formal report on Sunday, 11/24 to our customers. Our engineers are currently still working to bring MySQL back online. That will be up within the next hour or so. Thank you for your understanding," So, they obviously forgot to check for 16 days that their greatly advertised "Server Rewind" feature is actually working. I have a 2-day old SQL backup but two days of building the website with a custom theme and translation is gone. Since we go live by next Tuesday, I will have 5 days of no sleep ahead of me... At least our shop was not live but I am sure other Prestashop owners who operate from that server have been loosing quite some data (besides 36+ hours of zero sales).
  9. Well, whatever amount of data they had to backup, I just learned that they restored the server from the most recent backup which is 16 days old!
  10. 35 hours downtime and still counting.... And I just learned that the latest backup they did is 16 days old.... And this is one of the hosting providers Prestashop formally recommends! Unbelievable!
  11. We started our hosting with a2hosting on the Iceland server (that is down now for 35 hours and still counting) on November 7th. We have been building our Prestashop since then with the plan to go live early next week. They now were able to restart the server but still have database issues which means that one could not install a new Prestashop database. But the most ridiculous piece of the whole story? The last backup they loaded for us dates back to November 8th, a full 16 days! Luckily I have a more recent sql database but there is still 2 days of work lost. For some of you who do not have a more recent sql backup, it might be even worse... 35 hours downtime and still counting.... 16 days without any backup.... And this is one of the hosting providers Prestashop formally recommends! Unbelievable!
  12. @Dh42 Thanks for your feedback. Some good suggestions! In respect to scenario #2, are you telling us that it is common for hosting providers like a2hosting to use single controller RAID setups for shared hosting? That would absolutely shock me. Also, in terms of time it takes to restore data, what is the typical amount of data that sits on one shared hosting server before it becomes too much to handle (particularly during a disaster like we have been experiencing with a2hosting over the last 2 days)? The tech support person from a2hosting told me earlier today that they have hundreds of TBs to restore...
  13. 11/23/2013 6:00pm EST - Data is still being copied back over to the server. We believe we should have most of the data restored within the next couple of hours if it continues at the current rate. 4 hours later, it is still down... And what exactly do they mean with "most"? Not helpful at all.
  14. @Dh42 For a truly critical (high volume site), I doubt that uploading a backup to a different server and then redirecting it will be the solution since the DNS propagation will take time (even if it is just a few hours, it is still too long for a high volume site). If sales volume justifies the cost and down time must be limited to minutes and not hours, a mirror on a separate server in a different location is the only true redundancy, imho. I also fully understand that a complete restore from a backup will take time. My concern is, however, that there seemingly was a complete failure and data loss in the RAID 10. Technical support told me that they attempted to restart the server and lost all data during that process so it seems to me that the technicians in charge did not follow proper procedures to protect the data before restarting the server.
×
×
  • Create New...