I wanted to exclude the featured articles from appearing in the regular articles section, and I did so by using the WP_Query() parameter ‘post__not_in’.

The reason for writing this article is that collecting the post IDs from my first WP_Query and passing them to the second was, for me, non-trivial because the five featured articles appear in my header.php file and the ten regular articles appear in index.php.

In order to achieve my desired result I had to set a php variable in my functions.php file, and then declare it as a global variable in my header.php file and index.php file.

Here’s how the relevant code looks:

from functions.php

$featIDs = array();

from header.php

global $featIDs;
$feats_query = new WP_Query('category_name=Features&posts_per_page=5');
while ($feats_query->have_posts()) : $feats_query->the_post();
	array_push($featIDs, $post->ID);

from index.php

global $featIDs;
$index_query = new WP_Query(array( 
	'posts_per_page' => 10, 
	'post__not_in' => $featIDs
));

This article explains how to make custom queries using WP_Query() AND still allow for pagination.

My use case is: a custom query on my index page which excludes certain posts, and wp_pagenavi for paginating my archives.

I explain in detail why I am using WP_Query() instead of the regular WordPress loop in my next article ‘How to stop post duplication when using multiple WP_Query() requests‘.

In short, WP_Query doesn’t know what page you’re on like the regular WordPress loop does – you need to tell it which page of posts to ask for (and, in addition, how many posts per page you want it to retrieve).

Here’s the relevant code:

$pagedNum = get_query_var('paged');
$index_query = new WP_Query(
	array( 
		'posts_per_page' => 10, 
		'paged' => $pagedNum
	));

So there are two ways that you can achieve what I wanted to do, and both utilize the functions.php file.

Strategy One – just allow for html (no TinyMCE)

remove_filter('pre_user_description','wp_filter_kses');

Strategy Two – add TinyMCE to the User ‘Biographical Info’ field

Use the above code AND the code below

function biographical_info_tinymce() {
	if ( basename($_SERVER['PHP_SELF']) == 'profile.php' || basename($_SERVER['PHP_SELF']) == 'user-edit.php' && function_exists('wp_tiny_mce') ) {
		wp_admin_css();	
		wp_enqueue_script('utils');
		wp_enqueue_script('editor');
		do_action('admin_print_scripts');
		do_action("admin_print_styles-post-php");
		do_action('admin_print_styles');
		remove_all_filters('mce_external_plugins');
 
		add_filter( 'teeny_mce_before_init', create_function( '$a', '
			$a["theme"] = "advanced";
			$a["skin"] = "wp_theme";
			$a["height"] = "300";
			$a["width"] = "440";
			$a["onpageload"] = "";
			$a["mode"] = "exact";
			$a["elements"] = "description";
			$a["theme_advanced_buttons1"] = "formatselect, bold, italic, pastetext, pasteword, bullist, numlist, link, unlink, outdent, indent, charmap, removeformat, spellchecker, fullscreen, wp_help";
			$a["theme_advanced_blockformats"] = "p,h2,h3,h4,h5,h6";
			$a["theme_advanced_disable"] = "strikethrough,underline,forecolor,justifyfull";
			return $a;' ) );
 
		wp_tiny_mce( true );
	}
}
add_action('admin_head', 'biographical_info_tinymce');

How to reproduce the crash

Create a post with more than 20+ mp3s to play, or go to a page (archive for example) where more than 20+ players are present – it doesn’t matter if they’re all inline or each have their own wpaudio markup, you just need more than twenty players. The crash was occurring in Safari. Chrome was working ok. I didn’t test Firefox or Internet Explorer.

I have a monthly series that I run called the Monthly Best of the Blogosphere, wherein I post 25-30 tracks that have been really popular that month. Only on these posts was the browser crash occurring.

How to fix the crash

You have to edit the wpaudio.js (or wpaudio.min.js file, depending on what you use – I use the minified wpaudio.min.js file myself). You have to change two lines of code in this file, and add an additional one. It’s pretty easy, and if you follow my instructions carefully you can do this with minimal coding knowledge.

Find this function:

function WpaudioHTML5 (parent) {
			...
}

Find these two lines – they are sequential:

start = player.seekable.start();
end = player.seekable.end();

Change them to this:

start = player.buffered.start();
end = player.buffered.end();

Next, find these two lines:

player.src = parent.getUrl();
player.volume = 1;

And add this line after them:

player.preload = "none";

Voila! Problem solved!

This idea reminds me of the scene in Apollo 11 where NASA engineers are faced with the challenge of fitting a square peg in a round hole:

Great work is expensive because you have to pay for quality with one of those two resources no one wants to part with: time or money. It doesn’t matter which you pick, it’s going to be expensive if you want it to be great.

My frustrating learning experience

I just sorted out an issue with wordpress multisite, and it took quite a bit of searching and reading to uncover what is ostensibly a very simple solution. Admittedly, I didn’t know anything about the httpd.include or vhost.conf files before I set out a few weeks ago, nor the ServerAlias tag the VirtualHost tag or how dns entries, including the wildcard (*) are parsed.

The problem was this: wordpress multisite is installed with a subdomain install. That means every site created gets a new subdomain, and as a result you need a way to tell your server that any traffic that goes to that subdomain should ask the main site for information and files.

The practical solution is to use a wildcard dns (*) entry when setting up wordpress multisite – indeed this is the definitive proscribed solution. Unfortunately, this can cause some headaches if applied incorrectly, as has been well documented in this discussion thread.

What was supposed to happen

1. People can visit mysite.com
2. I can create a new site (a subdomain) in the mysite.com backend, and people can automatically access newsubdomain.mysite.com
3. People can access my subdomain community.mysite.com which is NOT a wordpress multisite blog, and any other special subdomains that I might like to define separately from the mysite.com wpms install (ie community is vanilla forums, and I might want to add some kind of mail redirect to google apps email mail.mysite.com)

What was happening when I included the vhost.conf file

1. I followed the instructions to add a line to my httpd.include file which includes a vhost.conf file. Incidentally, this is ALSO required for domain mapping, which I am also doing:

<VirtualHost xxx.xxx.xxx.xxx:80>
   ServerName   mysite.com:80
   ...
   Include /var/www/vhosts/mysite.com/conf/vhost.conf
</VirtualHost>

2. Because the vhost.conf file was included INSIDE the VirtualHost tag, the VirtualHost tag was NOT required in the vhost.conf file. All I required was one line: ServerAlias *.mysite.com
3. I could visit mysite.com
4. I could visit my wpms subdomains
5. I couldn’t visit community.mysite.com – I would be redirected to a page telling me that registration is closed (and presumably I would have been redirected to a signup page, were I to enable that feature)

What was happening when I took out the vhost.conf file

1. I could visit mysite.com
2. I could visit community.mysite.com
3. I couldn’t visit any of my wpms subdomains

The solution, and why

It took a minute, but when I paid attention to the details of the discussion thread the answer was pretty clear.

The way these dns redirects work is in order – the text file is just parsed, and apache takes the first valid option it finds. “Cool!” I thought, “that just means that I need to order my file properly!” Sure enough, once I added the VirtualHost record for community.mysite.com BEFORE the mysite.com record, and put the include vhost.conf statement in to the mysite.com VirtualHost record, things worked fine!

Voila:

<VirtualHost xxx.xxx.xxx.xxx:80>
   ServerName   specialsubdomain.mysite.com:80
   ...
</VirtualHost>
<VirtualHost xxx.xxx.xxx.xxx:80>
   ServerName   mysite.com:80
   ...
   Include /var/www/vhosts/mysite.com/conf/vhost.conf
</VirtualHost>

I hope this helps even one person, because I was seriously going nuts with this problem. Please feel free to comment if there is any confusion over what I’ve described here, but keep in mind that I am still a novice with Apache… but I’ll try my best!