Observations on Modern Blogging

Lately, I’ve been reading a lot of blog posts.

In fact, most of them are like this one.

One sentence per paragraph.

Or, if you’re feeling adventurous, maybe two. Like this paragraph.

As if every line was earth-shattering news that deserved a paragraph all to itself.

I understand what you guys are trying to do.

I get it.

You understand that short paragraphs are considered helpful.

You understand readers have short attention spans.

And you understand that writing long paragraphs is hard.

But I have a request.

And I’ll keep it brief.

Stop it.

Please.

It’s really annoying.

Thanks.

Gravity Forms Dashicon Plugin

If you’re someone like me that spends a lot of time in the WordPress admin, you’ll realize that little details in the UI can make a big difference. Combine that with my already slightly OCD bent, and it probably won’t surprise anyone that I find the lack of a Dashicon for Gravity Forms extremely annoying… so much so that I decided to make a plugin to fix it.

You can download it on GitHub. Hopefully they’ll update the core plugin before too long and this can become unnecessary.

Responsive, Flexible-Height Sticky Footers with Javascript

Back in March, I wrote a post about creating sticky footers with CSS using display: table and display: table-row. Since I wrote that post, it’s become by far the highest-traffic post on the site. Obviously it’s filling a need.

Since writing it though, I’ve discovered some issues with that approach. Sliders seem to be the biggest problem. For whatever reason, responsive sliders like bxSlider, RoyalSlider, and a few others break when they’re placed inside of a table or an element with display: table applied. Since the sticky footer method I posted applies display: table to the <body>, that pretty much means that responsive sliders break everywhere for me.

In April, Cory Simmons posted about using JavaScript for Responsive Dynamic-Height Sticky Footers. I mentioned in my post that I didn’t really care for the idea of using JavaScript to power sticky footers, but I must admit that I like the approach he came up with:

See the Pen Responsive Dynamic Height Sticky Footer by Cory Simmons (@corysimmons) on CodePen.

I think it really depends on what you need. If you’re building out a lightweight site that’s unlikely to use sliders or other more complex JavaScript components (I can only guess that display: table could prove problematic for them as well), then the CSS solution might be fine. For bigger sites though with more complex content, you might be best to go the JavaScript route.

Custom Post Type Search Results Templates in WordPress

As I was building out the the knowledge base section of the marketing site for my new WordPress church themes project, I came across the need to have a custom search results template for my knowledge base articles (custom post types called kb_article).

I figured that WordPress would have something build-in by default for this like they do with archive-{post_type}.php or single-{post_type}.php, but it turns out that’s not the case. The search results template WordPress looks for is search.php. If that’s not there they revert to archive.php and if that’s absent, index.php.

Limiting Search to a Particular Post Type

Before I go on, I want to quickly cover how to limit your search results to a particular custom post type. Add a hidden input to your search form with a name of post_type and the value attribute set to the name of whatever post type you want to search. In my case, my post type was called kb_article, so my form code looked like this:

Display Custom Results

We’ll name our custom search results templates using the WordPress filename conventions of {template}-{post_type}.php. In our case, that would result in search-kb_article.php. We could just check to see if that post_type=kb_article is set in the URL string and use get_template_part to load it if it is, but let’s go a step further. We’ll check to see if post_type is set in the URL string, and if it is, also check to see if custom search template exists for that post type using the {template}-{post_type}.php naming pattern. If it does, we’ll load it. If not, we’ll continue with the default search template.

So far this has worked well for me. If you have any ideas on how it could be improved, let me know in the comments.