wallyO

Hi Sharon,
I have been playing with Explanatory dictionary for a few days now, with similar problems to yourself, though in my case the problem occurred when I used html p tags, or h3 tags in the explanation text.
The explanation text accepts html, and in my case I actually have a lightbox image gallery in an explanation.
The problem occurs when the html is improperly nested, for example a p tag inside another p tag. WordPress then quite correctly fixes the improper nesting by adding a closing p tag and a new opening p tag.
SOLUTION: I chose to use span tags with a class instead of p tags and h tags inside the explanation text. For example,

<span class="MyHeading">Heading</span>
<span class="MyParagraph">Paragraph text</span>

Then styled these classes in my templates styles.css file to look like headings and paragraphs.

span.MyHeading{ display:block; color:#750909; font-weight:bold; font-size:14px;}
span.MyParagraph{ display:block; margin:0 0 10px 0;}

Hope this helps someone.

This problem occurs with the combination of Genesis framework Version: 1.7.1 and Search bbPress 2.0
The following code placed in the functions.php of Social Eyes Child Theme fixed this problem for me.

////////////////////////////////////////
// The following code is so that Search BBPress can co-operate with Genesis framework.
// The problem occurs because Search BBPress manipulates the_permalink() variable when genesis framework uses
// get_permalink(), in genesis/lib/structure/post.php to build the permalink for the search results

if ( isset($_GET['s']) ) {
	remove_action('genesis_post_title', 'genesis_do_post_title');
	add_filter('genesis_post_title', 'my_genesis_do_post_title');
}

function my_genesis_do_post_title() {
	$title = get_the_title();
	if ( strlen( $title ) == 0 )
		return;
	if ( is_singular() ) {
		$title = sprintf( '<h1 class="entry-title">%s</h1>', apply_filters( 'genesis_post_title_text', $title ) );
	} else {
		?>
		<h2 class="entry-title"><a href="<?php the_permalink(); ?>" title="<?php echo the_title_attribute('echo=0'); ?>" rel="bookmark"><?php echo the_title_attribute('echo=0'); ?></a></h2>
        <?php
	}
}
///////////////////////////////////////////

A number of separate issues that all affect w3 cache preload are being discussed in this thread.
1). Firing of wp-cron.
This can be controlled by hitting wp-cron with an http request from the hosting account’s crontab or by using an external spider application.
*/30 * * * * wget -O - https://domain.com/wp-cron.php > /dev/null 2>&1
will fire wp-cron every 30 minutes whether the site has traffic or not.
This has no liability. If wp-cron has tasks scheduled they will run in the same way as if a website visitor had triggered them. This would have to be setup independently of the w3tc plug-in.
2). Pages missing from cache because garbage collection has deleted them and w3tc is waiting for next cron run to rebuild them.
This could be eliminated if the w3tc plugin first built a path to, then deleted the cached page before its http request to rebuild it. This would have a very small resource liability. The resource liability could be furthur minimised by adding a sleep after each http request.
3). Garbage collection only deletes files whose html expires header lifetime has expired. (which is set up on a different page to cache preload but has a huge effect on it)

And thank you Frederick for your reply.
I look forward to future versions of w3 Total Cache.

I too was having trouble with cache preloading.
I checked the sitemap.xml location, and its well formedness, set the preloading interval to 30 seconds (to make it happen soon), then saved.
I checked the page cache for the next few minutes with an ftp program and no cached pages were created in \wp-content\w3tc\pgcache\
After research of wp_cron I found that it is triggered by any page load (which makes sense, everything needs a trigger).
So I called the home page in a browser.
Sure enough, 10 pages appeared in \wp-content\w3tc\pgcache\.
I imagine that by setting up a cron job in your hosting panel to hit the file, [ABSOLUTE PATH TO WEBROOT]\wp-cron.php, then the pagecache could be populated x number of pages () per cron run even without requiring site visitors to trigger it.

Huge thank you to Frederick for creating such an awesome plugin.
I struggle to think of any feature which would make it better.