 |
 |
 |
|
Recently, a client received an email from Yahoo Small Business, announcing:
You're receiving this email to notify you of an upcoming change that may affect your site. To improve security for both merchants and buyers, we will soon be disabling the following deprecated PHP options: Register_globals & allow_url_fopen.
Yahoo can calculate shipping for you, but gives you the option of doing that yourself, using Windows dot.net, asp, or PHP programming languages. If a shopper is on the Shopping Cart page and is trying out shipping options, you can use your own webserver to can get information and shoot back a quote. When a customer makes a purchase, you can get order information and update your own inventory/shipping/packing system.
If you are one of these businesses using PHP as your backend, this affects you.
So what are these settings?
Registered globals mean that if you pass in parameters in a url like http://www.mydomain.com/index.php?firstname=paul&lastname=wolborsky, a developer can add these lines in the script...
echo "Hello ".$firstname." ".$lastname
This is not good because I could influence the code just by crafting a URL. Registered Globals was a bad idea from the get-go, and the programming style it allows is no longer in use, and you probably won't need to take action on it.
The 2nd restriction, allow_url_fopen is a bigger deal. Your backend shipping system calls UPS and USPS for address verification and shipping quotes. Chances are great that your developer uses the fopen function to access them. The fopen function is used to open a file on your server, but if allow_url_fopen is enabled, you can open a file on an outside server as a URL. This is the most popular and oldest ways to get quotes out of UPS and USPS. And Yahoo now forbids it.
The other way to call UPS and USPS is to use the php cURL functions. But it's not as simple as replacing the fopen call with cURL calls. There are some wrinkles and gotchas:
1) UPS has separate services for getting shipping quotes, the old cgi you can use with fopen (http://www.ups.com/using/services/rave/qcostcgi.cgi), and a newer XML you can use with cURL (https://www.ups.com/ups.app/xml/Rate).
2) While writing code to calling the UPS CGI is easy, passing parameters as a single string like 'destinationCity=$city&destinationState=$state' you have to create an XML string for the xml, like
$xml="<?xml version="1.0"?>
<AccessRequest xml:lang="en-US">
<AccessLicenseNumber>$this->accesskey</AccessLicenseNumber>
<UserId>$this->userid</UserId>
<Password>$this->passwd</Password>
</AccessRequest>
<?xml version="1.0"?>
<RatingServiceSelectionRequest xml:lang="en-US">
<Request>
<TransactionReference>
<CustomerContext>Rating and Service</CustomerContext>
<XpciVersion>1.0001</XpciVersion>
</TransactionReference>
<RequestAction>Rate</RequestAction>
<RequestOption>$this->request</RequestOption>
</Request>
<PickupType>
<Code>$this->pickuptype</Code>
</PickupType>
<Shipment>
<Shipper>
<Address>
<StateProvinceCode>$this->s_state</StateProvinceCode>
<PostalCode>$this->s_zip</PostalCode>
<CountryCode>$this->s_country</f>
</Address>
</Shipper>
<ShipTo>
<Address>
<StateProvinceCode>$this->t_state</StateProvinceCode>
<PostalCode>$this->t_zip</PostalCode>
<CountryCode>$this->t_country</CountryCode>
<ResidentialAddressIndicator>$this->residential</ResidentialAddressIndicator>
</Address>
</ShipTo>
<Service>
<Code>$this->service</Code>
</Service>
<Package>
<PackagingType>
<Code>$this->package_type</Code>
<Description>Package</Description>
</PackagingType>
<Description>Rate Shopping</Description>
<PackageWeight>
<Weight>$this->weight</Weight>
</PackageWeight>
</Package>
<ShipmentServiceOptions/>
</Shipment>
</RatingServiceSelectionRequest>";
3) Then you have to setup cURL. The example for UPS looks like this:
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL,"$this->upstool"); /// set the post-to url (do not includethe ?query+string here!)
curl_setopt ($ch, CURLOPT_HEADER, 0); /// Header control
curl_setopt ($ch, CURLOPT_POST, 1); /// tell it to make a POST, not a GET
curl_setopt ($ch, CURLOPT_POSTFIELDS, "$y"); /// put the querystring here startingwith "?"
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); /// This allows the output to be setinto a variable $xyz
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0); /// some php version cause error withcurl without this line
$this->xmlreturndata = curl_exec ($ch); /// execute the curl session and return theoutput to a variable $xyz
curl_close();
4) Then, you have to extract the number you want from the response XML
$xmlParser = new xmlparser();
$array = $xmlParser->GetXMLTree($data);
$amount = $array["RATINGSERVICESELECTIONRESPONSE"][0]["RATEDSHIPMENT"][0]["TOTALCHARGES"][0]
["MONETARYVALUE"][0]["VALUE"];
5) And to top it off, Service codes have changed. When before you can pass in "2nd Day Air", XML requires a number code, so you have to change other code in other functions to make this work. Also, USPS now prefixes all its services with USPS, so any array with those services have to be changed too.
6) USPS uses a URL that embeds XML. "<" are bad to use in a URL and XML is all about <tag>some data</tag>, so you'd have to encode the "<" for safe passage.
Other issues may come up to light only because you hadn't looked at the code for a long time. For example, using cURL with XML, you can get a quote for all your packages with just one call, rather than making a call for each box. You may need to be logging each call and response to make sure they all succeed. I ran into code that returns a "0" shipping cost if even one box generates an error, to fix this issue, I'd have to add 0 to the total and log the specific error so the client will know that the total shipping cost is underestimated. If your call fails, you have to try again, otherwise, the error triggers a pernicious 'modify header' warning that results in your back-end returning an estimate of "0" for shipping cost.
Your back-end is also mission critical, so you need to add testing time to your cost, and you need to make sure the developer can batch test a large number of previous transactions to make sure results are the same, or changes are very small.
|
|
 |
 |
 |
|
|
|
|
Indispensible pocket wisdom for building websites you will find anywhere.
This is a constantly evolving list. Some require more expenation and will link to a blog.
#1 - Hire a professional developer to write up the specs for your project. You communicate your vision to the spec writer, and they turn it into a series of programming tasks & steps. The developer will also give you a reality check, an AI system may cost billions to build, but an e-commerce site is more feasible.
#2 - Don't be cheap. If you are building a professional business/avocation site, it is very serious business. If you are willing to spend $500 for a custom-crafted bed for your little doggie, you can spend $1,000 to build a web\site that may profoundly change your life or what you will be doing the next few years.
#3 - There is no such thing as a login page or a shopping cart. The login you see is the tip of a large application that involves many steps: the registration and validation process, password reminders, logging in, security & encryption, your profile and a user mgmt system for admins to use that may have 10's of thousands of users. Most content mgmt systems and e-commerce now have it built in, but like logging in, every other idea you have is the tip of the iceberg.
#4 - Web developers are highly skilled workers and web developing is a highly technical, logical and intellectual function. Do not treat them like day laborers and do not assume what they do is easy and something that only takes a couple of hours.
#5 - Small tasks take 10 hours. Medium tasks take 100 hours. Large tasks take 1000 hours and a team. Your facebook webpage takes 10 minutes. A static website can take 10 hours to build. A CMS with no frills can take 20 hours to build. A website that has users, and different audiences, and workflows with 12 steps that may span weeks takes 1,000.
#6 - A website with core functionality can be launched. You can launch a successful website with glitches as long as there are no show-stoppers. Live with glitches, no website is perfect. Microsoft has a policy of bringing still-buggy code to market and fixing them over time. You can do the same.
#7 - A website is a hell of a lot of work to create, for you as well as your contractors. The process is filled with show-stoppers, hard decisions, compromise, or surprise cost if you insist a feature works. Worries keep you awake while you build, while coding definitely keeps your contractor awake. Sleep deprivation is common in this field.
#8 - A web-based business is a business. After you go live, you have to manage it. And promote it. And deal with unhappy customers, payment issues, delivery and shipping. Brick-or-mortar, or the web, you're still the business owner and have the same responsibility.
#9 - Your business website has to be based on your business model and workflow. If you have a staff of 2, and your website gets 1,000 customers in 1 day, it must not take 1,000 hours for your staff to process. Web programming offers automation and scaling, if designed right, and your developer have better understand how to make it work for your staff of 2, or even 4. Your website has to serve your bottom line and insure greater economy-of-scale. If 100 transactions cost $10, 1000 must cost less than $100.
#10 - Developers should delivery clear, quality code that alternative developers can quickly adapt to. Developers should keep you as a customer because they delivery outstanding service and code, not because they saddle you with code only they can make sense of. Developers should give you blank buttons that you can use HTML/CSS to label.
#11 - To OffShore or not? For your first website - NO. Your 2nd website - NO. Small project after going live with first website? MAYBE. Your 3rd website? MAYBE. Clear Specs mandatory. Active mgmt mandatory. If you do everything right, you'll save more like 25%-50%. If you're saving 90%, DUCK.
#12 - Deadlines are not worth dying for. It happens all the time, it happens way too often. You have a date in your mind to go live, maybe it's the beginning of the Fiscal year, maybe its your wedding anniverseary. Maybe you're anxious to make your fortune. Websites are big projects. If you put down a live date, you're being naive. And that naive, arbitrary point of time all of a sudden becomes a tyrant that will put people through misery, introduce failure and catastrophe, stress, exhaustion, and sour everybody on each other. It shatters reputations. Developers hire contractors on short notice at great expense, house programmers work through the weekend without rest, code quality drops dramatically. Experts say that throwing man-power at a late project never works, it blows budgets out of the water and does not result in projects going live on time.
Who is master, you or your deadline? Does a date really mean anything but an arbitrary point in time? Stick with your deadline and your project becomes a nightmare with lots of casuallties. Or with a simple phone call grant another month, get a 10% discount, and everybody wins?
Do NOT put a live date in your contract. Put a soft delivery date instead.
Do put in a penalty in form of a discount for time extensions, but be prepared to give generous extensions. Enough that the current staff can complete the job properly in a normal work-week, and go home and have their own lives on the weekend.
When you are satisfied with the site, then you put a live date into motion. Starting your promotions, executing deals, putting logistics into place for the event.
The developer loses 10% of the total, but pays less than the overtime that would otherwise have happened. Developers succcessfully deliver a product to your satisfaction, well-rested, having enjoyed the experience of building you site. In the end, everybody gets a celebration.
|
|
|
|
|
|
|
|
|
This site is hosted on Go-Daddy and uses Joomla 1.5. I modified the rhuk_milkyway theme, substituting the Joomla logo with my own, making changes in 3 files to accomplish it - the xml, template.css and index.php (several lines of code were explicitly accessing the rhuk folder rather than my own copy). When I modify a template, or in any other case, I copy-and-modify. So I copied the content of templates/rhuk_milkyway into my own folder, modify that, and creating my own theme.
I just started, so I created a published a minimalist set of pages, using as few modules as possible. My portfolio page is just a pure html table. My contact information is just an email address on the intro page. Then I created a blog section and am trying to get Idoblog to work properly.
What's next?
Twitter tools, possibly a LinkedIn connection. Some eye-candy bookmarking icon tools. RSS/pinging for my blog. A nice gallery to create an alternate page for my portfolio. Oh, and a contact/inquiry form. I've already installed 2, but have yet to get them to function properly.
I will also create forwarding emails so you could contact me at an ajaxofalltrades email address. I will also establish some type of opt-in and newsletter featuring snippets from my blogs.
|
|
|
|
|
|
|
|
|
The recession hit the states so hard, the Nevada Legislature is contemplating a State Lottery. With State capitals scrambling to make ends meet, Cities are left high and dry. Income taxes are down because people aren't working. Business taxes are down because businesses are shutting down. Sales tax are down because nobody's buying, and when they are, they're buying off the web.
There's the rub.
State Tax boards are increasingly requiring people to pay local as well as state sales taxes. Cities are howling for their piece of the pie wherever pie can be found. Will local sales tax soon jump species into e-commerce?
It's likely, and in some states, it's happening now. The California Board of Equalization now has downloadable local sales tax tables with nearly 2,000 cities. But there is no clear standard yet on when, who, why, or where to tax!
I learned about the state of California's Local Sales Tax and e-commerce for a major e-commerce client doing 7-figure annual sales on the web alone. Confused? You're not alone. My client made multiple interpretations of the law before choosing one.
The issue is two issues: when you make a purchase on the web, where is the transaction really happening; and which address is the taxable one, billing or shipping?
E-Commerce transactions don't translate well to real life, so there is no right or wrong interpretation, only the one the states will choose, and each state may choose differently.
Assuming you, the E-tailer, has to charge sales tax for people who live or ship the order to your state, You can look at this in different ways:
- Scheme #1 - You pay State+Local by the city you live in or ship to.
- Scheme #2 - Same as #1, but only in cities where E-tailer has brick-and-morter business, or Nexus city.
- Scheme #3 - If you live in same state, you pay Nexus City Local Sales Tax.
- Scheme #4 - You pay the warehouse's local Sale Tax.
#1 - Buying off the web is like making a transaction in your own home, or wherever the product ends up. It breaks down when you use the billing address, because how do you know if the customer made the purchase in that town and not say, Inner Mongolia? But for Shipping, it makes sense because there is one and only one destination address.
#2 - Buying off the web like going to the local brick-and-mortar store. This exempts lots of people from paying local sales tax, and by the way, most of the e-tailers who do not have a brick-and-mortar store.
#3 - Buying off the web is like going to the E-tailer's corporate office (or bedroom over the garage). Happy Nexus city, not so happy every other city.
#4 - A disastrous idea, since at the time of purchase, your software may not even know what warehouse the product will come from, especially with drop shipping. And happy for the Warehouse's city but not so happy for every other city.
My pick? #1.
Because it lets every city get a piece of each transaction. And like gas prices, people get used to a bump in prices because they like the convenience of shopping on the web. And I think Shipping address will be the most commonly used, since you can purchase from in-state or off-planet, but the shipping address is a stationary target, so is easier to implement.
 | |
|
|
|
|
|
Copyright © -2010 AjaxOfAllTrades.com
|
