In WordPress themes – there is the “The Loop“, where it’s a “catch all” for all of the post content at a given query. This may be a page, a post or a series of posts. It all goes to “The Loop“, where inside that loop – are methods that make retrieving post data easy. Inside the loop, we can do something like “get_the_ID()” or “the_title()” – which will output the post id or its title.

We’re trying to achieve the same thing in Barebones. We have “TheLoop” component – which we’ll be adding in our “partials” directory. This component will be used everywhere – in single posts, pages or archive pages such as search etc.

Previously, we were just outputting the slug in TheLoop. The modified version is shown below.

import React from 'react';
import WithConsumer from '../context/WithConsumer';
import ThePost from './ThePost';
const TheLoop = ({ context }) => {
    const posts = () => context.posts;
    const pos = posts();
    let results = '';
    if(context.appError){
      results = <div className="app-error">{context.appError}</div>;
    }else{
      if(pos.length === 0){
        results = <div className="no-results">no results</div>;
      }else{
        results = pos.map(function(item,i){
             return <ThePost key={i} index={i}></ThePost>
           })
      }
    }
    return (results);
};
export default WithConsumer(TheLoop);

There’s really not a lot going on. We are simply isolating the “loop” logic in this component. So we don’t have to do the same elsewhere. But the key points to see is we’re getting the results from our Context. And depending on the count of the result, if there’s more than 0, we – return the “ThePost” component (more on this later).

If there’s no results – we simply return a div with the text “no results”.

If there’s an error – return the error message.

ThePost

ThePost component has all of the methods necessary to output the post data. This resembles WP’s “the_post()” in PHP. In here, we have access to the context.posts, filtered by the index. The index is a prop that we pass coming from TheLoop. So now, each item is a post:

const ThePost = ({index,context}) => {
    const posts = () => context.posts;
    const item = posts()[index];
    let linkPrefix = item.type === 'page' ? '/page/' : '/post/';
    let theContent = '';
    switch(context.route){
        case '/': //if homepage,
        case '/search/:term': //or if search
        case '/category/:catid': //or if search
            theContent = item.excerpt.rendered; //show excerpt only
        break;
        default: //for single, pages - show entire content
            theContent = item.content.rendered;
        break;
    }
    return (
        <div id={'post-id-'+item.id} className={'post-item'}>
            <h1><Link to={linkPrefix+item.slug}>{item.title.rendered}</Link></h1>
            <PostMeta index={index}></PostMeta>
            <div className="post-content" dangerouslySetInnerHTML={{__html:theContent}}></div>
        </div>);
};

We have to determine if its a “post” or a “page” (line 6). This will match with the post/page route in our index.js.

Then we have a switch statement, that checks the route. If its an archive page (like search, category) – let’s output only the content excerpt. Otherwise – if its a single, let’s output the entire thing.

The PostMeta component is also a new component that we haven’t built yet. Let’s add that in a little bit. For now, let’s grab the data.

Context.js

Now there are a few things we need to do to our Context component for the loop to work. Remember in our loop, we’ve setup up the links using “Link to”. We need to map these links to right REST url endpoint – so we can get the right data and put it in the right data store.

Remember, all of the data is inside this one file. May it be posts, comments – even methods that manipulate this data is in this component. So this file is extremely important.

Let’s start by adding the containers for our state. In the constructor, add the following:

constructor(props) {
    super(props);
    let restType = this.getRestType(props.router.match.path);
    let route = props.router.match.path;
    let slug = props.router.match.params.slug ? props.router.match.params.slug : '';
    this.state = {
      slug : slug,
      restType : restType,
      route : route,
      posts : []
    };
  }

Our state now has the necessary containers for the data we need. Primarily the “posts” array is what we aim to fill. Let’s add some actions in our lifecycle hook: componentDidMount:

componentDidMount(){
    this.getPosts(this.buildUrl());
}

Let’s build a couple of functions – one to build the REST url endpoint, and the other to fetch the posts:

buildUrl(){
    let url = '/wp-json/wp/v2/';
    switch(this.state.restType){
      case 'page':
        url += 'pages/?slug=' + this.state.slug
      break;
      case 'post':
      default:
        url += 'posts/?slug=' + this.state.slug ;
        break;
    }
    return url;
  }
 getPosts (url){
    let self = this;
    Axios.get(url).then((response)=>{
      self.setState({
        posts : response.data
    }).catch(function(error){
      console.log(error);
      self.appError = 'An unexpected error occurred';
    });
  }

That should set our post and page endpoints, bringing back data from the API. Make sure that TheLoop is in your Archive and Single components.

And if all is good, we should have something like below:

Remember that we have to change our permalinks in WordPress to match our route.

Add Paging

Paging is necessary especially for archive pages. You only want to see the latest X number of posts, then show the next X – and so on.

In Archive.js – simply add the pager component (that we still have to build), right underneath the loop:

 <TheLoop></TheLoop>
 <Pager></Pager>

Now let’s create a file in our partials folder – call it Pager.js.

import React, { useEffect } from 'react';
import WithConsumer from '../context/WithConsumer';
const Pager = function ({context}){
    let prevBtn =  React.createRef();
    let nextBtn =  React.createRef();
    let curPage = () => context.currentPage;
    let totalPages = () => context.totalPages;
    useEffect(() => {
        prevBtn.current.disabled = true;
        // eslint-disable-next-line react-hooks/exhaustive-deps
    },[]);
    function nextClicked(){
        context.nextClicked();
        if(parseInt(totalPages()) === parseInt(curPage() + 1) ){
            nextBtn.current.disabled = true;
        }
        prevBtn.current.disabled = false;
    }
    function previousClicked(){
        context.previousClicked();
        if(parseInt(curPage()-1) === 1 ){
            prevBtn.current.disabled = true;
        }
        nextBtn.current.disabled = false;
    }
    function pagerClass(){
        let cls = 'Pager';
        if(parseInt(totalPages()) <=1 ||
            context.appError){
            cls = 'Pager hidden';
        }
        return cls;
    }
    return (
        <div className={pagerClass()}>
        <button ref={prevBtn} onClick={previousClicked}>Previous</button>
        <button ref={nextBtn} onClick={nextClicked}>Next</button>
        <div className="PagerText">Page
            <span dangerouslySetInnerHTML={{__html: curPage()}}></span> of
            <span dangerouslySetInnerHTML={{__html: totalPages()}}></span></div>
        </div>
    )
}
export default WithConsumer(Pager);

Now the pager logic is a little more involved. Above simply outputs our “Next” and “Previous” buttons – depending on the number of pages. Fortunately, WordPress’s API makes this easy for us. We have 2 important header properties from each response called ” X-WP-Total” and ” X-WP-TotalPages”. From this we can determine the logic needed for our paging.

Going back to context, we need to modify our state, add some methods that modify that state, as well as modify our rest calls.

//ADD THIS TO this.state IN THE CONSTRUCTOR
currentPage : 1,
totalPages : 0,
nextClicked : this.nextClicked.bind(this),
previousClicked : this.previousClicked.bind(this), 

Above shows our new state. Note that currentPage always starts at 1. Totalpages – we update on every call, then we bind 2 methods to “this”.

Next, let’s add modify our buildUrl() method to have the page parameters from our state.

 case 'post':
      default:
        url += this.state.slug ? 'posts/?slug=' + this.state.slug : 'posts/?page=' + this.state.currentPage;
        break;    

Above simply appends the current page to the url endpoint. In our getPosts() method, we update our totalPages in state with each response:

Axios.get(url).then((response)=>{
      self.setState({
        posts : response.data,
        totalPages : response.headers['x-wp-totalpages']
      }

Now all we need to do is create two functions – which correspond to which button was clicked:

  nextClicked (){
    let newPage = this.state.currentPage + 1;
    this.setState({
      currentPage : newPage
    },function(){
      this.getPosts(this.buildUrl());
    })
  }
  previousClicked (){
    let newPage = this.state.currentPage - 1;
    this.setState({
      currentPage : newPage
    },function(){
      this.getPosts(this.buildUrl());
    })
  }

Both of these methods are called from our Pager component – which we access by doing context.XXXClicked(). Pretty neat right?

We also let the front end decide whether to show or hide the respective buttons. So if all goes well, we have something like below:

Okay that should be it for this round. A lot going on above. I suggest you download the code and run it yourself – along with following the steps. Note there are a lot of omitted code above. Only the important steps are outlined – the rest is up to you.

The post Let’s build a WordPress theme with React: Part 3 (The Loop) appeared first on Michael Soriano.

Now that we have our react app setup, let’s form how our application will be structured. We’re going to need 3 main folders: 1) templates, 2) partials and 3) context. These are all going to be inside react-src/src folder.

The templates folder is where we’re going to store the main files template files – namely Single.js and Archive.js. Single shows a single post, while Archive shows a running list of post in reverse chronological order.

The partials contain bits and pieces of reusable parts. These are files that make up the header, navigaition, pagination and the loop.

The context is where the data sits. We’re going to have two files in here – Context.js and WithConsumer.js. These files are what we need to store state and props. More on this later.

Also, don’t forget that we have our public folder (which is outside the src directory). This contains all the regular PHP files such as functions.php etc.

Routes

Let’s begin by adding a simple route. Make sure we’re in development mode by running:

npm run wpstart

Let’s create a new component called “Single”. Inside it, let’s start simple and put in the code below:

import React from 'react';
const Single = (props) => {
    return (
        <div className="Post">
            this is the page component
        </div>
    )
}
export default Single;

Pretty basic right? Now let’s install react router by running the command below:

npm install react-router-dom

Open up index.js and include react router in it

import { BrowserRouter, Switch, Route } from 'react-router-dom';

Inside the render function, let’s modify it to look like this:

ReactDOM.render(
<BrowserRouter>
    <Switch>
     <Route path='/page' component={Single}/>
    </Switch>
  </BrowserRouter>, document.getElementById('root'));

Now navigate to your site, but append the path “/page”. You should see your page component rendered.

Now let’s go back to index.js and modify the Route to look like below:

<Route path="/page/:slug" component={Single} />    

Notice we’re adding a :slug to the path. We’re going to be updating our component with this parameter. The slug will be the actual “slug” of the WordPress post. If you modify our page component with:

<h1>this is the slug: {props.match.params.slug}</h1>

You should see something like below:

So by now, you should see how we’re going to continue with our theme. We’re going to be adding the following routes:

• Home – mapped to “Archive”
• Page + slug – mapped to “Single”
• Post + slug – mapped to “Single”
• Search + term – mapped to “Archive”
• 404 – mapped to “404”

Go ahead and copy the Single component, duplicate it – and call it “Archive”. Then let’s match it to the routes above.

Our index.js now looks like below:

import React from 'react';
import ReactDOM from 'react-dom';
import { Route, BrowserRouter as Router, Switch } from 'react-router-dom'
import './index.css';
import Archive from './templates/Archive';
import Single from './templates/Single';
import Notfound from './templates/Notfound';
const routes = (
    <Router>
      <Switch>
           <Route exact path="/" component={Archive} />
           <Route path="/page/:slug" component={Single} />
           <Route path="/post/:slug" component={Single} />
           <Route path="/search/:term" component={Archive} />
           <Route component={Notfound} />
      </Switch>
    </Router>
  )
ReactDOM.render(routes, document.getElementById('root'));

Partials

Let’s quickly talk about our partials. Partials are components that we will be reusing in each route component. Things that come to mind are header, footer, sidebar – and whichever reusable piece of code we will come across along the way.

Let’s go ahead and create 2 partials. Head.js and Foot.js. These will be the header and footer of our pages. The code will be a simple functional component like below:

/******Head.js*************/
import React from 'react'
function Head(){
    return (<div className="header">header</div>)
}
export default Head;
/******Foot.js*************/
import React from 'react'
function Foot(){
    return (<div className="footer">footer</div>)
}
export default Foot;

Now in our template components, simply import, and add the components in. Here is the how our Single.js will look like with the partials. Note – make sure you add them inside the main div:

import React from 'react'
import Head from '../partials/Head';
import Foot from '../partials/Foot';
const Single = (props) => {
    return (
        <div className="Post">
            <Head></Head>
            <h1>Home</h1>
            <Foot></Foot>
        </div>
    )
}
export default Single

In the browser, you will see our partials and home page starting to take shape. Inspect the code and it should look like below:

Do the same thing to the rest of our main components so they all share the same header and footer.

Context (Data)

As mentioned above, this is where our data will sit. React has Context API which allows you to have a centralized data store – so that you don’t have to pass data through each child component. This article is probably the best explanation on Context API. As a matter of fact, the two files that we’re going to build, is code that came from the article.

Let’s start with Context.js. This file is considered to be the “Provider“. Add the code below:

import React from "react";
const storeContext = React.createContext();
export const Consumer = storeContext.Consumer;
export class Provider extends React.Component {
  constructor(props) {
    super(props);
     this.state = {
      posts : []
    };
  }
 componentDidMount(){
    this.setState({
       posts : ['title','title2']
    })
 }
 componentDidUpdate(prevProps){
    //more code here later...
 }
 render() {
    return (
      <storeContext.Provider value={this.state}>
        {this.props.children}
      </storeContext.Provider>
    );
  }
} 

Don’t worry so much about the test posts data. We’re just using that for – well, testing. Then let’s create WithConsumer.js

import React from "react";
import { Consumer } from "./Context";
function WithConsumer(WrappedComponent) {
  return function(props) {
    return (
      <Consumer>
        {ctx => <WrappedComponent {...props} context={ctx} />}
      </Consumer>
    );
  };
}
export default WithConsumer;

Now this one is pretty confusing. It’s basically a wrapper – for our components that require the “Consumer” component. Basically, all our components that want to “consume” data from our “Provider” will be using this file.

Now let’s create a partial called “TheLoop“. Add the code below:

import React from 'react';
import WithConsumer from '../context/WithConsumer';
const TheLoop = ({ context }) => {
    const posts = () => context.posts;
    const pos = posts();
    return (
       pos.map(function(item,i){
         return <div key={i}>{item}</div>
       })
    );
};
export default WithConsumer(TheLoop);

Notice that in our export – we’re passing our component TheLoop as a parameter to WithConsumer.

We’re going to talk more in detail about TheLoop component in our next session. For now, we just want to get it up and running – to demonstrate Context and Consumer.

Let’s open Single.js from our templates folder and modify it to look like this:

import React from 'react';
import Head from '../partials/Head';
import TheLoop from '../partials/TheLoop';
import Foot from '../partials/Foot';
import {Provider} from '../context/Context'
const Single = (props) => {
  return (
    <Provider>
    <div className="Post">
      <Head></Head>
      <TheLoop></TheLoop>
      <Foot></Foot>
    </div>
    </Provider>
  )
}
export default Single

You see how we’re wrapping everything in “<Provider>“, this is so we have access to our Context.js data. Also, we’ve included “TheLoop” as a component in between Head and Foot.

You should see “title” and “title2” in the browser by now.

Lastly, we need a way to get our “slug” parameter into our context. We can use props for that. Still in Single.js, pass the slug via props like so:

<Provider router={props}>

In Context.js, we should have access to the slug – through “props.router.match.params.slug“. As a matter of fact, we have access to the entire router object here, in a prop called “router”.

Let’s stop here for now. We are going to discuss more about TheLoop and Axios in our next session.

The post Let’s build a WordPress theme with React: Part 2 (Routes + Context) appeared first on Michael Soriano.

I specifically wanted to use React for the front end. React is Facebook’s product, and per their website: React is a library for building user interfaces. It has a very broad user base and lots of modules available, which makes it ideal for our theme. In conjunction, we’re using create-react-wptheme – which will make our theme up and running with React in no time. And of course, WP Rest API for the backend.

Note that this tutorial is geared towards PHP or WordPress developers – who are looking to get started working with Single Page Applications with React.

This will be the first of a series of posts:

• Part 1 – Setup
• Part 2 – Routes + Context
• Part 3 – The Loop

The theme we’re going to build throughout this series is more of a starter theme. We’re calling it “barebones” and it contains just the right amount of functionality for a basic WordPress theme.

We will need the following to get started:

• nodejs + npm
• git bash (or terminal)
• local WordPress installation

create-react-wptheme

Let’s talk briefly about create-react-wptheme. The goal is to get us bootstrapped with a new React based WordPress theme with a few commands. If any of you are familiar with create-react-app, its basically the same functionality – but for WordPress. One primary difference is that it uses WordPress (not webpack), as the development server. This makes development consolidated in one – front end and back end.

In addition, since it’s a WordPress theme, you have access to all the core functions, filters, actions, hooks etc. Also, you can use WordPress’ nonce for authenticated requests. Lastly, if you must use plain PHP – say only for a specific page, you can still use WordPress’ page templates – which is very handy.

So with that in mind, let’s get started.

First, assuming you have a local WordPress installation, go ahead and start a terminal (git bash) in the themes directory.

In Windows, git bash is a pretty good tool, simply right click and “Git Bash Here”. This will launch the terminal, where we can start our installation. Type in the command below:

npx create-react-wptheme barebones

Note that “barebones” is the name of our theme. You can simply replace this with a theme name of your preference.

Once that’s done, you will see a message like above. The installation created a root folder, with a “react-src” directory inside it. Consider the react-src directory as the most important directory because it holds all of your un-compiled code. From this directory – we can build the rest. You’ll see what I mean later.

Note that at this step, our theme is not ready yet.

See, if you look inside wp-admin > themes, you will see “barebones” under the “Broken Themes” section.

This is because we don’t have the necessary files (mainly the styles.css) for it to be a valid theme. Note that we also need index.php, so the we can hold the JavaScript and CSS files together.

wpstart

Let’s go back to our terminal and type the following:

cd barebones/react-src
npm run wpstart

We’re going into our theme directory and inside “react-src” by using the “cd” command, then we run wpstart. This will fix the “Broken Themes” issue, and if we go back to the browser and go in wp-admin > themes themes, you should be able to see our theme.

Now let’s activate the theme by clicking “Activate“. This will tell WordPress to use this theme we just built. Now let’s go and view our site in the browser. You should see a message

“Please restart the Nodejs watcher now… “

What this means is that we have to run wpstart a second time, for the script finish setting things up. Let’s go back to git bash and do a “CTRL + C”. Then type in:

npm run wpstart

Now, once this is done, a new browser tab should have opened automatically and looks like below:

It may not look like much, but this tells us a lot. This page indicates that we’ve just successfully installed our React theme. This includes the PHP, CSS and JavaScript files, plus all the resources to run our React application. So well done!

Note: wpstart is for “dev” mode.

From this point onward, when you’re in wpstart mode, (when you do npm run wpstart) that means you are in development mode. What this means is that anytime you change something in the react-src directory, the files will get recompiled and placed in the proper places. Any changes will also cause your browser to refresh – so you see your changes instantly.

Do Not Edit the files in ROOT

The files in the root folder (outside of react-src), is the compiled version of your code that is needed for WordPress and React to run. You shouldn’t edit anything in here because as soon as you save files in react-src – the files in the root will be replaced with the new. So anything you change here will get OVERWRITTEN.

File Structure

Let’s take a quick look at at the file structure for it’s important to know what it is and how create-react-wptheme use it. In a regular WordPress theme, all we really need are the PHP (such as header, footer) and CSS.

In our new theme, it looks something like below:

As you can see, there is none of the familiar files you would expect in a WP theme. Remember we’re building an SPA – which will all be in JavaScript.

As mentioned previously, inside react-src are the uncompiled and “editable” version of your code. Everything else (the root and static folder) are the output of what you have in react-src. Take note of that text file that’s titled !DO_NOT_EDIT_THESE_FILES!.txt. Remember what I said about not editing files in the root?

The “public” folder

The author of create-react-wptheme saved a special folder for our non-react files called “public”. Whatever you add in this folder, gets copied directly to the root. So, things like functions.php, or page templates – even CSS or JS can be dumped in here – and it will get copied into the root at compile time.

Again, this folder can be extremely helpful – especially for developers who would still like to access core functionality such as hooks, filters, actions etc.

Also, index.php – will only get loaded once, and is the entry way for your React application. The goal is, once loaded, all interactions will be through the REST api. So whatever PHP has produced in index.php will stay the same all throughout your application (except PHP page templates).

The “build” folder

We haven’t covered wpbuild yet, but since we talking about the file structure, you will notice a folder called “build“. This is a special folder that holds the final “deployable” code.

What that means is, almost like the contents of the “root” folder, but compressed, minified and optimized for production. Also, it doesn’t contain any dev files (such as react-src).

This brings us to the last section: wpbuild:

wpbuild

So let’s get back to git bash and do CTRL + C. Type in the following command:

npm run wpbuild

You will see messaging that looks something like:

This simply shows files that have been created, optimized and placed in the build folder, as well as the root. This means that you see your optimized code right away.

To see how that looks, when you refresh your browser, you will see just a bunch of compressed code like this:

Your WordPress theme’s source code has been flattened, ready for world consumption. Also, take a look at the contents of the root directory:

You notice the absence of the file !DO_NOT_EDIT_THESE_FILES!.txt. That means, that you’ve just run wpbuild and its now in “build” mode.

When you’re ready to go back to making some changes, don’t forget to go back into “dev” mode, by running “npm run wpstart” in the react-src directory.

And there you have it. We have our React application running as a WordPress theme. I’ve created a Github repo for Barebones theme. You can go ahead and fork it for your next project, or stay tuned for more tutorials.

The post Let’s build a WordPress theme with React: Part 1 (Setup) appeared first on Michael Soriano.

The $wp_query Object

According to the codex, the WP_Query class “deals with the intricacies of a post’s (or page’s) request to a WordPress blog”. This means that WordPress has already done the heavy lifting when it comes to information needed when you query your posts. Information needed when building stuff like paging, queries, templates and meta data.
In our case, we need the meta data – of the posts returned. So first off, open the index.php file in your theme directory and just outside the loop, add the code below:

print_r($wp_query);exit;

What we’re doing is seeing what the $wp_query is holding. $wp_query is the object that is derived from the WP_Query class that we talked about above. You will see a long array of information that pertains to the current request. So say you’re in a certain category, this object will contain information about that category and the posts that it contains.
So somewhere in this object lies the information we need. Let’s grab “post_count” and “found_posts”.

Now that we know the property names, we can go ahead and remove the print_r that we have.

The Output

This is as simple as it gets. All we need is to check if “post_count” is more than 0 and we can echo out our sentence. We can hard code the “1” since we’re always going to be showing at least 1 record.

    Showing 1 through  out of  articles..

The code above should work anywhere in your theme. It’s especially useful in your archive templates – so users can tell how many articles are in a specific category etc. It’s a good addition to your paging in the footer as well.
To test it, try searching for something, or click on a category. The “found_posts” should depend on the current request, while the “post_count” depends on the limit that you have in your WordPress settings.
And that’s it. Hopefully you can find this snippet useful in your theme somewhere. Please leave your comments below.

The post Show number of posts out of total records in WordPress appeared first on Michael Soriano.

.postid-4396 h1 {
   text-decoration: underline;
   font-size: 45px;
}

This will effectively target only that post’s h1 tags. Pretty useful right?

Add a Post slug to the Body Class

Now let’s take it a step further. If you’re like me who develop themes all day – you probably have a local server set up. Now, the problem with that is – you may not have your WordPress databases the same as the production site. So your post ids may not be the same!
The solution: use the post slug as an additional class. For example, you want to style the “About us” page’s H1 tags differently than the rest of the pages. So instead of relying on the default body_class()’s post id, simply add the code below to your functions.php file:

function getPostSlug(){
    global $post;
    $slug = '';
    if(is_object($post)){
       $slug = $post->post_name;
    }
    return $slug;
}

Then, in your header.php file (or where you have your opening body tag is), add the call to the body_class():

>

The output will be something like below:

Now you can code your CSS like so:

.about-us h1 {
   text-decoration: underline;
   font-size: 45px;
}

Conclusion

Pretty neat right? Adding a body class that is based on your post slug is not only very helpful, but also very semantic. The upside of using the slug is its always lowercase and no spaces (unless you change them when you create a post). But then – you can deal with that accordingly. Tell me your comments below.

The post Add an additional Body Class to WordPress by using the Post Slug appeared first on Michael Soriano.

The Problem with a Static Page:

The biggest issue I have with the static page is that you can’t use these entries in any other part of the site. For example, we have a small widget in our homepage that shows just a single testimonial. That means we have to duplicate these puppies in the static page and the homepage. Another problem is that each time you need to need to add an entry – the page becomes longer and longer. Pagination becomes a bit crazy. I guess you can use “Next Page” shortcodes – but still, a bit archaic. Lastly, it is quite cumbersome adding paragraphs and editing HTML for each entry.
Enter “Post Types”.

Why “Post Types” and “Custom Fields”

Creating your own Post types offer so many advantages. The most obvious is that you can continue to use the familiar WordPress “Add New” and “Edit Post” interfaces – whenever adding a new entry. This is because they ARE the same as your regular “Posts” – just a different “type”.
Another advantage is that you can define almost every element of this new Post Type such as a custom slug, exclude it from the menu, exclude it from search, have it’s own archive and single templates – almost every custom feature is definable. Read the WordPress docs for more information on these custom attributes.
Custom fields on the other hand, are key / value pairs we can use for each of our testimonials. In our case, we would need a “client” and a “company”. We will also make it real user friendly by creating “Meta Boxes” for them. You’ll see what I mean as we dive deeper. So are you ready to get started?
Let’s begin.

Step 1) Create the “Testimonials” Post Type

First step is to edit your current theme’s functions.php file. If it doesn’t have one, you need to create it and place it in your theme’s root folder. A functions.php file is the default file that stores all of your theme’s PHP functions. Add the code below, and I’ll explain what it does right after.

function create_posttype() {
  $args = array(
    'labels' => array(
      'name' => __('Testimonials'),
      'singular_name' => __('Testimonials'),
      'all_items' => __('All Testimonials'),
      'add_new_item' => __('Add New Testimonial'),
      'edit_item' => __('Edit Testimonial'),
      'view_item' => __('View Testimonial')
    ),
    'public' => true,
    'has_archive' => true,
    'rewrite' => array('slug' => 'testimonials'),
    'show_ui' => true,
    'show_in_menu' => true,
    'show_in_nav_menus' => true,
    'capability_type' => 'page',
    'supports' => array('title', 'editor', 'thumbnail'),
    'exclude_from_search' => true,
    'menu_position' => 80,
    'has_archive' => true,
    'menu_icon' => 'dashicons-format-status'
    );
  register_post_type('testimonials', $args);
}
add_action( 'init', 'create_posttype');

The meat of the above code is the “register_post_type” method. This function takes 2 arguments, the name of your Post type, as well as an array of settings that you can use to tweak your post type. As you can see, we are assigning a custom slug to the “rewrite” key, as well as excluding it from search results through the “exclude_from_search” key. For a detailed explanation of the settings you can use, consult the WordPress API.
Save your functions.php and log in to the admin. You will see a “Testimonials” section appears in the left menu. Go ahead and add some entries and you should see your testimonials fill up the right side – similar to “posts”.

By now you should already see how powerful this type of functionality is. Let’s continue to the next step and add Meta Boxes for the needed Custom Fields.

Step 2) Create the Custom Fields / Meta Boxes

As mentioned before, we need a “Client Name” and “Company” field – to add to each of our testimonial. This is easily done through “Custom Fields”. But the default WordPress implementation is a bit tacky – so we need a better way of presenting it: this is done through “Meta Boxes”.
Let’s add the code below to our functions.php file:

function my_add_meta_box(){
    add_meta_box( 'testimonial-details', 'Testimonial Details', 'my_meta_box_cb', 'testimonials', 'normal', 'default');
}
function my_meta_box_cb($post){
    $values = get_post_custom( $post->ID );
    $client_name = isset( $values['client_name'] ) ? esc_attr( $values['client_name'][0] ) : "";
    $company = isset( $values['company'] ) ? esc_attr( $values['company'][0] ) : "";
    wp_nonce_field( 'testimonial_details_nonce_action', 'testimonial_details_nonce' );
    $html = '';
    $html .= 'Client Name';
    $html .= '
';
    $html .= 'Company';
    $html .= '';
    echo $html;
}
function my_save_meta_box($post_id){
    // Bail if we're doing an auto save
    if( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) return;
    // if our nonce isn't there, or we can't verify it, bail
    if( !isset( $_POST['testimonial_details_nonce'] ) || !wp_verify_nonce( $_POST['testimonial_details_nonce'], 'testimonial_details_nonce_action' ) ) return;
    // if our current user can't edit this post, bail
    if( !current_user_can( 'edit_post' ) ) return;
    if(isset( $_POST['client_name'] ) )
        update_post_meta( $post_id, 'client_name', $_POST['client_name']);
    if(isset( $_POST['company'] ) )
        update_post_meta( $post_id, 'company', $_POST['company']);
}
add_action( 'add_meta_boxes', 'my_add_meta_box' );
add_action( 'save_post', 'my_save_meta_box' );

So to explain the code above, we create three new functions. The first two are setting up the input fields. Function “my_add_meta_box()” is simply a wrapper for “add_meta_box()” which takes several parameters such as the title of the meta box, display name, the call back function (the other function), the post type etc.
The callback function my_meta_box_cb() is the HTML we output in our form. If you read carefully – it’s creating the labels and input fields, along with it’s default values and simply echoing it. Next is actually saving the values to the database.
We have my_save_meta_box(), which does several checks and exits if it doesn’t meet our requirements. Then we update / save through update_post_meta() methods.
Finally, we have a couple of actions – which hooks our functions to the WordPress internal methods.
Go ahead and click on a testimonial to edit. Notice our nicely formed meta boxes:

Let’s set a featured image on a testimonial by setting a post thumbnail. Note that your theme has to support this feature in order for the “Featured Image” box to appear. Also, see in our code above that we are setting “thumbnail” as one of the values in the “supports” key – which adds this functionality to our post type.
Again, consult the WordPress API for more information on enabling post thumbnails in your theme.

Step 3) Create the Output: The Testimonial Archive

Now we’re getting to the fun part – presenting our data. Our company needs a running list of testimonials, along with the author thumbnail, name and company. So we’re jumping straight to this view (we’re not going to worry about the single view since it’s not necessary in our case).
Create a new file in your theme folder and call it “archive-testimonials.php”. Add the following loop inside your new file.

Note that the above code is just for the “loop” of your file. You need to add the other template tags such as getting the header and footer etc. The above is the same as any other loop in WordPress. The only way that it knows how to grab the “testimonials” is through the file name “archive-testimonials.php”.

The styling for our Markup above

Now to achieve our round author thumbnails and containers, we need to add some CSS Magic. In your theme’s CSS file (usually called styles.css), append the code below:

.post-type-archive-testimonials h1 {
    color: #21486f;
    font-family: 'Source Sans Pro', sans-serif;
    font-weight: 700;
    margin-top:35px;
    margin-bottom:35px;
}
.post-type-archive-testimonials .testimonial-wrap {
    clear:both;
    min-height: 120px;
    background:#F7F7F7;
    margin-bottom:25px;
    padding:25px 35px 30px 70px;
    margin-left:60px;
    border-radius:6px;
    border:1px solid #E7E7E7;
}
.post-type-archive-testimonials .client-photo{
    float:left;
    width:100px;
    height:100px;
    border:6px solid #fff;
    border-radius:50%;
    box-shadow:1px 1px 5px #A8A7A7;
    position: absolute;
    left: 23px;
}
.post-type-archive-testimonials h2.post-title,
.post-type-archive-testimonials .client_name{
    color:#579241;
    font-family: 'Source Sans Pro', sans-serif;
    font-weight: 900;
    margin-top:0;
}
.post-type-archive-testimonials .company {
    font-family:verdana;
    font-size:11px;
    color:#000;
}
.post-type-archive-testimonials .post-excerpt {
    margin-bottom:0;
}
.post-type-archive-testimonials .testimonial-wrap .post-excerpt p {
    color:#838383;
}

As you can see from our code above, each CSS rule is prefixed by “post-type-archive-testimonials”. This is default behavior by WordPress, which is to append this class to the archive page of your custom Post type. This is very useful especially if you want to organize your CSS files efficiently.
This also opens up many possibilities including writing your CSS in an Object Oriented fashion. But that’s an entirely different topic.
Save your css file and navigate to your http://yoursite.com/testimonials. You should see our HTML and styles in full effect.
Let’s move on to creating a custom widget to show in different parts of our page such as the homepage.

Step 4) Create a Homepage Widget

So now we have data. We are successfully display them it a running list – which is the main “testimonials” page. Now we can use that same list – and display it in other sections of our site. I’ve seen this implemented in the sidebar, but in our case – we’re putting it in our homepage (since we’re using a custom home page template).
Now I know I mentioned “widget”, but I’m not really going to build an actual WordPress widget – which you can reuse anywhere in your site (which is the best way to do it by the way). But for the sake of this tutorial – which is getting too long, I’m simply going to output it in the page.
For a tutorial on how to create a WordPress widget based on your Post Type – I have a separate tutorial for that.
Now, in your homepage template (or sidebar, footer etc) – paste the following code:
The code above is simply HTML with a combination of PHP. The meat of this code is WP_Query() – which is a WordPress class that deals with special queries to the database. In our case, we want our post type “testimonials”, we only want 1 and we want the order to be “random”.
Note the $args array that sets up all of those requirements. Then we create an object called $testimonilas from the WP_Query() class – which we then execute like a normal WordPress loop.

Styles for our widget

Now that we have our widget that pulls just a single testimonial, we also want this presented it a different way than our archive page. Let’s paste the code below into our CSS file:

.testimonial-home h6 {
    background:#003658;
    border-radius:6px 6px 0 0;
    padding:12px 0 12px 20px;
    margin:0 0 0 20px;
    text-shadow:1px 1px 0 #000;
       color: #C4D8BC;
}
.testimonial-home h6 a {
     color: #C4D8BC;
}
.testimonial-home-inner {
    background:#F0F3F5;
    padding:35px 60px 42px 94px;
    border-radius:0 0 6px 6px;
    margin-left:20px;
    position:relative;
}
.testimonial-home-inner img {
    position:absolute;
    left:-30px;
    top:25px;
}
.testimonial-home-inner p {
    font-size:16px;
    line-height:24px;
    font-style:italic;
}
.testimonial-home-inner .client-photo{
    float:left;
    width:100px;
    height:100px;
    border:6px solid #fff;
    border-radius:50%;
    box-shadow:1px 1px 5px #A8A7A7;
}
.testimonial-home-inner p {
     color:#838383;
}
.testimonial-home-inner p.client_name {
    color:#579241 !important;
    font-family: 'Source Sans Pro', sans-serif;
    font-weight: 900;
    font-style:normal;
    margin-bottom:0;
}
.testimonial-home-inner p.company {
    color:#000 !important;
    font-family:verdana;
    font-size:11px;
    font-style:normal;
    line-height: 16px;
}

Save your CSS file and view your site homepage (or wherever you plugged the widget code in). If all is successful, you should see a box like below:

Note that the heading for this widget links to our “testimonials” archive page. Also, you also need to consider making them responsive by using a solid framework such as Bootstrap.

Conclusion

I think that covers it. We now have a working system on adding new testimonials to our company site. Now this task can be assigned to the editors of the site. All they have to do is add new entries – as if they were adding posts (which they’re already familiar with).
Oh, I almost forgot – the thumbnails for the client faces have to be a square. This is to make the perfect round shape – and make sure their faces are in the middle.

The post Create a Testimonials section for your WordPress site – the Right Way! appeared first on Michael Soriano.

Create the basic Widget

In your functions.php file, write the following code:

class Realty_Widget extends WP_Widget{
function __construct() {
	parent::__construct(
		'realty_widget', // Base ID
		'Realty Widget', // Name
		array('description' => __( 'Displays your latest listings. Outputs the post thumbnail, title and date per listing'))
	   );
}
function update($new_instance, $old_instance) {
	$instance = $old_instance;
	$instance['title'] = strip_tags($new_instance['title']);
	$instance['numberOfListings'] = strip_tags($new_instance['numberOfListings']);
	return $instance;
}
} //end class Realty_Widget
register_widget('Realty_Widget');

The above code sets up our widget class. It’s extending an already built class – called WP_Widget, which have methods that we need to override. These methods are: update(), form() and widget(). Don’t worry if you don’t know what that means exactly. It’s just the rules of creating widgets.
Now, notice above that we have a method __construct() – which just register’s our widget id, a name and a description. We overrode another method update() – which just makes ensures that we’re passing the right values to our $instance array (also makes sure we’re using the correct calculated instance).
So all we need to create is 2 more methods: form() and widget(). Let’s take care of that next.

The form() method

The method form() builds the form that we have in the admin section. What we’re building is a very simple form with 2 fields: a text field for the Widget title, and a drop down list for the number of listings we want to show:

function form($instance) {
	if( $instance) {
		$title = esc_attr($instance['title']);
		$numberOfListings = esc_attr($instance['numberOfListings']);
	} else {
		$title = '';
		$numberOfListings = '';
	}

[code above has been truncated – due to syntax highlighting error]
We can now also save this widget – because we have an update() method. Notice that our title and selection saves on click. Now let’s move to the widget() method.

The widget() method

This is the method that actually outputs our widget. This method accepts a couple of arguments – one of them is our $instance array.

function widget($args, $instance) {
	extract( $args );
	$title = apply_filters('widget_title', $instance['title']);
	$numberOfListings = $instance['numberOfListings'];
	echo $before_widget;
	if ( $title ) {
		echo $before_title . $title . $after_title;
	}
	$this->getRealtyListings($numberOfListings);
	echo $after_widget;
}

One thing to note is the $before_widget and $after_widget variables. These are, markups that appear – you guessed it: before and after the widget. You will also see $this->getRealtyListings() – which we’ll cover next.

Pull our Custom Posts

This method will do a query of our custom posts. It will only return the number of posts that we’ve saved in our widget. Add this code to our class:

function getRealtyListings($numberOfListings) { //html
	global $post;
	add_image_size( 'realty_widget_size', 85, 45, false );
	$listings = new WP_Query();
	$listings->query('post_type=listings&posts_per_page=' . $numberOfListings );
	if($listings->found_posts > 0) {

[code above has been truncated – due to syntax highlighting error]

So we have the above code which takes 1 parameter: $numberOfListings. We do an add_image_size() so we can get a custom size for our thumbnails. Also note where we’re querying the post_type of “listings”, you can change this value to your own post type (or not even use it for default).
The code then continues building the HTML output of list items containing our post thumbnail, title and date added.

Add some CSS

Our CSS is pretty straightforward, just keeping the elements in the right place. You also might want to use your own styles, so I’ll just post the code that I used, without further explanation.

.noThumb{
  width:85px;
  height:45px;
  background-color:#000;
  float:left;
  margin:0 12px 0 0;
}
ul.realty_widget {
  margin-top:10px;
}
ul.realty_widget li {
  margin:0 0 15px 0;
  list-style:none;
  min-height:45px;
  line-height:19px;
}
ul.realty_widget li img{
  float:left;
  margin:0 12px 0 0;
}
ul.realty_widget li a {
  font-weight:bold;
}
ul.realty_widget li span {
  display:block;
  font-size:11px;
}

So with the above styling, our final output looks like below:

Conclusion

So there you have it. We have added a widget to our WordPress theme that pulls our custom post types. As mentioned, this technique will work with regular posts as well. I have updated the Realty theme files to include this code – so you can go ahead and download it if you like. Please let me know in the comments if this tutorial helped your development in any way.

The post Let’s make a WordPress Widget that displays our Custom Post Types appeared first on Michael Soriano.

Build the Form

As I’ve mentioned, we are working with custom post types and taxonomies. For this tutorial, we are working with a post type named “Listings”. We have also attached several taxonomies to this post type – named: “Type“, “Rooms“, “Area” and “Price“.
As you can imagine, a Real Estate website will have visitors who wish to search through your listings that match only the ones that are “Single Family“, “3 Bedrooms“, in “Chicago, IL” and “under $100,000“.
So you see how this can be real handy.

So first we write a function that will return html. Let’s use WordPress function get_terms() to populate our select tags. In your functions.php, add the code below:

The above function will run get_terms() on the Taxonomy passed, and will return several option tags with the term slug and name in it. So in your template (where you want your form to appear), create a form and use the function we just created.

Test your form and see your drop down lists populate with the right Taxonomy terms. If not, make sure you’ve added the right terms for each Taxonomy in your blog.
Also note the form action “/listing-search-results/“. This is a page we have yet to build – one that will handle the form processing. We will cover that in the next section.

The Processing

You will need to create a page template – name it “Custom Search Results“. For information on how to create page templates for your theme, click here. Now, on this page – start with the code below:

The code above creates two empty arrays. $item is filled up with each $_POST key and value, and added to the $list array. $cleanArray is a merge with “relation” key with value “AND” to our existing $list array.
So once a user selects items from our drop down lists and submits the form, it should supply the values needed for our arrays. Do a print_r() on the $cleanArray and the output should be similar to below:

Now we have enough to query our database with. Add the lines of code below:

The above code sets up a few more variables. These are the needed arguments we need to pass into the WP_Query object – which does all the querying.
As you see, we’re querying post_type “listings” and returning only 9 items. “paged” is needed for pagination to work, and the main argument “tax_query” – tells the object to query taxonomies. Also note that inside WP_Query is plenty of data sanitation – so data is clean once passed.

The Output

So once data is sent to the WP_Query object, all we need to do is loop through it and display the output. Our WP_Query object (now $the_query) has all the methods to produce the needed results. Add the code below:

The code above behaves like a normal WordPress loop. So insert regular template tags inside the “while” loop and your output should render. Notice the use of post navigation (next_posts_link) in the bottom of the code? It should behave like normal posts pagination in WordPress.

Our results page with formatting etc.

Conclusion

There you have it. An advanced search form that will filter through your custom post types. You can display this search form in any part of your website – ideally in your sidebar or header area. I especially like this treatment because it highlights your custom post type all the more. Making it really stand out from your regular blog posts.

Useful Resources:

Make sure you go through these links to better understand what the code above does.

1. WordPress Codex – WP_Query
2. Advanced Taxonomy Queries – Ottopress
3. Advanced Search Form Filters – WPAnswers

The post How to Create an Advanced Search Form for WordPress appeared first on Michael Soriano.

Lock Down the Registration Process

Now that you have your site open for registration, it is best that you install these plugins first to enable tighter security:
Secure WP – as many options that this plugin comes with to enhance security, what I especially need it for is to disable the error messages at login (which this plugin does very well)
SABRE – stands for “Simple Anti Bot Registration Engine”. This produces that image during registration to block “autobots”.
Limit Login Attempts – the plugin title says it all. Activate this plugin and tweak depending how tight you want login attempts. Note that you’re not going to see any error messages due to the Secure WP plugin.

Hide the WP Admin Panel

So registration is open, security is tight – you still don’t want users to see your WordPress admin area. Not that there’s anything wrong with that – but it just looks more sophisticated when all is done in the front end. Install the following plugins:
Theme My Login – this plugin will generate a page called “Login” – this is where your new login forms (includes new registration and forgot password) will sit. Additional options also include custom emails, redirection and moderation. *Make sure you check “Enable Template Tag” under “Optimization” – You’ll need this in your theme later.

Theme My Profile – plugin created by the same author, which ports the users “profile” page into the front end. Make sure you theme and block admin area ONLY for roles you want.
The following screenshots show the login page, as well as the profile page generated by the plugins that I’ve mentioned:

TDO Mini Forms

We’ve come to the meat of the project. This is the plugin that does all the magic. TDO Mini Forms allows users (registered on not registered) to submit and edit posts to your blog. It comes with its form creator that lets you design the post submission form any way you want. Widgets that let you drag and drop components into your form, as well as a form “hacker” that allows even deeper code tweaking. What I especially liked is that it hooks up with your “Akismet” for spam protection.

After specifying all the configuration settings with TDO, go ahead and create a form with “Form Creator”. The form creator is a somewhat decent drag and drop interface where you grab the widgets in the bottom and drag it to the form. Widget settings are applied by clicking on the settings tab and it brings up the settings window as shown below:

Once you’ve decided on the fields and the settings, you can now alter the code to change the verbiage, along with adding HTML elements in order to be able to style it in your stylesheet. Below shows my contribute form:

Maybe some Custom Code

Depending on your pages – you might need to add some PHP conditional tags and functions to the theme manually. This is to link the new pages to each other. Simply copy your theme’s page.php file and rename it to something.php – convert it into a template by adding the code on top of the page:

Now below the call for the content, add the conditional tag with from the Theme My Login plugin:

The screenshot below shows the custom link to the contribute form that we just created:

All you have to do now is to wait for guest post submissions and depending on the content – simply approve, edit or deny. The submissions are saved as draft posts and are in the moderation view of TDO mini forms:

Conclusion

Now that you have converted your blog into a more automated (and sophisticated) posting process – think of all the possible scenarios you can create. Of course I’m completely aware that my guest posts will not land any successful submissions any time soon – it’s just good to know that it’s available. Not to mention, it was fun to make.

The post How to automate the WordPress Guest Posting Process appeared first on Michael Soriano.

What is FlowPlayer?

FlowPlayer is an open source video player for the web. It is a way for you to stream videos in your pages, from your own server. Thus, eliminating the need for external video serving services such as YouTube. FlowPlayer is highly extensible and customizable. Though it may take a little more than a few clicks – the benefits far outweigh the work needed to get it running. Consider these pros and cons:

Pros:

No Links to External Sites – As I’ve mentioned, this alone is enough reason to use FlowPlayer. Your visitors cannot escape your website when video is live. They stay in your site during playback and when clicked. In addition, you can configure your player to use custom events (see below)
CSS Skinning and Branding – You can totally change the appearance of Flowplayer. This includes player controls, backgrounds and logo (custom logo is supported in the “Commercial” version). Best of all – skinning FlowPlayer follows strict web standards using simple HTML and CSS. Check out this demo using a billboard sign as the background of the player: http://flowplayer.org/demos/skinning/container-background.html.

Set your own Splash Image – one of the annoying things about Youtube is it automatically selects the splash image for you. With Flowplayer you can select a high quality image as the splash state – before the actual player loads.
You can add your own Events – configure your player to do more than just playback videos. Examples can be adding captions during playback, extracting clip information as well as chaining video clips to play one after the other. See some examples of events here.
Extend with Plugins – Plugins are already made functionalities that other developers have created and made available for you to download. Examples of kick ass plugins are Flash Content, Javascript Embed and Streaming Slow Motion.

Cons:

Need some HTML experience – you will need to touch the source code of your pages to use. For advanced functionality – scripting technologies such as javascript and flash is also required
You need to convert the videos locally first before uploading – at the time of writing, FlowPlayer supports FLV, H.264 and MP4. You will need to convert your video to the said formats before uploading. Check this article for good information on Flash Video Conversion: http://worldtv.com/blog/guides_tutorials/flv_converter.php
Bandwidth – Since videos are served locally you may see an increase in bandwidth usage.

How to use FlowPlayer

What I really liked about FlowPlayer is their extensive documentation. It includes walkthroughs for beginners, as well as in depth instructions for the expert programmers. To start using FlowPlayer – all you need is to do the following:
1) Download the FlowPlayer Files – This download includes the actual FlowPlayer .swf files as well as the .js file to get you started. It also includes an HTML page that demonstrate the basic installation of FlowPlayer.
2) Include the flowplayer.js in your HTML:

3) Setup the player container – Simply add an anchor tag with 3 important attributes: a) href – the pointer to the video file, b) style: determines the size and basic display properties of the player and c) id: very important – this acts as a selector for the javascript to target to load the player.

4) Install Flowplayer – The final code tells FlowPlayer to install in our anchor tag:

FlowPlayer and WordPress:

Oh yes – you can actually embed Flowplayer inside your posts. The beauty of it is – there are actually several Flowplayer plugins already available for WordPress. Though I’m just going to cover the two most popular:
FV WordPress Flowplayer – developed by Foliovision, is a straight forward FlowPlayer plugin made exceptionally easy. All you need is to install, upload your video and add the plugin shortcode to your posts. Note that this is the plugin I’m using for my video demo above. The screenshot below shows the plugin options page:

Flowplayer for WordPress – created by David Busby of Saiweb, this plugin also includes player customization features as well as commercial license key input for advanced settings:

Embed FlowPlayer in your Theme:

If you’re like me, you may come across a website project that requires videos hosted in their own server. Of course WordPress and FlowPlayer is a good combination. What about if the requirements for the player are so extensive that may not be achieved with any sort of plugin? This is when you’d want to embed FlowPlayer in your theme.
The process is pretty much the same as the basic FlowPlayer installation. The only difference is we’re using custom fields for the href attribute of our player. In your theme folder, edit single.php and include this code inside the loop:

This sets up a default player for each post, wrapped in an “if” block. This way you customize the page to your client’s extensive requirements. A screenshot of my page mockup is shown below:

Don’t forget the call to install FlowPlayer:

Now all you need to do is upload the movie using the default WordPress media uploader, and plug in the url in a custom field set to “movie”

Conclusion

If you haven’t already noticed – almost every aspect of FlowPlayer can be customized. Having this much control over video content is invaluable and cannot compare to services like YouTube. Best of all, the basic version is free under the GPL license which you can use for personal or commercial purposes. Note that there are also paid versions that determine the amount of branding you can as well as legal domain usage. Head on over to FlowPlayer’s website for more information.

The post Embed Videos in your Web Pages with Flowplayer! appeared first on Michael Soriano.