Extended OOB Onepage Link Block and link.phtml to disable the button based on customer group id, the changes are working but the button is disabled for all the customers, not just for the customers that are in specified group. I cleared cache many times but still no luck. I have correct entries in checkout_cart_index.xml and I do see it working but not the way it's supposed to do. Is there anything else that needs to be done to fix this issue since it prevent checkout for all the customers?
Found out hard way that it was a simple typo in the Block class name, I was using wrong Session class, where required method wasn't available. Took sometime to find this out and but it's working now. Please make sure that vendor/module, and/or other names are correct with case, otherwise it's hard to debug since we don't get meaningful errors unlike Java. I couldn't enable developer mode due to other issues which also complicated the problem.
Related
I'm attempting to do a number of things with the success page (order confirmation page) in Magento but I am faced with the nuisance of having to create a test order every time I wish to see a change because hitting refresh redirects you. The style changes are easy as I can fresh only the CSS if necessary but some of the conversion analytics (e.g. Google) and other items I'm trying to include on the final page aren't as straight forward. Is there a better way? Thanks in advance.
Magento clears session information for a customer after they place their order as it assumes most users will leave the site after that. It’s more of a user-experience feature than it is a security feature. That being the way it is, when you hit refresh on the order confirmation page, your information will disappear and Magento will generally tell you “you have no items in your cart.”
You can disable this for the purpose of development by going to app/code/core/Mage/Checkout/controllers/OnepageController.php and commenting out the line that says:
$session->clear();
Should be line 240. Change it to //$session->clear(); and Magento will instead allow the session to expire naturally according to how long session life is set to for that specific instance. Now you can style success.phtml or see what conversion information is being sent to various service providers (PepperJam, Google, Proclivity, etc..) without having to create more than 1 test order.
You could use Selenium, Firefox Add-on to record a macro for placing an order. This should avoid the repetitive process of placing an order.
https://addons.mozilla.org/en-us/firefox/addon/selenium-expert-selenium-ide/
You can also use this bookmarklet to auto-populate the fields on the checkout page.
http://www.nicksays.co.uk/auto-populate-magento-checkout-bookmarklet/
I have a Magento site using version 1.6.2.0 with which I'm experiencing problems with duplicate orders.
Having researched the subject I have found mostly forum threads explaining that 1.4.x had problems with duplicate orders and the solutions mentioned (even those on SO which I have found) merely suggest the user updates Magento to >1.4.
I have also found a proposed solution here but am reluctant to delete observers which will prevent downloadable purchases working.
I've also spotted the Array Of Death fix mentioned a few times (e.g. here) but this problem isn't present in 1.6.x, Zend appears to have resolved it.
There are a couple of Javascript hacks suggested whereby the Confirm Order button is hidden upon submission but Magento 1.6.x already does this.
I have increased the payment gateway timeout configuration variable to 120 seconds and am as yet to see if it yields results. I can't test it as the problem is intermittent (and probably therefore caused by communication or lack thereof between the payment gateway and Magento).
I am using Sagepay as the payment gateway.
How might I further debug this?
The link you posted is correct, but I wouldn't use their fix, I would just disable the Mage_Rss module.
Mage_Rss has several observers in it that call Mage::app()->cleanCache(...) in the checkout process, which is extremely expensive if your installation is using the default filesystem cache and it's gotten large.
I found the best thing for troubleshooting Magento performance problems is to wire up Xhgui and do some profiling. Reading call stacks will help your understanding of Magento immensely also.
Oh, and I don't know if this is true for Sagepay, but I went and fixed this problem completely for PayflowPro by rewriting the method that generates transaction IDs to use the quoteID instead of generating unique IDs on every invocation. I started down the path of committing this back, but I'm on 1.4.2 still and don't have time to test in later versions and it's a pretty significant rewrite. Guess I could just put it out there for someone else to run pass Moses...
Is there a risk in using #Html.Raw? It seems to me there shouldn't be. If there is a risk then wouldn't that risk already exist regardless of using #Html.Raw in that modern browsers such as Chrome will allow an edit injection of <script>malicious()</script> or even to change a form's post action to something else.
#Html.Raw will allow executing any script that is on the value to display. If you want to prevent that you need to use #Html.AttributeEncode
Correct, the risk is in how it is used. There's no risk inherent in Html.Raw. It's a tool, nothing more.
If you are displaying user entered information it is better to use #Html.Encode().
In another words, if you are displaying non-user eneterd data you are safe to go with #Html.Raw()
I'm working on a MediaWiki plugin that adds a certain captcha if users have more than three bad login attempts. I'm basing this on the existing ConfirmEdit plugin but for some reason the way they store bad login attempts doesn't seem to work for me. After checking the code they use, it seems they're using the global variable $wgMemc, which in my case appears to be an instance of FakeMemchachedClient. This is a fake memchache that just returns true on everything without even saving anything.
I'm trying to find out how to implement another way to internally keep track of the amount of bad logins, preferrably without having to consult the database for this.
The only thing I could come up with that avoids the cache entirely is POSTing the amount of bad logins, but this could easily be modified by a smart user/bot...
Anyone have any ideas?
In ideal case, $wgMemc should be instance of MemcachedPhpBagOStuff. It is actually an interface to memcached, see the MediaWiki page about it for more information and usage in MediaWiki.
For this use case it would be great choice. However, since it seems you don’t have memcached set up, the only viable alternative is probably using the database.
we are using magento with onestepcheckout module in our shopping system. But when the payment process fails and when we get an error about payment, not all but some translations fails on the checkout page.
Has anybody face this problem before. I will be very happy if there is an solution.
P.S. I can solve the situation by hard-coding the translations. But I dont want to use this method.
Thank you
When a module developer creates a module, it's up to them to make sure that each and every phrase that could be translated is marked for translation. In Magento this means
Strings in template files are passed through the ->__ method
Labels, parameters, and other strings in XML fiels are marked with translate attribute
As an individual developer, if you're not developing applications/modules intended for translation it's easy to fall into the habit of not doing the above. Also, the areas of Magento's XML configuration system that can (vs. can't) be translated aren't well documented. It's easy to miss a string or two, and localization (along with everything else) is almost never tested.
All of which is a long way of saying, contact your vendor and file a bug. If you want to play capitalism, since you've already hard-coded the translations, fix the core problem yourself and offer to sell the solution back to the onepage people.