WordPress Archives | Megan Garwood

November 15, 2018 by Megan Garwood

Don’t switch your website away from WordPress until you read this

Thinking about switching your website away from WordPress?

The sound of an “easier” platform—one that makes editing super simple right out-of-the-box, like SquareSpace or Showit—can definitely be alluring. Before you pull that trigger, though, think very carefully: in the long term, it’s probably not a smart business decision to switch.

In this post, I’ll outline the reasons why I think WordPress is still the best long-term website platform for small businesses (and for bloggers: oh my gosh, absolutely no contest) in 2018.

November 8, 2018 by Megan Garwood

wp_reset_postdata not working? See if you’re being affected by this known WordPress bug

Development / WordPress

Are you having trouble with wp_reset_postdata not working like it should?

If you’re trying to reset post data on an admin page, you may not be experiencing a simple case of programmer error. There’s a known bug in WordPress (that’s been around for SEVEN years, believe it or not) related to wp_reset_postdata on admin edit pages.

Read on to find out if this bug is affecting you, and if so, how to get around it.

Known wp_reset_postdata bug on admin pages

To put it simply, there’s a known bug in WordPress core that means wp_reset_postdata doesn’t work as it should on admin edit pages.

A tiny note exists on the WP_Query class reference, but if you happen to miss that—I did when I stumbled on the bug myself—you could potentially spend hours wondering what the heck you’re doing wrong.

Don’t hold your breath for a quick fix, either: the bug was first reported in 2011 and the last progress you can see on the ticket was from over a year ago, so it may not be getting fixed any time soon. It’s not a huge bug, so the WordPress team have bigger fish to fry.

There’s a lot more detail on the specifics of the problem on Trac ticket #18408. Some of the most informative comments are:

While using an explicit WP_Query object in a meta box, you cannot reset the postdata after the loop, no matter what you try. Any subsequent meta boxes identify global $post as the last post of the custom query.
— @misternify, https://core.trac.wordpress.org/ticket/18408#comment:9

The root issue is that wp_reset_postdata() is designed to reset globals to match the main query. But in the case of post.php, there is no main query – the $post global is populated manually, using get_post(), rather than through the normal $wp_query loop.
— @boonebgorges, https://core.trac.wordpress.org/ticket/18408#comment:14

How to get around the wp_reset_postdata admin bug

There are a handful of different solutions suggested in the Trac ticket’s discussion. The one you ultimately choose is down to programmer preference, but here’s how I decided to proceed:

The solution I used in EBB was suggested by @jpSimkins in https://core.trac.wordpress.org/ticket/18408#comment:25:

To bypass this issue, do not use the_post as this is the issue.

So, after you issue your query and start to loop through the results, do not use $query->the_post() to set up post data. As @jpSimkins notes in his comment, you won’t be able to use template tags like get_the_title() without arguments, but you can still access that information in other ways.

Here’s the relevant code snippet from EBB for your reference:

$args = array(
	'post_type' => EBB_Optin_CPT::POST_TYPE_SLUG,
	'post_status' => 'publish',
	'posts_per_page' => -1,
	'order_by' => 'title',
	'order' => 'ASC'
);

$optin_query = new WP_Query( $args );

if ( $optin_query->have_posts() ) {

	$results = array();

	// Non-standard loop due to ongoing bug in core: https://core.trac.wordpress.org/ticket/18408
	// Can't wp_reset_postdata on post.php edit screen
	foreach ( $optin_query->get_posts() as $p ) :

		$results[] = array(
			'id' => $p->ID,
			'title' => get_the_title( $p )
		);

	endforeach;

}

According to the discussion on the Trac ticket, you can also use get_posts without encountering the bug (as long as you don’t setup_postdata in your results processing).

Have you been affected by the dreaded wp_reset_postdata bug? Feel free to moan about how much time you wasted looking for the problem in the comments below. ?

wp_reset_postdata not working? See if you’re being affected by this known WordPress bug | megangarwood.com/blog

November 1, 2018 by Megan Garwood

How I added affiliate disclosures to my blog without having to copy and paste them into each post

Business / Development / Process & Systems / WordPress

If you make use of affiliate links in your blog posts, having a proper affiliate disclaimer in your blog posts is a necessity…if you want to stay out of legal trouble, that is. ?

Most bloggers just copy and paste their affiliate disclosure into their posts. While this works well enough—assuming you don’t accidentally forget to add it before publishing your post, oops!—there are much better ways of covering your legal bases in your blog posts.

How to add affiliate disclosures to your WordPress blog posts without having to copy and paste

Build websites like a pro web developer: a look behind-the-scenes at my web development process

Development / Tips & Tricks / WordPress

Disclaimer: I may receive a commission if you purchase something I link to in this post. I only recommend tools or services I love, use personally, and wholeheartedly believe will help you do business better. Read more here.

Have you ever wondered exactly what your developer is doing after you hand a site design over to her?

Unless you’re a super-seasoned web professional—and even if you are!—the web development process can be a bit…mysterious.

Today, I want to help clear up some of the secrecy surrounding the web development process. I’m going to peel back the curtain a little and explain my “standard” WordPress web development process for you in-depth.

After reading this post, the next time your developer takes the baton from you to begin her part of your web project, you might not feel so “in the dark.”

Step #1: Prep work

Okay, okay: the REAL step #1 is sending out a proposal and project negotiation, but you’re probably already familiar with that part of the process, so we’ll skip it for now. 😉

The prep work phase involves a lot of information-gathering.

I reach out to the client before the project begins to let them know when I need the site mockups and/or style guide. I also ask for copies of all images and graphic elements that I’ll need to replicate the mockups saved in the appropriate file type. And, if there’s an existing site that has content to integrate into the new site, I get access to it so that I can duplicate it on my server.

Before development officially begins, I create a tracking board in Asana that covers all the important milestones of the project and invite my client to it. Then, she can easily see when she needs to deliver each item and when she can expect to see a completed demo site.

She can also follow my progress, since I check things off the project to-do list as I finish them. I find that this helps alleviate some of the nerves associated with working with a new client, since they can see that I’m actually working on their site and moving toward demo site delivery.

Step #2: Site setup

Once the project actually begins, I set up my local development environment. I work locally because it helps move development along faster and I don’t have to worry about anyone stumbling across the partially completed site on the internet.

For WordPress sites, I prefer to use Local by Flywheel to set them up: it’s quick and painless, and works just fine even though I don’t actually use Flywheel’s hosting (I’m team WPEngine). If needed, I upload the existing site’s database and files into Local as well.

Next, I’ll create a folder for the new theme I’ll be developing and install any necessary parent theme, such as Genesis. I then set up my new theme structure to work with gulp, a task runner that automatically performs steps in my build process, and make an initial commit to my GitHub account to test git integration.

I like to back up each site I develop to git in case of a computer failure or natural disaster! Also, I love git’s version control to make sure I don’t lose anything.

The final step in my local site set-up process is adding pages to the navigation menu(s).

Step #3: Basic site structure

The first bit of real development I do is creating the basic structure of the site. The site structure consists of universal site elements—like the header, navigation, and footer—that appear site-wide or on many of the site pages.

Like everything else in my development process, I work on the site structure in a mobile-first fashion. So, I build and style the mobile header, navigation, and footer BEFORE I start working on the desktop version. (For an overview of the benefits of mobile-first, I highly recommend Mobile First by Luke Wroblewski – it’s an oldie-but-goodie!)

Step #4: Individual pages

After the basic site structure is complete, I start developing the site’s individual pages. I’ll develop every page except the homepage during this phase, again following a mobile-first pattern.

Step #5: Blog

After the individual pages are complete, I work on developing and styling the site’s blog (if one is included). I begin by styling the blog index and archives, then move on to work on the single post layout.

Step #6: Home page

Finally, I wrap up development by building and styling the homepage. Many developers start with the homepage since it’s the site’s entry point, but I leave it until the end of the project.

Why?

It’s simple: often, the homepage design includes elements from other parts of the site, like blog post excerpts or short bits of content from the other pages. If I’ve already created and styled those elements, it’s a lot faster and easier to drop them into the homepage.

Step #7: Upload to demo server

After development of the full site demo is complete, I upload the site from my local server to a demo server on the web so that the client can preview and use it. I normally host my demo sites on a transferable install in my WPEngine account so that I have full control of hosting, but can simply hand over control to a client when the site’s finished if they want to use WPEngine as well.

The sites are password-protected, so only project stakeholders with the login information can view the demo site. And, the demo site is fully functional, so clients can log in and update content or otherwise make changes to it.

Step #8: Revisions

Once clients have had around a week to review the demo site, revisions begin. For a standard project, clients get a choice between either one week of unlimited revisions (as many rounds as desired!) or three rounds of revisions spread over no more than two weeks’ time.

Clients send me revision requests via Asana, we discuss if needed, and then I perform the revisions and upload them to the demo site for testing.

Step #9: Cross-browser testing

After revisions are done and the final site has been approved, I—or one of my trusted junior developers—perform cross-browser testing (CBT for short) on the finished site. I make sure the site looks and acts as it should across the most popular browsers in OS X, Windows, iOS, and Android. If any bugs are found during CBT, they’re fixed before launch.

Step #10: Launch!

The most exciting part has finally arrived: site launch! I either transfer billing to the client (which converts the transferable install on my WPEngine account to a full install on their account) or upload the site to the server where it will “live” indefinitely.

This is usually the last step of most of my development projects, but some clients prefer to keep me around on retainer to deal with any issues that may arise or to add new content to the site. Even if we don’t have a maintenance agreement in place, I fix bugs on the completed site (as long as they’re not caused by updates) for a year after launch.

Though it sounds long and complicated, the development process moves along fairly quickly: the entire thing from start to finish is usually completed in six weeks.

Do you feel more enlightened about what goes on behind-the-scenes when you turn a project over to your developer now? ?

May 24, 2018 by Megan Garwood

Why I integrated a page builder into my custom WordPress website (and why you should consider it, too)

Business / Design / Development / Process & Systems / WordPress

If you’re new around here, you may not know it, but I’m a web developer by trade. And, like many other web developers, I tend to be a little bit (or a lot) critical of website “builders:” graphical interfaces that allow you to create a website much like you would a Word document or a Photoshop design.

Picture things like SquareSpace, ShowIt, Divi, etc. Now, picture me crinkling up my nose and frowning, and you’ve got the right idea. ?

Despite my natural developer’s aversion to page builders, last summer when I relaunched my business website, I decided to integrate one into my new site…even though I’m perfectly capable of coding every page from scratch.

Oh, the horror! Right?!

Not really.

There were a couple of strategic reasons why I went the page builder route, and I’ll lay them out for you in this post.

2 reasons why I chose to build my new WordPress website with the help of a page builder

#1 – Speed of development

Time is money, friend!

I built my new website without taking any time out from my client work. That meant I was working on it alongside a full load of retainer hours and custom projects, so I needed to be really efficient at developing it.

Using a page builder is significantly faster (and more efficient) than hand-coding every page on a site. Page builders help me keep development costs reasonable for my client projects, too, since they allow me to spend less time on the tedious parts of development and more time making sure I really nail the look and feel of a site.

#2 – Outsourcing

The longer I stay in business, the more I plan to outsource. Website content updates are no exception!

A website developed with the aid of a page builder is much easier for someone with little to no code knowledge (like a virtual assistant) to update and change. Can you envision passing off little website tweaks and copy changes to your assistant in the future? I can, and it sounds GLORIOUS.

Ease of editing is one reason why I recommend integrating a page builder in almost all of the sites I build for my clients these days. It’s really frustrating for a client to have a gorgeous, functional site that can’t stay up-to-date with the changes in their business because it’s too complicated for them to edit!

What page builder do I recommend for WordPress?

Hands down, it has to be Beaver Builder. BB is the only builder I use and recommend in my development business, so of course it was the one I chose for my own site.

Here are the top reasons why I love Beaver Builder:

It plays nicely with Genesis framework.
It’s fast (as far as builders are concerned)
It’s not too bloated
It doesn’t leave behind shortcode soup when you deactivate it since it runs on HTML behind-the-scenes
It makes proper use of WordPress hooks, so I can modify it any way I need to

It’s been nearly a year since my website relaunch, and every time I have to add new content to my site or update an existing page, I’m reminded of the reasons why I chose to integrate Beaver Builder into my site all over again.

Left top navigation

WordPress