One of the newest and biggest revolutions in content consumption is streaming on audio. Audiobooks are one way to consume content, but involve a fairly substantial investment of time to actually finish a complete book (longer than actually reading it). Podcasts are a more low commitment and convenient way to stay up to date with your industry of choice, while learning new skills in the process.

Podcasts can be played in the background of doing tasks that don’t consume your complete attention, and you can use podcasts to stay updated on the latest WordPress news and topics that may help you and your business. Listening to audio can easily fit into your life during a commute, waiting before an appointment, or even during a gym session.

Regardless of how you decide to fit podcasts into your life, here are the top WordPress podcasts to listen to for staying up to date with the WordPress community.

1. MATT REPORT

Matt Medeiros, the founder and host of Matt Report, started his podcast in October of 2012 with the goal of connecting to the WordPress community and helping them to start and run their digital businesses. On Matt Report, he interviews consultants, bootstrappers, and business owners.

Some topics he’s discussed during his podcast include general online business considerations, like:

• How to build an online community
• How to find an angel investor for small startups
• Creating an online course

2. THE WORDPRESS CHICK

The founder and host of this podcast, Kim Doyal, is also known as The WordPress Chick. Doyal started the podcast in 2013 with no grand plan, just a commitment to show up and do things her way.

Through The WordPress Chick, Doyal shares her passion for business, geeks out over tools and plugins, and casts a spotlight on others in the same online space. She also uses her podcast as an opportunity to transparently document her own online business journey.

Some of the topics Doyal discusses during the podcast include a focus on tactics, such as:

• Organic Facebook marketing
• Content planning & creating
• General WordPress development tips
• How to run social campaigns

3. WPWATERCOOLER

WPwatercooler is a podcast created specifically for WordPress developers. Its creator and host Jason Tucker interviews people from the community each week to talk about WordPress and how it’s changing businesses and people’s lives.

WPwatercooler topics always come back to WordPress, focusing on specific activities like:

• Managing events using WordPress
• Structuring your data in WordPress
• Structuring your WordPress projects
• Documentation for your WordPress project

4. WORDPRESS WEEKLY

WordPress Weekly is a WordPress-related podcast run by WP Tavern’s founder Jeff Chandler and mega-marketer and WordPress genius Marcus Couch. Together, Chandler and Couch talk about the latest community news and conduct interviews with well-known members of the WordPress community.

The WordPress Weekly podcast topics focus on current events and different individuals, but you can expect the conversation to include things like:

• WordPress Meetups, events, and WordCamps
• The latest WordPress news
• Themes, plugins, and WooCommerce

5. OFFICEHOURS.FM

OfficeHours.FM is a WordPress podcast that targets freelancers, small business owners, and other related parties providing WordPress based products or services. Its host, Carrie Dils, interviews people from the WordPress community to talk about their stories and what they’ve learned throughout their careers.

Many of the topics covered on OfficeHours.FM include a focus on general small business processes and productivity, including things like:

• Project management strategies and tactics
• Providing ongoing client services
• Onboarding clients for success

6. KITCHENSINKWP

kitchensinkWP is a podcast about everything WordPress. Its host, Adam Silver, wanted to find a way to give back and share the things he has learned about WordPress throughout his career, and a podcast was his ideal medium for doing so.

Through kitchensinkWP, Silver talks about the latest news and events in the WordPress community, interviewing popular WordPress professionals in the process.

Some of the topics that come up during kitchensinkWP include things like:

• Setting up redirects
• Building a site with an iPad
• Handling ownership and licenses of premium themes and plugins

Here’s a kitchensinkWP episode featuring the writer of this article.

7. POST STATUS DRAFT

Post Status Draft is a WordPress podcast that covers general news and information for WordPress professionals. Hosts Brian Krogsgard (creator and editor of Post Status) and Joe Hoyle (co-founder and CTO at Human Made) set forth interviews, conversations, and editorials for the WordPress community.

Topics covered on Post Status Draft run the gamut, but have included things like:

• Maintaining legacy WordPress websites
• Editing and customizing core focus areas
• Building a healthy remote company
• The art of being a self-employed web consultant

8. MASTERMIND.FM

Hosts Jean Galea (founder of WP Mayor, and creator of the WP RSS Aggregator and EDD Bookings) and James Laws (co-founder of WP Ninjas) are the masterminds of this WordPress podcast. Mastermind.FM is where Galea and Laws share wisdom from their own experiences, as well as those from other successful entrepreneurs.

Mastermind.FM could be described as a podcast perpetuating WordPress business thought leadership, covering topics such as:

• Business analytics
• The theme market
• Growth hacking: create, connect, deploy, succeed

9. HALLWAY CHATS

Hallway Chats is somewhat of a new podcast that shares the stories of marketing consultants, content creators, project managers, designers and developers—all with some sort of tie to WordPress.

Hosts Tara Claeys and Liam Dempsey share advice, tips, stories, and experiences from the people in the WordPress community that empower listeners to understand that their own challenges are shared by a wider community, regardless of the specific roles they play.

Some of the topics they’ve discuss during podcast so far include:

• How to use processes and software
• Managing content and community projects
• Web literacy

10. YOUR WEBSITE ENGINEER

Your Website Engineer is a WordPress podcast that aims to help listeners create a great looking website. Host and creator Dustin Hartzler is a huge fan of creating podcasts, which is why he spends his time creating this type of content. Each show focuses on just one topic so you can drill down on picking up a new skill.

Some of the topics covered in Your Website Engineer include things like:

• Setting up and configuring a custom email address
• Exploring hooks, actions, and filters
• WordPress template hierarchy
• WordPress.com for business

11. APPLY FILTERS

Hosted by Brad Touesnard (founder of Delicious Brains) and Pippin Williamson (creator of Easy Digital Downloads), Apply Filters is a WordPress podcast that covers everything from development in WordPress core, to plugin and theme development.

During Apply Filters, hosts Touesnard and Williamson share their own stories in the development world and also invite guest developers to share their stories.

Some of the topics discussed during Apply Filters include things like:

• WordPress development challenges
• Advanced Strategies vs. Just Shipping
• How to build a batch processing process
• Growing through strategic acquisitions

12. WPINNOVATOR

WP Innovator is a podcast about WordPress, marketing, strategy, and agency life. Host Lee Jackson interviews entrepreneurs and agency owners about their experiences.

Some of the podcast topics published so far include things like:

• Page builder frameworks
• Systemising for profit
• Making more sales with Woocommerce

TOP WORDPRESS PODCASTS FOR STAYING CURRENT WITH THE COMMUNITY

By tuning into one or a few WordPress podcasts, you’ll be able to stay up to date with the community during your downtime. The trick is just focusing on a few, as trying to follow every episode of all podcasts listed may not be relevant to you, and will certainly consume a large chunk of your time. Pick and choose the WordPress podcasts that best fit your current (or aspirational) position.

The post 12 Best WordPress Podcasts appeared first on Jayatechnology.

After reading all of the documentation and spending some time trying Grav out, I’m definitely sold and will be using the platform. I hope you will too.

WHAT WE’LL BE BUILDING

For the first part of this tutorial we’ll be building a one-page website, and in the second part, we’ll build a simple blog. I’ll assume you have a good understanding of HTML and CSS (or CSS preprocessors). We will not be getting into the styling of the themes but rather focus on Grav, and its functionality.

You can check out both of these themes on GitHub:

• OnePager
• MNMM

INSTALLING GRAV

Below are the very few requirements Grav needs in order for it to run:

• A web server (Apache, Nginx, LiteSpeed, Lightly, IIS, etc.)
• PHP 5.5.9 or higher

Download Grav Core with the Admin Panel Plugin and unzip the package in the webroot of your web server and you’re ready to roll.

PAGE TYPES

Grav comes with 3 types of pages out of the box:

STANDARD PAGE

These are typically single pages, such as blog posts, contact pages, error pages, etc. Grav assumes that any page is a standard page unless otherwise specified.

LISTING PAGE

These are basically a standard page that has a reference to a collection of pages, for an example, a blog listing page. Configuration settings for these pages include: order, number of items and whether or not pagination is enabled.

MODULAR PAGE

Modular pages build a single page from it’s child pages, allowing us to build one-page layouts from smaller modular pages.

FILE STRUCTURE

Generally speaking, the only folder you’ll use is the /user folder.

THE CONTENT

The /user/pages folder is where all of the content pages live. Each page is placed in its own folder, and folder names should reflect the page’s name, and also be a valid slug.

You can order pages by naming the page folders with a preceding number: 01.home, 02.blog. Page folders then contain a markdown file and media for the page. The name of the markdown file will reference the name of the theme’s template to be used to render the content, for example: home.md would look for a template named home.html.twig.

THE THEME

Themes can be found within the /user/themes folder. For a theme to function you’ll need:

• blueprints.yaml – a file which contains information about the theme.
• themename.php – a file which contains any logic your theme needs.
• themename.yaml – a configuration file used by the plugin to set options the theme might use.
• templates/ – a folder containing the Twig templates to render the pages.

You should also include and these are required if you plan to release a theme:

• CHANGELOG.md – a file that follows the Grav Changelog Format to show changes.
• LICENSE – a file containing the license to the theme.
• README.md – a file with documentation for the theme.
• screenshot.jpg – a 1009px x 1009px screenshot of the theme.
• thumbnail.jpg – a 300px x 300px screenshot of the theme.

This is also where the css, sass, fonts, images, and js folders for the theme reside.

THE TEMPLATES

Templates can be found in the /user/themes/themename/templates folder. These templates are Twig templates and will be used to render your pages.

THE BLUEPRINTS

Blueprints are located in the /user/themes/themename/blueprints folder. The files within this folder are YAML files used to extend and modify the admin plugin with custom forms to make updating the website simpler.

PART 1: ONE PAGER MODULAR THEME

Now that we have a basic understanding of how Grav works, let’s get started on our first Grav theme: a one page theme showcasing Grav’s awesomeness. Below is what our content and themes folder are going to look like:

CONTENT FILE STRUCTURE

├── 01.home
│   ├── _download
│   │   └── download.md
│   ├── _features
│   │   └── features.md
│   ├── _highlights
│   │   └── highlights.md
│   ├── _intro
│   │   └── intro.md
│   ├── _overview
│   │   ├── grav-logo.png
│   │   └── overview.md
│   └── home.md

THEME FILE STRUCTURE

├── blueprints
│   └── modular
│       ├── highlights.yaml
│       └── showcase.yaml
├── css
│   └── main.css
├── fonts
├── imgs
├── js
├── sass
├── templates
│   ├── home.html.twig
│   ├── modular
│   │   ├── download.html.twig
│   │   ├── features.html.twig
│   │   ├── highlights.html.twig
│   │   ├── intro.html.twig
│   │   └── overview.html.twig
│   └── partials
│       └── base.html.twig
├── blueprints.yaml
├── onepager.yaml
├── screenshot.jpg
└── thumbnail.jpg

CONFIG FILES

SITE.YAML

The site’s configuration file. We should never edit the default configuration files found in system/config. Instead, we overwrite the settings we’d like to change via creating our own configuration files within user/config. Below is a simple version of a site configuration file.

For more complex configurations, have a look at the documentation.

title: 'One Pager'
author:
    name: 'Angie Vella'
    email: 'email@email.com'
metadata:
    generator: 'Grav'
    description: 'Simple One Page Theme for Grav'
    keywords: 'HTML, CSS, Grav, Theme, One Page'
    author: 'Angie Vella'
    robots: 'noindex, nofollow'

THEME FILES

As mentioned before, there are a couple of files Grav requires for a theme to function.

BLUEPRINTS.YAML

This file defines theme information and configuration options to be shown in the Admin panel. Blueprints are defined with YAML and below is our blueprints file for our One Pager Theme.

name: One Pager
version: 1.0.0
description: "A simple one page theme for Grav"
author:
    name: Angie Vella
    email: email@email.com
    url: http://www.website.com
license: MIT

ONEPAGER.YAML

This file contains theme configuration, like the blueprints file this is also defined in YAML. For this example we’ll keep it super simple.

enabled: true
default_lang: en

THEME TEMPLATES

Now that we have the files the theme requires to function, it’s time to get started on the Twig templates. These templates will be used to render our content.

BASE.HTML.TWIG

The base template is just that: the template that will be the base of our theme. We’ll be extending this template within our other templates. Let’s break it down:

<html lang=”{{ theme_config.default_lang }}”> – Gets the configuration set in onepager.yaml.

{% block head %}{% endblock head %} – This defines an area in the base template, typically containing the stuff we put in the<head>element. Note that the head in {% endblock %} is not required, but can be used for readability.

<title>{{ site.title }}</title> – Pulls the configuration set in config/site.yaml.

<link rel=”canonical” href=”{{ page.url(true, true) }}”> – Sets a canonical URL for the page.

<link rel=”icon” type=”image/png” href=”{{ url(‘theme://img/favicon.png’) }}”> – Points to the site’s favicons, located in the theme/imgs directory.

{% block stylesheets %} – Within this block we register our stylesheets for the theme.

{{ assets.css() }} – This outputs the stylesheets we just registered.

{% block javascripts %} – Just like the stylesheets block this registers our JavaScript files for the theme. Note that the jQuery library comes bundled with Grav.

{{ assets.js() }} – Renders the scripts we just registered.

<a href=”{{ base_url}}”>OnePager</a> – Links to the home page.

{% for module in page.collection.modular() %}
    <li><a href="#{{ module.header.anchor }}">{{ module.menu }}</a></li>
{% endfor %}

Runs over the collection defined withinhome.mdto create the navigation.

{% block content %}{% endblock %} – This is where content from other templates that extend this one will be.

{% block bottom %}{% endblock %} – We add our custom JavaScript initialization here.

And this is what the file looks like when it’s all put together:

<!DOCTYPE html>
<html lang="{{ theme_config.default_lang }}">

    <head>
        {% block head %}
        <title>{{ site.title }}</title>

        <link rel="canonical" href="{{ page.url(true, true) }}">

        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">

        <link rel="icon" type="image/png" href="{{ url('theme://img/favicon.png') }}">

        {% block stylesheets %}
            {% do assets.addCss('theme://css/main.css') %}
            {% do assets.addCss('https://fonts.googleapis.com/css?family=Montserrat:400,700') %}
        {% endblock %}

        {{ assets.css() }}

        {% block javascripts %}
            {% do assets.addJs('jquery', '110') %}

            {% do assets.addJs('theme://js/singlepagenav.min.js') %}

            {% if browser.getBrowser == 'msie' and browser.getVersion >= 8 and browser.getVersion <= 9 %}
                {% do assets.add('theme://js/html5shiv.min.js') %}
                {% do assets.add('theme://js/respond.min.js') %}
            {% endif %}
        {% endblock %}

        {{ assets.js() }}

        {% endblock head %}
    </head>

    <body>

        <header class="main-header">
            <div class="wrapper">
                <div class="logo">
                    <a href="{{ base_url}}">OnePager</a>
                </div>

                <nav class="main-nav">
                    <ul>
                        {% for module in page.collection.modular() %}
                            <li><a href="#{{ module.header.anchor }}">{{ module.menu }}</a></li>
                        {% endfor %}
                    </ul>
                </nav>
            </div>
        </header>

        <section class="content-wrapper">
            {% block content %}{% endblock %}
        </section>

        <footer class="main-footer">
            <p>&#169;<script type="text/javascript">document.write(new Date().getFullYear());</script> OnePager Grav Theme.</p>
        </footer>

        {% block bottom %}
            {{ assets.js('bottom') }}

            <script>
                $('.navigation-wrapper').singlePageNav({
                    offset: $('header.menu').outerHeight(),
                    updateHash: true,
                    currentClass: 'menu-active'
                });
            </script>
        {% endblock %}
    </body>
</html>

HOME.HTML.TWIG

The template used to render the home page (user/pages/01.home/home.md). It builds on top of the base template and adds anchors to the sections. These anchors will be defined within the modular markdown file’s Front Matter.

{% extends 'partials/base.html.twig' %}
{% block content %}
    {% for module in page.collection() %}
        <div id="{{ module.header.anchor }}"></div>

        {{ module.content }}
    {% endfor %}
{% endblock %}

INTRO.HTML.TWIG

The intro to our one page site. Simply pulls the content of the intro.md file using {{ content }}.

<div class="intro">
    <div class="wrapper">
        {{ content }}
    </div>
</div>

HIGHLIGHTS.HTML.TWIG

The second section of our website. This pulls the content from the highlights.md file as well as the the custom header settings defined in the file’s YAML Front Matter (We’ll understand this better once we get into the content files).

<div class="highlights">
    <div class="wrapper">
        {{ content }}
        {% for highlight in page.header.highlights %}
            <div class="highlight">
                <i class="fa fa-fw fa-{{ highlight.icon }}"></i>

                <h4>{{ highlight.header }}</h4>
                <p>{{ highlight.text }}</p>
            </div>
        {% endfor %}
    </div>
</div>

OVERVIEW.HTML.TWIG

By now you should start seeing a theme (no pun intended). This template renders the third section of the website. It pulls the content from overview.md and also get the image from the pages folder (section folder since this is a modular theme).

<div class="overview">
    <div class="wrapper">
        <div class="text">
            {{ content }}
        </div>

        <div class="image">
            {% set image = page.media.images|first %}
            {% if image %}
                {{ image }}
            {% endif %}
        </div>
    </div>
</div>

FEATURES.HTML.TWIG

Similar to the features template. This pulls the content defined within the features.md file and the file’s YAML Front Matter.

<div class="features">
    <div class="wrapper">
        {{ content }}
        {% for feature in page.header.features %}
            <div class="feature">
                <i class="fa fa-{{ feature.icon }}"></i>

                <h5>{{ feature.header }}</h5>
            </div>
        {% endfor %}
    </div>
</div>

DOWNLOAD.HTML.TWIG

The last template of our theme, pulls the content from the download.md file and the button defined in the YAML Front Matter.

<div class="download">
    <div class="wrapper">
        {{ content }}

        {% for button in page.header.buttons %}
            <div class="button-wrapper">
                <a class="button" href="{{ button.url }}">{{ button.text }}</a>
            </div>
        {% endfor %}
    </div>
</div>

CONTENT FILES

Our theme is now complete. We can focus on our content.

HOME.MD

This file tells Grav which subpages to pull to assemble the modular page, and which order to display them in. The name of the file also tells Grav to use the home.html.twig template to render the page.

---
title: Home
content:
    items: '@self.modular'
    order:
        by: default
        dir: asc
        custom:
            - _intro
            - _highlights
            - _overview
            - _features
            - _download
---

INTRO.MD

Within the YAML Front Matter we define the title of the section and an anchor. The content is then defined using markdown.

---
title: Home
anchor: intro
---

# OnePager
## A Simple One Page Modular Theme for Grav

HIGHLIGHTS.MD

Another title and anchor are defined, then we also create a custom header option called highlights. Each highlight has a header, text, and an icon. These are then rendered using the assigned template (highlights.html.twig).

Looking at the template you can see how the for statement {% for highlight in page.header.highlights %} loops through the highlights page header and then pulls the header {{ highlight.header }}, text {{ highlight.text }}, and icon {{ highlight.icon }}. At the end of this tutorial we’ll create a blueprint so these values can be edited via a form within the Admin panel.

---
title: Highlights
anchor: highlights
highlights:
    - header: 'Crazy Fast'
      text: 'Performance is not just an after thought, we baked it in from the start!'
      icon: fighter-jet
    - header: 'Easy to build'
      text: 'Simple text files means Grav is trivial to install, and easy to maintain.'
      icon: database
    - header: 'Awesome Technology'
      text: 'Grav employees best-in-class technologies such as Twig, Markdown & Yaml'
      icon: cubes
    - header: 'Super Flexible'
      text: 'From the ground up, with many plugin hooks, Grav is extremely extensible'
      icon: puzzle-piece
---
### Built on top of Greatness
#### Four core tenants keep Grav focused

OVERVIEW.MD

Similar to the intro.md. Here we only define the title and anchor in the YAML Front Matter, together with the content in markdown syntax.

---
title: Overview
anchor: overview
---

### Fast, Extensible, Open Source!
#### Grav is a modern open source flat-file CMS
Grav is a modern open source flat-file CMS. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse suscipit ultrices ligula eget accumsan. Sed egestas augue a risus semper pretium non sit amet odio.

FEATURES.MD

Here we basically repeat what we done in the highlights.md.

---
title: Features
anchor: features
features:
    - header: Markdown Syntax
      icon: text-height
    - header: Twig Templating
      icon: code
    - header: Smart Caching
      icon: rocket
    - header: Flexible Taxonomies
      icon: tags
    - header: Simple Install
      icon: cloud-download
    - header: Powerful Plugins
      icon: cogs
    - header: Intuitive UI
      icon: dashboard
    - header: File-Based
      icon: file-text
    - header: Documentation
      icon: bookmark
    - header: On Github
      icon: github
    - header: Responsive Design
      icon: html5
    - header: Awesomazing
      icon: heart
---

### Stuffed full of Amazing Features
#### This is a non-inclusive smattering of them

DOWNLOAD.MD

By now you’ve gotten the hang of the the YAML front matter. These headers can be as simple or as complicated as you want or need them to be. In this file we’ve defined the title and anchor for this section, together with a custom header defining our download button.

---
title: Download
anchor: download
buttons:
    - text: Download
      url: https://getgrav.org/downloads
---

### Get Grav

BLUEPRINTS

At this point our Grav theme is fully functioning, and we’ve also added the content for our one page website. Blueprints allow us to extend and modify the Admin panel. They are YAML files, defining a custom form for the specified template which then saves the data from the content file’s front matter.

Going over the files below, you can see they are very readable thanks to YAML. They extend on top of the default.yaml blueprint provided by Grav, and create a new tab in the Admin panel for each of the pages (in this case the highlights page and the features page).

HIGHLIGHTS.YAML

title: Highlights
'@extends': default

form:
  fields:
    tabs:
      fields:
        advanced:
          fields:
            columns:
              fields:
                column1:
                  fields:
                    name:
                      default: modular/highlights
                      '@data-options': '\Grav\Common\Page\Pages::modularTypes'
            overrides:
              fields:
                header.template:
                  default: modular/highlights
                  '@data-options': '\Grav\Common\Page\Pages::modularTypes'
        highlights:
          type: tab
          title: Highlights
          fields:
            header.highlights:
              name: highlights
              type: list
              label: Highlights

              fields:
                .icon:
                  type: text
                  label: Icon
                .header:
                  type: text
                  label: Header
                .text:
                  type: text
                  label: Text

FEATURES.YAML

title: Features
'@extends': default

form:
  fields:
    tabs:
      fields:
        advanced:
          fields:
            columns:
              fields:
                column1:
                  fields:
                    name:
                      default: modular/features
                      '@data-options': '\Grav\Common\Page\Pages::modularTypes'
            overrides:
              fields:
                header.template:
                  default: modular/features
                  '@data-options': '\Grav\Common\Page\Pages::modularTypes'
        features:
          type: tab
          title: Features
          fields:
            header.features:
              name: features
              type: list
              label: Features

              fields:
                .icon:
                  type: text
                  label: Icon
                .header:
                  type: text
                  label: Header

PART TWO – MNMM BLOG THEME

Since much of the code is repeated from the previous theme, we will only go over the new code.

CONTENT FILE STRUCTURE

├── 01.home
│   ├── _blog-post
│   │   ├── media.jpg
│   │   └── item.md
│   └── blog.md

THEME FILE STRUCTURE

├── css
│   └── main.css
├── fonts
├── imgs
├── js
├── sass
├── templates
│   ├── blog.html.twig
│   ├── error.html.twig
│   ├── item.html.twig
│   ├── modular
│   └── partials
│       ├── base.html.twig
│       └── blog_item.html.twig
├── blueprints.yaml
├── mnmm.php
├── mnmm.yaml
├── screenshot.jpg
└── thumbnail.jpg

PLUGINS

In the previous theme, we only used the plugins that come with the Grav Core + Admin Panel. For this theme we’ve added some more plugins;

• Feed – Lets you view a Grav Collection as RSS or Atom news feed.
• JS Comments – Enables you to add comments to your site with Discourse, Disqus, Facebook, Google+, IntenseDebate, and Muut comment systems.
• Pagination – Adds pagination to your site.
• Readingtime – Adds reading time to your pages.
• SimpleSearch – Enables you to search your site’s content.

CONFIG FILES

SITE.YAML

Our config files remain the same, the only thing that changed is the title in site.yaml.

THEME FILES

BLUEPRINTS.YAML

The Front Matter here was changed to reflect this theme.

MNMM.YAML

This file is completely unchanged.

THEME TEMPLATES

BASE.HTML.TWIG

The base template file is very similar to the previous theme. The only changes here are for content/aesthetic reasons. The Grav code remains the same and is explained it the previous section.

<!DOCTYPE html>
<html lang="{{ theme_config.default_lang }}">

    <head>
        {% block head %}
        <title>{{ site.title }}</title>

        <link rel="canonical" href="{{ page.url(true, true) }}">
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link rel="icon" type="image/png" href="{{ url('theme://img/favicon.png') }}">

        {% block stylesheets %}
            {% do assets.addCss('theme://css/main.css') %}
            {% do assets.addCss('https://fonts.googleapis.com/css?family=Open+Sans:300,400,600,700') %}
        {% endblock %}

        {{ assets.css() }}

        {% block javascripts %}
            {% do assets.addJs('jquery', '110') %}

            {% do assets.addJs('theme://js/singlepagenav.min.js') %}

            {% if browser.getBrowser == 'msie' and browser.getVersion >= 8 and browser.getVersion <= 9 %}
                {% do assets.add('theme://js/html5shiv.min.js') %}
                {% do assets.add('theme://js/respond.min.js') %}
            {% endif %}
        {% endblock %}

        {{ assets.js() }}

        {% endblock head %}
    </head>

    <body>

        <header class="main-header">
            <nav class="main-nav">
                <div class="wrapper">
                    <div class="logo"><a href="{{ base_url}}">MNMM</a></div>

                    <div class="search">
                        {% if config.plugins.simplesearch.enabled %}
                            {% include 'partials/simplesearch_searchbox.html.twig' %}
                        {% endif %}
                    </div>
                </div>
            </nav>

            <div class="site-title">
                <div class="wrapper">
                    <h1>{{ site.title }}</h1>
                </div>
            </div>
        </header>

        <section class="main-wrapper">
            {% block content %}{% endblock %}
        </section>

        {% block footer %}
        <footer class="main-footer">
            <div class="wrapper">
                <span class="credits">&#169;<script type="text/javascript">document.write(new Date().getFullYear());</script> MNMM Grav Theme.</span>

                <span class="icons">
                    <a class="button" href=""><i class="fa fa-facebook-square"></i></a>
                    <a class="button" href=""><i class="fa fa-twitter-square"></i></a>
                    <a class="button" href=""><i class="fa fa-google-plus-square"></i></a>
                    <a class="button" href=""><i class="fa fa-pinterest-square"></i></a>
                    <a class="button" href=""><i class="fa fa-linkedin-square"></i></a>
                    <a class="button" href=""><i class="fa fa-instagram"></i></a>
                    <a class="button" href=""><i class="fa fa-github-square"></i></a>

                    {% if config.plugins.feed.enabled %}
                        <a class="button" href="{{ feed_url }}.atom"><i class="fa fa-rss-square"></i></a>
                        <!--<a class="button" href="{{ feed_url }}.rss"><i class="fa fa-rss-square"></i> RSS</a>-->
                    {% endif %}
                </span>
            </div>
        </footer>
        {% endblock %}

        {% block bottom %}
            {{ assets.js('bottom') }}
        {% endblock %}
    </body>
</html>

BLOG.HTML.TWIG

This template is use to render the blog listings page, which in this case is the home page. It loops through the child pages (blog items) and includes the blog_item.html.twig template as well as pagination.html.twig which adds the blog listings page navigation.

{% embed 'partials/base.html.twig' %}

    {% set collection = page.collection() %}

    {% block content %}
        <div class="blog-list-wrapper">
            <div class="listing">
                {% for child in collection %}
                    {% include 'partials/blog_item.html.twig' with {'blog':page, 'page':child, 'truncate':true} %}
                {% endfor %}

                <div class="pagination-wrapper">
                    {% if config.plugins.pagination.enabled and collection.params.pagination %}
                        {% include 'partials/pagination.html.twig' with {'base_url':page.url, 'pagination':collection.params.pagination} %}
                    {% endif %}
                </div>
            </div>
        </div>
    {% endblock %}
{% endembed %}

ERROR.HTML.TWIG

This template is rendered when a page is not found. The error plugin is used which is included with the Grav Core + Admin Panel package.

{% extends 'partials/base.html.twig' %}
{% block content %}
    <div id="error">
        <div>
            <h2>{{ 'ERROR'|t }} {{ page.header.http_response_code }}</h2>
            <p>
                {{ page.content }}
            </p>
        </div>
    </div>
{% endblock %}

ITEM.HTML.TWIG

The item template renders the blog item content as specified in the blog.md file.

{% embed 'partials/base.html.twig' %}

    {% block content %}
        <div class="blog-item-wrapper">
            <div id="blog-item">
                {% include 'partials/blog_item.html.twig' with {'blog':page.parent, 'truncate':false} %}
            </div>
        </div>
    {% endblock %}
{% endembed %}

BLOG_ITEM.HTML.TWIG

The template that renders the blog item. In here we pull the date, post title, post content, reading time (using the Reading Time Plugin), post tags, social share buttons (using the Social Buttons Plugin), comments (using the JSComments Plugin), and post pagination.

<div class="blog-list-item">

    <div class="blog-list-header">
        <span class="blog-list-date">
            <time class="date" datetime="{{ page.date|date("c") }}">
                <span>{{ page.date|date("d") }}</span>
                <em>{{ page.date|date("M") }}</em>
                <em>{{ page.date|date("Y") }}</em>
            </time>
        </span>

        {% if page.header.link %}
            <h4 class="post-name">
                {% if page.header.continue_link is not sameas(false) %}
                <a href="{{ page.url }}"><i class="fa fa-angle-double-right u-url"></i></a>
                {% endif %}
                <a href="{{ page.header.link }}" class="u-url">{{ page.title }}</a>
            </h4>
        {% else %}
            <h4 class="post-name"><a href="{{ page.url }}" class="u-url">{{ page.title }}</a></h4>
        {% endif %}
    </div>

    <div class="list-blog-padding">
        {% if page.header.continue_link is sameas(false) %}
            <div class="post-content">
                {{ page.content }}
            </div>
            {% if not truncate %}
            {% set show_prev_next = true %}
            {% endif %}
        {% elseif truncate and page.summary != page.content %}
            <div class="post-content">
                {{ page.summary }}
            </div>

            <div class="meta">
                {% if config.plugins.readingtime.enabled %}
                    <span class="reading">{{ page.content|readingtime }}</span>
                {% endif %}

                {% if page.taxonomy.tag %}
                    <span class="tags">
                        {% for tag in page.taxonomy.tag %}
                            <a href="{{ blog.url|rtrim('/') }}/tag{{ config.system.param_sep }}{{ tag }}">{{ tag }}</a>
                        {% endfor %}
                    </span>
                {% endif %}
            </div>
        {% elseif truncate %}
            <div class="post-content">

                {% if page.summary != page.content %}
                    {{ page.content|truncate(550) }}
                {% else %}
                        {{ page.content }}
                {% endif %}
            </div>
        {% else %}
            <div class="post-content">
                {{ page.content }}
            </div>

            <div class="post-meta">
                {% if page.taxonomy.tag %}
                    <span class="post-tags">
                        {% for tag in page.taxonomy.tag %}
                            <a href="{{ blog.url|rtrim('/') }}/tag{{ config.system.param_sep }}{{ tag }}">{{ tag }}</a>
                        {% endfor %}
                    </span>
                {% endif %}
            </div>

            <div class="post-share">
                {% if config.plugins.socialbuttons.enabled %}
                    {% include 'partials/socialbuttons.html.twig' with {'url':page.url} %}
                {% endif %}
            </div>

            <div class="post-comments">
                {% if config.plugins.jscomments.enabled %}
                    {{ jscomments() }}
                {% endif %}
            </div>
        {% set show_prev_next = true %}
    {% endif %}
    </div>
</div>
{% if show_prev_next %}
    <div class="post-pagination">
        <div class="wrapper">
            {% if not page.isFirst %}
                <span class="lft"><a class="button" href="{{ page.nextSibling.url }}"><i class="fa fa-chevron-left"></i> Next</a></span>
            {% endif %}

            {% if not page.isLast %}
                <span class="rgt"><a class="button" href="{{ page.prevSibling.url }}">Prev <i class="fa fa-chevron-right"></i></a></span>
            {% endif %}
        </div>
    </div>
{% endif %}

CONTENT FILES

BLOG.MD

items: ‘@self.children’ – tells Grav to loop through the page’s subpages (the blog posts).

order: – Order configuration for the blog posts.

pagination – enables the pagination.

---
title: 'MNMM Grav Theme'
content:
    items: '@self.children'
    order:
        by: date
        dir: desc
    limit: 5
    pagination: true
feed:
    description: 'Sample Blog Description'
    limit: 10
pagination: true
---

# MNMM Grav Theme

ITEM.MD

This is what the blog post files look like. A title and date are specified, as well as taxonomy. In this case we add this post to the blog category and define its tags. After the YAML Front Matter, the blog post content is defined.

---
title: The Urban Jungle
date: 17:34 07/04/2014
taxonomy:
    category: blog
    tag: [travel, photography, city]
---

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec ultricies tristique nulla et mattis. Phasellus id massa eget nisl congue blandit sit amet id ligula. Praesent et nulla eu augue tempus sagittis. Mauris faucibus nibh et nibh cursus in vestibulum sapien egestas. Curabitur ut lectus tortor. Sed ipsum eros, egestas ut eleifend non, elementum vitae eros. Mauris felis diam, pellentesque vel lacinia ac, dictum a nunc. Mauris mattis nunc sed mi sagittis et facilisis tortor volutpat. Etiam tincidunt urna mattis erat placerat placerat ac eu tellus.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec ultricies tristique nulla et mattis. Phasellus id massa eget nisl congue blandit sit amet id ligula. Praesent et nulla eu augue tempus sagittis. Mauris faucibus nibh et nibh cursus in vestibulum sapien egestas. Curabitur ut lectus tortor. Sed ipsum eros, egestas ut eleifend non, elementum vitae eros. Mauris felis diam, pellentesque vel lacinia ac, dictum a nunc. Mauris mattis nunc sed mi sagittis et facilisis tortor volutpat. Etiam tincidunt urna mattis erat placerat placerat ac eu tellus. Ut nec velit id nisl tincidunt vehicula id a metus. Pellentesque erat neque, faucibus id ultricies vel, mattis in ante. Donec lobortis, mauris id congue scelerisque, diam nisl accumsan orci, condimentum porta est magna vel arcu. Curabitur varius ante dui. Vivamus sit amet ante ac diam ullamcorper sodales sed a odio. Curabitur ut lectus tortor. Sed ipsum eros, egestas ut eleifend non, elementum vitae eros. Mauris felis diam, pellentesque vel lacinia ac, dictum a nunc.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec ultricies tristique nulla et mattis. Phasellus id massa eget nisl congue blandit sit amet id ligula. Praesent et nulla eu augue tempus sagittis. Mauris faucibus nibh et nibh cursus in vestibulum sapien egestas. Curabitur ut lectus tortor. Sed ipsum eros, egestas ut eleifend non, elementum vitae eros. Mauris felis diam, pellentesque vel lacinia ac, dictum a nunc. Mauris mattis nunc sed mi sagittis et facilisis tortor volutpat. Etiam tincidunt urna mattis erat placerat placerat ac eu tellus. Ut nec velit id nisl tincidunt vehicula id a metus. Pellentesque erat neque, faucibus id ultricies vel, mattis in ante. Donec lobortis, mauris id congue scelerisque, diam nisl accumsan orci, condimentum porta est magna vel arcu. Curabitur varius ante dui. Vivamus sit amet ante ac diam ullamcorper sodales sed a odio.

CONCLUSION

After building these two themes, you should have a basic understanding of how Grav works. As I’ve already said, in my opinion Grav can be as simple or as complex as you want/need it to be. I look forward to seeing some awesome things being built with this is awesome platform!

The post How To Build Your Own Theme for Grav CMS appeared first on Jayatechnology.

Well that’s me, in any case. Given the popularity of the monthly calendar format, I suspect many others feel much the same way. It’s no wonder, then, that we like putting calendars on websites. It can give our users that exact same context, that mental image of the amount of time they have to work with.

“Oh, the 24th is a Wednesday, I can do that.” That’s what we’re looking for. Add in a few calendar features like reservations or ticket sales, and you’re good to go. So how do you put a calendar on your site? Well, you could start by checking out the list of options below.

GOOGLE CALENDAR

There’s not a lot to say. I mean, it’s Google Calendar! If you have any Google-related services, you’ve probably at least seen it. It’s a solid product, with all of the basic features you’d expect. What’s more, it makes use of Google’s extensive collaboration features, and integration with all other Google products.

It’s free, with a business option that starts at $5 USD per month available through G Suite. If you want to know how to put a Google Calendar on your website, look no further.

BRAVENET CALENDAR

Bravenet Calendar has some upsides and downsides. On the upside, it’s free, and generally full-featured. You can theme it to match the rest of your site, and you’re good to go. However, the free version is ad-supported. And you can’t properly embed it.

No, what you get is a link to your calendar, which acts as a standalone page/app, with a link back to your main site. But, if all you need is a basic calendar on a budget, it’s free. And the paid version starts at $3 USD per month.

AVAILABILITY CALENDAR

This calendar service is designed for one very specific purpose: letting people know when your rentable property (or “Holiday Home”) is available for rent. That’s it. It does one thing, and does it pretty well. It’s compatible with just about every CMS, as you can just embed it right on your site. It can also sync with services like AirBnB.

At $15 USD per year, it’s not a bad product, if you need to do this one very specific thing.

THE EVENTS CALENDAR

Billing itself as The Events Calendar, this product seems rather self-confident. The main product is a free WordPress plugin, which you can download, install, and manage yourself. It looks good, and is pretty feature-complete. So if you use WordPress, give it a go.

The pro version starts at $89 USD per year, and comes with extra calendar formats, search options, shortcodes, and more.

UPTO

UpTo offers embeddable calendars primarily for events. They are customizable, of course, and you can use a variety of calendar formats. Some relatively large brands like People Magazine, TechCrunch, and the Detroit Lions are using them, so that speaks well of the service’s ability to handle large amounts of traffic. They also offer applications for iOS, Android, and Google Chrome to help you manage your own calendar, and even follow other people’s calendars (provided they’re public).

There is no free version, but there is a fourteen-day free trial. The basic plan starts at $9 USD per month.

LOCALENDAR

Localendar is a event calendar service designed specifically for small businesses, sports teams, churches, non-profits, and pretty much any other small, local organization that needs one. The feature list is pretty extensive: extensive enough to compete with a few enterprise-level solutions I’ve found.

And yeah, there’s a free plan. It’s ad-supported, but it’s pretty good. Paid plans start at $45.95 USD per year.

TIMELY

Timely advertises beautiful calendars. And they are pretty good-looking. On top of that, there’s a lot of integrated functionality for signing up to events, selling tickets, and more. Plus you can import events from Facebook, sell recurring tickets, and all of that is available in the free plan. You can embed your calendars, or use their own WordPress plugin.

The paid plans start at $9 USD per month, and the feature list just gets longer from there.

OCCASION

Occasion is one of the pricier options on this list at $249 per year. They do offer a “free sample calendar”; but it’s just that: a free sample. That said, it’s a pretty well-rounded app, so if you need a calendar for your business, it’s worth looking at.

You can sell tickets, and there are themes designed for different types of businesses. There’s a whole bunch of integration options, including social media sites, email marketing apps, deal and coupon sites, payment gateways, and CMSs, of course.

TOCKIFY

Tockify is all about clean, modern-looking calendars that can be integrated into just about any design. Feature-wise, it’s fairly simple, but offers a pretty detailed visual customizer to match your calendar to your website. There’s also a mini-calendar option if you’re working with limited space.

They offer a pretty well-rounded free plan with unlimited events. The paid plans start at $8 USD per month.

The post 9 Best Embeddable Calendars appeared first on Jayatechnology.

DV DEVELOPER IS THE ANSWER TO EVERY WEB DEVELOPER’S DREAMS

DV Developer works exclusively with Linux, and is crafted especially for seasoned developers, who are basically left to their own devices and unencumbered in the process of creating everything from scratch. And true enough, as far as software is concerned, the user has no line on the horizon. He\she is also responsible for server backup and administration.

Nevertheless, (mt) Media Temple takes full charge of uptime, hardware, or SSH availability. Interestingly, high-speed RAID-10 SAS disks are used here, and they happen to be ideal for data centers.  

It is necessary to mention that DV for developers comes with Parallels Virtuozzo Containers, and therefore has proficient settings and diagnosing tools which enhance system performance while minimizing the chances of overhead. The Parallels PowerPanel does a fast job out of rebooting, backing up, repairing or rebuilding the server.

What is more, you can scale from 1 GB to 32GB, or scale back if you reckon that you no longer need all that memory (RAM) anymore. This is big because it proves just how powerful (mt) Media Temple’s virtual private hosting is.

DV MANAGED IS TAILORED FOR RESELLING

(mt) Media Temple’s DV Managed is just right for designers who resell hosting to their clients. While allowing for a straightforward and simple allotment of resources for every client in particular, and giving each a control panel, the administration interface also facilitates a fast and hassle-free installation of applications like WordPress or Joomla. I would like to emphasize that the AccountCenter is very user-friendly. Once again, the Parallels PowerPanel is available for server reboot, repair, rebuild or backup.

MONEY RETURNED IN CASE OF UPTIME FAILURE

I kept the best treat for last. When Media Temple says that the uptime is uninterruptible, those aren’t just empty words. If the user’s uptime is not 99.999%-perfect, he\she gets to be partially refunded, according to their 20/20 uptime guarantee. In short, for every 20 minutes of inexplicable downtime, (mt) Media Temple pledges to return 20% of the monthly sum of an elected service period plan. This is important because it demonstrates just how seriously (mt) Media Temple takes the uptime of their DV Managed and DV Developer clients.

It comes as no surprise that ringing names such as Sony or Red Bull (confirm with Alex) have selected (mt) Media Temple as a hosting provider. Their reliability, support and dedication seem to exceed those of any other hosting company.

[This was a sponsored review for Media Temple]

The post Quality Virtual Private Servers for Web Developers and Designers appeared first on Jayatechnology.

Users expect a stable and reliable service, so interruptions not only decrease customer satisfaction but increase support requests.

In this article I’m going to talk about three areas that are particularly sensitive when it comes to downtime, and offer some improvements that will push you towards 99.9999% uptime.

1. MONITORING AND ALERTS

Properly monitoring your infrastructure is the first step in being proactive with any issues, and it’s the most efficient way of discovering issues before they affect your customers.

This also includes aggregating and retaining a record of stats such as application performance metrics, and system resource utilization. Alerts then build on the metric collection through evaluating rules against current metrics. In other words it looks for anything weird.

A client is often implemented on each host that gathers metrics for monitoring, and then reports back to a central server. The metrics are stored in a database and are available for services like searching, alerting, and graphing.

There is monitoring software that can do this for you, including:

GRAPHITE

Graphite provides an API that has the support of dozens of applications and programming languages. Metrics are pushed, stored, and graphed in the central Graphite installation.

PROMETHEUS

Prometheus can be used to pull data from a variety of community supported and official clients. It has an alerting system that is built-in, is highly scaleable, and comes with client libraries for several programming languages.

2. SOFTWARE DEPLOYMENT IMPROVEMENT

Software deployment strategies are one area that many people overlook, but it has a huge impact on your downtime.

Having a deployment process that is very complex, or requires a number of manual steps to be completed will result in the production environment leaving the development environment behind. This contributes to risky software releases because every deploy is a much larger set of changes, and that naturally carries a much higher risk of problems arising. This in turn leads to numerous bugs, which slow down development and can potentially lead to the unavailability of resources.

To combat this, you need some up-front planning. If you already have this issue then set aside some time to smooth out the problems and start afresh, before you move on.

Finding a strategy that allows you to automate the workflow, code integration, deployment, and testing, will give you the best chance of syncing your production environment with your development environment.

A good place to start automating deployments is to make sure that you’re following best practices with regards to continuous integration and delivery (CI/CD) and testing the software. These best practices include:

MAINTAINING A SINGLE REPOSITORY

Maintaining a single repository ensures that every person on the development team works on the same code, and can test their changes easily.

AUTOMATING TESTING AND BUILD PROCESSES

Automating your development and testing is essential. This will simplify deployment in an environment similar to the final use-case, and is particularly helpful when debugging platform-specific issues.

3. IMPLEMENTING HIGH AVAILABILITY

The last strategy to use when attempting to minimize downtime is to use the concept of high availability on the infrastructure. This includes principles used in designing resilient and redundant systems.

The system must be able to detect the health of the system. If the system fails, it needs to know precisely where it has failed.

The system must be able to redirect traffic. This is essential in minimizing downtime as it ensures that traffic between servers is quick, with minimal interruption.

Eliminate single points of failure. This means that several redundant servers are used. Moving to multiple web servers and a load balancer from a single server is one of the ways you can upgrade to a highly available infrastructure. The load balancer performs regular health checks on web servers and routes traffic from those servers that are failing. (It also enables a more seamless deployment of code.)

Increasing database resilience using database replication is another way you can add resilience and redundancy. Different database models have different configurations of replication. However group replication is the most interesting because it allows you to have both read and write operations on a redundant cluster of servers. Failing servers can be detected and routing done to avoid downtime.

CONCLUSION

In this article we’ve covered three areas where processes and infrastructure improvements will lead to less downtime. This will lead to happier clients, and of course ultimate more revenue.

Investigating the changes you can make to reduce downtime is one of the best investments you can make in software; start by improving deployment, monitoring your metrics, and ensuring a high infrastructure availability.

The post 3 Ways To Minimize DownTime appeared first on Jayatechnology.

Reasons to avoid using Akismet

1. It’s only free for personal use; otherwise you have to pay from $60 a year for each site up to $50 a month (“for publishing networks, agencies, hosts and universities or multiple sites”). Part of the problem with that concept is that they don’t really define what they consider a “commercial” website. Is a commercial site a mommy blogger with a few Adsense ads or is it only true commercial enterprises that sells a product or service?
2. A lot of obvious spam gets through.
3. Doesn’t actually block the spammers. Akismet might flag their comments as spam but it does nothing to keep them from dumping 100 spam comments a day on your site. All of that junk uses your bandwidth, disk space and clutters up your WordPress database.
4. False positives. Akismet has a reputation for flagging good comments as spam. That means you’re still going to have to slog through all 1,248 comments in your spam folder to make sure it is all truly spam.
5. It can ignore comments made by legitimate visitors. I’ve seen several articles about this and experienced it myself. You leave a thoughtful reply to a blog post and when you hit submit there’s no notice of the comment awaiting moderation, no posting of the comment and no outward sign that what you took the time to write was actually accepted. Akismet may have simply blocked it.

Ah, but wait, Akismet is supposed to send suspicious comments to the spam folder. Apparently, not only does it send some legitimate comments to the spam folder, it doesn’t let some comments even into the system. Through the mysteries of their algorithm and reporting system, one of my email addresses was apparently placed on a spammers list. I don’t do a lot of blog commenting and when I do, it is usually several paragraphs long and they are always on point and would contribute to the conversation. In researching this article for Olaf, I found several folks theorizing that a denial of a trackback or even a single blogger tagging a comment with a particular email address can get that email banned in Akismet. I had always just assumed something went wrong between my lousy Internet connection or the blog I was commenting on. I don’t spam. It never occurred to me that I was on some sort of blacklist.

Even allowing for some false positives and blocking of legitimate comments, Olaf and I still don’t use Akismet. If I’m still going to have to review every comment being left on my blog, manually delete them AND never even see some potentially great comments; what’s the point?

So, if we don’t use Akismet anymore, what do we use?

Alternatives to Akismet

There are a number of free alternatives to Akismet that are more effective and are simply a better way to save you time, keep garbage from getting into your database in the first place and block bad bots before they have a chance to leave comments.

First off, Olaf and I don’t think there’s a single answer for fighting comment spam. The spammers are constantly changing their approach and there just doesn’t appear to be a 100% solution available. But, that might be a good thing in the long run. Perhaps some of the reasons why Akismet is not as effective as it once was is that in trying to be a sole solution, it can’t focus enough on each issue we face from spammers.

As a rule, Olaf has been using a three-pronged approach against spammers – filtering the bad traffic, blocking bad bots and automated comment post scripts and a more traditional comment-based spam blocker.

Cloudflare

Cloudflare has become our first line of defense against comment spam. They maintain their own blacklist, use 3rd party lists like AVH and it can be configured to block known spammers by their IP addresses. Once CloudFlare has noticed a new attacker, Cloudflare starts to block the attacker for both the particular website and the entire Cloudflare community. Olaf tells me that Cloudflare has the fastest and most secure network that he has ever worked with. He’s also noticed, across dozens of sites that he owns or operates for his clients, that Cloudflare has measurably decreased site load times. Cloudflare has also been known to recognize and repel brute force attacks against a site.

AVH First Defense Against Spam Plugin

AVH is a good alternative to the protection provided by Cloudflare. This plugin uses external lists (Stop Forum Spam, Project Honey Pot and Spamhaus) to block bad bots and users from even accessing your site. With AVH, you can also create your own blocked IP list.

5G Blacklist

5G Blacklist creates something of a firewall for your WordPress installation. The folks at PerishablePress.com believe the best way to stop those who wish to harm or exploit your site is to evaluate request strings and simply block them from even accessing your site. 5G helps reduce the number of malicious URL requests and protects against evil exploits, bad requests and other garbage.

5G isn’t a plugin. It is a bit of code that you add to your .htaccess file. If you don’t have direct access to your .htaccess file, you should consider changing hosts. But, in the meantime, you can make changes to your .htaccess file via one of the tools in the WordPress SEO plugin from Yoast.

Antispam Bee

This is a gem of a plugin that has not received the attention it deserves. It is the closest thing to a free version of Akismet except it doesn’t have the problems with false positives and saving all of the spammy comments for review. Antispam Bee blocks virtually all of the garbage from getting into your database in the first place. It doesn’t stop the spammer from leaving the comment; it just deletes it before you ever see it. Of course, you can change the settings to allow the comments into your Spam queue for individual review.

This plugin has a strong and loyal following. When the original developer had to beg off the project, members of the WordPress community have rallied behind him to keep this powerful plugin alive.

Stop Spam, Stop Wasting Time

All in all, the best defense against spam is to utilize a system that begins with preventing access from your WordPress site and then properly handling anyone who manages to get past that first line of defense. We don’t use Akismet anymore because it lets the spammers gain access to the site and may delete legitimate comments. Flagging comments as spam lets the spammers leave their garbage and the blog owner still has to review each comment – a total waste of time.

Deploying an approach that begins at the server level and denies known spammers and hackers from accessing your site in the first place is far more effective. Add to that a plugin like Antispam Bee and you will see your spammy comments virtually disappear – we did.

The post Why We Don’t Use Akismet appeared first on Jayatechnology.

Whether you’re a tester or a developer, I hope you’ll try pairing! And no matter what your main specialty, pairing with someone in another specialty is so rewarding on so many levels. You’re bringing different perspectives together, which helps overcome your unconscious biases.

If you’re participating in the Ministry of Testing’s 30 days of agile testing challenge, I hope this article will help you with the pairing challenges! I didn’t mention it in the article, but pairing works well if you and your pair are not co-located. We have great tools these days like ScreenHero for screensharing along with audio and video.

I’d love to hear your experiences with pairing.

I also recommend publishing articles with Ministry of Testing. For one thing, they compensate you. And you have the option of donating your comp into their Scholarship Fund. They have expert editors to help you. Whether you are a newbie or experienced author, you will enjoy the experience.

The post Tips for tester-developer pairing appeared first on Jayatechnology.