ViscoDesign

Thanks for the response esmi. Yes I did use Regenerate Thumbnails, but that’s where the problem lies.

When I first imported all the posts, I noticed the image links in the posts had pixel dimensions at the end of the filename. So, when I regenerated the thumbs to fit my new design, all the images had broken links (1,500+ posts!). This is because the URL was looking for image-100×100.jpg and I now had image-200×200.jpg.

is this how WordPress operates normally — automatically adding characters to image links? Or was it they way the users were importing the photos?

Either way I’d love to find a solution. Find & Replace is not going to cut it obviously, because of the thousands of random sizes (all images were not identical sizes and were cropped proportionally.)

This is the final code that works…

if ( has_term( 'custom-taxonomy-term', 'custom-taxonomy' )) {
get_header('header-custom');
} else {
get_header();
}

Oh my god, yes! Awesome, that worked. Thank you!

I’ve created a new single-custom.php to handle the Custom Post Types so it’s all good. It shouldn’t interfere with any other templates/posts.

Thanks again!

Installing multiple versions of WordPress on subdomains is not a problem. In fact, it’s how a lot of developers run live test sites.

If you like, you can even use the same database for all installs. Just make sure you change the table prefix to something unique – do not leave it as the default, which is wp_, but rather use something unique like wpabc_. That way there won’t be any chance of conflicting tables.

In your case however, I would recommend using a new database, especially if you don’t plan on using anything from the old site. That way you won’t have any redundant content saved in the database taking up space.

It can be a little tricky when it comes time to move the site to the top level. However, I personally use BackupBuddy from iThemes as it makes moving WP sites a breeze.

This may have helped you – it’s from the Twenty thirteen functions.php file …

/*
 * Set up the content width value based on the theme's design.
 *
 * @see twentythirteen_content_width() for template-specific adjustments.
 */
if ( ! isset( $content_width ) )
	$content_width = 604;

Thanks to Binary Moon for the heads-up! Ben suggests it only effects images uploaded through the Uploader and embed shortcodes, but it’s probably good practice to set it correctly for child theme templates anyway.
Also, it’s pluggable (as per the Codex suggestions when developing themes), so that means you can simply insert the same code in your own child theme functions.php, change the value, and it will override the default value.

Ok, so I figured it out. Just in case anyone needs the code, simply add this to your functions.php, changing ‘custom_taxonomy_name’ as necessary …

function custom_post_type_listings ( $query ) {
	if ( is_admin() || ! $query->is_main_query() )
    	return;

	if ( is_tax('custom_taxonomy_name') ) {
		$query->set( 'posts_per_page', -1 );
		$query->set( 'orderby', 'title' );
		$query->set( 'order', 'ASC' );
		return;
	}
}
add_action( 'pre_get_posts', 'custom_post_type_listings', 1 );

Just wondering if anyone has any quick advice on where to start problem solving this one? Thanks!

I had exactly the same issue and simply changed the values in function.js to 200 : 220 with a gutterWidth of 10.

if ( $.isFunction( $.fn.masonry ) ) {
		var columnWidth = body.is( '.sidebar' ) ? 200 : 220;

		$( '#secondary .widget-area' ).masonry( {
			itemSelector: '.widget',
			columnWidth: columnWidth,
			gutterWidth: <strong>10</strong>,
			isRTL: body.is( '.rtl' )
		} );
	}

This worked for a content width of 980px.
Not an ideal solution as it will probably be reverted after a Twenty Thirteen update, so it’s probably best to somehow deregister the parent JS and enqueue a new one.
See this tutorial: https://wp.tutsplus.com/tutorials/creative-coding/how-to-modify-the-parent-theme-behavior-within-the-child-theme/