ThemeLab We build High Quality, Good Looking Premium WordPress Themes that are Easy to Use and ready for just about anything. Wed, 23 Apr 2014 14:40:15 +0000 en-US hourly 1 New Beginning – Say Hello to the New ThemeLab Wed, 23 Apr 2014 14:29:14 +0000 Hello and Welcome to the new ThemeLab. ThemeLab was started in 2007 by Leland Fiegel with the aim to make it an authoritative source of WordPress themes. However due to time constraints and other personal obligations, Leland was unable to focus on the project. In late 2013, my team acquired ThemeLab. Over the last 6

The post New Beginning – Say Hello to the New ThemeLab appeared first on ThemeLab.

Hello and Welcome to the new ThemeLab.

ThemeLab was started in 2007 by Leland Fiegel with the aim to make it an authoritative source of WordPress themes. However due to time constraints and other personal obligations, Leland was unable to focus on the project.

In late 2013, my team acquired ThemeLab. Over the last 6 months, we have worked on revamping the site and strategy, so we can restore it’s position at the top like it deserves.

My name is Syed Balkhi, and I’m the founder of WPBeginner, List25, OptinMonster, and several other websites. Above all, I’m an avid WordPress fan.

As a WordPress user watching from the sidelines, I’ve noticed that themes have become extremely complex over the last several years. The race to add more features, more options, more shortcodes, and more of everything has led developers to lose sight of what’s more important: usability.

Beginners who are just starting out no longer find WordPress to be easy. A lot of this has to do with themes because that’s their first encounter. Having to go through 600 options just to get the theme to look like the demo is beyond silly.

Our mission is to solve this problem by creating WordPress themes that simply work. It’s a big task, but our team is ready for the challenge.

What’s happening to the Old Free Themes?

In the past, Leland released hundreds of free WordPress themes. In order to have this fresh start, we’ve retired all those themes. You will no longer be able to download them.

However, we certainly plan on releasing new free WordPress themes. Slipstream is just the beginning.

WordPress Tutorials

Aside from releasing free themes, Leland did a great job on sharing useful WordPress tutorials. We plan on updating the old ones and continue to add new useful tutorials. We’ll do our best to update as fast as we can, but we apologize for any outdated tutorials in advance.

I’m really excited for this new journey, and I welcome your support and feedback. I want to thank Leland for all his hard work and wish him all the best on his future endeavors.

Photo credits: Jason Carpenter

The post New Beginning – Say Hello to the New ThemeLab appeared first on ThemeLab.

]]> 6
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
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
WordPress DC Presentation – CSS Tricks and Wizardry Wed, 30 Nov -0001 00:00:00 +0000 Guess what? I'm speaking at another WordPress DC meetup! It will be on Tuesday, August 9th at 7 PM located at Fathom Creative‘s office in DC.

Check out the slides in this post.

The post WordPress DC Presentation – CSS Tricks and Wizardry appeared first on ThemeLab.

If you’re still not following me on Facebook or Twitter, you probably haven’t heard that I’m speaking at another WordPress DC meetup.

It will be on Tuesday, August 9th at 7 PM located at Fathom Creative‘s office in DC. More details on location, parking, etc. can be found on the meetup page (linked previously).

What I’ll Be Talking About

Similar to my last presentation at WordPress DC, I will be discussing CSS. Unlike last time, however, the CSS tips I’ll be going over aren’t necessarily WordPress-specific, and can apply to nearly any type of site. The official description:

You’ll learn some useful and practical CSS tips and tricks. These could include tips on speeding up development time, general optimizations, and other cool things. Also, these aren’t necessarily limited to WordPress, but could apply to nearly any HTML/CSS based site. Beginner to intermediate CSS knowledge would be nice but not absolutely required.


These are in the same format as my previous slides (but less crammed so it’s easier to see on the TV).

Theme Lab T-Shirts

This will be the premiere of the limited edition Theme Lab t-shirts! Okay, they’re not really limited editions, I can print more if needed. I’ll be bringing various shirts in S/M/L sizes. A picture of them is below.

I’ll figure out some way to give them away at the meetup.

Andy Stratton’s Presentation

Also speaking at the same WordPress DC meetup is Andy Stratton, who I got to know pretty well at WordCamp Raleigh earlier this year. I saw his presentation there called Diet Pills, SEO and Theme Frameworks, which he’ll also be presenting here. Trust me, it’s one you won’t want to miss.


Looking at the meetup page, it looks like spots are filling up pretty quickly. If you want in, you should RVSP ASAP.

The post WordPress DC Presentation – CSS Tricks and Wizardry appeared first on ThemeLab.

]]> 6
TimThumb Security Vulnerability – Common in WordPress Themes Wed, 30 Nov -0001 00:00:00 +0000 TimThumb, an image resizing script commonly used in WordPress themes, is being exploited.

If you think your WordPress theme may use the TimThumb script, please read this.

The post TimThumb Security Vulnerability – Common in WordPress Themes appeared first on ThemeLab.

TimThumb, an image resizing script commonly used in WordPress themes (especially paid ones), is being exploited through a zero day vulnerability. If you think your WordPress theme may use the TimThumb script, please pay attention.

Quick Fix

The easiest way to fix it would be to delete any instance of timthumb.php on your sites. It is also commonly named thumb.php (this is what WooThemes uses). I’d imagine this also applies to inactive themes.

As outlined in the previously linked post on Mark Maunder’s blog, the next best quick fix would be to remove all the “Allowed Sites” in the array.


$allowedSites = array (

Change to:

$allowedSites = array();

Also make sure the following constant is set to false, otherwise removing the “allowed sites” won’t really matter, since every site would be allowed if it wasn’t:

define( 'ALLOW_EXTERNAL', false );

What’s the big deal?

You might be thinking, “lolz, Flickr or Wikipedia is gonna hack my site? Yeah right!” Wrong.

The problem is would be just as “allowed” as, which is where the real vulnerability lies.

Theme Providers that Use TimThumb

Some WordPress theme providers that bundle TimThumb in their themes to resize images include WooThemes and ElegantThemes, two very popular commercial theme vendors that have tons of sites using themes with the vulnerable TimThumb script.

As far as WooThemes goes, it appears they’re aware of the issue according to the following tweet:

To address the timthumb issue, we have a post and fixes coming very soon. :) ^RRless than a minute ago via CoTweet Favorite Retweet Reply

Let’s not forget theme marketplaces (*cough* ThemeForest *cough*) where countless authors have produced countless themes used on countless sites, a lot of which probably use the TimThumb script. I’d imagine this would be a much messier situation than with a single vendor.

Theme Lab Themes

In the name of transparency, there are three themes on Theme Lab that use the TimThumb script. They have been updated to the latest version (with allowed sites removed).

If you use any of these themes, please update the /scripts/timthumb.php file ASAP. This advice can also apply to any other theme that uses the timthumb script, obviously.

Why only three? Because I discovered a better way to include thumbnail functionality in WordPress themes.

Use add_image_size Please!

WordPress has a great, built-in API for resizing images that can effectively replace the need for timthumb on WordPress sites. It’s called add_image_size.

For some live examples on how to use this in your own themes, check out the Green Tea, Cool Blue, or SongSpace themes here at Theme Lab.

This feature has been built into WordPress since version 2.9, which was released on December 19, 2009 (well over a year and a half ago).

Mark Jaquith posted a great tutorial on including this feature in your themes, so I can’t think of many other excuses for not including this in new themes.

A Note on the TimThumb Developer

I noticed that the TimThumb developer, Ben Gillbanks, was getting directly and indirectly “bashed” pretty hard in the comments of the original vulnerability post.

Yes, it turns out the TimThumb script isn’t the most secure script in the world, but at least the developer is sticking around and supporting it for free.

I believe the script was released with nothing but the best intentions, and to see this “bashing” take place against someone who is doing all he can to help the situation is a bit bewildering, to say the least.

Over the years I’ve seen him respond to lots of TimThumb support requests on Twitter, something he’s certainly not obligated to do for a free script, but he does it anyway.

After all the profit that’s been made from the script (like commercial themes using it to make sure their fancy Jquery slider images are resized nicely) you’d think you’d see a little gratitude, but what else is new?


Obviously this is a pretty messy situation, a lot of users probably won’t have any idea they’re vulnerable until they’re hacked. It’s important to understand how widely used this script has been bundled with WordPress themes over the years.

Jayvie has also posted his thoughts on the issue in his post titled Timthumb zero day vulnerability: time to get back to basics.

What do you have to say about it? Let me know in the comments.

The post TimThumb Security Vulnerability – Common in WordPress Themes appeared first on ThemeLab.

]]> 15