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 Portable Database Caching Class

So here’s a little library/class that I wrote to make caching a little easier from project to project. WordPress requires a plugin like W3 Total Cache to be in place for “persistent” caching to be available … that is, caches of data that survive longer than the current page view. But sometimes when you’re building a complex custom project there are some queries you know could be safely cached regardless of the global caching setup. With this class you can build it right into your theme or plugin.

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');