Author: Ipstenu (Mika Epstein)

Display Videos Shortcode

This is a one-off, but it’s interesting to me so I’m sharing. I have a site with very pretty archives. It came with a video Custom Post-Type, but no archives for that type. Now I could have edited the theme, or overwritten the CPT, but I decided instead to embrace what I had and add on. What if I made a shortcode for [recent-videos] that showed me the recent videos?

This code was specifically designed for the custom post-type ‘Videos’ in the News Theme by Theme Hybrid.

add_shortcode('recent-videos', 'recent_videos_shortcode');
function recent_videos_shortcode($atts) {

        extract( shortcode_atts( array(
                'posts_per_page' => '10',
        ), $atts ) );

        $args = array(
                'post_type' => 'video',
                'posts_per_page' => $posts_per_page,
        );

        $vidlist = new WP_Query($args);
        if ( $vidlist->have_posts() ):
                $return .= '<div class="display-vidlist archive" style="margin: 0 0 0 -20px!important;">';
                while ( $vidlist->have_posts() ): $vidlist->the_post(); global $post;

                        $image = '<a class="image" href="'. get_permalink() .'">'. get_the_post_thumbnail($post->ID, thumbnail, array('class' => 'news-thumbnail')).'</a> ';
                        $title = '<h2 class="entry-title"><a class="title" href="'. get_permalink() .'">'. get_the_title() .'</a></h2>';
                        $date = '<div class="byline"><abbr class="published" title="'. get_the_date('l, F jS, Y, g:i a') .'">'. get_the_date('F j, Y') .'</abbr></span></div>';
                        $excerpt = '<div class="entry-summary"><p>' . get_the_excerpt() . '</p></div>';
                        $output = '<div id="post-'. get_the_ID() .'" class="hentry videos publish author-'. get_the_author_meta( 'user_login' ) .' has-excerpt">' . $image . $title . $date . $excerpt . '</div>';
                        $return .= apply_filters( 'display_posts_shortcode_output', $output, $atts );

                endwhile;

                $return .= '</div>';
        endif; wp_reset_query();

        if (!empty($return)) return $return;
}

The heavy lifting was formatting it to look right, and I’m not happy about my hack in class="display-vidlist archive" style="margin: 0 0 0 -20px!important;" but I also wasn’t 100% sure I wanted to separate the css just yet.

Most people will need to change 'post_type' => 'video', to their CPT, and remove the style hack.

I can already see where I’d extend this if I wanted to allow more arguments. The only one I put in was for the number of posts: [recent-videos posts_per_page=10] — You could easily add in one to allow ANY post type:

function recent_videos_shortcode($atts) {

        extract( shortcode_atts( array(
                'posts_per_page' => '10',
                'post_type' => 'post',
        ), $atts ) );

        $args = array(
                'post_type' => $post_type,
                'posts_per_page' => $posts_per_page,
        );

Then call [recent-videos post_type="video"] — Of course, if you do that, you should probably fork this into ‘Recent Posts Shortcode’ and rebrand recent-video to something else.

Which you totally can do (this, as with all my code, is licensed GPL2).

4 October, 2011

BuddyPress Overkill

For a lot of people, BuddyPress is overkill. Personally I love it, it’s great to make your own ‘Facebook’ or ‘Ning’ type site. But there’s a time and a place for everything. BuddyPress’s intention is to let you build your own social network. This means that it’s a Big Dog type application, that it has a lot of bells a whistles. And while you certainly can install it and only activate a few, if you’re only doing it to use one of those things, it may be overkill.

I’m going to take this one by the numbers. Or rather, by the features listed on BuddyPress’s site!

I need to stress, since some people miss the point of these posts, that if you’re only going to use one feature of a product this big, you should reconsider if it’s the best use of your time. If you only want to use one for now, and plan to grow, that’s different altogether. In each of my examples, I’m presuming that the user plans to only use that one specific feature, and I will address alternatives.

Activity Streams

This is actually my favorite thing about BuddyPress. If you post in a blog, or a group, or a forum, all of that gets pulled into ‘Sitewide Activity.’ That’s right, every last bit of your site is on one big page! Now, if you’re only using WordPress as a blog (no groups, no forums, JUST a CMS/blog), you’d think “I want this because I want a page that lists all my comments from all my posts!” To an extent, you’re right. There isn’t a better way to do this! Or is there?

There’s already a widget in the default WP install and theme for ‘Recent Comments’ which shows all comments, right? And there are plugins that can show Recent network wide comments too. So if you’re really lazy, why not use Widgets on Pages and call it a day?

Extended Profiles

If all you need is fancy profiles, BuddyPress is way overkill. In fact, for super cool profiles, most people use a plugin to extend the defaults! What’s the alternative? There are a lot of profile related plugins in the WordPress repository, and it just matters what you want. Personally, I’d caution against using those default Yahoo/AIM ones in our current profiles, as they may be going away. By the way, many of those profile plugins can add in extra fields to use on registration as well, like Cimy User Extra Fields.

Local Avatar

This isn’t a promoted feature of BuddyPress, but I’ve seen a lot of people do this. Yes, BuddyPress can let you use local avatars for your users, this is true, however so can plugins like Add Local Avatars. Frankly, I’m a proponent of Gravatar, since it works, and much like YouTube, I’m no longer responsible for you uploading nudie pics. Keeps legal brouhahah off my back.

Friend Connections and Private Messaging

While there are plugins like Private Messaging for WordPress out there, I have to hat-tip BuddyPress for a fully integrated front end PM system. This is one of the moments where, hands down, I would seriously consider using BP just for one feature. Ditto Friend Connections. I’ve just never seen its equal, and since the odds are most people would be using it for both friends and PM, it’s a great reason for BuddyPress.

WordPress Blogging

I don’t even know where to start. Someone insisted the only way to use WordPress for blogging was to install BuddyPress. It was a moment where I wanted a button to press to make a giant mallet jump out of his monitor and bash his head in for not reading. (By the way, you also don’t need MultiSite to use BuddyPress anymore. It works just fine with single site.)

Groups

This is tricky. Part of me wants to say ‘Just make a page and let people comment’ because, to some degree, that’s all a group really is. It’s a fan page (ala FaceBook) which shows posts in reverse order. Like a P2 blog. Which means that it’s not insurmountable to make a single page for your site that behaves that way (or a subsite running P2 if you went the MultiSite way). But is that the best way?

Forums

If you just want a forum, just install bbPress. Nuff said. Now, knowing that bbPress 2.0 is now a 2.0 plugin, and that BuddyPress is still on 1.2 (I think), and that the import from bbPress 1.x to 2.0 is a bit iffy, I would really be cautious about using bbPress if I know I want to upgrade to BuddyPress in the future. Connecting the bells and whistles are interesting.

What about you? What reasons have you seen people use to justify BuddyPress when it was clearly overkill?

2 October, 2011
Risk Theater and Open Source Testing

We make multiple test environments and platforms, testing with hundreds of users. We perform stress tests (how much traffic can my site take?), and have an obscene amount of checks and balances to ensure that only code that is good makes it into the file product. We have teams who question every change asking “Do you need this?” or “What’s this function for?” We audit every update process and ensure that our work is as good as we can make it. This is all done, we say, to reduce our risk. Our software, we insist, will be better if we do all these things.

But the failure rate has not dropped.

Initially, when a product is released, there’s a spike of failures. We didn’t anticipate that, or this didn’t work like we expected it to. Those are not classified as ‘failures’ but as kinks to be ironed out. Six or seven months down the line, we’ve released another set of itterations to fix the worst offenders and our failure rate drops to a comfortable rate where, most of the time, everything’s fine.

What if I told you that one in five IT projects was a success?(Source: Statistics over IT Failure Rate)

What if I told you that all your myriad checks, balances, testing, forms and CYA dances didn’t make anything less risky?

What if I told you it was all Risk Theater.

Of course you can do things in a less risky way. If given the choice between dismantling a bomb in a nice quiet room, where you have all the time in the world and a blast shield, or doing it on the back of a van while being shot at and you only have 30 seconds, everyone would point at that room and say ‘Less risky!’ And they’d be right. The problem with risk is that there are often, if not always, external forces that perpetuate risk.

We have to ask ourselves “What is risk?” We can look at it mathematically. Risk = {si, λi, xi} – and most of us have no idea what that means. Risk is not a magical number that says “Defusing a bomb is this risky.” Determining risk is how we discern how likely something is to happen, and from that, what is the likelihood of an unwelcome outcome.

Too often risk is defined as risk = likelihood * consequence and safety = 1-risk

This can misinform: acceptable risk is a consideration of likelihood ANDconsequence, not a simple multiplication with safety as the additive inverse of risk. Acceptable risk and safety are normative notions, changing with situations and expectations, and must be assessed accordingly. (Source: Woody’s Perspective – by Steven A. “Woody” Epstein)

Risk analysis, for all it’s a mathematical discipline, is just that. A discipline. That means the numbers matter far less than you think they do, and if all you do is look at the numbers and say “But we’ve predicted a five point uptime!” then you’re ignorant of the truth.(A five point uptime refers to the claim people make of providing 99.99999% uptime. The five 9s after the decimal point are feel-good numbers/) The trick to it all is that variation is something computers are phenomenally bad at handling. Look at your computer. It’s what can be best described as a ‘brittle’ system. If you throw something a computer’s never seen before, it tends to react poorly, because unlike the human brain, it can’t adapt or improvise. It can’t know “Oh, you meant ‘yes’ when you typed ‘yea’” unless some programmer has put in a catch for that. On some systems, it may not even know the difference between an uppercase Y and a lowercase y.

Variation is nature. It’s reality. It’ll never go away, either. The point of risk analysis is not to come up with that number to say ‘By doing foo, we are x% less risky.’ The point is to look at the system and understand it better. The point is to learn. The act of explaining and defining the process, whatever it is from changing a tire to pushing software to a few hundred servers, is what makes a process less risky. You understand what it is you’re doing, and you can explain it to someone so they too can understand it, and now you know what you’re doing. The numbers will come, but they’ll also change over time due to variation.

We mitigate our risk by understanding, testing and documenting. But just as you can never have 100% uptime on a system (you have to upgrade it at some point), you cannot excise risk entirely. On the other hand, we cannot ignore the need for testing.

A woman named Lisa Norris died due to a software error, caused by a lack of testing. All the safety checks, the manual monitoring and brainpower failed because the automated system wasn’t tested. Prior to the automated system going online, the old way was for people to manually transcribe medical dosage. This was felt to be ‘high risk’ because there was a risk of transcription error. However nowhere in the incident report were any ‘manual errors’ noted, prior to the automated system being used. We can assume, then, that any manual errors (i.e. transcription errors, the risk the system was meant to abrogate) were caught in-flight and corrected. The automated system does not appear to have ever been tested with ‘real world’ scenarios (there’s no documentation to that affect that anyone investigating the situation had found). If they had run simulations, testing with data from the previous, manual system, they may have found the errors that lead to a woman’s death. (Source: Lisa Norris’ Death by Software Changes – by Steven A. “Woody” Epstein)

There remains a possibility, however, that even with all the testing in the world, that the error that led to Miss Norris’ death would have been missed. So how do we make testing better? As long as we’re only testing for the sake of testing (i.e. it’s expected, so we do it), or we follow the standard test plan, we miss the point of dry testing. Even people who stick by their ridgid test scripts are missing the point.

Open Source software, however, gets the point.

You see, we know we can’t test everything, and we know that we’re going to miss that one variation on a server where code that works a hundred times on a ninety-nine servers will fail on that one where it has a tiny difference. And yet, if a million monkeys banging on a million keyboards could write Hamlet, then why can’t they fix software? They can help cure AIDS, we know. Crowd sourcing knowledge means that you let the monkeys bang on your data and test it in ways you never imagined it being used. No longer driven by a salary (and that really does lock your brain in weird ways), the monkeys (and I’m one of them), cheerfully set up rigs where we can roll back quickly if things break, and start just using the iterations of software, coming up with weird errors in peculiar situations.

We always talk about how we want to lower the bar and make products more accessible to more people. Make it easier for them to use. In order to sustain that model, we need to embrace the inherent risk of software and teach the users how to correctly perform basic troubleshooting and report real errors. To often we write our code in a vacuum, test it in a limited fashion, and release into the wild knowing there will be a second release to fix things. As development matures, we push out more changes more often, small changes, so people are eased into that new thing. We step out of isolation and embrace the varations of how our product will be used.

Now we need to get our users to step out of their isolation and join the monkeys. We can’t make things better for everyone unless everyone is a part of the improvement process. We must ease these users into understanding that every software product is ‘in progress’, just like we taught them to accept that all webpages are perpetually ‘under construction.’ Our dry tests will never be complete until we can determine how to safely bring them in. Maybe we make smaller changes every day, like Google does with Chrome, such that they never notice. Or maybe we ask them to ‘check the box to join our test group and get cool features before everyone else!’ But we must do it, or we will fall behind in giving the users what they want, and giving them a solid, safe, secure product.

Until then, we’re not analyzing or assessing actual risk, we’re merely players in risk theater.

27 September, 2011
How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness

Remember those times in the ’90s when you had to type WWW. and websites looked dull, boring, and full of moving and annoying flash banners. I’m sure nobody wish to go back to those times. Now, websites are focusing more and more on the user experience, loading speed, and subtle ways to locate ads without distracting the content or function.

via How 17 Famous Website Looked In The Past: In The ’90s. You’ll Be Amazed | ImmatureBusiness.

26 September, 2011
Custom Post Types Are Not Posts

This confuses the heck out of a lot of people. Custom Post Types are’t posts they are post types.

Otto wrote a very nice primer on WordPress 3.0 and CPTs which points this out. Nearly a year later, people are still getting it wrong becuase they refuse to let go of the word ‘post.’ It was, in retrospect, probably a poor choice of names. Ditto Post Formats, in my opinion, but there we are.

I blame the naming, really. “Custom Post Types” makes the implication that these are “Posts”. They’re not. “Post Type” is really referring to the internal structure of WordPress. See, all the main content in WordPress is stored in a table called “wp_posts”. It has a post_type column, and until now, that column has had two main values in it: “post” and “page”.

So now, with CPTs, we can make new ‘post types’ and name them whatever we want. It’s very important to note that the column name of post_type is why we call these Custom “Post Types.” If you can let go of the (very logical) connection of ‘Custom Post Type is a type of post’ and start thinking of it as ‘Custom Post Type is a new Post Type’ then you’re halfway to victory.

If you’ve ever used a Wiki, there is no real post hierarchy like there is with a default WordPress installation. In WordPress, you always have the ability to frame your post URL slugs with date, or even category(As of WordPress 3.3, it’s not as disastrous as it was to use /%category%/%postname%/ in your URLs.), as it happens. Look at MediaWiki. Everything is pretty much top-level. You don’t sort by subfolders, or categories, or anything. All the URLs are domain.com/post-name.

What about SEO? I’ve said it before, and I’ll say it again: SEO doesn’t care. Google doesn’t care if your URL is domain.com/foobar or domain.com/2001/foobar – Your readers might care (which is why I advocate using at least the year in your URLs for HEO), but Google, not so much. If they did, why would MediaWiki be ranked so high on most searches? No, what SEO cares about is your content, your context, and your relationships.

That really begs the question of why would anyone use CPTs at all? Last year, Otto advocated you don’t use them if you’re just blogging. He’s right. You shouldn’t. But I use them here to make custom pages for my plugins, and I use them on another site to record all the questions people send me. They’re unorganized, when you compare them to posts. But I can, and have, added in taxonomies support to sort them. Thanks to people like Justin Tadlock, there are tutorials on how to correctly make your Custom Post Type and I know to just add 'taxonomies' => array( 'post_tag', 'category '), to let my CPT use tags and categories. Want to limit it even more? How about linking specific post types and taxonomies!

Some great examples of CPTs are things like bbPress 2.0, the new forum plugin from WordPress, but also this is the future of BuddyPress! People use them to create movie databases, actor pages, a FAQ, or pretty much anything that needs its own structure. What shouldn’t you use CPTs for? Basically if you want something to act like a blog, don’t use CPTs. If you want something to live on it’s own, like a forum, a wiki, a Facebook page, then you want a CPT. If you want multiple blogs, with unrelated, unconnected, content that just happens to have the same author, we call that MultiSite.(See? There are great reasons to use MultiSite!)

But they’re not for everything, and never will be, any more than WordPress is right for everyone. So let go of the ‘But they’re posts!’ argument, because you are flat out wrong. They’re post types. Not posts.

26 September, 2011
Don’t Use WordPress MultiSite

Edit: It’s May 2015 and this post is still relevant.

I talked about this at WordCamp SF 2013. Check out my slides or watch the video.

I love MultiSite. I think it’s awesome and very helpful when you want to make a network of sites. But more and more I see people doing things where I just tilt my head and wonder why they’re using MultiSite for that particular use-case. People seem to think that simply because they can use MultiSite that they should use it, and this simply is not the case!

MultiSite, either by intention or effect, works best when you think of it as running your very own version of WordPress.com. You have a network of sites that are disconnected from each other, data wise, but share the same available user base. That means the only ‘information’ that is shared between two sites is your user ID, and even then, unless you’re explicitly granted access to the site, you’re nothing more than a subscriber. Which is to say you can read the site, and comment.(You could get nitpicky here and point out that there are a lot more things one can do as a subscriber on a site, but you understand the gist.) That means that while there are many perfectly valid reasons for having a MultiSite, it will never be a perfect solution for all people.

One of the best alternatives to MultiSite is Custom Post Types. They let you make ‘subfolder’ additions to your site and format them as you want. There is a drawback, though, in that you cannot use YYYY/MM/DD in your permalinks for them (Otto on Custom Post Types – wp-testers email list) however I would wonder why people use that anyway these days? The only reason I use YYYY in my URLs is that I believe there’s a date on the usefulness of these posts, and if you come back in five years, you should know how old the information is.

Another alternative is good planning. If you sit down and define your needs for your site before you build it out, and plan for the growth you desire, a lot of things become clear. Think about how many different places you’d want to go to maintain your site.

Here are some examples of sites that should not be built out as MultiSites:

To Categorize Posts

This one comes from my girl, Andrea, who reminded me of a fellow we ran into who wanted to have one site to post from, and each post would go to a special site based on the category. WordPress already has that built in! It’s called, get this, ‘categories.’ Now the user in question said he didn’t want categories because your URL shows up as /category/pemalink, and that wasn’t his desire. So I suggested Custom Post Types. /posttype/name was much better, and he could add in tags as he wanted.

When Your Site is Homogenous

Do you want your whole network to look and feel 100% the same? Don’t use MultiSite. If every single subsite is going to be exactly the same, except for content, but the content is all written the same way, you don’t need MultiSite. Replicating the theme and settings on every subsite is a pain, and you can achieve the same result with categories, tags and CPTs. You can even use a membership plugin to control who sees, and has access to, each CPT!(Role Scoper claims to do this, in fact.)

Now someone will point out that this site fails that check! If you notice, three (four, kind of) of the sites look very similar. Same general layout, same links and sidebars, but different headers. This site could have all been done as categories and CPTs, and not needed the multisite until I hit on the children sites like the one for my grandmother. But. When I built it out, I decided to put my tech posts on their own page to separate the writing. They are separate sites. What I write here is vastly different from my blog, and that’s important to me. The site has the same ‘feel’ in look alone: the context is what separates us.(And I have a plan for the photo blog.)

For One Special ‘Thing’

I’m guilty of this one. I had a site that was a blog, and I wanted to make a ‘video’ section. So I made a MultiSite! Boy was that dumb. Two admin areas, two sections for layout, and I wanted the site to still look like ‘itself.’ I caught a clue later on and converted the whole thing to Custom Post Types! Much easier to maintain! Now I have a smaller, faster, site.

Users Shouldn’t Know About Each Other (AKA Separate User Databases)

Andrew Norcross pointed this out. If you need users to be on different sites, but not aware that they’re on a network, don’t use MultiSite! Now, yes, there are ways around this, however it’s an auditing nightmare for any large company, and a security risk that you should be aware of before you start.

Curtiss Grymala points out that if you need totally separate user databases, this is a strong case against MultiSite. Be it for security or just obscurity, if the users need to be separated don’t do it. There are workarounds, but you’ll spend more time on that then updating your sites.

Hosting Small Client Sites

I don’t host my Dad’s site, Woody.com, even though I maintain it. Why? Because, as

Cristian Antohe said, he just needs a standalone WP install. Would it be easier for me to have one place to go to upgrade him? Yes and no. He’s small, he doesn’t need a lot, and he now owns his domain, his site and his email, all in one place. It costs him $7 a month, plus the number of meals he buys me when we’re in town together, and he’s master of his own domain. This is great for him, because if he fires me, he still has everything. Also, if he does something weird that spikes his traffic 500% (like last month), it doesn’t affect the rest of my sites. Factor that into your budget. Make your client own their own data.

Users Need To Embed JS Into Posts

This is not a bug, people. Only the Super Admin on a MultiSite install has the access to include iframes, javascript, and other non-oEmbed’d data into posts! You don’t want them to! If you’re running a MultiSite, you’re the big dog, and you’re responsible for limiting their actions to things that won’t take down everyone because they don’t understand what an insecure iframe hack is. Yes, there’s a plugin that will let you allow this. No, I won’t tell you what it us, because unless you’re using a 100% locked down, you approve users you know and trust with your car, site, you do not want to open this door.

If you can’t give them they access they need via shortcodes, then they need to host themselves, or you host them separately. Protect everyone on your network, and don’t give them unregulated access.

Users Need To Install Themes/Plugins

Curtiss again reminded me that MultiSite doesn’t let you let your users install themes and plugins as they want. You can, via the use of clever themes that save settings per site (like TwentyEleven) and plugins that allow you to tweak CSS (like WordPress.com Custom CSS) give them more customization, but you cannot give them access to install plugins and themes. Why? Because those things will be available to everyone on the whole Network.(There are plugins to manage plugins more granularly, and only permit some sites to use certain plugins, but again, this isn’t something everyone on your network should have access to do.) Remember, we’re sharing here!

Same Post, Every Site

I keep running into this one. “I want to have the same post pushed to every single site on my network!” I understand why people do this, I just think they’re doing it wrong. It’s not just that MultiSite is meant to be separate (aka individual) sites, it’s that you’re diluting your content. The more different places someone can go to in order to get the information you’re providing, they less impact you have because you’ve given them too many options. Decisions. Make one. Also, as Andrea reminded me, identical content in multiple places is something spammers do. Google will downgrade your site ranking if you do this.(This doesn’t impact categories, tags and archives because of the use of canonical links.)

Now, one user said he needed to do this as a business decision, because each of his (mapped) domains was a separate brand. But the separate brands had shared data. So … they’re not actually separate, but children. Me? I’d have everything link the shared data back to the master brand. McDonalds may sub-brand out happymeal.com (they did!) and make a whole separate site, but if you click on their ‘Privacy’ link, you go back to macdonalds.com! Why? Because the parent brand is where that stuff belongs.

BuddyPress Separation

This comes from Andrea again. If you need to have totally separate BuddyPress installs, use separate installs entirely. Just … y’know, you can do it other ways, but it’s not worth it.

What else?

This list could go on and on, so jump in and tell me your reasons why you’d never use MultiSite!

22 September, 2011