WordPress

WordCamp Sheffield was this weekend (24th April) and I did a short presentation about ‘Going beyond LAMP’ and looking at direct replacements and complimentary services.

Amazon CloudFront is remarkably simple to setup, you don’t need a S3 account, simply use your own HTTP server as the origin. SNI allows multiple SSL certificates to be associated with a single IP but is not 100% supported. Amazon CloudFront supports using your own SSL certificate with SNI. The combination means you can quickly build a CDN for your site.

oEmbed has been around for quite a while but has been making the WordPress news recently, so what is it, how does it work and how can you turn any WordPress site into a oEmbed Provider all really good questions someone should answer that!

This is a bit of an unusual presentation, normally I talk about indepth technical articles but this time around I get to go all egotistical and talk about why I restarted the blog and where it’s going in the future as well as what’s keeping it up and running now.

Most people have shopped online with a credit or debit card and these days we barely think before using the plastic. But, the credit card details we put in don’t just make purchases. They can also tell us a lot about the user including, banking habits, information such as town of origin and even fraud risk.

For many, the concept of using WordPress as a static site generator would seem quite mental. Static Site Generators basically take a content management system’s content and combine it with a theme and generate static html pages. No dynamic content means they can be hosted more or less anywhere, consuming few resources to improve performance and, because they don’t require any specialist software, reducing the complexity of any stack. Imagine hosting your WordPress site entirely on Amazon s3 or Github, well you can but at a cost.

Setting up WordPress is famously easy! It takes only 5 minutes but it’s worth taking some time to look at the best way to structure your next WordPress project. Tim looks at his current preferred WordPress structure and discusses some of the rationale behind it. Continue Reading

Many plugins call on 3rd party services when they do those services often provide some form of credentials and 9 times out of 10 those credentials get stored in wp-options table. Except I don’t want my security credentials in my database. Where you store you secrets can be deeply personal thing.

A common way to call credentials in plugin is something along the lines of

$api_key = get_option( 'mysecretkey' );
define( 'SECRETKEY', $api_key );

if you are going to do that, then try this instead

if ( ! defined( 'SECRETKEY' ) ) {
$api_key = get_option( 'mysecretkey' );
define( 'SECRETKEY', $api_key );
}

By checking if it’s already defined before pulling it from DB it allows me to add the API key in the wp-config.php and avoid putting it in my DB.

If you develop plugins that make use of third party services and storing API keys, then give your users the flexibility to store the keys where they want.

It’s always the way. The one event you don’t go to and all the cool toys are announced. This year is the first time I didn’t make it to Innovate PayPal developer conference and they announced a huge pile of new stuff including an interesting ecommerce platform hybrid thingiemagik. However, what really interested me were […]

Paypal recently released a whole heaps of new ways to use their services, I have been lucky enough to have been part of early beta testing and now no longer under those pesky NDAs can spill the beans on some of the new features. The two big releases from Paypal have been Adaptive Payments and […]