Nginx (pronounced engine-x) is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. Igor Sysoevstarted development of Nginx in 2002, with the first public release in 2004. Nginx now hosts nearly 12.18% (22.2M) of active sites across all domains. Nginx is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption.Nginx Official Website

Now I’m not going to go into why nginx may or may not perform better than Apache, today I’m simply going to talk you through setting up a fresh CentOS 6 installation with a LEMP (Linux, nginx, MySQL and PHP) stack.

CentOS and Repositories

Let’s start with a clean install of CentOS with nothing installed. We’re going to make it easy by installing everything via Yum, however CentOS’s package support is a bit crap so we need to add a couple of extra repos:

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm

Installing MySQL

Now we need to install MySQL. This is fairly simple:

yum install mysql mysql-server

Once the download and install is complete we start MySQL and ensure it starts on system boot up:

chkconfig --levels 235 mysqld on
service mysqld start

We also need to do some basic configuration which can be done easily using the mysql_secure_installation command. You will be prompted for your current password, as we’ve only just installed MySQL you can leave this blank.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

CentOS automates the configuration process quite nicely, you’ll need to set a root password followed by a series of questions, most of which you can leave as the default answer. This does things like remove anonymous access and test tables etc. Once complete it will reload and implement all the changes. Simple.

By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
... Success!

By default, MySQL comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

Installing nginx

Yum makes installing nginx nice and easy (now we have the right repos setup!):

yum install nginx

As with MySQL we need to start nginx and make sure it starts on system boot.

chkconfig --levels 235 nginx on
service nginx start

Now we can test to see if it has works by simply going to our IP or hostname in a browser. You should see the following.

Installing PHP

We’re going to be using PHP-FPM which we can install from the REMI repo we added earlier. Our yum install script is a little different as we need to tell yum to use the REMI repo.

yum --enablerepo=remi install php-fpm php-mysql

.....

================================================================================
 Package               Arch          Version                  Repository   Size
================================================================================
Installing:
 php-fpm               x86_64        5.4.14-1.el6.remi        remi        1.3 M
 php-mysql             x86_64        5.4.14-1.el6.remi        remi        134 k
Installing for dependencies:
 compat-mysql51        x86_64        5.1.54-1.el6.remi        remi        1.4 M
 php-common            x86_64        5.4.14-1.el6.remi        remi        892 k
 php-pdo               x86_64        5.4.14-1.el6.remi        remi        117 k
Updating for dependencies:
 mysql-libs            x86_64        5.5.31-1.el6.remi        remi        774 k

Transaction Summary
================================================================================
Install       5 Package(s)
Upgrade       1 Package(s)

Total download size: 4.6 M
Is this ok [y/N]:

Configuring PHP

We need to make a small change to our default PHP config to tighten up the security a little. So open up your php.ini in your favourite code editor:

nano /etc/php.ini

Find the line, cgi.fix_pathinfo=1, and change the 1 to 0.

cgi.fix_pathinfo=0

When set to 1 the php interpreter will try to process the file that is as close to the requested file as possible. This could lead to possible PHP exploits, when set to 0 the interpreter will only process the exact file path. Save your changes and exit.

Configuring nginx

We need to alter a couple of things in our nginx configuration, open up the default config file in your favourite editor:

nano /etc/nginx/nginx.conf

We want to increase the number of worker_processes. With nginx the maximum number of clients = worker_processes * worker_connections so a basic config can handle nearly a thousand concurrent connections. However a good tweak is to increase your number of worker_processes based on the number of processor cores you have. Increase the number of worker processes to match how many CPU cores you have, you can check how many cores you have with the following command:

cat /proc/cpuinfo | grep processor
processor	: 0
processor	: 1
processor	: 2
processor	: 3

So in my case:

worker_processes 4;

We also want to modify the user that nginx or PHP-FPM run as. These need to be the same user so you have 2 choices:

nano /etc/php-fpm.d/www.conf

Then find the user and group settings and change them from apache to nginx:

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;	will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

Alternatively we can change the user nginx runs as to match the PHP-FPM default config. Open up the nginx confif file we edited earlier and edit the user found right at the top of the file:

user              apache;

Finally we need to configure our nginx virtual hosts. This is much simpler to configure than Apache. Take a look at the config below, it is slightly different to our default config, but I’ll explain the changes below:

#
# The default server
#
server {
    listen       80;
    server_name mydomain.com;

    location / {
        root   /usr/share/nginx/html;
        index index.php  index.html index.htm;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /usr/share/nginx/html;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        root           /usr/share/nginx/html;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME   $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

So what did we change?

• We added index.php to the index line.
• Change the server_name to your domain name or IP address (replace the mydomain.com in the configuration above)
• Change the root to /usr/share/nginx/html; This of course can be whatever you like.
• Uncomment the section beginning with "location ~ \.php$ {"
• Change the root to access the actual document root, /usr/share/nginx/html; This should match the root above.
• Change the fastcgi_param line to help the PHP interpreter find the PHP script that we stored in the document root home.

Once you’ve made your change save and exit. Then all we need to do is restart PHP-FPM to make the changes take effect:

service php-fpm restart

Testing

Our basic configuration is complete! Let’s test to make sure it is all working. Create a new file:

nano /usr/share/nginx/html/test.php

Then add the following line:

<?php
phpinfo();

If you now browse to your hostname or IP address you should now see the PHP Info page! How easy was that?

This should get you up and running, have a play and you will find loads more you can do. Also check out this article on great nginx and PHP-FPM config tips and tweaks!

I will be playing with it over the coming weeks to improve a few areas that still need some more love but would love to hear what you think?

So head over and get yourself the latest development version of Jetpack and add the following line to your wp-config.php before activating the plugin.

define('JETPACK_DEV_DEBUG', true);

Just like magic Jetpack will now let you use it for local testing without having to connect to your WordPress.com account!

Multi-Author blogs are becoming increasingly popular and with good reason. Creating regular, engaging content can often be a challenge for an individual blogger. With multiple authors it can be a lot easier and also allows you to cover a greater range of topics pulling from the knowledge of several people. On sites like Wptuts+ you get to read articles from a massive team of writers and bloggers, we all have our own writing style and personalities. Like Wptuts+, on most multi-author sites, you will find a nice little author information box somewhere on the page. Today I’m going to show you how you can create one for your very own site.

Read the Full Article

If you’re simply including the following in your header.php you’re doing it wrong!

<!-- Scripts -->
<script type="text/javascript" src="http://code.jquery.com/jquery-1.8.3.min.js"></script><script type="text/javascript" src="js/bootstrap.js"></script>

WordPress gives us two functions for handling JavaScript in a way that doesn’t conflict with other plugins and themes and more importantly with the WordPress Core itself.

wp_register_script()

First up is wp_register_script() think of this as letting WordPress know about your JavaScript. When you call this function is doesn’t do anything except let WordPress know it’s there and that you might want to use it at some point.

<?php wp_register_script( $handle, $src, $deps, $ver, $in_footer ); ?>

• $handle – This is the name of the script, it should be unique as you will be using this later on in the wp_enqueue_script() function.
• $src – This is the URL to the script. If you are using a local script you should never hardcode the URL, instead make use of the functions available such as get_template_directory_uri(). Since WordPress 3.3 you can also use protocol agnostic URLs for remotely hosted scripts. (//remotehost.com/myscript.js).
• $deps – Array of handles of any script that this script depends on; scripts that must be loaded before this script. False if there are no dependencies. This parameter is only required when WordPress does not already know about this script. Useful if you are registering a jQuery plugin you can specify jQuery as a dependancy.
• $ver – String specifying the script version number, if it has one. Defaults to false (which uses the WordPress version number by default). This parameter is used to ensure that the correct version is sent to the client regardless of caching, and so should be included if a version number is available and makes sense for the script. Set to null to disable. You can check out how to dynamically add a version number to your scripts and styles in this previous post.
• $in_footer – Normally scripts are placed in thesection. If this parameter is true the script is placed at the bottom of the

  . This requires the theme to have the

  wp_footer()

  hook in the appropriate place. Note that you have to enqueue your script before wp_head is run, even if it will be placed in the footer.

Let’s go back to our example and see how we can register our scripts correctly.

function mojowill_scripts() {
    wp_register_script( 'bootstrap', get_template_directory_uri() . '/js/bootstrap.js', array( 'jquery' ), '2.2.1', false );
}

add_action( 'wp_enqueue_scripts', 'mojowill_scripts' );

I created a function and inside it called the wp_register_script() function. I am then registering a local copy of bootstrap.js. You can also see that it depends on jQuery. jQuery is one of the bundled JavaScript libraries with the WordPress core so we don’t need to register it and can simply call it as a dependancy.

wp_enqueue_script()

Next up we have wp_enqueue_script() instead of simply letting WordPress know about our script this function loads the JavaScript and outputs it in your template.

<?php wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );?>

You’ll notice that the parameters are exactly the same as the previous function. If you have already used wp_register_script() then you can simply do the following:

<?php wp_enqueue_script( 'bootstrap' ); ?>

If we hadn’t run the register function then it would look like this:

<?php wp_enqueue_script( 'bootstrap', get_template_directory_uri() . '/js/bootstrap.js', array( 'jquery' ), '2.2.1', false ); ?>

Personally I always register my scripts first. Let’s have a look at the completed code:

function mojowill_scripts() {
    wp_register_script( 'bootstrap', get_template_directory_uri() . '/js/bootstrap.js', array( 'jquery' ), '2.2.1', false );
    wp_enqueue_script( 'bootstrap' );
}

add_action( 'wp_enqueue_scripts', 'mojowill_scripts' );

Always remember to call your own function with the correct action hook! Use the wp_enqueue_scripts() action to call this function, or admin_enqueue_scripts() to call it on the admin side, or use login_enqueue_scripts() for login screens.

Bundled Libraries

WordPress comes with a whole heap of JavaScript libraries already included in the core so all you need to do is enqueue the script. You would use as follows:

function mojowill_builtin_scripts() {
    wp_enqueue_script( 'jquery' );
    wp_enqueue_script( 'backbone' );
}

add_action( 'wp_enqueue_scripts', 'mojowill_builtin_scripts' );

A huge number of developers still don’t use jQuery correctly, enqueue it properly and preferably use the built in core version. If you use a different version then there is a high chance you will break plugins or themes. This is still one of the biggest issues with WordPress developers. Now there maybe times you want to use a different version of a library that is included with WordPress perhaps to take advantage of a CDN version. This is fine on your own site as long as you know what you are doing, but if you are releasing a theme or plugin publicly then for the love of God use the bundled libraries! I’m not even going to tell you here how to use a non standard version of a bundled library as personally I hate it and it’s my site so I get to write what I want!

jQuery noConflict Mode

Finally a note about jQuery. The bundled library in WordPress loads in “no-conflict” mode. This helps to stop compatibility problems with other JavaScript libraries that WordPress can load. In “no-conflict” mode the $ shortcut is not available and you instead use the longer jQuery:

// Old Way
$(document).ready(function(){
$(#myfunction)
});

// No Conflict Way
jQuery(document).ready(function(){
jQuery(#myfunction)
});

You can also use a shortcut alias, in the following examples the first piece of code will execute when the page has finished loading, however in the second example you can see how to execute the code immediately.

jQuery(document).ready(function($) {
    // $() will work as an alias for jQuery() inside of this function
});

(function($) {
    // $() will work as an alias for jQuery() inside of this function
})(jQuery);

Conclusion

Do you feel all warm and fuzzy now you know how to do it properly? Probably not. Please, please, please do it the correct way though. It screws up so much other stuff when lazy developers don’t use the correct functions for JavaScript. It’s not difficult and becomes second nature very quickly!

Hugs!

First off props go to Thomas Griffin who posted a great example on GitHub of how to do this! Secondly I must admit I don’t fully understand everything but hey I’m not a Javascript Ninja, but I think I know what is going on!

So WordPress actually tries to make things a little easier for us….a little bit anyway. Introducing wp_enqueue_media. Now documentation on this function is extremely lacking but what we do know is this.

Enqueues all scripts, styles, settings, and templates necessary to use all media JS APIs.

So instead of having to enqueue the media-upload script and thickbox we can now call this one function and it gets everything ready for us. We now need to do some of our own code to hook into the media uploader and then pass our images information back to our page. Let’s take a look at a form field from my Mojo Admin Toolbox plugin:

<label>
<input name="mojoToolbox_options[login_logo]" type="text" value="<?php if ( isset( $this->options['login_logo'] ) ) echo $this->options['login_logo'];?>"/>
<input class="mojo-open-media button" type="button" value="<?php echo _e( 'Upload Image', 'mojo-toolbox' );?>" />
<span style="color:#666666;margin-left:2px;"><?php echo _e( 'The URL for your custom login page logo, (270px x 60px works well!)', 'mojo-toolbox' );?></span></label>

So what we want to do is launch the media manager when the button is pressed and then passback our data to the text field. We need to create our own Javascript file and enqueue that after the new wp_enqueue_media function is run.

We want to create a new Javascript function and inside it do a few different things. We need to set a couple of variables that we will be using later on then we need to create a function a bind it to our on click event. You can get much more information by going to Thomas Griffin’s GitHub example. Inside the on click event we do the following:

1. Prevent the default actions from occurring.
2. Set our Form Label variable using jQuery to get the parent element.
3. Check to see if a frame already exists, if so we open a new one.
4. We create a new media frame, there are variables we use to define what kind of media options we want. You can see in my code that I want a simple select option, that I don’t want to allow multiple selections and that finally we only want to deal with images.
5. We next grab the selected image from the media manager and pull some data from it as a JSON object.
6. Finally we use our previously set formlabel variable to pass back the image url to the correct field.

Make sense? Have a look at the code:

/**
 * Thanks to Thomas Griffin for his super useful example on Github
 *
 * https://github.com/thomasgriffin/New-Media-Image-Uploader
 */
jQuery(document).ready(function($){
 // Prepare the variable that holds our custom media manager.
 var mojo_media_frame;
 var formlabel = 0;

 // Bind to our click event in order to open up the new media experience.
 $(document.body).on('click.mojoOpenMediaManager', '.mojo-open-media', function(e){ //mojo-open-media is the class of our form button
 // Prevent the default action from occuring.
 e.preventDefault();
// Get our Parent element
formlabel = jQuery(this).parent();
 // If the frame already exists, re-open it.
 if ( mojo_media_frame ) {
 mojo_media_frame.open();
 return;
 }
 mojo_media_frame = wp.media.frames.mojo_media_frame = wp.media({

//Create our media frame
className: 'media-frame mojo-media-frame',
 frame: 'select', //Allow Select Only
 multiple: false, //Disallow Mulitple selections
 library: {
 type: 'image' //Only allow images
 },
 });
 mojo_media_frame.on('select', function(){
 // Grab our attachment selection and construct a JSON representation of the model.
 var media_attachment = mojo_media_frame.state().get('selection').first().toJSON();

// Send the attachment URL to our custom input field via jQuery.

 formlabel.find('input[type="text"]').val(media_attachment.url);
 });

// Now that everything has been set, let's open up the frame.
 mojo_media_frame.open();
 });
});

Now I wish I could explain a whole lot better, however it works for me and hopefully looking at this along side Thomas Griffins example and a great post by Mike Jolley on doing this you should be able to get head around all of this!

WooCommerce brings serious big boy e-commerce to WordPress in the first part of our series we looked at installation and getting everything setup. Today we’re going to move on and talk about products, we’ll discuss the different product types WooCommerce offers and we’ll add our first products to our site. We’ll then move on to styling and theming WooCommerce before wrapping up with some next steps.

Read the Full Article

You can grab the update from your WordPress dashboard or download below:

Visit the Plugin page on WordPress.org or visit the project on GitHub.

E-Commerce is massive, most of us use it and global e-commerce sales are set to top $1.25 trillion by 2013. Over the past few years it has become easier to start your own e-commerce store with products likeZenCart, Open Cart, OSCommerce and Magento. WordPress has a few options for e-commerce but none have stood out as the full enterprise quality system that serious sellers need.

Today I’m going to talk about a product that has changed that and put WordPress right at the front as a serious contender as an e-commerce platform. Say hello to WooCommerce. In the first of our two part series we’ll look at installation and initial setup talking through the various options available to you. In our second tutorial we will look at adding our first product as well as theming and styling WooCommerce.

Read the Full Article