ThemeLab We build High Quality, Good Looking Premium WordPress Themes that are Easy to Use and ready for just about anything. Thu, 10 Apr 2014 12:33:43 +0000 en-US hourly 1 How To (Efficiently) Load Social Sharing Buttons with WordPress Wed, 30 Nov -0001 00:00:00 +0000 Before I begin, let me just say that I am extremely picky about anything that involves loading any scripts or dependencies from a third-party site. Nowadays, if you want to have a simple “Like” button on your site for a popular social network, they’ll probably require you to load their JavaScript from their server to

The post How To (Efficiently) Load Social Sharing Buttons with WordPress appeared first on ThemeLab.

Before I begin, let me just say that I am extremely picky about anything that involves loading any scripts or dependencies from a third-party site.

Nowadays, if you want to have a simple “Like” button on your site for a popular social network, they’ll probably require you to load their JavaScript from their server to handle it.

This allows popular social networks like Facebook to collect a bunch of data about your site visitors (we all know how social networks love big data), in exchange for giving you integrated liking/tweeting/sharing functionality directly from your site.

This can potentially turn into a good source of free traffic, which can then turn into an expanded audience for your content. Problem, loading these scripts tend to take a while, and can noticeably slow down your site on the initial page load.

Enter Floating Social Bar

This is exactly why WPBeginner‘s Floating Social Bar plugin caught my eye. What is particularly interesting about the plugin is the social script loading is delayed until a user mouses over them. Check out the screenshots to see how easy it is to use.

This way, the scripts can’t slow your site down on the initial page load. Also, the mouseover activation acts as a sort of user intent logic. Although they can hover over them inadvertently, usually a user wouldn’t hover over them unless they actually intended to share your content with them.

Before that, a placeholder image along with a cached share count is displayed, designed to look exactly like a normal share button.

Limited Social Networks

Most social sharing plugins I’ve seen for WordPress include pretty much every social network under the sun, including niche ones that wouldn’t really be relevant to your site content at all.

This isn’t a joke: AddThis allows users to “submit” your site to the W3C Validator. It’s almost comical how overboard most of these things go, so it’s refreshing to see a plugin that actually limits your options.

Even worse, I’ve seen sites that take full advantage of all the social networks other sharing plugins support, leaving a huge ugly space below your content full of 50+ sharing icons that 99% of your users never use.

If you check your analytics, and find very little incoming traffic from a specific social network, it’s safe to say that sharing functionality can be removed from your site. People can always share manually.

WPBeginner’s plugin cuts it down to the most popular ones, and gives you an easy to use drag & drop interface to add, remove, or rearrange the order in which they appear.

The “Floating” Part

Remember, this plugin is called Floating Social Bar, because the social icons stay in a fixed position once the user scrolls past a certain point. Hence, you’re never letting them forget that option is there to share the content.

You can always disable the floatiness if you don’t want that.

Make It Easier For Users To Share Your Content

I like to think, that if a reader finds my content truly compelling, they can always manually share it on the social network of their choice. The Theme Foundry makes a good argument on why you don’t need sharing buttons.

Copying and pasting a URL isn’t really that hard to do. But simply clicking a like button is even easier, plus the user stays on your site longer.

Social network traffic is becoming something harder and harder to ignore, but you have to make sure your site loads as fast as possible, only loading scripts when absolutely necessary. And that’s exactly why, if you’re going to use a social sharing plugin, I recommend Floating Social Bar.

Further Reading

The post How To (Efficiently) Load Social Sharing Buttons with WordPress appeared first on ThemeLab.

]]> 0
Get The Google Malware Hammer For Commented Out CSS Wed, 30 Nov -0001 00:00:00 +0000 Yes, you read that right. Here’s the deal: WPTavern interviews a split-testing service Split-testing service site gets flagged for malware (terrible timing, I know). Why? Because their style.css had a comment referencing another site with an actual malware infection. That’s it. Read more about it in this comment. If you’re a WordPress consultant, developer, or

The post Get The Google Malware Hammer For Commented Out CSS appeared first on ThemeLab.

Yes, you read that right. Here’s the deal:

If you’re a WordPress consultant, developer, or whatever, and your client comes to you with a “malware” warning problem, you should definitely be aware of this possibility.

The top of a WordPress theme’s style.css file

At the top of every WordPress theme’s style.css file, a theme may include the following (optional) info to describe itself. Here’s an example:

Theme Name: Theme Lab
Theme URI:
Description: The theme I use for Theme Lab.
Author: Leland Fiegel
Author URI:
Version: 1.0

License: Not Applicable License v2.0
License URI:

WordPress uses this to display certain information on the themes page within your admin (more on this later). It’s also used to generate a page on the theme directory should it be submitted and accepted there.

If whatever URL is listed next to “theme URI” and “author URI” is flagged for malware, you could also be flagged for malware, simply for referencing them.

Sponsored Themes and Sketchy Sites

It’s been a well known fact that actually linking out to sketchy sites can potentially get you penalized and potentially flagged for malware. This has been a hot topic during the “sponsored themes” era as well as shady theme site discussion.

Getting flagged for malware for linking out to a malware-infected site is totally understandable as, well… you’re directly linking to a possibly infected site that your visitors could then click on and get infected too.

But getting flagged for malware because of a commented out URL reference in a stylesheet? That’s certainly news to me. How do you protect yourself from that?

Premptively Removing URL References In Stylesheets

Pretty much all released themes include a link back to and/or the theme developer’s site. Many remove these outgoing links (for “SEO” reasons or whatever).

Not many even think about removing credit info from their stylesheet. The only people who actually check this stuff out are mostly other developers. I know I frequently check WordPress sites’ style.css files to see what theme they’re using, whether it’s pre-made or custom, etc.

Turns out, it’s not just developers who check out commented-out stuff in your style.css file, but also Google bots.

Considering this is something totally out of your control (i.e. the malware status of a third-party site, likely your theme developer) it might be worth removing the Author URI and Theme URI in your style.css file. Heck, even the License URI just to be on the safe side.

Hopefully curious developers can find out the origins of a theme through Googling the theme author and/or name to find their hopefully-non-malware-infected site.

Is Merely Referencing A Commented Out URL In CSS… Malware?

Possibly the most concerning part of this news, is that even if I referenced the most spammy, malware-ridden site in my CSS with commented out code, how is that any sort of danger to my visitors?

It’s not like I’m loading an external resource from an infected site. It’s just a comment. In CSS. Totally harmless, right?

Like I mentioned above, most people who typically check stylesheet code are other developers. Even if they copy and paste the URL into their browser and get infected with imaginary malware, I feel Google’s policy is overreaching at best (assuming this actually is a policy, not a bug within their malware checking mechanisms).

It’s also worth considering that these theme and author URIs are displayed as actual links within the WordPress admin. It may be Google’s odd way of protecting WordPress users, not necessarily people creeping through your style.css file.


We all know Google and other major search engines will scan your CSS to check for boneheaded “black hat” text hiding techniques (negative text indents, display: none, visibility: hidden, matching background and foreground colors), among other things.

You can certainly get penalized and banned for doing something stupid like that, that’s a well-known fact. Getting a malware warning for commented out code in CSS? Not so well known.

Getting flagged for malware in Google is pretty much SEO suicide. I’ve thankfully never had to deal with one before, although it’s safe to assume my search engine traffic would take a nosedive if I ever did get one.

I would also feel really bad considering that any site that uses a Theme Lab theme could also potentially be flagged for malware as well, just for simply referencing Theme Lab’s URL in the theme stylesheet.

You don’t want to share the blame with another site’s malware status if you don’t have to, even if that original site’s malware status was made by mistake.

So yeah, consider removing the Author URI and Theme URI in your style.css. No matter how good a reputation the author/theme has, anybody can potentially be hacked, and it may save you a headache in the future for something that’s no fault of your own.

The post Get The Google Malware Hammer For Commented Out CSS appeared first on ThemeLab.

]]> 5
“Just Writing” Isn’t Enough Wed, 30 Nov -0001 00:00:00 +0000 New blogging platforms and services are popping up all over the place to simplify the process of writing and publishing on the web, as if it wasn’t simple enough already. One of these services is called Medium, self-described as “a better place to read and write things that matter.” The design is minimalistic, the typography

The post “Just Writing” Isn’t Enough appeared first on ThemeLab.

New blogging platforms and services are popping up all over the place to simplify the process of writing and publishing on the web, as if it wasn’t simple enough already.

One of these services is called Medium, self-described as “a better place to read and write things that matter.” The design is minimalistic, the typography is great, and most importantly, the content is high-quality.

It also encourages collaboration with a pretty unique commenting system, called “Notes” on Medium, that allow other users to laser-target a certain bit of content in an article and leave feedback on it.

But what is it actually like to write for Medium? An insightful article I read recently was Why I Left Medium by Kenneth Reitz.

The Draw

Reitz cited the following reasons for switching his blog over to Medium.

  • Great typography
  • Encourages collaboration
  • Forces photos for every post
  • Responsive design

Yep, it certainly does have great typography. Just look at a post on Medium. It’s so easy to read, on any device (this is where the responsive design part comes in).

I’m not sure why forcing photos on every post would be considered something positive. It sounds more like a burden to track down a relevant, copyright-friendly photo to attach to every single one of your posts.

I thought we were putting the focus on writing?

The Downsides

Reitz ultimately left Medium in favor of a self-hosted WordPress blog because of some of Medium’s limitations.

  • No content embedding
  • No analytics or referral data
  • No custom domains
  • No custom post URLs or “slugs”

All you can do is keep writing, and have your articles hosted on And repeat. And that’s it

You Do More Than Just Writing

The problem with Medium is, chances are, you do more than “just writing” on your blog.

  • You embed stuff. Tweets, YouTube videos, Instagram photos, SlideShare presentations. WordPress makes it really easy to do that.
  • You check your stats. You see what content is popular, what isn’t, and tailor your future content strategy using that data. Whether it be through Google Analytics, Woopra, Jetpack (if you use WordPress) or literally any other analytics service.
  • You have an identity. You have a domain name that represents your name, your business, and/or your organization. When your URLs are structured like, it’s kind of hard to stand out.

Speaking of URLs, does “9e53ca408c48″ accurately reflect the content of that URL? Unlikely. WordPress makes it easy to design your URLs in a meaningful (and SEO-friendly) way.

My point is, when you self-host a WordPress site, you can do pretty much whatever you want with it.


The only really unique/innovative feature I see in Medium is its notes feature (as opposed to traditional blog commenting) which is supposed to encourage “collaboration” among other writers. Time will tell how well that actually works.

Everything else design-wise, all the way from the smooth responsive design and the super-clean typography, can be replicated with a solid, responsive WordPress blogging theme.

I like minimalism and simplicity just as much as the next person, but I think “restrictivism” would be a more appropriate word when it comes to Medium and all of its limitations.

I’m not trashing Medium. On the contrary, I think it’s a pretty cool service with cool people behind it. I’d personally never use it, but I’m pretty gung-ho on self-hosting your own websites for (what I hope are) obvious reasons.

Sure, if all you want to do is write, and not worry about absolutely anything else, Medium would be perfect for you. But chances are, “just writing” isn’t enough.

The post “Just Writing” Isn’t Enough appeared first on ThemeLab.

]]> 3
Why You Should Never Offer Unlimited/Lifetime Support Wed, 30 Nov -0001 00:00:00 +0000 WooThemes made a controversial announcement today that eliminated promises of "lifetime" support and upgrades for previous customers.

The answer should be obvious. It's simply not sustainable.

The post Why You Should Never Offer Unlimited/Lifetime Support appeared first on ThemeLab.

Selling a WordPress product along with lifetime support and upgrades is tricky, because:

  1. You’ll realize that sort of pricing model isn’t sustainable, you slowly crumble under the pressure, and your business fails.
  2. You’ll realize that sort of pricing model isn’t sustainable, you backtrack on your policy and get a lot of bad press and angry customers who no longer have that “lifetime” support they were previously promised.
  3. You’ll realize that sort of pricing model isn’t sustainable, you honor the “lifetime” or “unlimited” support agreement past customers originally bought, eat the costs associated with that, and apply the new time-limited support/upgrade policy to any new purchase.

Notice anything in common with the three above options? Oh yeah, that sort of pricing model isn’t sustainable.

Option 2 is exactly what WooThemes just did earlier today, and the decision has been met with mixed feedback (to put it nicely). In hindsight, they could’ve handled things a bit differently:

  • They could’ve kept their existing customer base happy by going with option 3, and at least stopped the bleeding of their previously flawed pricing model.
  • They could’ve minimized a lot of the bad press and angry customers if they decided to make their “option 2″ announcement a long time ago.
  • They could’ve eliminated all of the bad press and angry customers if they didn’t offer any “guarantee” of unlimited/lifetime support to begin with, along with an appropriate pricing model.

Obviously, things always look a lot different in retrospect.

Is the price increase a good thing?

I admit, when I first heard this news, I thought it was a good thing. I tweeted this:

WooThemes is simply increasing their prices to make their business more sustainable for the long-term. I mean, what good is “lifetime” support if the company who is supposed to be providing that support goes out of business?

Premium WordPress themes have been priced too cheaply for too long. When you consider the time put into development of such a product, the time put into maintaining such a product, and the time put into supporting such a product, it’s understandable to charge a premium for it.

The problem is, and what I now realize, is they’re basically making their customers pay for the mistake they made, which was only compounded by the fact they waited so long to announce it, presumably because they wanted to hop on the BS marketing term train of unlimited” to grow their user base in the short term.

They should’ve known what they were getting into, and could have put a stop to it a long time ago.

“Unlimited” is a BS marketing term

Albert Einstein once said, “Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.”

Notice Einstein didn’t mention any of the following:

  • Unlimited hard drives with endless disk space
  • Unlimited network capacity that unlimited megabytes of files can be downloaded from
  • Unlimited time to answer support requests from an unlimited amount of customers
  • Unlimited time to continuously develop and maintain an unlimited amount of products

Because it’s simply NOT POSSIBLE.

And yeah, I know the first two are references to the web hosting industry and their love affair with imaginary “unlimited” space/bandwidth. Try putting up a super high-bandwidth site on a cheapo “unlimited” web host and see how fast your account gets suspended.

The point is, any time you see “unlimited,” especially next to a really low price tag, question it.

Taking it one step further: per-incident support

There is an infinite amount of numbers between any two numbers. For example, between 1 and 2, there is 1.1, 1.11, 1.111, and so on.

How does this apply to unlimited support, even within a limited time frame? Well, it’s inevitable certain customers are going to submit a lot of support requests regardless.

The question may come up in the future: is the “unlimited support requests within a certain time frame” model even sustainable?

Why not limit support to a certain amount of “incidents” rather than annually or per site? I’ve seen this done on web hosts and other software products, but never seen it in the WordPress product world.

This way, the cost associated with a customer with 100+ incidents a month wouldn’t affect the price paid of another customer who required less support with less than 25 incidents in a year. Presuming incidents exceeding the predetermined limit cost extra, everything remains sustainable.

Just something to think about, but I think it would make a lot more sense than limiting it “per site” or “within a year.”

What About Unlimited Usage?

Now, keep in mind the code behind WooThemes’ products is GPL licensed. Customers can still use that code on an unlimited amount of sites forever, it just won’t be supported by WooThemes after the support period ends, unless that support agreement is renewed for an additional fee.

How long it takes that code to get old and deprecated after the one year of upgrades (or whatever limited amount of time) is up is another story.


Gravity Forms knew how to pull it off. They also did it over three years ago, before it became too big of a deal to offer lifetime support to all customers prior to the announcement.

WooThemes continued chugging along the unlimited train for long, it sounds like it was too late to do what Gravity Forms did and still make fiscal sense. But, at least they made a change. Despite all the negative feedback they’ve received today, they set their business up for future sustainability.

For all the customers complaining about losing their “lifetime” support, imagine how they would feel if WooThemes completely went out of business in a couple years? It could’ve been worse for everyone, longer down the road. Better late than never, I suppose.

So, what do you think of all of this? I’d love to hear your thoughts in the comments.

Further Reading

The post Why You Should Never Offer Unlimited/Lifetime Support appeared first on ThemeLab.

]]> 8
Do We Really Need More “Coming Soon” Themes and Plugins? Wed, 30 Nov -0001 00:00:00 +0000 It seems like there’s a new “coming soon” or “maintenance mode” theme or plugin coming out every day. Haven’t we seen enough of them?

This post discusses their limited shelf life, and limited room for innovation.

The post Do We Really Need More “Coming Soon” Themes and Plugins? appeared first on ThemeLab.

It seems like there’s a new “coming soon” or “maintenance mode” theme or plugin coming out every day. Haven’t we seen enough of them?

Note: I use “theme” and “plugin” interchangeably a lot in this post. Depending on your site, it may make sense to get your “coming soon” type page up with either a theme or a plugin.

I also may use “coming soon” and “maintenance mode” interchangeably a lot, as the functionality used to accomplish these tasks are pretty similar.

Anyway, this is what I think about them.

Limited Innovation

Seriously, what else are you going to put in a “coming soon” theme besides the following?

  • A short description or intro video of what’s coming soon
  • A fancy JavaScript countdown of some sort
  • Social media links
  • Newsletter subscription
  • Feed subscription

Any other ideas? I’d love to hear them in the comments.

Limited Shelf Life

The point of a “coming soon” or “maintenance mode” theme/plugin is to be, well, a placeholder for something else a lot more useful in the future.

I realize pre-launch marketing and lead generation is a big deal. It can really make or break a product. There are some really crucial things you can do with “coming soon” themes:

  • Lead generation
  • Email list building
  • Social media traction

Basically, you can utilize “coming soon” themes to build your brand before anything substantial has really launched.

With that said, I still don’t think a lot of that time, money, or thought should be invested in the web template you use as a placeholder for your future site/product launch.

That time, money, and thought, could be better spent on: social media campaigns, developing content strategy, and most importantly, the launch of the actual site you are announcing.

And remember, you can always do all that lead generation, list building, social media and brand building stuff after you launch your site.

Do We Really Need More [Insert Any Type of Theme Here] Themes?

That’s a good point. The market is pretty saturated with pretty much any type of WordPress theme as it is. We already have a ridiculous amount of:

  • News/magazine themes
  • Corporate/business themes
  • Gallery/portfolio themes
  • Good ol’ blog themes
  • And everything in between

The difference is, those types of themes are an actual end product. “Coming soon” themes are merely a temporary transition point.

We can discuss overall WordPress theme market saturation in a future post, if you’d like. But that’s not really the point of this particular post.

But, but… you made a coming soon theme!

Yes, you’re right, I did release a “coming soon” style theme earlier this year called IceChimp.


Although it does integrate pretty well with the MailChimp WordPress plugin, chances are there’s some other similar product that does the same thing. I didn’t really look though.

Overall, to be honest, it introduced hardly any new and innovative stuff to the WordPress community. I never expected it to.

Mostly, I considered it personal practice developing with WordPress’ Theme Customization API, which I used to handle a bunch of options in the theme, including a color style changer.

Maybe a developer downloaded the code, checked out how I did stuff, and used it to develop their own “customized Theme Customizer” (say that three times fast) for their own project. That would’ve been cool.

But still, I never intended or expected IceChimp to become any kind of “game changer” in the world of “coming soon” themes, if there even is a such thing.

Why Do People Still Make “Coming Soon” Themes?

In short, they’re (relatively) easy to develop. Take a look at’s Theme Review page. A huge chunk of that stuff would not apply to a one-page template like a “Coming Soon” theme.

  • There’s no Theme Unit Test to worry about
  • No WordPress generated CSS classes to style for
  • No extensive documentation needed (hopefully)

Basically, it’s an easy way to get your foot in the door of the WordPress community. Even though it will probably go largely unnoticed (see market saturation note above), everyone has to start somewhere.

That’s fine, but a new developer would probably be better off developing something designed to actually display a wide variety of content in a fully-featured WordPress theme, rather than a one page “coming soon” template.

Also, if you’re a commercial theme club, aiming to be a one-stop shop for all of your customers WordPress theme needs, it might be helpful to have one or two “coming soon” themes/plugins in your WordPress product portfolio.

That way, a customer wouldn’t have to look elsewhere for a “coming soon” template if they’re just looking to get a quick site up really quickly. That makes sense.


Yep, this post is a bit ranty, but I’d be interested in hearing your thoughts on the subject.

  • What do you think about “coming soon” themes?
  • Do you think there’s any room for innovation? If so, how?
  • Are “coming soon” pages in general that particularly useful anyway?

Sound off in the comments.

The post Do We Really Need More “Coming Soon” Themes and Plugins? appeared first on ThemeLab.

]]> 4
Shortcodes Should Never Be Included With Themes. Period. Wed, 30 Nov -0001 00:00:00 +0000 ThemeForest recently updated their submission requirements to be more inline with WordPress theme development best practices.

While definitely a huge step in the right direction, there's still a problem.

The post Shortcodes Should Never Be Included With Themes. Period. appeared first on ThemeLab.

ThemeForest recently updated their WordPress theme submission requirements to be more stringent and more inline with WordPress theme development best practices.

The guidelines require the use several of WordPress’ core features, standard theme hooks, and disallow PHP functions (like base64 and fopen) that really shouldn’t have ever had any place in a WordPress theme to begin with.

Basically, pretty much’s Theme Review policy, give or take a few things.

Overall, it’s a step in the right direction and moves to promote best practices on one of the most popular WordPress theme marketplaces on the net. There’s just one problem…

Admissible Shortcodes

One thing that particularly caught my eye, however, was how certain “admissible” shortcode functionality was allowed (i.e. by directly including them through the theme’s functions.php file). The ones listed as “admissible” included the following:

  • buttons
  • pricing tables
  • image containers
  • dropcaps
  • lists

Inadmissible shortcodes include: maps, accordions and toggles, boxed contents, column, contact forms, charts.

The Problem with Shortcodes in Themes

I can’t really put it better than Justin Tadlock already has. One of the most noticeable issues, is that when a user changes themes, the shortcodes will no longer be parsed.

Let’s say “Super Awesome” theme had a shortcode feature that would output a big green button with a link when you typed out something like [button url=""]Big Green Button[/button].

Big Green Button

When you switch to another theme (let’s face it, people get bored of themes easily), there’s no more big green button. Instead, you see the unparsed shortcode in the post as if it were any other piece of content, like this:

[button url=""]Big Green Button[/button]

It looks ugly, confusing, and out-of-place, and it’s a pain for the user to go back and remove/replace all of them.

The Other Problem with Shortcodes in Themes

Something that Tadlock went over in his “Dealing with shortcode madness” article is, a lot of shortcodes are so simple and HTML-like, it might even be best to instruct users to write out a little (*gasp*) real HTML code.

The same [button url=""]Button Text[/button] shortcode in my example above could be easily rewritten as something like:

<a href="" class="button">Button text here</a>

While there may not be CSS code styling the .button selector in a new theme, at least a normal link will show up. Which is a big improvement over an unparsed [button] shortcode showing up in a post’s content.

Plus, I believe every WordPress user should have at least some basic understanding of HTML code. By teaching them, even in little bits (like how to construct a link), will help. If they can understand a shortcode, it won’t take much more to get them to understand basic HTML.

But The Users Don’t Care!

A common argument I see defending all sorts of bad practices when it comes to theme development is that the users simply don’t care. I mean, maybe they never want to update their theme, in which case, this shortcode issue would be a moot point.

The problem is, some users inevitably will want to switch themes some day. Some users will want to install a plugin that might conflict with some other poorly-thought-out code in a theme.

Then, they probably will care, and probably will wonder if the theme they bought with 100s of built-in shortcodes and other superfluous features was really worth it.

The Right Way to Include Shortcodes

Put it in a plugin. A really simple plugin. It doesn’t need a separate options panel. Just literally copy and paste whatever you were going to include via your theme’s functions.php file, and put it in a plugin instead.

It could even be bundled with something like TGM Plugin Activation to make it required on theme activation. Or not. A theme is still a theme without shortcodes.

This way, if the user changes themes, the shortcodes will still work, because that functionality is handled by the plugin that is still active.

Maybe the plugin could also enqueue styles for the shortcodes as well. This way, the big green buttons you included with the [button] shortcode will still be big green buttons, regardless of the theme used.

Why Did ThemeForest Allow “Admissible” Shortcodes?

It’s hard to say what exactly the reasoning behind this decision was. Japh Thomson, a WordPress evangelist at Envato (ThemeForest’s parent company) had this to say about it in a comment on

Complex shortcode functionality really should reside in a plugin, not a theme. It also just makes sense when you consider most of our authors have multiple themes.

Obviously, he gets it. So it’s a mystery to me why there would be any “admissible” shortcodes at all. And yes, I realize he used the word “complex” in the quote above, and the admissible shortcodes do tend to be pretty simple ones (dropcaps, lists, etc.).

Simple as a shortcode may be, the problems I outlined above will still exist. ThemeForest has shown to be responsive to community feedback, so it’s possible this rule is amended in the future.


I realize this post seems a bit nit-picky, and these new guidelines are definitely a huge step in the right direction. But there’s really no reason any shortcode should be allowed in a theme, simple or not.

Spoiler alert: Didn’t get any responses to that tweet with a real example of a shortcode absolutely needing to be included in a publicly-released theme.

That’s because it’s just not user-friendly for a user to go back and replace hundreds of button shortcodes after they switched to a theme that doesn’t have the exact same shortcode support.

The post Shortcodes Should Never Be Included With Themes. Period. appeared first on ThemeLab.

]]> 11
How To Create A Custom Twitter Feed With WordPress Wed, 30 Nov -0001 00:00:00 +0000 If you're using WordPress and you noticed your nicely styled Twitter feed suddenly stopped working, read this post.

You'll need to use an entirely new method to pull the tweets with Twitter's new API, and I'll explain how.

The post How To Create A Custom Twitter Feed With WordPress appeared first on ThemeLab.

Broken Twitter FEedOne of my most popular non-WordPress related posts here at Theme Lab was about making a custom Twitter widget without a plugin.

That was over three years ago. And it doesn’t work anymore because Twitter retired the version of the API it used to pull the tweets.

This is why you may have noticed Theme Lab, as well as a number of other sites, lost functionality in their Twitter feeds. But not to worry, it can be fixed (look at my site’s footer right now if you don’t believe me).

First Steps

The bad news, the “without a plugin” thing won’t work out so well anymore. The good news, there’s an awesome WordPress plugin we can now use to display tweets. It’s called, fittingly, Display Tweets.

Grab that plugin and install it. Then you’ll need to register for a Twitter application to get the required authentication info. Don’t worry, it’s free.

I already had a Twitter application for a previous project, so I just used that instead of registering a new one.

Fatal Error?

The Display Tweets WordPress plugin requires CURL to be enabled on your server. This won’t be an issue on any decent web host, although when I was testing locally I did run into the following fatal error:

Fatal error: Call to undefined function curl_init() in path\to\wordpress\wp-content\plugins\display-tweets-php\includes\Twitter\twitteroauth\twitteroauth.php on line 199

I solved it in XAMPP by simply uncommenting the extension=php_curl.dll line in my php.ini file.

Again, you probably won’t run into this issue, but just in case… now you know.

Authenticating and Configuring

After installing the Display Tweets plugin, hopefully error free, head on over to the Settings page (Settings → Twitter Feed) and input the following information you got from your Twitter application.

  • Consumer Key
  • Consumer Secret
  • Access Token
  • Access Token Secret

Keep the ones with the word “Secret” in it, well… secret. Then you’ll have to set the following configuration options:

  • Screen Name: In my case, “themelab”
  • Count: How many tweets to display, up to 200 (in my case, 2).
  • Include Retweets: Self-explanatory
  • Exclude Replies: Again, self-explanatory.

Note: Excluding retweets and replies may affect the actual count of tweets displayed, as the “Count” setting will retrieve the number of tweets before filtering out retweets and replies.

Placing The Tweets

Now you’ll need to decide where and how to place the tweets on your WordPress site. You have a couple options here, either including them with a shortcode (useful for placing into posts) or a template tag.

In my case, I used the following template tag and put it where my old broken Twitter feed used to be.

<?php if ( function_exists( "display_tweets" ) ) { display_tweets(); } ?>

Styling the Tweets

The markup of the tweets output from the Display Tweets plugin vary from the old method of displaying tweets.

Here’s a sample of the new markup of a single tweet, lifted directly from my current site:

<p>Wrote about an issue I had with disappearing widgets after migrating WordPress to a new URL. Here's how I fixed it: <a href="" target="_blank"></a><br /><small class="muted">- Sunday Jul 7 - 1:00am</small></p>

Here’s a sample of the old method markup:

<ul id="twitter_update_list">
<li><span>RT @<a href="">Screenr</a>: Cool Screenr update: Now your screencasts publish twice as fast. <a href=""></a></span> <a style="font-size: 85%;" href="">46 minutes ago</a></li>

Basically, paragraphs versus lists. If you used the old code, some of your CSS selectors will have to be adjusted to apply to the new markup style.

It’s hard to say which is better or worse, but at least Display Tweets’ default markup doesn’t use lame inline styles like style="font-size: 85%;".

It also looks like the Display Tweets plugin has a displaytweets_tweet_template hook included in case you want to alter the tweet HTML, something you didn’t really have much control over before.


While it is a bit frustrating when Twitter retires old APIs and breaks a lot of stuff, hopefully this newest version will stick for a while. Since this new method uses authentication, it’s not a free-for-all, which hopefully lessens the strain on Twitter’s resources.

Finally, thanks very much to Michael Ruddy, who developed Display Tweets. It looks like a lot of thought went into the plugin, especially when it comes to future-proofing. There’s also a GitHub repo if you’d like to contribute to the project.

Also, if you’re looking for an even quicker and easier (but not quite as customizable) way to embed a timeline onto your website, it may be worth looking into Twitter’s own embedded timelines feature. Perhaps something to delve into on a future blog post.

Anyway, thanks for reading, and go fix those broken Twitter feeds if you haven’t already.

The post How To Create A Custom Twitter Feed With WordPress appeared first on ThemeLab.

]]> 0
Why WordPress Widgets Vanish When Migrating to New URL Wed, 30 Nov -0001 00:00:00 +0000 I was working on a client site the other day and noticed a strange issue: almost all of my widgets vanished when I migrated the site from a local server to a separate development server.

Here's how I fixed it.

The post Why WordPress Widgets Vanish When Migrating to New URL appeared first on ThemeLab.

I was working on a client site the other day and noticed a strange issue: almost all of my widgets vanished when I migrated the site from a local server to a separate development server.

I have a pretty simple procedure for migrating WordPress:

  • Upload the contents of the directory WordPress is installed in
  • Export the database using PHPMyAdmin
  • Replace all references of the old URL to the new one in the database dump
  • Import the updated database dump to the development server

It’s a procedure I’ve been using for years without issue, except this time around, all my text widgets were nowhere to be found on the development site.

The Problem

I luckily stumbled across this post by Andy Stratton: Lost Widgets When Migrating WordPress Domains (dev to production server). In the post, he explains how WordPress stores widget data in a serialized array.

Here’s a simplified example of how a text widget is stored in a WordPress database:

s:5:"title";s:22:"The title of my widget";s:4:"text";s:101:"Text goes here <a href='http://localhost/wordpress/'>This is a link which URL is going to be replaced";

Notice how the number after the s: corresponds with the number of characters in the string that follows (i.e. s:5:”title” … “title” is 5 characters long).

When you do a basic find and replace for all mentions of a URL in a database and the new URL has a different amount of characters than the one before, this will invalidate the serialized array.

Basically, you lose all your widgets that are stored in that array, including individual widgets that didn’t have a URL (or any text for that matter) replaced with a new one with a different amount of characters.

This problem never happened to me before, even when hardcoding old URLs in WordPress posts, because posts (along with all other post types) are stored differently than widgets, and aren’t affected by this sort of serialized data issue.

They widgets are not technically “lost” however, you just need to edit your database (in one way or another) to make the serialized array valid again.

How To Fix It

In my particular case, there were only 5 text widgets that included content with hardcoded URLs. I just manually updated them, then followed my usual migration procedure.

By manually updating them from the widget panel, the string lengths are automatically updated in the database. Alternatively, you could count the new string lengths and edit the database directly, although that’s a little risky and unnecessary when you can just edit the widget text normally.

After importing my new database, my widgets were back!

If you have a ton of offending widgets and would rather not manually update each one, you’re going to need a different & more efficient approach.

It may be worth looking into the WordPress (And Others) Search and Replace Tool. This tool was developed by Interconnect IT to solve this, and similar problems. It’s important to note, however, their disclaimer:

IMPORTANT: This code is supplied with no warranty or support implied. You use it entirely at your own risk. [...] And when you’ve finished using the script, PLEASE delete it as it can pose a serious security risk to your site.

…so yeah, delete it when you’re done.

Note: Also, it was suggested that simply updating the site URL in your WordPress admin panel would solve this issue. This is a technique commonly used when migrating WordPress sites to new URLs. But it doesn’t, and shouldn’t affect text already inside of a widget. Therefore, this method won’t work in this sort of situation.

Shortcodes instead of Hardcodes

Another way of “solving” this issue, is to just never interlink to different URLs on the same site by hardcoding the base site URL into a text widget. Instead, you may want to look into including the page URL with a shortcode instead.

I found a cool plugin called Peter’s Blog URL Shortcodes which gives you access to a number of shortcodes you can use to link to different parts of your site, dynamically.

If you’d rather not install that plugin, you can always just make your own shortcode by adding the following into your functions.php (or separate plugin) file.

function themelab_url_shortcode() {
return get_bloginfo('url');

Note: Slightly altered code from the source for less generic function prefixing.

You’ll also need to add some code to allow the use of shortcodes in widget text to your functions.php (or separate plugin) file.

add_filter('widget_text', 'do_shortcode');

Source: DigWP

This way, you don’t have to worry about replacing new URLs in widget data and messing up the string length. The URLs are automatically output by the shortcodes.

Wrapping Up

This may be an issue some of you experienced WordPress developers were already aware of. But if you ran into this problem like I did and were wondering how to fix it, I hope this information came in handy for you.

As well as for future reference, this is definitely something to keep in mind when you’re migrating WordPress to a new URL, especially if you use a lot of text widgets that may be affected by a similar issue.

And yes, I realize this is my first blog post in ages. If you want to know what I’ve been up to lately, check out my recent interview on WPTavern. A quick roundup:

  • I’ve been in college the past few years, hence the lack of updates here.
  • I’m now working full time as a front-end developer (mostly WordPress stuff).

It gives me the chance to work on a lot of awesome WordPress projects, and hopefully some experience I get from that will find it’s way here in the form of blog posts like this one.

The post Why WordPress Widgets Vanish When Migrating to New URL appeared first on ThemeLab.

]]> 2
Free PSD: Yellow Navigation Bar Wed, 30 Nov -0001 00:00:00 +0000 This is a free PSD graphic that you can use however you want. As the title might suggest, it's a yellow navigation bar. Submenus included!

In future tutorials, I'll show you how to code it into HTML/CSS, and later implement it into a WordPress theme.

The post Free PSD: Yellow Navigation Bar appeared first on ThemeLab.

Going to try something new here. Basically I’m going to give away free PSD graphics that you can use however you want, and then I’ll show you how to code them.

First up is this yellow navigation bar PSD, screenshot is below. Click it to download.

Yellow Nav PSD

(Background image isn’t included in the actual PSD, I just lifted it from my site to make the preview graphic more Theme Lab-esque.)

I’m planning on writing the following tutorials to go along with this as well, and will link to them from here when ready.

  • How to code the yellow navigation bar in HTML/CSS
  • How to implement the yellow navigation bar in a WordPress theme

Let me know what you think in the comments!

The post Free PSD: Yellow Navigation Bar appeared first on ThemeLab.

]]> 3
Car Dealership – Free Site Template Wed, 30 Nov -0001 00:00:00 +0000 I saw Michael from Fearless Flyer released a free PSD mockup for a car dealer website, so I figured I’d code it into HTML/CSS and release the coded version here.

Included in the download are three different layouts: a homepage and two subpages.

The post Car Dealership – Free Site Template appeared first on ThemeLab.

I saw Michael from Fearless Flyer released a free PSD mockup for a car dealer website, so I figured I’d code it into HTML/CSS and release the coded version here. Click the screenshot below for a live demo.


Click on the logo text on the top right corner to cycle through the different layouts. Or just download it to try it out for yourself.

It’s a fairly simple template, and certainly not limited to car-related websites. Just switch out a couple images, and it could be used for whatever you want.

Quick Facts

  • Valid HTML/CSS
  • Uses the Titillium font (via Google Web Fonts)
  • Utilizes CSS :nth-of pseudo-selectors

There’s three layouts included in the download: a homepage, listing page, and details page. Click through the live demo pages to see them all.

Let me know what you think in the comments.

The post Car Dealership – Free Site Template appeared first on ThemeLab.

]]> 4