Tag: themes

Self-Update Your Plugins

When your plugin is hosted on WordPress.org, this isn’t a problem at all. But if you’re selling your own work, or hosting it on a non WPORG resource, there are other concerns. You see, if you host a plugin on WordPress.org, your plugin can’t have it’s own updater script. You have to use the default .org updater. This is just fine, except when you have an add on that you want to be pay-only. Then what?

Take a look at Easy Digital Downloads. You can get the main plugin from WordPress.org, and if you buy add ons from their site, they get magical updates too! How did they do that? They put an updater script in the main plugin which is then called by the paid extensions. You can even use their Software Licensing add ons to run your own updates on your server! If you want to sell on their site, they’ll help you take care of that too.

Todd Lahman also has an WooCommerce API manager, so if you’re using WooThemes, you’ve got that covered too.

Speaking of self hosting, if you’re hosting your own code on Github, then you want to use Andy’s Github Updater. While it’s not allowed on .org (sorry Andy), this will let you push updates from your GitHub or Bitbucket hosted WordPress plugins and themes.

My buddy Norcross has his own free updater for you as well.

You can also look at services like Auto Hosted or WP Updates, both of which promise to make it even easier and faster for you.

Jeremy Clarke has a automatic theme/plugin updater as well if you still want to be self hosted.

If you’re using ThemeForest, there’s the Envato WordPress Toolkit, which your users (not you) will need to install on their sites to get updates. I don’t know if there’s a way to include an updater in your packaged theme or plugin, but that toolkit needs to be all over the place for users. That it’s not brings all the issues you see with their products being out of date.

There are hundreds of other ways around this. And really, there’s no excuse to not keep your plugins and themes up to date, no matter where they live. Keep those users updated and make it easy for them to do it! What resources do you use when self-hosting a plugin or theme, to keep it on the up and up, and keep everyone updates?

17 September, 2014
Mailbag: Multisite Theme Activation
Briany from Ireland has a cool idea (put the guilt away, Briany, I think this is a pretty wild concept and I like it). This is the sort of ‘support’ email I love because it’s not a yes/no answer, but a theoretical concept to think about and parse!

Here’s the meat of the email:

SO MY FASCINATING QUESTION IS THIS; In a multi site network is there any way to use 2 separate themes for each or any sub-site based on the URL used (or any other method) Example 1 Visit www.sitename.platform.com and view the whole site using theme A (Standard) Visit www.sitename.com and view the whole site using theme B (custom)

At first I thought “Briany can’t possibly be asking ‘How do I activate a separate theme per site.’” and then I realized the question was for the network! So to phrase it in WordPress terms, if I visit the site via foo.example.com, I get theme foo on every site on the network.

(If you just want Site A to have one theme, and Site B another, that’s easy. Either network activate the theme and select it on the site, or go to WP Admin -> Network -> Sites, click on edit, click on the themes tab, and activate the theme you want for the sites. Then go back to the site and select that theme. A couple steps, yes, but relatively easy.)

Theoretically yes, yes you can. There’s a plugin called Theme Switcher which lets users pick, and based on some code on StackExchange, you can change the theme based on users, but the issue here is that you want to only change it per domain for that user.

It’s certainly possible to change settings by detecting the domain, I do that with SSL.
```
if ( $_SERVER["HTTP_HOST"] == "foo.example.com" ) {
    // My Code Here
}
```
That’s the easy part. The hard part is keeping that setting when I go from foo.example.com to example.com…

I sat and kicked this idea around for a while. It would be much easier on a single install of WordPress, since I could make everything relative and then just use the host name. But you have to have a way to track the starter domain, and have it be per-visitor, which means you have to use cookies, and read from that, using setcookie() (which is a PHP thing, not WP specific).

At that point, I think I would close the book and say “No, it’s possible, but not a good idea.”

Why, you ask? Caching. How the hairy hell could I possibly cache that if the theme changes every time for every user? Maybe, maybe, I would do it with multi-networks, and define a theme per network, but not per-domain. Obviating any caching would pretty much kill my sites, and even a good opcode cache (I use memcache) will be usless in that scenario.

By the way, there are a lot of neato plugins to change themes based on weird things, like Domain Theme, which is great for single installs of WordPress.
11 July, 2014
Why Not Multisite?

My most popular post ever has been Don’t Use WordPress Multisite, which I wrote in 2011. It’s 2014 so it was time for a revisit of this concept.

The point I made in 2011, and again at WordCamp San Francisco in 2013, was that while Multisite is amazing and awesome and wonderful, it’s got limitations. I love it, I think it’s perfect for me, but I always keep those limitations in mind and try to educate people as to what they are. I think I have a pretty good grasp on them by now, and so does Nacin:

@jbenton @Krogsgard Basically read everything @Ipstenu has written (including when she suggests to not use it).

— Andrew Nacin (@nacin) December 20, 2013

This may make you wonder what I could possibly say that hasn’t been said before? The questions remain the same, but the answers change a little as time goes by. I want to stress that for every single reason I’m going to list as a case for not using Multisite, I probably have broken. Rules aren’t meant to never be broken, their meant to make sure we understand what and why we’re doing what we’re doing.

The absolute number one aspect about Multisite that you cannot forget is this: Multisite is for running multiple WordPress blogs (aka sites) on one install (aka a network), with separate content but a shared base for code and users.

If I was to make it a rule it would be this: Don’t use Multisite unless you want to run multiple WordPress sites, each with their own admin section.

But …

You know how I made that list of reasons? Like you don’t need it to categorize posts and make a site that’s all the same (or even all different), and I still firmly think that no one has any reason in the world to have a site that duplicates content 100%. Sometimes you do need Multisite for this stuff. Or rather, sometimes you can use Multisite, and it’s not the wrong choice!

You don’t need Multisite

WordPress comes with categories so just use that. Want to remove the word ‘/category/’ from your permalinks? WordPress SEO (by Yoast) can do that, as can No Category Base. Need to limit an author to a category? Use Author Category! In addition, there are Custom Post Types, which you can create for each ‘category’ and then limit authors using Custom Post Type Privacy.

WordPress comes with categories and Custom Post Types which let you keep your site looking exactly the same from page to page to page, which is awesome. This is, in an essence, what WordPress was made for. If you don’t want your ‘sections’ to look the same, hey theme templates will let you customize the look and feel of each category (or CPT) as you want. WordPress is crazy flexible, and plugins are phenomenally wonderful to let you customize WordPress to the nth degree. Like categories as subdomains, which means it’s theoretically possible to do the same for a CPT. I know you can map CPTs to domains already.

Before someone gets all snippy about how too many plugins make your site slow, I have to point out that too many poorly written plugins do this. It’s not the number, it’s the quality. A bad theme can slow your site down too, and I see that every single day.

You could use Multisite

So why would I use Multisite for those situations?

What if your ‘sections’ aren’t just meant to segregate content? Like you’re selling eBooks and you want to run a whole special ecommerce tool for tracking and payment. Or maybe you’ve got a membership tool and want to set up a news site where people can register and write, but keep them off the ‘main’ site where you’ll be linking featured content back. What about a site that will exist for a year to represent an event like a WordCamp, and then be ‘retired?’ Suddenly we’re talking categories in a different light, and maybe, just maybe, Multisite would work for this.

It’s easier in Multisite to totally re-skin a section because it’s using its own theme. You can quickly spin up a child theme just for one site, or use a plugin like the CSS Editor that comes with Jetpack to allow each site it’s own custom CSS.

Because each site is separate, I can limit plugins and prevent load creep per site. Not every ‘section’ needs the same plugins, after all. And at the same time, the ones that do can be network activated. Also a growing number of plugins are taking Multisite into consideration, like W3 Total Cache now lets the network admin configure a large amount of caching settings for the network as a whole! This number grows every day.

Which Should I Use

There isn’t one perfect answer here, but that’s true of all things WordPress. I think my cardinal rules of Multisite are mutable and all colored with a great deal of “It depends.” For every single reason I wouldn’t use Multisite, I also would (and probably have) used it. You have to take into consideration supportability most of all, though. Multisite’s worst flaw is that it leads to cases where your eyes are bigger than your stomach, and your network becomes huge and unwieldily before you’re ready to cope.

The one rule I’ve yet to break, and one I strongly feel no one should, is this: Never use Multisite if your users cannot know about other sites.

Other than that? Hey, the world is your oyster!

Multisite is big. It’s daunting. It’s complicated. It’s still, and probably will always be, harder than running a single blog, which makes sense. You’re no longer running a site, you’re running a network.

3 February, 2014
Gaining REM
Not sleep… And not the band.

I was reading Breaking up responsive design on Yoast.com and, like pretty much everyone else, they’ve been been scaling down the browser base font to 62.5% for a while now. The default font-size for most browsers is, as it happens, 16px. The problem with that 62.5% call is that, at least on Chrome for Mac, I ended up getting a flash of 25.6px fonts before the page would load right. Turns out that wasn’t just me, and it’s the bane of 62.5%

So the fix would be to make my font 100%:
```
html {
	-webkit-text-size-adjust: 100%;
	font-size: 100%;
}
```
And then I’d have to re-do all my font calls in my CSS because they were all based on 14px. This made me stare at my child theme on another site for a while, and finally knuckle down and script in better font handling, because the idea of manually cranking through everything was too daunting, even if I used REM Calculator to sort out my px/em ratio.

Still, doing this still meant I’d still have a lot of stuff like this:
```
  font-size: 16px;
  font-size: 1rem;
```
Bah. Who want’s that? It was time to get sassier. I went back to Tracy and came up with her use of “Mixins.” And this is where Sass gets weird. It can do my math for me. This was, I admit, what originally made me interested. But in July it was a theoretical attraction. By December it was love. See, Tracy did the math with her sass-responsive library, which she calls a library of variables, mixins and formulas geared towards Responsive Web Design using Sass.

I called it _taupecat.scss but we’ll get to that in a second.

The first step would be to split up my files. See, I’m using Genesis, and they have a handy table of contents for all the sections, so I just made each section an import:
```
/*
HTML5 Reset
--------- */
@import &amp;quot;normalize&amp;quot;;

/*
Defaults
--------- */
@import &amp;quot;defaults&amp;quot;;

/*
Structure and Layout
--------- */
@import &amp;quot;structure&amp;quot;;
```
I admit, this gives me a million files, as you can see in that image on the right, but it’s actually pretty easy to figure out what’s where. It took me a while to get everything where I wanted it, and while I could have used Bones for Genesis, I know me, and like using Git is the fastest way to learn it, so is using Sass. So I started with the basics of splitting it up like imports. Also I didn’t want to add in Compass to my mix just yet.

I named my files _section.scss and they all consisted of the normal CSS for each section at first. After all, the first step is segregation of code. The second step was to use Tracy’s code and change all instances like this:
```
	margin-bottom: 24px;
	margin-bottom: 1.5rem;
```
to this:
```
	@include rem(margin-bottom, 24px);
```
And then
```
    padding: 0 12px 0 40px;
    padding: 0 0.75rem 0 2.5rem;
```
to this:
```
    padding: 0 12px 0 40px;
    padding: 0 cr(12px) 0 cr(40px);
```
This lets me use Tracy’s cool files and her hard work to make mine way easier! Basically I no longer have to math out that if 16px is 1rem, then 32px is 2rem, and that means 40px is 2.5rem and so on and so forth. It’s faster. Of course, since I’ve done this in pixels, it takes me a teensy bit longer to use inspector to fiddle, since I have to uncheck the rem and edit the px, but I’m okay with that.

I also tossed in two special calls:
```
@import &amp;quot;settings&amp;quot;;
@import &amp;quot;taupecat&amp;quot;;
```
The taupecat has all of Tracy’s code, and settings… well that’s for another post about how I’m controlling my colors and the fonts. But for now, well, all my font sizes and paddings are dynamic. It does mean I have to rebuild my css every time I make a change, but if you ask me, that’s better than math sometimes.

That’s why we have calculators, right?
15 January, 2014
A New Utility
I’m more like Brian Gardner than I care to admit.

I’m often dissatisfied by the feel of a site, my own included, and for a long time I’ve been ‘not quite right’ with the theme here on Half Elf. Oh, sure, it works, and I love the open whitespace, but … I wanted something else. Since I spend a lot of time looking at other sites, and especially Genesis Theme Devs, I had a vague idea of what I wanted. Even if I have no plans to change my site (and frankly I never plan this stuff) I want to be able to help people when they say “I want a theme that does this!”

My checklist:
- Less cartoony
- Font Icons
- Easy to configure front page sections
Begin the hunt!

This was a close race. I’ve been looking at the themes from Web Savvy Marketing for a while, and I was this close to taking one of those and editing it, when I thought “I don’t want a slider.” I will note that if the only thing bad I can say about a theme is that it has a slider, then that theme is doing something right. While I have an idea about that hunter theme or maybe Colin, none of them were quite right. They were all so close it hurt.

Then I stepped back and looked at my list again. Font Icons was easy, since I wrote Genericon’d after all, and everyone else had these photo backgrounds and neatly blocked sections that resized, and while I had something close, I kept screwing it up when I went to edit it. Maybe what I needed was something that stopped me from doing that?

I doodled out a sketch of what I wanted: Title, menu, welcome box, Call to Action section, list of posts. That’s pretty much what it looked like from the top down, so I needed to find a simple, direct, theme that did all that and let me jiggle the CSS if I wanted to.

Enter Carrie

There’s this awesome person I know, Carrie Dils. She fell into my web of friends when she had a horrible experience at a meetup a year ago, and was told she wasn’t welcome to speak because she was someone’s competition. When that post hit my feed, retweeted by a friend I knew and trusted, I remember spinning my righteous anger into full gear and asking this (then) total stranger for information so I could pass it on to the Official WordPress Meetup Peoples.

Before I did that, though, I read her posts (just to make sure she wasn’t on the wrong of this argument, hey, it happens) and found a delightful, intelligent, witty, and skilled theme dev. Themes! My Kryptonite! Carrie (perhaps accidentally) leveraged her situation into talking about collaboration at WordCamp San Francisco in 2013, and by that time she had ended up on my list of awesome people I want to hear from regularly about things.

So I thought I’d pop over to her site and see what she’d done with Modern Portfolio (oddly the same theme I was using here at the time). I liked what she did, but it wasn’t quite right for me. I wasn’t enjoying the three column latest posts, since mine kept goofing the alignment with different length post titles and excerpts. But what should my wandering eyes appear? A link to her theme: Utility.

It does what it says

Seriously it does exactly what it says. I picked a photo I took of a palm tree outside my office/gym earlier this year (which a friend was putting on cards for me for something else) and gave the green color a little kick. With built in button CSS classes, I was able to ditch my own and while I do have some of my own custom CSS going on, it’s because I have a couple plugins that need some extra love.

In the end, it worked how I wanted to, and fast. Normally when I change my sites, I get to a point where I say ‘Eeeeh, close enough.’ With this one, though, I spent about two hours (while working, so really maybe an hour) moving widgets around, replacing a couple plugins, and then I said “Oh. That feels right!”

This was, I feel, a choice that was well worth the work.
25 December, 2013
Is SEO Best Handled by a Plugin or Theme?
I’m not an SEO expert, but I know a heck of a lot more than many people who claim they are. For the record, I’ve been messing with SEO since it was ‘correct’ to put hidden text in the source code of your site. I used to spend time getting sites to rank well on Lycos and Altavista, back when I was but a wee intern for my friends. It’s fair to say I’ve been around the block with SEO.

I don’t consider myself an expert because of skill, though in the last couple years, I’ve decided not to keep up as closely with things like schema, mostly because I don’t have to. I still retain a solid grounding in what does and does not make for good SEO (content!), and I understand that part of good SEO isn’t just content, it’s how the content is displayed for the reader, but also how the information is sorted for the computers at search engine companies.

Credit: Plymouth UK
About every couple months, someone asks me if I prefer using a theme or a plugin to manage my SEO, and I have been giving the same answer for a couple years now. I don’t use either.

This does not mean that the themes I use aren’t ‘SEO’ optimized, of course. It means that I don’t use their ‘extra’ features. I use, primarily, StudioPress’ Genesis Framework right now, and that comes with an SEO settings page which I never use. Ever. In fact, I turn it off in any child theme I make. This is not because I don’t think that it’s useful, but that what I do ‘use’ for SEO is already included.

My SEO consists of making my content fantastic, using a theme that includes schema headers (or adding them myself if not), and following the guidelines Yoast outlines in his article WordPress SEO Tutorial. I don’t do everything he says (he likes ‘category/postname’ for permalinks, I like ‘year/postname’ but if date doesn’t really matter, I use category instead), but I do read and think about what it means.

That’s the crux isn’t it? I don’t blindly follow advice, or use a plugin or theme because people say I have to. I read, I think, and I come to logical conclusions, and I apply them after I write my post.

For example, Yoast says not to use ‘stopwords’ in titles and make them SEO friendly. I take this to mean your human readable title should be gripping, but the title slug should be short, to the point, and descriptive. So I customize every single title. I come up with four or five before I post, and then when I have one with a good grab, I tweak the title slug to be as short as possible, while still being descriptive. Sometimes I’m better at this than others, but I keep working it.

Next I customize my ‘publicize’ lede. This has to be good and it has to be short. I know I’m using my helf.us yourls, so the URL itself will be tiny, but that doesn’t mean I should use just my title for Twitter. I customize it, trying to make it a little more witty and pithy, to reflect me and my readers. Finally I customize my excerpt. Oh yes, my excerpts are all custom written, and they are intended to grab you hard. Like Yoast, I feel the only well written description is a hand written one, and I do it. For everything.

This puts me at a funny disadvantage. Most plugins and themes I’ve seen tend to want you to make a custom meta description. There are plugins (like the one I do use, listed further down in this post) that allow you to use your excerpt as descriptions, but I’ve never quite understood why themes make this so hard. In Genesis, I have a field for “Custom Post/Page Meta Description” in every post, which if I use it, will change the meta value for description.

When I dug into the code, I saw that it was pulling this:
```
genesis_get_custom_field( '_genesis_description' );
```
Clearly all I need to do is make that default to what I want. And when I figure that out, I’ll let you know. Right now, all I could do was remove Genesis’ function and replace it with my own. Not elegant at all.

Now all that said, there are times when I see to ‘improve’ upon the SEO I’ve been given, because someone else is handling the content will far less care than I give. When that happens, I grab Yoast’s WordPress SEO Plugin. But for the most part, I don’t do anything on a regular basis that involves having to ‘customize’ my SEO, so it’s infinitely portable to any theme I want.
2 December, 2013