WordPress Archives - Michael Soriano

How to create an Accordion Block using React and WordPress’ Block API

Michael Soriano — Mon, 06 Nov 2023 23:03:50 +0000

I was tasked with creating a custom component for our public website which runs on WordPress. Most commonly known as an “Accordion“, it is a section of a page where you can have a title and an expandable and collapsible directly underneath it. Usually a list of these items are blocked together – forming an “accordion” like pattern.

In HTML, this is easily achieved by the “Details” element. But of course, our users cannot write HTML. Similarly, a default block already exists in WordPress called “details“. The problem with this one is that our users do not find it intuitive. Also, they want to limit the formatting of the contents for each item.

You see how each item is contained within a big block. A button will add a title/content pair to the list – along with a checkbox that allows for the section to be expanded or collapsed by default.

Register the Block

This is the “housekeeping” part of the codebase. There is a PHP part of this process – and it really depends if you’re putting this in a plugin or a theme. But main function is below:

register_block_type(
    'namepsace/my-blocks-accordion',  // Block name with namespace
    [
        'style' => 'accordion-style',  
        'editor_style' => 'accordion-edit-style', 
        'editor_script' => 'accordion-js'  
    ]
);
...

Also, there are other parts of this such as enqueuing the styles and scripts for your blocks – which I’m not going to cover here. We’re mostly focusing on the “client” or JS side of things.

To read more about registering blocks in WordPress – see the codex.

For the JavaScript, create a file called index.js and start with the registerBlockType() function. If you’re not familiar with how to build blocks for WP – this is a good start Anatomy of a Block | Block Editor Handbook | WordPress Developer Resources.

registerBlockType(
    'namespace/accordion', {
      title: __('Accordion'),  
      icon: 'list-view',
      category: 'my-blocks', 
      attributes : {
        items : { 
         type: 'array',
         default : []
     }
    ...
}

Pay extra attention to the “attributes” object. This is the main “context” of our application. Notice that we want an array called “items” inside attributes – this is where we’ll manage our data.

The “Edit” Component

So in Gutenberg Blocks, the two major components that we have to worry about is the “Edit” and “Save”. Edit is what you see during the editing of Posts or Pages. Let’s look at how to build this first – particularly the JSX section:

const { RichText } = wp.editor;  
const { __ } = wp.i18n;

...

title: __('Accordion'),  
icon: 'list-view',
category: 'my-blocks', 
attributes : {
   items : { 
     type: 'array',
     default : []
   }
},
edit ( {className, attributes, setAttributes} ) {

... 

return (

{attributes.items && attributes.items.length > 0 ? attributes.items.map((item,i) => {
return (

    
     updateItemTitle(val,i)}
    />
    
    updateItemExpand(e)} />
        Expanded
    
    
     updateItemContent(val,i)}
    />

)
}) : null}


);

} //END EDIT

The HTML above is the UI for our editors. Notice that we’re going through out “items” and outputting it for action. We’re using the built-in RichText component for our editable sections (title and content). RichText is awesome – find out more about it. We’re also including a checkbox called expanded – that will allow our users to show the item expanded or collapsed.

Adding Items

When first using the block – all you see is a button that says “Add Accordion Item“. Clicking this button will execute below:

const addEmptyItem = () => {
    const items = [...attributes.items, {
      title : '', 
      content : '', 
      expand : true
    }];
   setAttributes({items})
}

This will add an empty object to our Attributes Items array, allowing our users to be able to edit our RichText components.

Click and Change Handlers

If you look in our JSX, we’ve mapped our inputs to event handlers. Add the code below”

const updateItemExpand= (e) => {
    const items = attributes.items.slice();
    const index = e.target.attributes.getNamedItem('data-index').value;
    items[index].expand = e.target.checked;
    setAttributes({items})
}
const updateItemTitle = (title,i) => {
    const items = attributes.items.slice();
    items[i].title = title;
    setAttributes({items})
}
const updateItemContent = (content,i) => {
    const items = attributes.items.slice();
    items[i].content = content;
    setAttributes({items})
}

The function names are pretty self explanatory. All we’re doing is manipulating the data in our Attributes. Also notice the setAttributes() function we’re using in each function. This is a “setter” that is very similar to React’s useState setters.

With all that in place, our Accordion block is ready for editing:

Typing “/accordion” will insert our block – ready for editing.

The “Save” Component

This is simply JSX that outputs our HTML for the public users. The code for this is quite simple – we’re simply using “details” and “summary“. This automatically has the expand and collapse functionality out of the box.

save( { attributes } ) {
    return (
        
        {attributes.items && attributes.items.length > 0 ? (
            attributes.items.map(item => {
                return (
                    
                    {item.title}
                     
                    
                )
            })
        ) : null}
        
        )
    } 
}

Notice the use of dangerouslySetInnerHTML – because we’re outputting HTML content from WordPress. If this can be done in other ways leave a comment below.

Styling the output with some CSS:

.wp-block-my-blocks-accordion {
    margin-bottom: 25px;
}

.wp-block-my-blocks-accordion details > summary {
    background:url('/images/arrow-down.png') no-repeat;
    background-size: 13px;
    background-position-x: right;
    background-position-y: 10px;
    font-weight: 500;
    border-bottom:1px solid #ebebeb;
    margin-bottom: 10px;
    padding-bottom: 6px;
    cursor:pointer;
}
.wp-block-my-blocks-accordion details[open] > summary {
    background:url('images/arrow-up.png') no-repeat;
    background-size: 13px;
    background-position-x: right;
    background-position-y: 10px;
} 
.wp-block-my-blocks-accordion details > summary:hover {
    opacity: 0.6;
}  
.wp-block-my-blocks-accordion details > summary > * {
    display: inline;
}

We’re simply overriding the default look of the details component – specifically the arrows. I prefer to see them in the right instead of left. Also, adding a subtle border to make it look better.

And with that in place – it should look like below when the post is saved:

There you have it. We’ve just made our own custom Gutenberg block. This was pretty fun to build – and learning about the Block API is quite straightforward. It’s very much like classic React – but simpler.

Be sure to leave your thoughts below.

The post How to create an Accordion Block using React and WordPress’ Block API appeared first on Michael Soriano.

Let’s build a WordPress theme with React: Part 3 (The Loop)

Michael Soriano — Thu, 03 Oct 2019 21:24:06 +0000

Okay its been a while since I last posted. Let’s continue with Barebones React WP theme. The last time we left off, we introduced the concept of “The Loop“. But we really didn’t get into what its all about. Let’s describe what this piece is doing.

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 = {context.appError};
    }else{
      if(pos.length === 0){
        results = no results;
      }else{
        results = pos.map(function(item,i){
             return 
           })
      }
    }
    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 (
        
            {item.title.rendered}
            
            
        );
};

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:

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 (
        
        
        
        Page
             of
            
        
    )
}
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.

Let’s build a WordPress theme with React: Part 2 (Routes + Context)

Michael Soriano — Mon, 15 Jul 2019 04:10:50 +0000

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 (
        
            this is the page component
        
    )
}
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(

    
     
    
  , 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:

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:

this is the slug: {props.match.params.slug}

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 = (
    
      
           
           
           
           
           
      
    
  )
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 (header)
}
export default Head;
/******Foot.js*************/
import React from 'react'
function Foot(){
    return (footer)
}
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 (
        
            
            Home
            
        
    )
}
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 (
      
        {this.props.children}
      
    );
  }
}

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 (
      
        {ctx => }
      
    );
  };
}
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 {item}
       })
    );
};
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 (
    
    
      
      
      
    
    
  )
}
export default Single

You see how we’re wrapping everything in ““, 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:

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.

Let’s build a WordPress theme with React: Part 1 (Setup)

Michael Soriano — Tue, 21 May 2019 16:38:24 +0000

It’s been a while since I worked with WordPress, especially building themes. This time around, I wanted to bring in a bit more modern development experience into the process. I wanted to build a Single Page Application (SPA), with WordPress’ Rest API – but as a WordPress theme. The problem is, this can be a pain to setup. Especially with the build step and all.

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:

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.

How to Build a Company Timeline using Bootstrap and WordPess REST API

Michael Soriano — Fri, 27 Jul 2018 19:08:32 +0000

So our Company wanted to build a Timeline. One that shows our projects throughout the years, decades even. One that is sleek, modern and responsive. We’re already running WordPress, and have Bootstrap installed. So this shouldn’t be too bad. It turns out – it was a pretty fun project to build.

Our in house designers are responsible for the design of this page. It’s a little bit of Facebook’s original timeline layout – but a lot simpler and minimalist. Here is a preview of how it looks:

In a nutshell, this is what we’re going to accomplish: We’re going to use custom post types (CPT) for each entry in the Timeline. We’re grabbing them via JavaScript – using the WP Rest API as the endpoint. We’re also using Boostrap’s grid system – so our timeline behaves well in mobile.

We are going to build everything as part of the theme. For more advanced users – you can also build it as a plugin.

Note that you have to be familiar with WordPress, PHP and Front end to follow. There is no download for this – you simply have to follow along.

Ready to get started? Let’s begin:

The Back-End

First off, let’s take care of the data. We need to register the CPT with WordPress and make sure we have the right custom fields. Actually, we only have one custom field necessary – and that is the year. The year is what the timeline is sorted by (newest to oldest).

Open up functions.php in your theme. First let’s add the CPT initialization.

function registerTimelineCPT() {
        $labels = array(
            'name' => __( 'Timeline' ),
            'singular_name' => __( 'Timeline' ),
            'add_new_item'       => __( 'Add New Timeline'),
            'new_item'           => __( 'Timeline'),
            'edit_item'          => __( 'Edit Timeline'),
            'view_item'          => __( 'View Timeline'),
            'all_items'          => __( 'View All'),
        );
        register_post_type( 'timeline',
            array(
                'labels' => $labels,
                'public' => true,
                'has_archive' => false,
                'rewrite' => false,
                'publicly_queriable' => true,
                'exclude_from_search' => true,
                'show_ui' => true,
                'show_in_nav_menus' => false,
                'show_in_menu' => true,
                'show_in_admin_bar' => false,
                'menu_icon' => 'dashicons-backup',
                'show_in_rest' => true,
                'public' => false, //removes the "permalink"
                'supports' => array(
                    'title',
                    'excerpt',
                    'thumbnail',
                    'custom-fields'
                )
            )
        );
        //REMOVES COMMENTS
        remove_post_type_support( 'timeline', 'comments' );
}
add_action( 'init', 'registerTimelineCPT' );

Above, we’re simply creating our CPT called “Timeline”. We’re setting up the labels, what it supports and what it doesn’t support. Upon logging in you should see a “Timeline” in your admin area.

Now for the custom fields – you can easily add this the default way according to WordPress. In my case, I wanted to make it easier for the users to update – so I’m using this plugin called “Meta Box“.

Our custom field is now easier to set up and become much cleaner to the users.
If you have MetaBox installed, adding the field is as simple as below. This goes into your functions.php.

function createMetaBoxes($meta_boxes ){
	$prefix = 'tl_';
	$meta_boxes[] = array(
		'id' => 'timeline_metabox',
		'title' => esc_html__( 'Other', $prefix ),
		'post_types' => array( 'timeline' ),
		'context'    => 'normal',
		'priority'   => 'low',
		'autosave'   => true,
		'fields'     => array(
			array(
				'name' => esc_html__( 'Timeline',  $prefix  ),
				'id'   => 'timeline_year',
				'label_description' => esc_html__( 'Year', $prefix ),
				'type' => 'range',
				'min'  => '1930',
				'max'  => date("Y"),
				'step' => 1,
				'std'  => date("Y"),
			)
		)
	);
	return $meta_boxes;
}
add_filter( 'rwmb_meta_boxes', 'createMetaBoxes' );

Now if you go to the Timeline page, you should see our nice range slider:

We’re also using the following default WordPress fields:

Title
Excerpt
Featured Image

So as you’re following along, go ahead and add several timelines and make sure these fields are filled out.

REST Endpoint

Before we can call our Timelines through REST, we have to do some setup. Still in functions.php, add the code below:

function restProperties(){
	register_rest_field( 'timeline',
		'timeline_year',
		array(
		   'get_callback' => 'registerRestCb',
		   'update_callback' => null,
		   'schema'          => null,
		)
	 );
	function registerRestCb($object, $field_name, $request){
		return get_post_meta( $object[ 'id' ], $field_name, true );
	}
}
add_action( 'rest_api_init', 'restProperties');

So the above makes the ‘timeline’ available as and endpoint in REST. Also, we’re adding the ‘timeline_year’ as a property in the response. To find out more about WP REST API, check their documentation.

Now, when you hit the endpoint: YOURURL +’/wp-json/wp/v2/timeline?_embed&per_page=100‘, you should now see data as a JSON string. This is enough for us to work with in our Front End. Let’s go do that now.

The Front-End

Before we continue, I forgot to mention the libraries that we need to work with:

jQuery
Bootstrap
Handlebars

Markup

I’m going to add the markup first (the handlebar templates), then we’ll move on to the logic.

This is the main template:

As you can see, we’re using the Bootstrap col classes to make each item responsive. We’re also using pull classes – so the alternate item will be pulled to the left.

The decades scroller:

Nothing fancy here, just a list of decades that is clickable.

Lastly, let’s build the wrapper:


  
       Getting Items

The above markup simply holds the timelines together. It also has the text “Getting Items” – which acts as our loader – until our AJAX call completes. Also, we have a “show more” button – so that when clicked – the rest of the items appear in the bottom.

So the above is our HTML. Now we need JavaScript, which is described below.

Getting and Grouping the Items

This is where we pull the data from our REST endpoint, and pass it on to the handlebars templates that we’ve created. We also need additional logic – specifically grouping the decades together to build the scroller.

Let’s grab our items via .ajax():

$(document).ready(function(){
	$.ajax({
		url : '/wp-json/wp/v2/timeline?_embed&per_page=100',
		success : function(data){
                        console.log(JSON.parse(data));
			//TODO :compileTemplates();
			//TODO: bindDecadeScroller();
		},
		error : function(data){
			console.log('Error in fetching timeline...')
		}
	})
});

All things are happening inside the document ready handler. Now if you refresh your browser, you shall see our data in a parsed JSON object.

Now that we have our objects in place, remove the console.log() line that we have. We have 2 TODOS: functions that we haven’t built yet, namely compileTemplates() and bindDecadeScroller(). You can guess what both of them do.

Let’s add the first function compileTemplates():

function compileTemplates(data){
	var parsed = JSON.parse(data);
	if(parsed.length > 0){
		var obj = buildTimeline(parsed);
		var source  = $("#timeline-template").html();
		var source2 = $("#timeline-decades-template").html();
		var template = Handlebars.compile(source);
		var template2 =  Handlebars.compile(source2);
		$('.timeline-decade-links').html(template2(obj));
		$('.timeline-wrapper').html(template(obj));
	}
}

The above simply compiles the JSON data and hands it over to our templates. This alone should get our views going. But don’t refresh the browser yet. There are plenty of logic that still needs to happen.

Notice the new function in line 4 called “buildTimeline()“. On top of that, we have Handlebar helpers that we haven’t registered – so the browser will actually throw a fit. This will be covered in the section below “View Helpers“.

Let’s build the function called buildTimeline():

function buildTimeline(data){
    function comp(a, b){
        return b - a;
    }
    function compYear(a,b) {
        if (b.year < a.year)
            return -1;
        if (b.year > a.year)
            return 1;
        return 0;
    }
    function grabImg(el){
        var src = '';
        if(el._embedded){
            if(el._embedded['wp:featuredmedia']){
                src = el._embedded['wp:featuredmedia'][0]['source_url'];
            }
        }
        return src;
    }
    $.each(data, function(){
        $(this)[0].timeline_year = parseInt($(this)[0].timeline_year);
    })
    //add decade:
    $.each(data, function(){
        var year = $(this)[0].timeline_year;
        $(this)[0].timeline_year_decade = Math.floor(year / 10) * 10;
    })
    //group decades:
    var decades = [];
    $.each(data, function(){
        decades.push($(this)[0].timeline_year_decade);
    })
    var uniqueDecades = [];
    $.each(decades, function(i, el){
        if($.inArray(el, uniqueDecades) === -1) uniqueDecades.push(el);
    });
    decades = uniqueDecades.sort(comp);
    var clean = Array();
    var final = Array();
    $.each(data, function(i, el){
        var obj = {};
        obj.id = el.id;
        obj.img = grabImg(el);
        obj.title = el.title.rendered;
        obj.excerpt = el.excerpt.rendered;
        obj.year = el.timeline_year;
        obj.year_decade = el.timeline_year_decade;
        clean.push(obj);
    });
    clean = clean.sort(compYear);
    $.each(decades,function(i,el){
        var key = i;
        final[key] = Array();
        $.each(clean,function(x,xel){
            final[key]['decade'] = el;
            if(xel.year_decade == el){
                final[key].push(xel);
            }
        })
    })
    return final;
}

Okay this is the meat of our logic. We’re trying to grab all of the years in our timelines. And from each of those years, we need to calculate the decade, take out the duplicates and stuff them back to a final array, grouped by decade.

In lines 31-34 is where we calculate the decade, then stuffing it to a new property called “timeline_year_decade“. Then we’re doing a couple more loops to remove duplicates, sort and create a clean “decades” array – which we need for our final loop in lines 66-75.

Refresh your browser and see what our “final” array looks like.

Now we our compileTemplates() is done, let’s go and register our helpers and do some CSS.

View Helpers

Now we have to do add more scripting to determine additional classes that makes our timeline look the way it does.

In case you haven’t noticed, our templates are sprinkled with helpers for handlebars. Let’s register those helpers now.

Handlebars.registerHelper('leftOrRight', function(index) {
	return index %2 == 0 ? 'left' : 'right';
});
Handlebars.registerHelper('closeWrap', function(index) {
   return (index+1) %2 == 0 ? '' : '';
});
Handlebars.registerHelper('pull', function(index) {
   return index %2 == 0 ? '' : 'col-lg-push-4 col-md-push-4 col-sm-push-4';
});
Handlebars.registerHelper('showingOrNot', function(index) {
	if(index == 0){
		return 'showing';
	}
});

The above are view helpers – that cooperates with the HTML templates that we just built. For instance, the “leftOrRight” helper – determines if a class of “left” or “right” is to be added. Below are the images for that:

Left Line:

Right Line:

Arrow up:

Vertical Line:

The Styles

Finally, the styles that make our timeline look good. I’m not going to walk through what each style does. I’m just going to add this as a reference for you to plugin. You might have a different style depending on your preference.

.timeline-wrapper {
    position:relative;
    z-index: 99;
}
.decade-wrap {
    overflow:hidden;
    clear:both;
    display:block;
    background:url('vertical_line.png') #fff repeat-y;
    background-position-x: center;
}
.decade-wrap:first-child {
    padding-top: 40px;
}
.decade-wrap:last-child{
    margin-bottom: 75px;
}
.decade-wrap h1 {
    text-align: center;
    background:#fff;
    padding:25px 0 35px;
    font-size:45px;
    color: #0077C8;
}
.timeline-thumbnail {
    background-position-x: center !important;
    background-position-y: center !important;
    background-size: cover !important;
    height:319px;
}
.timeline-item,
.timeline-inner-wrap {
    padding-left:0;
    padding-right:0;
}
.timeline-left {
    background:url('left_line.png') no-repeat right center;
    margin-left: 8px;
}
.timeline-right {
     margin-top: 100px;
    background:url('right_line.png') no-repeat left center;
    margin-left: -15px;
}
.timeline-inner-wrap {
    padding-top: 25px;
}
.timeline-year {
    position: absolute;
    top: 39%;
    font-size:30px;
    font-weight: 500;
    color: #0077C8;
}
.timeline-right .timeline-year {
    padding-left: 35px;
}
.timeline-left .timeline-year {
    right:0;
    padding-right: 34px;
}
.timeline-title {
    font-size: 19px;
    font-weight: 500;
    color: #000;
    padding-top: 15px;
    padding-bottom: 10px;
}
.timeline-decade-links {
    background:#ececec;
    min-height: 60px;
    display: flex;
}
.timeline-decades-link-item {
    width: 100px;
    margin: 0 auto;
    text-align: center;
    font-size: 18px;
    padding-top: 18px;
    height: 60px;
}
.timeline-decades-link-item a:hover,
.timeline-decades-link-item a:focus{
    text-decoration:none;
}
.timeline-decades-link-item.showing {
    background:url('arrow-up.png') transparent no-repeat center bottom;
}
.timeline-decade-links-wrapper {
    overflow: hidden;
}
.timeline-decade-links-wrapper.fixed {
    position: fixed;
    top: 0px;
    z-index: 110;
    left:0;
    width:100%;
}
.admin-bar .timeline-decade-links-wrapper.fixed {
    top:32px;
}
@media(max-width:1199px){
    .timeline-thumbnail {
        height:253px;
    }
    .timeline-item {
        background-position-y: 33%;
    }
    .timeline-year{
        top: 21%;
    }
}
@media(max-width:991px){
    .timeline-thumbnail {
        height:190px;
    }
    .timeline-item {
        background-position-y: 28%;
    }
    .timeline-year{
        top: 18%;
        font-size: 23px;
    }
    .decade-wrap h1 {
        padding: 14px 0 24px;
        font-size: 31px;
    }
}
@media(max-width:768px){
    .timeline-thumbnail {
        height:354px;
        width:410px;
    }
    .decade-wrap {
        background:none;
    }
    .decade-wrap:first-child {
        padding-top:0;
    }
    .decade-wrap h1 {
        padding: 0px 0px 0px 0px;
    }
    .timeline-right {
        margin-top: 0;
    }
    .timeline-item {
        background:#fff;
        margin-left: 0 !important;
        margin-right:0 !important;
    }
    .timeline-year {
        position: relative;
        padding-left: 0 !important;
        padding-right:0 !important;
    }
    .timeline-decade-links {
        display: none;
    }
}
@media(max-width:500px){
    .timeline-thumbnail {
        height:302px;
        width:auto;
    }
}
@media(max-width:375px){
    .timeline-thumbnail {
        height:242px;
    }
}

After our helpers apply the classes, our CSS and images in place – Bootstrap will take care of the rest. If you refresh, you should see your timeline. Inspect and you see our classes applied.

Finally, let’s go ahead and bind that scroller:

function bindDecadeScroller(){
	 $('.timeline-decades-link-item a').on('click',function(){
		var id = $(this).attr('href');
		var offset = ($(id).offset().top - 150) ;
		$('html, body').stop().animate({
			scrollTop: offset
		}, 1000);
		return false;
	})
}

This should have a smooth animating effect when you click on the decades on the scroller. Note that our timelines are grouped by decades, encapsulated in a DIV with the ID – of the decade. So when our scroller is cicked – it has the ID of the DIV in it’s href attribute.

So technically, even without our animation – it will know where to focus naturally.

We’re using .animate() to make that jump smoother. Check jQuery’s documentation on .animate for more information.

Conclusion

And there you have it. We’ve just build a pretty cool timeline – grouped by decades, with a scroller that focuses on the decade when clicked. This is also responsive – so it looks real good in a mobile device.

Note that this is a pretty basic timeline – which you can greatly enhance by adding other things. For example, you can add a modal for more details for each of the item. Or even multiple images per item – one that you can scroll left to right like a slideshow. There are many possibilities.

For the live page, check out the Parsons timeline page. I hope you enjoyed this tutorial. Leave your comments below.

The post How to Build a Company Timeline using Bootstrap and WordPess REST API appeared first on Michael Soriano.

New WordPress Starter Theme using VueJS

Michael Soriano — Sat, 17 Feb 2018 19:21:18 +0000

I’ve been building WordPress themes for quite some time now. And with the advent of front-end frameworks and WP’s REST API, I thought it would be a good combination to build one that uses both. The benefits would be that the site’s user experience would be lightning fast. There wouldn’t be server page loads (except for the first one).

So all subsequent navigation will be done in the client side. This results to a smoother and better user experience.

View in Github

I wanted to build several themes, but would like a base theme to start with. Enter wp-vue-starter. A starter theme that is built on a popular framework called Vue, and WP’s REST API in the background.

Note that since all of the rendering is done in the client, SEO is not going to be available. But for sites that SEO will not matter, I think this is a good choice. Let me explain the theme design and structure and maybe you can use the theme in your next project.

Traditional Blog Design

If you do a search on WordPress Theme and Vue, there have been many attempts on it. This however, is slightly different. First of all, is the design. It uses the traditional blog design that many of us WordPress users have grown to like.

Here is a screenshot of the homepage:

As you can see, it has a “static” page that is called “home”. There is a big area (jumbotron) for your carousel or hero image, while the latest posts are directly below it. The CSS framework is Bootstrap (version 4). So editing the grid and elements is familiar to many. A sidebar is built in – which is pretty standard to most sites.

What is a site without “Search”. That of course is also included. A search form is in the header, and is a component called “search-form”. So this component can be used in the sidebar, footer – where ever you want the form to be.

The search results look look like below:

Also notice the paging. The paging system is inside a component called “the-loop”. For many of us theme developers, the “Loop” is the basis of a template inside a theme. So I wanted to keep the same concept here. So you will see the “archive” and “search” is basically using “the-loop” component, because it shares the same properties.

Single, Page and Comments Form

The “single” post page is also a Vue component. This accessed using the slug:

/post/post-name

The “page” page is another component, and can be accessed by:

/page/page-name

So the urls are not exactly as the traditional WordPress urls, but is quite clean in my opinion. So you need to update your permalink structure in WordPress to /post/%postname%/:

So you can still access most of the admin functionality such as viewing pages, posts and previewing.

Below is an example of the single page.

In addition, to the content – is the comments. This theme is built with the comment responses and the form in it. It is pretty basic in design – very “Bootstrapy”. But again, this is a starter theme – so what do you expect.

Theme Structure

So if you’re going to use wp-vue-starter, chances are, you’re going to edit it. So let’s go over the structure briefly. Note that you need to know WordPress and Vue a little bit to dive into this.
Everything goes in through index.php.

This is where your entire HTML wrapper is. From the opening HTML tag, header and footer is inside here. You will also see that all of the templates are included in this page as “template” tags.

This is also where the DIV called “app” is – so Vue is inserting the entire application into this DIV. The styles.css in the root is nothing but a marker. It just tells WordPress about the theme name and such.

There are actually no styles in here. Instead, the styles go into /css/dist/main.css The main.js is where all of the JavaScript logic is. This is where the components are declared, all of the methods as well the routing. If you want to change Vue or JS logic, this is the right file. Below shows a sample of the route mapping system.

Normal WordPress functions go inside the functions.php. This is where you will see modifying REST responses and such. Note that by default, the theme is allowing anonymous comments – so you might want to change this.

Lastly, inside the “templates” folder – are the components. They’re PHP files, but there’s no PHP logic in them. I just left it like that for consistency – and just in case you want to add some PHP in it, you can. The files resemble a traditional WordPress theme. Like 404, page, single, search etc.

Lastly, the “partials” are the files with the underscore prefix. So this the _header, _footer, _sidebar. Note that this “header” is the html header – not the “”.

Installation

Installation is the same as any other theme. Simply upload and activate (don’t forget to update the permalinks). You can also use SASS – for CSS preprocessing. This is included by default, and is the best way to edit CSS. The source files are inside /src and output is /dist.

Gulp is the default build tool, so you can run

npm i -D gulp gulp-sass gulp-sourcemaps gulp-clean-css

For the SASS compiler and CSS clean up.

The theme is under MIT license, and is available in GithHub. I will be adding more features such as additional templates etc., so stay tuned.

The post New WordPress Starter Theme using VueJS appeared first on Michael Soriano.

Convert WordPress default Gallery into a simple Carousel without a plugin

Michael Soriano — Sat, 02 Sep 2017 17:57:04 +0000

I had the fun task to turn the default WordPress gallery into a carousel. Our users didn’t really like the grid of images, that WordPress ships with. Instead, our designers came up with something like below:

It’s basically a carousel, with the caption in a grey area in the side, along with control buttons in the bottom. When clicked, the next image is shown.

At first, I thought of using a plugin, which would’ve been fine. Except this would’ve added some level of training on how to use carousel plugins. Most of which are quite complicated to use. Besides, our users are already familiar with using the default WordPress gallery option. They just want to change the way it looks!

So the solution was to use a little bit of JavaScript and CSS. Note that this requires jQuery, Bootstrap for the grid, as well as Handlebars for templating.

Let’s begin:

First, let’s add a gallery to our page.

Make sure that each image has a caption to go with it:

This will ouput the default gallery in WordPress. Now note that each gallery will have a “.gallery” class in them. So let’s grab all of them, and create an object with it.

var galleries = {};
    $('.gallery').each(function(i,item){
        var id = $(this).attr('id');
        var imgs = Array();
        var children = $(this).find('.gallery-item');
        $.each(children,function(){
            var imgSrc = $(this).find('img').attr('src');
            var caption = $(this).find('.wp-caption-text').html();
            var imgItem = imgSrc + "::" + caption;
            imgItem = imgItem.trim()
                        .replace(/[\n\r]+/g, '')
                        .replace(/\s{2,10}/g, '')
                        .replace('undefined','');
            imgs.push(imgItem);
        })
        galleries[id] = imgs;
    });

Now we have a “galleries” object, with the gallery id as the indexing property. This will support multiple galleries in a page, hence the index.

Inside each gallery object contains properties for the source and caption (separated by a “::”).

So we’ll have something like below:

With our object in place, we can create our carousel.

Let’s create the HTML. The below code is simply HTML but using Handlebars syntax.

As you can see above, we are wrapping everything in it’s own “carousel-wrap”, with an attribute of “data-gallery”, along with the gallery index as the value.

We loop through each image and assign the values to the HTML.

We are using Boostrap col classes, and using a “background” for the image (not img tag). This makes our image behave properly in different viewports.

Note that we have “Previous” and “Next” buttons – which we’re adding for now – and will explain later.
Also, we’re creating the controls in the bottom, which will look like below:

Back in our JavaScript, let’s register a helper called “hiddenOrNot” – which simply decides if it’s not the first image – hide everything:

Handlebars.registerHelper('hiddenOrNot', function(ind) {
         return ind === 0 ? '' : 'hidden';
    });
    var source   = $("#carousel-template").html();

Now let’s compile our object and output to our template.

Remember our delimiter “::”, that’s what we’re doing in line 8 below. Also, we’re binding events to each of the controls along with assigning hidden and active classes to both itself and the large images.
Finally, we remove the default WordPress gallery by using jQuery’s .remove().

for(gallery in galleries){
        // console.log(gallery);
        var col = {};
        col.gallery = '#' + gallery;
        col.imgObj = {};
        for($i=0;$i





Remember our Previous and Next buttons, this is only to show up in viewports for mobile devices. That is made possible by using the “visible-xs” Bootstrap class. So, it looks like below in small devices:





Now let’s add some events to those buttons:



$('[data-gallery]').each(function(i,item){
        var previous = $(this).children('.carousel-previous');
        var next = $(this).children('.carousel-next');
        previous.on('click',function(){
            var currentGallery = $(this).closest('.carousel-wrap').attr('data-gallery');
            var previousBox = $('[data-gallery="'+currentGallery+'"]'+' [data-index="'+getCurrentBox(currentGallery)+'"]')
                            .prev('.boxed-style');
            if(previousBox.length !== 0){
                hideBoxes(currentGallery);
                previousBox.removeClass('hidden');
                updateDots(currentGallery);
            }
            return false;
        });
        next.on('click',function(){
            var currentGallery = $(this).closest('.carousel-wrap').attr('data-gallery');
            var nextBox = $('[data-gallery="'+currentGallery+'"]'+' [data-index="'+getCurrentBox(currentGallery)+'"]')
                            .next('.boxed-style');
            if(nextBox.length !== 0){
                hideBoxes(currentGallery);
                nextBox.removeClass('hidden');
                updateDots(currentGallery);
            }
            return false;
        })
        function updateDots(currentGallery){
            $('[data-gallery="'+currentGallery+'"] a.trig').removeClass('active');
            $('[data-gallery="'+currentGallery+'"] a[data-index="'+getCurrentBox(currentGallery)+'"]')
                .addClass('active');
        }
        function hideBoxes(currentGallery){
            $('[data-gallery="'+currentGallery+'"] .boxed-style').addClass('hidden');
        }
        function getCurrentBox(gallery){
            var curBox = $('[data-gallery="'+gallery+'"]' + ' .boxed-style').not(':hidden');
            var curBoxIndex = $(curBox).attr('data-index');
            return curBoxIndex
        }
    })



For each button, we’re doing some logic – each of them are in functions that we can reuse.
Finally, let’s add some CSS styles:



.boxed-style {
    clear:both;
    display: block;
    margin-bottom: 50px;
    overflow: hidden;
    position: relative;
}
.boxed-style .box-style,
.boxed-style-vertical .box-style-vertical {
    display: flex;
    flex-direction: column;
    justify-content: center;
    height: 380px;
    background-position-x: center !important;
    background-position-y: center !important;
    background-size: cover !important;
    padding-bottom:100px;
    box-shadow: inset 0px 0px 1px 1px rgb(234, 234, 234);
}



This is for the carousel itself:



.carousel-wrap {
    clear: both;
    display: block;
    overflow: hidden;
    margin-bottom: 45px;
    margin-top:40px;
    position: relative;
}
.carousel-previous,
.carousel-next {
    position: absolute;
    width:48px;
    height:48px;
    text-indent: -9999px;
    top:35%;
}
.carousel-next {
    background:url('images/chevron-right.png') 0px 0px no-repeat;
    right:0;
}
.carousel-previous {
    background:url('images/chevron-left.png') 0px 0px no-repeat;
}
.carousel-wrap .boxed-style {
    margin-bottom: 0;
}
.carousel-controls {
    text-align: center;
    margin:15px 0;
}
.carousel-controls a {
    font-size:13px;
    margin-right: 3px;
    color: #ccc;
}
.carousel-controls a:hover,
.carousel-controls a:focus,
.carousel-controls a.active {
    color: #0077C8;
}



Now you might have noticed a little triangle in our caption. This is the CSS that made that possible:



.triangle-left-large {
    width: 0;
    height: 0;
    border-top: 12px solid transparent;
    border-bottom: 12px solid transparent;
    border-right: 12px solid #eaeaea;
    position: absolute;
    right: 0;
}



Below is the finished result. In desktop and mobile view. A live example can be found here (scroll down to the middle of the page).









And that’s about it! We’ve just created a carousel without a plugin. This may be a simplistic carousel – one that can be enhanced even further. Maybe add some animations, previews, swipe events etc.



Hope you try it out in your projects. Leave your comments below.
The post Convert WordPress default Gallery into a simple Carousel without a plugin appeared first on Michael Soriano.



Get all posts from WordPress REST API
Michael Soriano — Thu, 22 Jun 2017 16:18:40 +0000

As you may know, WP REST API has a limit of 100 records per call. This is what it says in the API Docs:

Now this may be enough for some people, but what if you need to get ALL of them. Here are two solutions that I came up with.



1. Using PHP



We’re using PHP’s multi cURL. This means that we are doing multiple REST calls, but doing them simultaneously. Meaning, the amount of time to do the requests – is not dependent on the number of calls you make (because they’re asynchronous).
So let’s begin. First in your functions.php, create a function:



function getAllRecordsFromRest(){
   //ADD ALL CODE IN HERE...
}



Inside your new function, is where we put the rest of our code.
Let’s figure out how many calls we need to make:



$totalItems = wp_count_posts()->publish;
$callsToMake = ceil($totalItems/100);



Let’s create an empty array and stuff it with the curl options:



$ch = array();
for($i=0;$i<$callsToMake;$i++){
    $page = $i + 1;
    $ch[$i] = curl_init(get_bloginfo('url').'/wp-json/wp/v2/posts?_embed&per_page=100&page='.$page);
    curl_setopt($ch[$i], CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch[$i], CURLOPT_SSL_VERIFYPEER,  0);
}



As you can see above, we’re simply looping through the $callsToMake variable, to add a $page as part of our querystring. Similar to a paging system. As part of our loop, we are passing the options for curl through curl_setopt().



Now for the calls:



$mh = curl_multi_init();
        for($i=0;$i<$callsToMake;$i++){
            curl_multi_add_handle($mh, $ch[$i]);
        }
        $running = null;
        do {
            curl_multi_exec($mh, $running);
        } while ($running);
        for($i=0;$i<$callsToMake;$i++){
             if (!curl_errno($ch[$i])) {
                 $info = curl_getinfo($ch[$i]);
                 //error_log(print_r($info,true));
             }
            curl_multi_remove_handle($mh, $ch[$i]);
        }
        curl_multi_close($mh);
        $responses = array(); //array
        for($x=0;$x<$callsToMake;$x++){
            $responses[$x] = json_decode(curl_multi_getcontent($ch[$x]));
        }




First we create a handle $mh – this is what curl uses to execute and initialize the class. We loop through our $callstoMake once more to add the handles to curl_multi_add_handle().
We do a do while, and execute curl. Now if if there is an error in any of the calls, we will get them in curl_getinfo().



Finally, we get all of the contents of our calls through curl_multi_getcontent(), and we stuff it in our newly created $responses array.



Now our $responses will look something like:



$responses[$response[0], $response[1], $response[2]]



So we need to loop through them to create a big array of responses (in order).



So we do a final loop and do an array_push().



$final = array();
for($i=0;$i




Then, we return our array as a JSON string by doing json_encode($final).



Now all we have to do is call our PHP function “getAllRecordsFromRest()” and we should have all of our posts.



2. Using JavaScript



We also have the option of using JavaScript for our multiple calls. Let’s start by getting the number of calls in our functions.php file:



function getNumCalls(){
    $totalItems = wp_count_posts('posts')->publish;
    $callsToMake = ceil($totalItems/100);
    return $callsToMake;
}



Now, in our header.php – let’s create a JavaScript variable that stores the number of calls to make – from the function that we created above:







Now, let’s create an array, that houses all of the responses, from our AJAX calls.



 var requests = Array();
 for(var i=0; i




We then to a “.when()” to fire our calls. And doing a console.log() on the arguments, we see the responses. This technique is described in my previous post Working with Promise and Deferred.



$.when.apply($,requests).done(function(){
   console.log(arguments);
})







Finally, let’s do a couple of for loops to merge the contents into one big array.



$.when.apply($,requests).done(function(){
    for(var i=0; i




And that should do it. Using either of these techniques should overcome the 100 record limitation of pulling records from WordPress REST api.
 
The post Get all posts from WordPress REST API appeared first on Michael Soriano.



Show number of posts out of total records  in WordPress
Michael Soriano — Tue, 15 Mar 2016 02:59:48 +0000
From time to time, I just look at my blogs and see what I can add to it to make it more appealing to the user. I’ve always admired those sites that tell you what number of posts a certain category has, and what number of posts it is currently showing. So I set out to do just that.

Since I haven’t written anything WordPress related for a while, I figured this would be good practice. What we’re writing is something like below:



You see, we want to show what posts are currently showing – out of how many total records. It’s not a hard task – since all we really need are 2 variables: the current total showing and the total number found.
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.



Add an additional Body Class to WordPress by using the Post Slug
Michael Soriano — Mon, 11 May 2015 02:40:50 +0000
One of the real useful things I’ve come across with WordPress is the body_class() method. This adds several classes to the body element of your HTML. The output looks something like below:



Why is this so great? Now you can style your pages very efficiently because you’re able to select from the template you’re using, the post type, when user is logged in – even to the post Id.

An example of what I mean is say – you want all the H1 tags styled differently only for post ID “4396”. Now in you CSS file you can add a rule like below:
.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.