Gutenberg by default comes with a handful of block types that should cover standard web content updating needs. However, it also has a nifty Block API for adding custom block types if you need them to display specially designed components for our website. In this tutorial, you are going to add a custom Gutenberg block type so that the output is a notice box with a few predefined styles that accepts arbitrary text input from the user.

This is what you’re going for.

And here is how it looks from the admin’s side.

Alright, let’s get to coding!

Step 1: Create a plugin for the new block type

You will be creating a custom block type as a WordPress plugin. This will allow you to decouple it from any themes you are using and in case anything goes wrong, you can simply deactivate it.

So create a new folder in the WP plugins folder and let’s call it gutenberg-notice-block. In this new folder, create a plugin.php file with the following code:

/**
* Plugin Name: Gutenberg Notice Block
* Author: Shaiful
* Description: A notice box with a few predefined styles that accepts arbitrary text input.
* Version: 1.0
*/

// Load assets for wp-admin when editor is active
function shaiful_gutenberg_notice_block_admin() {
   wp_enqueue_script(
      'gutenberg-notice-block-editor',
      plugins_url( 'block.js', __FILE__ ),
      array( 'wp-blocks', 'wp-element' )
   );

   wp_enqueue_style(
      'gutenberg-notice-block-editor',
      plugins_url( 'block.css', __FILE__ ),
      array()
   );
}

add_action( 'enqueue_block_editor_assets', 'shaiful_gutenberg_notice_block_admin' );

// Load assets for frontend
function shaiful_gutenberg_notice_block_frontend() {

   wp_enqueue_style(
      'gutenberg-notice-block-editor',
      plugins_url( 'block.css', __FILE__ ),
      array()
   );
}
add_action( 'wp_enqueue_scripts', 'shaiful_gutenberg_notice_block_frontend' );

Basically what this file does is initialise the plugin by loading the necessary JS and CSS files at the right place and at the right time. The code above is looking for block.js and block.css, which you will create momentarily.

At this point, you should be able to see the new plugin listed in your WP Plugins admin page. Go ahead and activate it.

Moving forward, all of your coding will be done in JavaScript with some ReactJS flavour to interact with the Gutenberg Block API.

Step 2: Register the new block type

Create a file called block.js in your custom plugin folder. This file will hold the entire logic of the custom block type for the admin-side and frontend of your website.

Start by adding the following bare-bones code.

/* block.js */
var el = wp.element.createElement;

wp.blocks.registerBlockType('shaiful-gutenberg/notice-block', {

   title: 'Notice', // Block name visible to user

   icon: 'lightbulb', // Toolbar icon can be either using WP Dashicons or custom SVG

   category: 'common', // Under which category the block would appear

   attributes: { // The data this block will be storing

      type: { type: 'string', default: 'default' }, // Notice box type for loading the appropriate CSS class. Default class is 'default'.

      title: { type: 'string' }, // Notice box title in h4 tag

      content: { type: 'array', source: 'children', selector: 'p' } /// Notice box content in p tag

   },

   edit: function(props) {
      // How our block renders in the editor in edit mode
      return null;
   },

   save: function(props) {
      // How our block renders on the frontend
      return null;
   }
});

The code above registers your new block type with the name “Notice”, using a light-bulb Dashicon and putting it under the Common Blocks panel in the Gutenberg blocks browser. You should be able to see the new block in your editor at this point.

You also specify the attributes (and their data type) that your new block will be storing which are the box type, the box title and the box content.

Lastly, there are two functions called edit() and save(). The edit() function is responsible for rendering your block in the editor while the save() function outputs your block HTML on our website’s frontend.

Let’s explore them now.

Step 3: The edit() function

The edit() function controls how the block will appear in the Gutenberg editor for the user to interact with.

For your custom Notice block type, the goal is to accomplish two things:

1. The user can select the notice box type as well as enter the box title and content.
2. Selecting different notice box types will show a simple live preview of what the box is going to look like on the frontend.

Add the following code into the edit() function.

/* block.js */
edit: function(props) {
   // How our block renders in the editor in edit mode

   function updateTitle( event ) {
      props.setAttributes( { title: event.target.value } );
   }

   function updateContent( newdata ) {
      props.setAttributes( { content: newdata } );
   }

   function updateType( event ) {
      props.setAttributes( { type: event.target.value } );
   }

   return el( 'div',
      {
         className: 'notice-box notice-' + props.attributes.type
      },
      el(
         'select',
         {
            onChange: updateType,
            value: props.attributes.type,
         },
         el("option", {value: "default" }, "Default"),
         el("option", {value: "success" }, "Success"),
         el("option", {value: "danger" }, "Danger")
      ),
      el(
         'input',
         {
            type: 'text',
            placeholder: 'Enter title here...',
            value: props.attributes.title,
            onChange: updateTitle,
            style: { width: '100%' }
         }
      ),
      el(
         wp.editor.RichText,
         {
            tagName: 'p',
            onChange: updateContent,
            value: props.attributes.content,
            placeholder: 'Enter description here...'
         }
      )
   ); // End return

},  // End edit()

Line 16-49 is the main code you will use to display the user interface in a way that allows you to update the content in your block type. The code is written in ReactJS specifically the React.createElement() function is used to create new DOM elements. Do not worry if ReactJS is unfamiliar to you. You can make use of this specific tool to compile JSX template code to React.createElement() functions.

Here is an example.

It’s a good idea to create your block.css file right now so that you can test the live preview functionality in the editor. Make sure the CSS file is saved in your plugin folder.

/* block.css */
div.notice-box {
   border: 1px LightSkyBlue solid;
   border-left-width: 5px;
   padding: 10px 15px;
   margin: 30px;
}

div.notice-box.notice-success {
  border-color: MediumSpringGreen ;
}

div.notice-box.notice-danger{
   border-color: LightCoral ;
}

div.notice-box h4 {
   font-size: 18px;
   margin:0 0 10px 0;
}
div.notice-box p {
   font-size: 16px;
   line-height: 24px;
   margin:0;
}

At this point, you should be able to add your Notice block type into the editor and see three different fields for configuring the notice box. The dropdown for selecting the notice box type should also gives you a live preview between the default (blue), success (green) and danger (red) box types.

Step 4: The save() function

The save() function for your Notice block type is pretty straightforward. You just have to construct the correct HTML structure and populate the title and content into the notice box <div>. Once again the DOM elements creation code has to be written in ReactJS.

Here is the code:

/* block.js */
save: function(props) {
   // How our block renders on the frontend

   return el( 'div',
      {
         className: 'notice-box notice-' + props.attributes.type
      },
      el(
         'h4',
         null,
         props.attributes.title
      ),
      el( wp.editor.RichText.Content, {
         tagName: 'p',
         value: props.attributes.content
      })

   ); // End return

} // End save()

That’s it!

Your Notice block type should now work on both the admin and website’s frontend.

Here is the link to download the completed plugin.

Something to keep in mind

Looking at the save() function, you’d imagine that updating the HTML output in there would cause a global update for all instances of the Notice box that you have populated on your website. It’s natural to expect this (it is, at least from our experience with working with WP shortcodes). Unfortunately, this isn’t what happens.

Making any changes to the block HTML output would trigger a conflict with all existing instances of the blocks that have been populated. What’s worse is that the only way to fix this is by repopulating the blocks one by one. This is the caveat of static block types.

To work around this, make use of the Dynamic Blocks feature which hands over the save() function from JS to PHP to generate the block HTML output on the fly.

Final thoughts

The ability to create custom block types is very cool and opens a lot of possibilities for content customisation. After trying it out myself, I would say the basic concept is fairly easy to follow. The real challenge, however, is presenting the custom block in the best possible way to give content authors the best editing experience, especially for blocks with complex functionalities. I find that the official developer documentation for various attributes configurations or working with RichText field for example, are still lacking. It will improve surely but the best reference materials we have at this moment are online articles and the existing blocks that came out of the box with WP5.

On another note, I am personally looking forward to the Advanced Custom Fields (ACF) plugin taking on the custom block types with their own ACF Blocks for Gutenberg. This new addition should lower the barrier for WP developers to take advantage of Gutenberg block capabilities in a more intuitive way.

The post Creating a Custom Block Type for WordPress Gutenberg Editor appeared first on Stampede: the strategic design & technology company.

Since a couple of years ago, I have pretty much refrained from coding CPTs from scratch, unless for extremely simple post types. I have sworn my allegiance to two well-known CPT solution plugins namely Pods and Types. In this post, I’ll try my best to explain how they fare against each other, specifically on the way they handle CPTs (and custom taxonomies).  What I don’t intend to cover are extended features like user roles or data migration. Finally, there’s a bonus section about enhancing their functionalities.

WordPress Pods plugin

The CPT management screens in Pods are really well-done and user friendly. If you are new to the world of CPTs, Pods will present you with a gentle learning curve to get you up and running. When you create a new CPT or custom taxonomy, you immediately have access to the custom fields management panel within the same CPT or custom taxonomy edit page. This makes the whole process of managing the custom fields a breeze and feels natural.

These are the main strengths of Pods:

1. Nice and intuitive user interface.
2. Large selection of custom field types.
3. You can add custom fields to custom taxonomies too.
4. Pods Template is an optional component you can enable in Pods to create templates for outputting Pods CPTs using magic tags and shortcodes all within WordPress without messing around with theme files.
5. You can create a custom Settings page for miscellaneous usage.

The limitation of Pods based on my experience are:

1. While you can create true parent-child (or one-to-many) relationships between Pods CPTs, the level of integration doesn’t appear to be truly seamless. For instance, in a property rental website presumably you had setup a one-to-many relationship between two CPTs; Properties and Rentals. However when editing a Property record you cannot add new Rental records in the same screen.
2. Each CPT can only have one meta box named More Fields containing all the custom fields.
3. You cannot make basic fields like plain text repeatable which could be handy in certain scenarios. Fortunately multiple image uploads is still possible.

WordPress Types plugin

The Types plugin may not look as straightforward to use at first glance primarily because the CPT and custom fields are managed in different admin screens but once you get your head around this it actually opens up a new possibility of the things you can do.

These are the main strengths of Types:

1. You can create true parent-child (or one-to-many) relationships between any CPTs or WP’s native objects with very seamless integration. For instance, in a property rental website presumably you had setup a one-to-many relationship between two CPTs; Properties and Rentals. When editing a Property record you can quick-add new Rental records in the same screen. Additionally, you can also specify which fields should appear in the quick add form.
2. You can have as many meta boxes with custom headings and combination of custom fields in each CPT. Furthermore, the meta boxes support custom CSS so you can arrange certain fields in side-by-side fashion instead of one per row for instance. This creates a more intuitive editing experience for the end users.
3. All custom fields can be made repeatable.
4. Non-repeatable custom fields can be fine-tuned with conditional logic to control when they should appear based on the values of other fields.
5. Meta boxes and custom fields can be added to user profiles.
6. The equivalence of Pods Templates for Types is called Views. It is not free but certainly a lot more powerful.

The limitation of Types based on my experience are:

1. User interface can be a bit tricky to work with.
2. No custom field of type Relationship.
3. No way of adding custom fields to custom taxonomies.

Bonus: Advanced Custom Fields plugin

In cases where I was using Types and needed to use the Relationship-type custom field, I usually resorted to the Advanced Custom Fields plugin. It may sound like an overkill to use it solely for one purpose but the field provided by Advanced Custom Fields simply has the perfect UI for a relationship-type field. It is also far superior than what Pods provided by default.

The perfect UI for a relationship-type field.

As a matter fact, Advanced Custom Fields is by far the best custom fields plugin for WordPress. To unlock its full potential you need to purchase the Pro version though.

Bonus: Codepress Admin Columns plugin

When you are working with CPTs, the Codepress Admin Columns plugin is quite simply the icing of the cake for all your hard work. The plugin allows you to customize table columns in the admin landing page of CPTs or any WP’s native objects. It fulfills a basic need that greatly enhances user experience when working with CPTs in the admin area.

Custom table columns FTW!

Though this plugin has a Pro version, the free one is awesome enough in most cases.

Conclusion

Pods and Types are my two favorite custom post types solutions for WordPress. How I decide between them depends ultimately on individual project requirements but so far I tend to choose Types for complex projects that require post relationship. With a couple of amazing supporting plugins, you’ll be having a blast working with either anyway.

Have a nice day!

Update (June 2015)

For an in-depth look at the features and technical differences between popular WordPress CPT plugins, view this awesome comparison matrix spreadsheet by Scott Kingsley Clark and Matt Gibbs.

The post WordPress CPT Solutions Comparison: Pods vs Types appeared first on Stampede: the strategic design & technology company.

Syahir was also featured in this interview by Blink Colony – where he speaks of the development and features of the Graphene theme, his experiences meddling with his first family computer and being taught on the basics of HTML and CSS by his sister Shaza (where his interests in coding spurts from there) as well as mentioning Stampede Design in the interview!

Syahir also runs a blog of his own, khairul-syahir.com, where he talks a lot about web development, hiking and his life in general in Auckland.

The post Graphene—The Road to Million Downloads: An Interview with Syahir Hakim appeared first on Stampede: the strategic design & technology company.

Supermassive can help you to create a great looking theme that allows you to make your own unique and abstract layouts in minutes. You can easily change the position of a particular element since the <div>s are fluid. Imagine you have two horizontal boxes, named Box Left and Box Right. You can easily make Box Right in 100% width by just removing Box Left completely.

I find this task to code based on Supermassive template really puts my XHTML/CSS skills to the test. I need to optimize everything that I’ve learned about building reliable yet semantic XHTML/CSS template which works on IE6, IE7, IE8, Chrome, Opera, Firefox and Safari. Working with a custom design on an existing theme requires a different set of considerations.

The first thing I needed to consider is where to do the front-end coding for the custom design. This is because we want to be able to update Supermassive template in the future when a new version is released. Therefore, I need to consider where to add my front-end codes. After some discussions, we decided to code on a Supermassive Child Theme. It’s the easiest yet very reliable way to keep the ability to update to new Supermassive version in the future. When updating Supermassive original template, it will only replace the parent theme which is the original Supermassive Theme. In this case, updating the original template won’t affect the child theme.

Second thing to consider is the HTML structure. Since Supermassive uses shortcode heavily for its layout based on <div>, I can’t simply code custom HTML structure. What I need to do is to create each Supermassive element using the shortcode first. Once all elements are created, I can start styling the elements based on design without making changes on the HTML element or structure. Using this method, I can still use any Supermassive shortcode without having to worry about the styling even if the shortcode will never be used.

The last thing to consider is how to make the template styled according to my custom CSS instead of the original CSS. This is the trickiest part. I need to make sure everything on the custom CSS has the highest priority, so the website will be styled according to it. We can’t simply remove the original CSS because we still need some styling from it such as the administration interface, sliding effect and JavaScript element.

For me, the easiest way is to add !important syntax at the end of the styling, e.g. div a {text-decoration:hover !important;}. With that, it will have higher priority. I recommend not to define any font size on the CSS because on current version of Supermassive template, there is a specific panel to change the font size directly.

Supermassive is a great tool for WordPresser because it comes with its own JavaScript snippets which includes sliding effect, tabs, and image manipulation. It also has a very user-friendly interface for administration. I’m sure Supermassive shortcode list will come in handy for beginners.

The post Supermassive Custom Template appeared first on Stampede: the strategic design & technology company.

Disclaimer: This may not be the only nor the best way for anyone to achieve the same presentation, but I intend to share it as a reference for interested people.

There are several reasons I usually choose to use the Sticky Post feature instead of implementing another custom field or tag or category etc. First, I notice the native WordPress Sticky Post feature is not in use in most of the blogs (note: personal observation), and I think this native feature should be more well utilized.

Second, I think the current way presenting Sticky Posts in WordPress takes away too much attention from the worthy latest posts because Sticky Posts take up the place before the latest posts at the same content area. A separate area to display the Sticky Posts such as the post slider area is a good way to give attention to some ‘selected’ posts while not attracting too much attention away from the latest posts.

Third, implementing the post slider using a tag or a category is more like a hack because tags and categories are supposed to describe the contents of the blog post. Sometimes there may be a need to present contents with a certain tag or category differently (e.g. tag templates or category templates), but the main point of using tags and categories should be to describe the blog post contents, not merely as a way to differentiate the way blog posts are presented.

Enough said. Let’s get into how I do it.

Let’s say I have these blog posts and several of them are made ‘Stick Posts’:

In the default Twenty Ten theme, each of the Sticky Posts appears in a box in a light-blue background with a thick black top border line in the home page of the blog, in the main blog posts area above all most recent posts:

MooTools and noobSlide

Since in this post, I’m going to use noobSlide as our content slider, we need to include MooTools JavaScript library. Go to the functions.php file in the template and add the following codes at the bottommost.

function register_custom_js() {
    wp_register_script( 'mootools', 'http://ajax.googleapis.com/ajax/libs/mootools/1.3.0/mootools-yui-compressed.js', '1.3.0' );
    wp_register_script( 'noobslide', get_bloginfo('template_directory') . '/_class.noobSlide.packed.js' , array( 'mootools' ) );
}
add_action( 'init', 'register_custom_js' );

function enqueue_noobslide() {
    if ( is_home() ) { // our slider only appear in the home page, so load the script only in home page
        wp_enqueue_script( 'noobslide' );
    }
}    
add_action( 'wp_print_scripts', 'enqueue_noobslide' );

Post Thumbnail Support

In this tutorial, I’m going to use post thumbnails in my slider. If your theme has not yet added the feature, you can add it using the following codes in your functions.php:

function custom_theme_setup() {
    add_theme_support( 'post_thumbnails' );
}
add_action( 'after_setup_theme', 'custom_theme_setup' );

Also make sure your Sticky Posts has set the ‘Featured Image’ (BTW, WordPress should standardize the use of name).

Custom ‘Read more’ Link

In the default Twenty Ten theme, a custom “Read more” link is used. I’m going to change it to use my own customized “Read more” link so I can place a class for styling.
I will comment out this line in the Twenty Ten functions.php file:

//add_filter( 'get_the_excerpt', 'twentyten_custom_excerpt_more' );

Then, I will add the following to the same file:

function custom_excerpt_with_more( $excerpt ) {
    if ( has_excerpt() && ! is_attachment() ) {
        global $post;
        return $excerpt . '<p class="slider-more"><a href="' . get_permalink( $post->ID ) . '">Continue reading</a></p>';
    }
    return $excerpt;
}
add_filter( 'get_the_excerpt', 'custom_excerpt_with_more' );

function custom_excerpt_more( $more ) {
    global $post;
    return '<p class="slider-more"><a href="' . get_permalink( $post->ID ) . '">Continue reading</a></p>';
}
add_filter( 'excerpt_more', 'custom_excerpt_more' );

custom_excerpt_with_more() function is for automatic excerpts or user-specified excerpts with read-more tag. custom_excerpt_more() is for hand-crafted excerpts.

CSS and JavaScript

Then, we add the custom CSS and JavaScript codes in functions.php to make the theme serve them when we are in the home page where the slider will appear.

function custom_slider_css_js() {
    if ( is_home() ) { // only in home page
?>
<style type="text/css">
#slider{border:1px solid #ccc;width:640px;position:relative;overflow:hidden;height:213px;margin-bottom:20px;}
#mask{position:absolute;height:213px;}
.items{float:left;height:213px;width:640px;position:relative;}
.items .wp-post-image {float:left;}
.info{width:320px;float:left;font-family:Arial, Helvetica, sans-serif;}
#content .info h2{font-size:20px;font-weight:bold;color:#1c3f95;margin:10px 10px 15px 10px;}
#content .info p{font-size:11px;color:#1c3f95;line-height:16px;margin:10px;}
.info a{font-size:10px;padding:5px 7px;background:#e1e1e1;text-decoration:none;text-transform:uppercase;font-weight:bold;color:#1c3f95;}
.info a:hover{color:#ffffff;background:#1c3f95;}
#slider .handle{position:absolute;bottom:0;right:5px;line-height:10px;text-align:center;font-size:25px;font-weight:bold;}
.handle a{color:#ccc;height:20px;width:20px;display:inline-block;cursor:pointer;}
.handle .active{color:#1c3f95;}
.handle a:hover{color:#1c9f65;}
</style>
<script type="text/javascript">
/*<![CDATA[*/
window.addEvent('domready',function(){
    var nS8 = new noobSlide({
        box: $('mask'),
        items: $$('#mask .items'),
        size: 640,
        autoPlay: true,
        interval:8000,
        handles: $$('.handle a'),
        onWalk: function(currentItem,currentHandle){
            $$(this.handles).removeClass('active');
            $$(currentHandle).addClass('active');
        }
    });
    var handle = $$('.handle a');
    handle.each(function(el,i){el.addEvent('click',nS8.walk.bind(nS8,[i,true]));});
});
/*]]>*/
</script>
<?php
    }
}
add_action('wp_head', 'custom_slider_css_js' );

WordPress Theme Modification

Next, go to the theme template file that display the Loop in the home page, in this case, it is the loop.php file in the Twenty Ten theme. Place the cursor right before the Loop area and we can start putting our codes for the slider.

<?php 
if ( is_home() ):
    $sticky = get_option('sticky_posts');
    $slider = new wp_query( array( 'post__in' => $sticky ) );
    ?>
    <?php if ($slider->have_posts()): $count = 0; ?>
        <div id="slider">
            <div id="mask">
                <?php while ( $slider->have_posts() ): $slider->the_post(); $count++; ?>
                    <div class="items">
                        <?php the_post_thumbnail( array( 320, 213 ) ); ?>
                        <div class="info">
                            <h2><?php the_title(); ?></h2>
                            <?php the_excerpt(); ?>
                        </div>
                    </div>
                <?php endwhile; ?>
            </div>
            <div class="handle">
                <?php for ($count; $count > 0; $count--): ?>
                    <a>&bull;</a>
                <?php endfor; ?>
            </div>
        </div>
    <?php endif; ?>
<?php endif; ?>

At this point of time, when you go to the home page of the blog, you will see the slider is up and running already and we are almost done:

But wait, we are not done yet. Notice the main blog posts area still have the Sticky Posts? We need to get rid of them to return the attention taken away from the latest posts. To accomplish that, we will add the following codes right after our content slider codes:

<?php 
if ( is_home() ):
    $sticky = get_option('sticky_posts');
    $slider = new wp_query( array( 'post__in' => $sticky ) );
    ?>
    <?php if ($slider->have_posts()): $count = 0; ?>
        <div id="slider">
            <div id="mask">
                <?php while ( $slider->have_posts() ): $slider->the_post(); $count++; ?>
                    <div class="items">
                        <?php the_post_thumbnail( array( 320, 213 ) ); ?>
                        <div class="info">
                            <h2><?php the_title(); ?></h2>
                            <?php the_excerpt(); ?>
                        </div>
                    </div>
                <?php endwhile; ?>
            </div>
            <div class="handle">
                <?php for ($count; $count > 0; $count--): ?>
                    <a>&bull;</a>
                <?php endfor; ?>
            </div>
        </div>
    <?php endif; ?>

    <?php
    $args = array_merge( $wp_query->query, array( 'post__not_in' => $sticky ) );
    query_posts( $args );
    ?>
	
<?php endif; ?>

All Done!

Now enjoy your fully functional content slider. =)

Images in the sample blog courtesy of phalinn.

The post Sticky Post Slider in WordPress without a Plugin appeared first on Stampede: the strategic design & technology company.

While this is not a bad thing at all, it is however quite cumbersome if you’re using custom shortcodes (that generate divs) in your content creation and you’re planning to arrange them nicely in the editor by giving a couple of line breaks for better readability. They will end up in the frontend as <div> wrapped inside a <p>, and you’ll get some unwanted <br /> as well. Certainly not pretty.

The auto-formatting function will still run even if you disabled the visual editor entirely because it is not part of the TinyMCE editor. In fact it is performed via a function in WordPress called wpautop that runs before the content is displayed on the frontend. Thus it is possible to bypass this feature by using the remove_filter function in our theme function.php file. The simple code for a global site-wide effect is:

 
   remove_filter('the_content', 'wpautop');

A more elegant approach would be to use a custom field to control which content will bypass wpautop and which not. This way we can still take advantage of the usefulness of the wpautop function for pages that doesn’t require fancy HTML. The code below also goes in the function.php file.

function WP_auto_formatting($content) {
    global $post;
    if(get_post_meta($post->ID, 'disable_auto_formatting', true) == 1) {
        remove_filter('the_content', 'wpautop');
    } 
    return $content;	
}
add_filter( "the_content", "WP_auto_formatting", 1 );

Using this method, you simply have to add a custom field in your post/page called disable_auto_formatting and give it a value of 1 to bypass the wpautop function. To enable auto formatting, simply change the value to 0 or delete the custom field.

Have a nice day!

The post Disable HTML Auto-Formatting in WordPress appeared first on Stampede: the strategic design & technology company.