Damn Good Content To Grow Your Business In The Digital World
Insights, Ideas and Innovations from the brains of the Saucal NERDS.
Authorize.Net to stop support for HTTP GET method
23 Jun

Recently users have been getting an mail from Authorize.Net informing them, that they would be ending support for any HTTP GET method for transaction requests; this is because HTTP GET methods no longer adhere to current TLS protection requirements. It’s a welcome change that increases security.

Authorize.Net HTTP GET

Previously Authorize.Net has strongly encouraged merchants to upgrade their connections to use TLS 1.2 exclusively and now this, adds a huge step towards making ecommerce more secure along with the web in it’s entirety. This will eventually make transactions over the web much safer than it is now.

Solution to HTTP GET changes

All the functionalities using HTTP GET methods for transaction requests has to be replaced by HTTP POST.

The team here at Saucal would recommend users to update to the latest version of the official Authorize plugins.
Authorize.Net CIM
Authorize.Net AIM
Authorize.Net DPM

The team has been watching the transition closely and understands this can be challenging for many out there.  Don’t slack off because July 30, 2016 is approaching quickly and can kill your eCommerce sales if forgotten.

If you want to discuss more about the change with the team, or need help replacing the plugins please feel free to contact us.

You can’t have AJAX and SEO together… or can you?
21 Aug

So a few years ago, a bunch of sites started implementing AJAX navigation. It allowed smooth transitions from one page to the other. Load times increased, and overall, the UX was great.

But there were some issues with it. Your sites looked incomplete to search engines, trashing all the effort you’d put into your SEO rankings.

After avoiding this approach for a while — because we care a lot about SEO (and you should too) — we decided to research how could we do this within our sites (mostly built with WordPress).

The important thing to know is that search engines don’t execute JS, so the direct links to each URL of the site need to look nice SEO-wise (with meta tags, H1 tags and all). All good — we’ll make no changes to the templates — just navigate through the site doing AJAX requests to bring up the complete HTML of the page we need to load, and replace the content container with the new one.

That doesn’t sound right. It would allow us to do smooth transitions, but load times would still be the same (or slightly smaller).

We then realized that we didn’t need the header to load for all pages. We just needed it to load the first time the user arrived directly at our site (or if the page didn’t get loaded through AJAX). And there you go! We improved the UX with smooth transitions, improved load times, and kept all the SEO juice.

So, to answer the question in the title, it turns out that with a little extra work you can have both AJAX and SEO!

If you need to do something like this, our IgniteWP framework has a module you can use to avoid doing this work yourself. Sounds good, right?

The problems of working with History API, and how we solved them
08 Jun

Have you ever worked with the History API to build your apps? No? Well you should try it – it’s awesome!

You don’t believe me? You think it sucks? Well, that’s probably because you’ve encountered some of the many problems with it:

  • In some cases, a popstate event is triggered at pageload for no apparent reason. This happens when you refresh a page that previously had a state set. Most of the time you don’t need this, as you can check the window.history.state from JS on page load if you need to do anything with it.It feels more natural that a popstate event is only triggered when the user hits the back/forward buttons, right?
  • Why include the title parameter in the pushState and replaceState methods, if the browsers are not implementing it at all? It’s not rocket science to change the document.title parameter.Come on, Mozilla and Google! Microsoft, we know you try so hard  – just kill IE already!
  • Google Analytics doesn’t play well with the History API yet, but in this case it’s understandable. Not every pushState or popState event is meant to trigger an Analytics response.

After struggling with these issues for a while, I put together a small JS library that provides almost the same interface as the native history object, but fills the gaps mentioned above.

It’s included in our open source framework, Ignite WP. Check out the source here and documentation here.