Hide WordPress Post from All Queries

Problem: you want to create a variation of a page but you don’t want it to show up on the home page or in any archives or anything. You just need a direct link so you can share it with someone.

Solution:

add_action('pre_get_posts', 'hide_hidden_posts');
function hide_hidden_posts($query) {
  if ( is_admin() ) {
    return $query;
  }

  if ( is_single() AND $query->is_main_query() ) {
    return $query;
  }
  $ids = wp_cache_get('hidden_posts', 'posts');
  if ( !$ids ) {
    global $wpdb;
    $ids = $wpdb->get_col("SELECT post_id FROM {$wpdb->prefix}postmeta WHERE meta_key = 'hide_post'");
    wp_cache_set('hidden_posts', $ids, 'posts');
  }
  $query->set('post__not_in', $ids);
  return $query;
}

This function will modify all WordPress’ frontend queries to exclude any posts with a custom field “hide_post”, except in the case that the query is the main query on a single post page.

Caveat: This will only be functional for plugins and themes using the WP_Query api. Custom queries will not be modified.

How to Be a Good WordPress Developer?

Pippin has some thoughts. I concur with most of them, especially the one about challenging yourself. The best self-taught developers are those who become obsessed with solving problems. They can’t stop themselves. They might get discouraged and walk away from the computer in disgust. But a few minutes later they’ll think “but I haven’t try this” and be right back at it.

Good developers surround themselves with people who know more than they do. They have no real desire to show how smart they are but would rather learn something smart from others. If you can let your pride go and be ok being the dumbest person in a room full of the smartest people ( as opposed to being the smartest in the room ) you’ll be better than you’d ever imagined otherwise. Plus people will like working with you which helps .

If your looking for a more “skill” based assessment of what it takes to be a developer, this is a pretty good article. Specifically, I like the notion of “problem decomposition,” which is a fancy way to say troubleshooting.

A key aspect of solving a problem ( and thus being a good developer ) is not getting handcuffed by what you don’t know. Obviously, if you knew you wouldn’t have a problem. But just because you don’t know what is causing a specific issue doesn’t mean you know nothing. I often start troubleshooting by clarifying and confirming what I do know.

For instance,  if WordPress gives me an “Error establishing a database connection” screen: What do I know? Do I know my username and password are correct? Can I confirm that by connecting to mysql via the command line or PhpMyAdmin? Do I know that mysql is running on the server?  Again does phpmyadmin work? Does my hosting dashboard have a mysql “status” icon”? Or does <code>service mysql status</code> return something? So on and so forth.

Confirming what you know sometimes exposes that what you think you know may not actually be true. And if it is true, it helps you focus your theories of the problem on areas that really are unknown. Like anything else, the more you decompose problems the better you’ll be at it.

Quick List: Things WordPress Plugins Developers Can Do to Help Their Plugins Scale

1) For heavy backend operations like generating reports, don’t generate the screen on the init hook. Schedule a cron job and generate it periodically … if the administrator needs it right away, give them a refresh button.

2) Don’t autoload options unless they are really needed on every page load. And if you do autoload the option then make sure it isn’t too big 10KB should be plenty. Keep in mind if you create your option for the first time using the update_option(); [codex] function it will be autoloaded by default. So you should instead intiate the option using add_option('myoption','myvalue', false);

3) Don’t use wp_postmeta fields for numeric calculations. WordPress strongly encourages developers to work within their custom post type API, which is good, but that doesn’t mean the Metadata API is equally good for all data types. For instance a post_type, “order”, in which the record will have fields like ‘subtotal’,’tax’,’discount’,’grand_total’, which will likely be summed and counted and multiplied etc, go ahead and use a custom table with a foreign key on post_id.

Should I Use WordPress Multisite? Why Not?

WordPress Multisite ( a.k.a WPMU )  has been alluring ever since it was introduced. Sweet! Now I can start my own blog network like WordPress.com, next stop global domination!

Ah, were it that easy I would be an enormous fan. But global domination doesn’t come without hard work unfortunately and if you’re not ready for that then WordPress Multisite can be a curse rather than a blessing.

First let’s establish what is awesome about WordPress Multisite and when you should use it. As a developer you always get talked into building sites for friends and family. To save myself time I have a multisite install I use to host these charity sites. It makes it super convenient for me. Less maintenance. Less setup time. Add the WordPress Domain Mapping plugin and I’m rockin’. WordPress MU is great for this.

It’s also great if you really do need a “network” of blogs. In some cases this is exactly your goal and WP Multisite is the only tool that’ll get you there. Great! Use it!

But it’s the improper use that irks me. Too often development agencies see it a as a shortcut to hosting their client sites or, worse, someone who is not a server admin thinks they will make a quick buck throwing up a multisite on someone else’s servers and selling hosting.

So before using multisite there are a few things to know about it:

  1. It can be a bitch to scale. Each blog instance on your multisite creates it’s own set of 11 tables … no big deal for 50 sites. But once you hit 100 – 200 sites you’re going to start getting some headaches on shared hosting, and just 250 – 500 sites is enough to crater an entire VPS.
  2. Maintenance Costs Grow Exponentially. The cost to maintain your first 50 WPMU sites is relatively cheap. You definitely make some money up front. But the bloating database starts getting expensive to maintain when it has to have it’s own database server, and then even more when it has to be shared across several. Moreover, development slows down since you spend more time on performance issues … that cross site feed that worked fine for 50 sites is really dragging at 250. Also, try creating a dev environment for a network, not as easy as you think.
  3. Bugs Get More Dangerous. The cost of a mistake also grows. Now you have all your customers connected to one WordPress Multisite code base and database. But your growing customer base requires you to bring on some new developers. And guess what? One of them isn’t that great and commits some bad PHP to the code base. Now all of your customers are pissed, instead of just the one he/she was working on.

WordPress MU is appealing and sexy. It’s like magic. No more updating 100 installs manually, one and done, Woot! But it’s really just deferring costs until later. If you’re prepared for them, maybe it’s still worth the trade off, but in most cases it’s not. There are plenty of other services that will manage your code upgrades for you without having to use WordPress MU and that’s really the main benefit.

Other Reading

https://halfelf.org/2011/dont-use-wordpress-multisite/

https://tadpole.cc/blog/to-multisite-or-not/

Obfuscate Your Code at Your Own Risk

Looks like ZippyKid no longer supports WishList Member. I think it raises a good point about obfuscating code. Hiding your code behind some sort of encryption like Base64 may prevent your code from being ripped off, but it also prevents it from being improved and supported. If WLM made it’s code transparent it could share the burden of support and innovation with other services and developers. ZippyKid/WP Engine/WPMU/WP.com and on and on. But the obfuscation instead guarantees this vast community of resources can be of no benefit to WLM at all. I hope it’s worth it.

WordPress Caching: Clear An Individual WordPress Post Cache

I’ve become a bit obsessed with caching lately. Speed is an addiction I suppose. So I found another new trick today. If your writing a plugin or theme and have some front in functionality adding and updating posts, sometimes you want to make sure a cached object is cleared before the page is refreshed. But you don’t want to dump the whole object cache, especially if there are thousands of posts. So to just dump one post you can simply do this:

wp_cache_delete($post_id,'posts');

WordPress Theme Frameworks: Who needs ’em!

The buzz word in WordPress circles these days is “framework”. What the hell does that mean? Isn’t WordPress a framework? The official definition offered in the WordPress Codex is “a theme that is designed to be a flexible foundation that can serve as a parent theme for building child themes.” But this doesn’t quite give us enough information.

Taking only the simple definition under consideration, WordPress users are likely to get the impression that, all things being equal, you should use a framework. After all, who wouldn’t want the added benefit and “flexibility” of being able to have “child” themes. Sounds cool.

But once you unpack a framework theme and start futzing with it, you quickly realize all is not perfect in the land of “frameworks”. So here’s my stab at a more useful definition. A WordPress Theme Framework is a theme that has additional code built into it making selected tasks easier for theme developers to manage. The emphasis on developers is mine and is very important.

Over the last several months I’ve built sites using several different frameworks and found that there is little advantage consistent across all frameworks, though each framework has specific advantages. The only consistency is that to really benefit from frameworks you need to have a deeper understanding of WordPress, its syntax, functions, plugins, etc.

If all you want to do is customize a theme, frameworks are likely to drive you crazy.

In Theory

In theory, frameworks are a very powerful thing. The idea is that you can take certain standard needs of theme developers and abstract them into new functions that allow the theme developer to execute customizations without messing with the theme core. With many theme frameworks, if you know what you’re doing, you can perform most theme modifications by editing only the style.css and the function.php files.

By way of an example, the Thematic Theme Framework has a hook called thematic_above_indexloop();. If I wanted to add a feature ad banner above the index loop of a regular theme, I would have to go into the the index.php, find the loop, and ad the code. But in the framework I simply have to go to the function.php file and add the following:

function feature_ad_banner() {
echo 'my feature ad banner';
}
add_action('thematic_above_indexloop','feature_ad_banner');

This code just tells the theme to pull in my custom function when it triggers this action. This gives me a ton of power as a developer because I can easily build an awesome site without worrying about building the “guts” of the theme. Or, to put it simply, I can focus on the cool stuff while ignoring the mundane details.

It’s all about the HOOKS

The drawback is that each theme framework has its own peculiarities and learning the appropriate hooks and filters can take time. If you’re a developer, this time is justified because it saves time on future projects. But if you just understand the basics of WordPress themes and are simply trying to customize one for your own use …especially if you aren’t all that comfortable with PHP … this extra level of abstraction can be a royal pain in your ass. If you’ve modified a loop before, you’ll find modifying a loop in a framework isn’t nearly as simple as you remembered. You have to create your own function and then track down the right hook to apply it to. A mod that used to take you 15 minutes, now takes you an hour.

Again, there are rewards to learning a framework, but make sure you understand the time investment required and how that squares with the benefits you expect to receive in return.

In short, WordPress Theme Frameworks are great for those serious about development. But hobbyist might want stick with an old fashioned WordPress Themes. In future articles I will look a few different frameworks and when you mind be inclined to use them.

Site Plug: ReadyMadeWeb.com

For those of you on a budget (me me me me), www.readymadeweb.com is a great resource for web tips about easy-to-use, out-of-the-box, ready-made web-ware. Is there a record for the number of hyphens used in a single clause? For instance, here’s a great post explaining why you might want to use a mass follow program to grow your twitter audience.