To be honest I struggled to find the solution immediately so wanted to explain how you can filter by one or more post types. For both of the explanations below I will explain how this can be achieved by editing the search form, or by editing the themes functions.php file.

Note: For information on creating a search form see this link:

http://codex.wordpress.org/Function_Reference/get_search_form

Filter Search Results by a Single Post Type

Search Form

<form method="get" id="searchform" action="<?php echo esc_url( home_url( '/' ) ); ?>">
	<input type="text" class="field" name="s" id="s">
	<input type="hidden" class="field" name="post_type" id="post_type" value="movies">
	<input type="submit" class="submit" name="submit" id="searchsubmit" value="<?php esc_attr_e( 'Search' ); ?>">
</form>

functions.php

function SearchFilter($query) 
{
	if ($query->is_search) 
	{
		$query->set('post_type', 'movies');
	}
	return $query;
}
add_filter('pre_get_posts', 'SearchFilter');

Filter Search Results by Multiple Post Types

Search Form

<form method="get" id="searchform" action="<?php echo esc_url( home_url( '/' ) ); ?>">
	<input type="text" class="field" name="s" id="s">
	<input type="hidden" class="field" name="post_type[]" id="post_type" value="movies">
	<input type="hidden" class="field" name="post_type[]" id="post_type" value="photos">
	<input type="submit" class="submit" name="submit" id="searchsubmit" value="<?php esc_attr_e( 'Search' ); ?>">
</form>

functions.php

function SearchFilter($query) 
{
	if ($query->is_search) 
	{
		$query->set('post_type', array('movies', 'photos'));
	}
	return $query;
}
add_filter('pre_get_posts', 'SearchFilter');

So there we have it. By using an array we can filter the search results by two or more post types.

$data = array(
	'username' => 'joebloggs',
	'name' => 'Joe Bloggs',
	'email' => 'joe@bloggs.com'
);

$this->session->set_userdata('user', $data);

In the above code we are creating a session called ‘user’, then assigning an array to it containing the users information.

Now, lets imagine that at a later date we also want to add a phone number to this session. We can do this easily using the method outlined below:

$data = $this->session->userdata('user');

$data['telno'] = "01234 567 890";

$this->session->set_userdata('user', $data);

If you can’t make out what we’re doing here, we’re assigning the existing user data to a variable called $data. We then add an extra element to the array, in our case this is the user’s telephone number, then overwrite the existing user session with the new infrmation.

Whilst recently installing it on a new PC however, I came across the following error in the logs:

Process exited with code 1633

The Solution

The problem turned out to be that I had downloaded and installed the wrong version. On the downloads page there are two versions of SyncToy available; a x64 version and a x86 version.

After trying the other, correct package, it installed and ran immediately as expected.

I was recently working on a site that would be used on a mobile or tablet device, and therefore required the carousels be controlled through swipe motions and the users using their fingers to control the direction of the carousel. The current plugin I was using doesn’t come with this functionality included (probably due to it’s age) so I needed to look elsewhere.

Luckily for me it turned out that a chap called Karl Swedberg has continued, and still maintains, his own version of the jCarousel Lite plugin. The ‘swipe’ option is activated by default so the mobile functionality works straight out of the box.

The other great thing is, that because this improved plugin simply extends the original, I can simply go back through my old sites containing carousels and drop it in over the top without having to change any code.

One thing that’s always gnarked me a little about the plugin however is how the slides always fade out before the next one fades in. This results in seeing a glimpse of the background colour for a split second. I couldn’t see an option in the available parameters to disable this, so set about looking for the responsible code in the plugin file itself.

The Solution

The plugin file itself is quite large so it took a while to find the culprit code. The change required however is tiny, one character to be precise. You simply need to do a search and amend the following line of code (for me it was line 997) from:

opts.animOut = { opacity: 0 };

To:

opts.animOut = { opacity: 1 };

In making the change above, the slides no longer faded out, and the next slide simply faded in over the top of the previous one.

My chance came on a site that wanted to use video heavily in lightboxes to demonstrate a new product they were releasing. I did some research into the different video formats supported across devicces and browsers, and set to work. I actually ended up using Video.js due to its ability to provide a Flash fallback and to incorporate different skins. I got the video player code added in a few minutes and was ready to hit the ‘Play’ button on the website.

In FireFox the lightbox opened and the video played as expected. In Safari and Chrome however, the audio of the video could be heard but without the visual. I tried different video formats, different video players, different everything, but the two browsers would not behave as expected and simply just kept playing the sound.

The Solution

I mentioned that the videos were being shown in a lightbox. As a result I’d gone to some effort to hide and show the lightbox layer when the ‘Play’ button was clicked. What I didn’t realise however was that I’d hidden the actual <video> tag by doing something like so:

<video id="lightbox-video-player" style="display:none" class="video-js vjs-default-skin" controls preload="auto" width="1000" height="563" data-setup="{}">
	<source src="/my-video.mp4" type='video/mp4'>
	<source src="/my-video.ogg" type='video/ogg'>
</video>

Notice that I’d put a ‘display:none’ on the video? This was the reason for only hearing sound on Chrome and Safari and, after removing this, the video played as expected.

document.title = 'This is my new title';

Yup, that’s it! I told you it was easy.

Note: Bear in mind that search engines don’t execute JavaScript and therefore won’t take your updated title into account. Just be aware of this if you’re wary of the pages impact in serch engine rankings.

I needed to do exactly this today. I built the form’s HTML, made it submit to itself (ie. the same URL) and coded some PHP to process the form. When the form was submitted however, it just went a 404 page straight away.

I knew the page existed because the form was posting to the same URL, and I knew it was OK to POST data from a form, so what was the problem?

The Solution

In summary, WordPress has a list of reserved words for POST variables that can’t be used when building a bespoke form. In my scenario one of the textboxes had the name of ‘name‘, which turned out to be one of these reserved words.

I don’t have a definitive list of these reserved words, however I did find a full list here.

Once I used a different name for the text field in question, my form then began to submit as expected.

I was stuck on this problem for literally 2 hours and, after searching on forum after forum, could not find a viable solution anywhere.

What was the cause? Well, to be fair it wasn’t the fault of the NextGEN Gallery. It was indeed my coding that had broken the photo gallery. I had setup a custom post type called ‘gallery’ that was conflicting with the plugin. Turns out that the plugin uses the same post type name, and therefore was causing it to fail.

After changing my custom post type name in my themes functions.php file, the photo gallery began to work as expected. It would be great if the plugin detected a conflicting custom post type and warned developers about this. I’ll put it to the plugin authors and hopefully it will get added as a feature soon.

I did face a problem recently though when trying to build a zip file, and it took me a while to figure out the answer. I would open a new Zip reference, add some files, and then close the zip immediately after. Oddly enough however there was no zip actually created and, even weirder, no errors informing me something had gone wrong with the build.

Let’s take a quick look at some code that builds a zip. Afterwards we’ll analyse what’s wrong with the code, why it won’t work, and how we can easily fix it:

// Initiate a new instance of ZipArchive
$zip = new ZipArchive();

// Open a new zip file
$res = $zip->open("myZip.zip", ZipArchive::CREATE);

// Add a file to the zip file
$zip->addFile("/path/to/file/myPhoto1.jpg", "newPhoto1.jpg");

// Add a file to the zip file
$zip->addFile("/path/to/file/myPhoto2.jpg44", "newPhoto2.jpg");

// Add a file to the zip file
$zip->addFile("/path/to/file/myPhoto3.jpg", "newPhoto3.jpg");

// Close the zip file.
// At this point it should be created
$zip->close();

Now, running the above code will result in nothing at all. No zip file, or no errors. Just a completed script that apparently has done everything it was meant to do.

The Solution

In the code above can you tell what’s wrong? No, it’s not me making a typo. The second image we’re adding isn’t a valid image and doesn’t exist at all. As a result we’re not left with a zip file, but a sense of confusion which, for me at least, lasted a couple of hours.

To fix the problem we have one of two options:

1. Fix the path to the broken image,

or

2. Do a check that the file exists before trying to add it. This approach will involce amending the code to read something like so:

// Initiate a new instance of ZipArchive
$zip = new ZipArchive();

// Open a new zip file
$res = $zip->open("myZip.zip", ZipArchive::CREATE);

// Add a file to the zip file
if (file_exists("/path/to/file/myPhoto1.jpg"))
{
	$zip->addFile("/path/to/file/myPhoto1.jpg", "newPhoto1.jpg");
}

// Add a file to the zip file
if (file_exists("/path/to/file/myPhoto2.jpg44"))
{
	$zip->addFile("/path/to/file/myPhoto2.jpg44", "newPhoto2.jpg");
}

// Add a file to the zip file
if (file_exists("/path/to/file/myPhoto3.jpg"))
{
	$zip->addFile("/path/to/file/myPhoto3.jpg", "newPhoto3.jpg");
}

// Close the zip file.
// At this point it should be created
$zip->close();

I personally went for the second option and after making the changes above, I was presented with the zip that I expected.