Archive | AS Burst RSS feed for this section

Introducing Springboard › Minimal JavaScript / CSS / HTML Project Template

Springboard is an ultra minimal JavaScript / CSS and HTML project springboard.

I love HTML5 Boilerplate and use it a lot as a basis for web projects. Sometimes however, I find it still does a little bit too much for my needs and I end up removing a lot before I can get started.

Most importantly for me though, it still currently doesn’t support building with Google Closure Compiler which I tend to use both for it’s advanced code optimisations and for coding better Object-Oriented JavaScript (not to mention generating JavaScript documentation from the very same comments I write for the compiler).

So What’s Springboard Then?

Springboard is an ultra minimal JavaScript / CSS and HTML project template (or springboard).

It features a very useful ANT build file which, among other things, can:

  • Refactor template files to match your project’s namespace so you’re ready to code in seconds
  • Combine JavaScript and CSS libraries to reduce HTTP requests
  • Compile JavaScript using the Google Closure Compiler (simple or advanced)
  • Minify CSS using the YUI Compressor
  • Generate JavaScript documentation using the JSDoc Toolkit
  • Sanitize HTML and inject variables at compile time

Also included is a simple JavaScript Model-View-Controller (MVC) template (based on Alex Netkachov’s) which can optionally be used as a basis for your project.

Hopefully No fluff – just the very basics you need to get a project or experiment started.

HTTP API « WordPress Codex

HTTP API

Contents

[hide]


HTTP API

Within PHP, there are five different ways to send an HTTP request. For simplicity, the five different ways are called 'transports' and will be used from now on. The purpose for the HTTP API is to support all of them with an API that is simple and standard for each of the transports.

The problem is that web hosting servers support different transports and some might support none. The solution then is to support as many as possible to allow for those who have hosts that disable one or two to still access the web through one of the other transports that might still be enabled or supported.

The other problem was that there wasn't any API for plugins and WordPress core to standardize on. Therefore, there used to be several different implementations in WordPress and many still in Plugins. The problem is even worse for plugins, because the author had to write the implementation themselves and support it afterwards. Given how many workarounds were required for the HTTP API in WordPress, that would be extremely difficult to support. It would also had to be reimplemented in each plugin that wanted to support as many as possible, which many just choose to support one or two if the plugin author was feeling generous.

The HTTP API was also an attempt to standardize on a single API that handled everything as simply as possible. The actual implementation is object-oriented, but there are utility functions, which can be used to abstract the API usage.

The HTTP API was added in WordPress 2.7 and extend further in WordPress 2.8. You may want to maintain backwards compatibility with previous versions, so you should wrap the function calls in function_exists() and provide an alternative, if possible.

In WordPress 2.7, the basics of header, body and response support was started. In the next version, WordPress 2.8, compression, cookie support and proxy support were added. Some of the features are passive, meaning that you don't have to set any option or do anything in order to use the feature. If you use an option that is in a later version, it won't give you an error, but may not work correctly.

While most of the features can be set using the options or using filters, the proxy implementation relies on constants and thus will need to be set manually in the wp-config.php. Of course, there could be and might already be a plugin that will allow you to configure it in the WordPress administration panels.


Helper Functions

The helper functions utilize the HTTP API classes to simplify the process as much as possible. You could use the classes and could use some of the methods to help process the code. The classes assume that you know what you are doing and can use the classes.

You must use the helper functions if you are modifying the core code of WordPress. It is one of the reasons for the helper API, to reduce the amount of error checking and prevent having to edit multiple places when bugs are found.

The functions below are the ones you will use to retrieve an URL. Please be aware that these functions will return a WordPress WP_Error class on failure. You will have to check for that after using these functions.

* wp_remote_get() - Retrieves a URL using the GET HTTP method. * wp_remote_post() - Retrieves a URL using the POST HTTP method. * wp_remote_head() - Retrieves a URL using the HEAD HTTP method. * wp_remote_request() - Retrieves a URL using either the default GET or a custom HTTP method (should be caps) that you specify.

The other helper functions deal with retrieving different parts of the response and does the testing for WP_Error for you. It should be noted that using these functions adds a small amount of overhead (<1-2 milliseconds), because of the function calls and checks made in the functions. If speed is important, then learn the array structure and access the array instead.

* wp_remote_retrieve_body() - Retrieves just the body from the response. * wp_remote_retrieve_header() - Gives you a single HTTP header based on name from the response. * wp_remote_retrieve_headers() - Returns all of the HTTP headers in an array for processing. * wp_remote_retrieve_response_code() - Gives you the number for the HTTP response. This should be 200, but could be 4xx or even 3xx on failure. * wp_remote_retrieve_response_message() - Returns the response message based on the response code.

You should first check that the response is not a !WordPress error.

$response = wp_remote_get('http://wordpress.org');  if( is_wp_error( $response ) ) // Handle error here.

As you can see in the example below, the API also handles redirection.

$theBody = wp_remote_retrieve_body( wp_remote_get('http://www.wordpress.org') );


Other Arguments

The argument 'method' is the HTTP method, such as POST, GET, HEAD, PUT, etc that you want to use. The safest methods to use for server support are POST, GET, and HEAD, all others, you may meet with various degrees of success. The default for this value is 'GET'.

The argument 'timeout' allows for setting the time in seconds, before the connection is dropped and an error is returned. The default for this value is 5 seconds and it also has a filter named, 'http_request_timeout', in case you want to write a plugin that sets it for every request.

The 'redirection' argument is the amount of times to follow a redirect before giving up. The default is 5 and there is a filter for the value. The filter name is 'http_request_redirection_count' and only passes the redirection default value.

The 'user-agent' argument allows you to set the user-agent. The default of which is, "WordPress/2.7; http://www.example.com" where 2.7 is the WordPress version number and www.example.com is the blog URL. There is a filter for changing this value as well, which is 'http_headers_useragent'.

The 'blocking' argument allows you to trigger a non-blocking request. The default is true; setting it to false will generally allow PHP to continue execution while the transport is working. The key is that when you set blocking to false, then it will just send the request and won't bother you with the details. This is useful for sending a POST request, where you aren't concerned with whether it succeeded or not, or if you don't want to slow down the processing time of the page.

The argument 'compress', available with Version 2.8, allows you to send the request body as compressed.

The 'decompress' argument by default will decompress any compressed content that comes in. If you do leave this as true, then the headers will be set to tell the server that compressed data is accepted and it will be decompressed in the response. If you sent it to false, then the header will be sent that tells servers that compressed content is not accepted. If the content is still compressed, because of incorrect implementation or you sent the headers for it, then you will need to decompress the content. This is also a 2.8 argument.

The 'sslverify' argument was added in Version 2.8 and will check to see if the SSL certificate is valid (not self-signed, actually for the site in the request) and will deny the response if it isn't. If you are requesting HTTPS and and know that the site is self-signed or is invalided and are reasonably sure that it can be trusted, then set to false.


External References

Get a URL Google+ Count Via PHP

<?php
$ch = curl_init();

$encUrl = "https://plusone.google.com/u/0/_/+1/fastbutton?url=".urlencode($url)."&count=true";

$options = array(
CURLOPT_RETURNTRANSFER => true, // return web page
CURLOPT_HEADER => false, // don't return headers
CURLOPT_FOLLOWLOCATION => true, // follow redirects
CURLOPT_ENCODING => "", // handle all encodings
CURLOPT_USERAGENT => 'spider', // who am i
CURLOPT_AUTOREFERER => true, // set referer on redirect
CURLOPT_CONNECTTIMEOUT => 5, // timeout on connect
CURLOPT_TIMEOUT => 10, // timeout on response
CURLOPT_MAXREDIRS => 3, // stop after 10 redirects
CURLOPT_URL => $encUrl,
CURLOPT_SSL_VERIFYHOST => 0,
CURLOPT_SSL_VERIFYPEER => false,
);

curl_setopt_array($ch, $options);

$content = curl_exec($ch);
$err = curl_errno($ch);
$errmsg = curl_error($ch);

curl_close($ch);

if ($errmsg != '' || $err != '') {
print_r($errmsg);
print_r($errmsg);
}
else {
$dom = new DOMDocument;
$dom->preserveWhiteSpace = false;
@$dom->loadHTML($content);
$domxpath = new DOMXPath($dom);
$newDom = new DOMDocument;
$newDom->formatOutput = true;

$filtered = $domxpath->query("//div[@id='aggregateCount']");
return $filtered->item(0)->nodeValue;
}
?>

Introducing the Nest Learning Thermostat

I got to get me one of these!

Find out more: http://www.nest.com/

Bikers in Cinema

Python for the Web – Gun.io

This article will give an extremely high level overview of how to use python for the web. There are many ways you can interact with the web using python, and this post will cover all of them. This includes python web scraping, interacting with APIs (Application Programming Interfaces) and running your own python web site using python server software. There are many ways to do all these things in python, but I'm going to show you how to do it the right way using the most modern techniques.

via gun.io

Great article to get an overview of Python for the web. I wish more articles were written like this or maybe we all should be inspired by this article to write more like it.

Setting up Drupal in Rackspace Centos 5.5 in 3 minutes or less

The boring part:

Log in to Rackspace and spin a new server with Centos 5.5 and most basic settings.

We will be doing this with root so this setup will be for testing only and no production.

The fun part:

$ yum install httpd php php-mysql mysql-server unzip nano php-xml php-gd

(NOTE: php-xml and php-gd are required by Drupal dom/gd respectively)
$ service httpd start
$ service mysqld start
$ msyql
> create database drupal
> quit()
$ cd /var/www/html
$ wget http://ftp.drupal.org/files/projects/drupal-7.2.zip
$ unzip drupal-7.2.zip
$ mv drupal-7.2/* .
$ rm -rf drupal-7.2
$ mkdir files
$ chmod 777 files
$ cp default.settings.php settings.php

open the IP address on your browser and follow the installation instructions

Untitled

How do you install Vim plugins? – Wikianswers – Find and edit the best answers. How to? What? Is it? Can I? Where is?

  • The "plugin" directory is for plugins that should always be loaded whenever Vim starts. These define global commands, interface tweaks, or new functionality useful for all or many file types.
  • The "ftplugin" directory is for filetype-specific plugins, such as autocompletion or highlight-errors-as-you-edit plugins.
  • The "syntax" directory is for updated syntax highlighting rules specific to a file type.
  • The "indent" directory is for filetype-specific indentation rules.
  • The "ftdetect" directory is for filetype-detection rules. Files that go here should usually do nothing but set the filetype so that files in the ftplugin, indent, or syntax directories are loaded for a new filetype.
  • The "colors" directory is for color scheme files.
  • The "doc" directory is for any help file documentation.
  • The "after" directory contains another tree with directories like "plugin", "ftplugin", and "syntax" that can be used to override settings in the system-wide settings or other plugins placed in the normal version of these directories. These files will always be loaded after their counterparts in other directories.
  • All about the VIM Folder structure

    Command Center: Nerd tree Tips

    > (a)dd a childnode(m)ove the curent node(d)elete the curent node(c)copy the current node

    m + c on the folder would duplicate it

    How to jump back to NERDTree from file in tab?

    ctrl-ww  http://stackoverflow.com/questions/1656591/how-to-jump-back-to-nerdtree-from-file-in-tab

    NERDTree moving from file in tab.