This was a doozy today. I signed up for USPS Web Tools, plugged my User ID and test server details into my Magento Development site, and was rudely greeted with the error:
“API Authorization failure. RateV4 is not a valid API name for this protocol”
My initial symptom: I didn’t see any USPS rates in my front end. Enabling debugging allowed my to see the error in /var/log/shipping_usps.log.
The problem is that the USPS test servers didn’t support RateV4. So, you email USPS support to enable production server access for your USPS User ID. And we’re all set!
Found this great extension that does it. I’ve used it on EE 1.12, and from the reviews I gather it works on CE 184.108.40.206 as well. YMMV, use with caution, etc. I can’t imagine installing this in anything other than a development environment. Seamless Delete Order.
Reset Dashboard Statistics
To remove “Bestsellers” from my dashboard, I add this stored procedure to my development MySQL environments, courtesy of this post at PHP Bugs.
DROP PROCEDURE IF EXISTS reset_dashboard;
CREATE PROCEDURE reset_dashboard()
DELETE FROM report_event WHERE event_type_id IN (SELECT event_type_id FROM report_event_types WHERE event_name IN ('catalog_product_view'));
The DELETE FROM report_event code I stumbled across shortly after I originally posted this. I found it here at DesignersSandBox.
I just posted a project on BitBucket that is a small, proof of concept C# Console application that exercises a few SOAP API v2 Calls against Magento Web Services.
It should serve as a good starting point for C#/ .Net/ Mono folks trying to tap into Magento’s potential.
Here’s the link: https://bitbucket.org/MXWest/magento-listorders-in-c … have fun!
I’ve access to only 1 MySQL database, but I have multiple Magento Installations in it – so naturally, I’m using Table Prefixes to keep them separated. In my case, I have Magento Community Editions 220.127.116.11 and 18.104.22.168.
My table prefixes are ce1620_ and ce1702_, which is simple and easy to understand. The problem is how can I simply remove all tables for only 1 installation?
The answer came in the form of a stored procedure. Most of the heavy lifting was done by a nice poster over on StackOverflow.
My little extra ingredient was to disable foreign key constraints, so I could obliterate the whole darn thing in one pass.
As always, be careful and back up before doing something as drastic as this.
DROP PROCEDURE IF EXISTS droplike;
CREATE PROCEDURE droplike(pattern VARCHAR(20))
SET foreign_key_checks = 0;
SET group_concat_max_len = 65535;
SELECT @DROP:= concat( 'drop table ', group_concat(TABLE_NAME) , ';' ) FROM information_schema.TABLES WHERE table_schema = "YOUR_DATABASE_NAME_HERE" AND TABLE_NAME LIKE pattern;
PREPARE statement FROM @DROP;
SET foreign_key_checks = 1;