Mark Tuttle

I see. That is not my experience, but I understand your explanation. It would ordinarily be a very minor issue, except that I import large sites subtree by subtree over extended periods of time as I and other volunteers hack the archaic html to meet modern standards before importing. Perhaps the most elegant solution is to insert a line into the documentation (even into the configuration page?) mentioning this distinction so the next guy like me (if there ever is one) is not surprised.

Looking at method get_post($path,$placeholder) in class HTML_Import in html-importer.php

// if we're doing hierarchicals and this is an index file of a
// subdirectory, instead of importing this as a separate page, update
// the content of the placeholder page we created for the directory
if (is_post_type_hierarchical($options['type']) &&
    dirname($path) != $options['root_directory'] &&
    basename($path) == $options['index_file']) {
	$post_id = array_search(dirname($path), $this->filearr);
	if ($post_id !== 0)
		$updatepost = true;
}

if ($updatepost) {
	$my_post['ID'] = $post_id;
	wp_update_post( $my_post );
}
else // insert new post
	$post_id = wp_insert_post($my_post);

it seems that files in the root directory are not made children of the index file in the root directory, because no placeholder post gets made for the root directory, so there is no existing post to update with wp_update_post. Am I reading this correctly? So by design the hierarchy in for root directory must be constructed manually?

To strip the cdata, script, and style blocks, I think it is sufficient to add the functions

function allowed_tag($tag,$allowedtags=NULL) {
  return
    !is_null($allowedtags) &&
    stripos($allowedtags,$tag) !== false;
}

function strip_cdata_block($string,$allowedtags=NULL) {
  if ($this->allowed_tag('<cdata>',$allowedtags)) return $string;

  $delim = "@";
  $cdata_start = preg_quote('<![CDATA[',$delim);
  $cdata_end = preg_quote(']]>',$delim);
  $block = "$cdata_start.*?$cdata_end";

  return preg_replace("${delim}$block${delim}s","",$string);
}

function strip_tag_block($tag,$string,$allowedtags=NULL) {
  if ($this->allowed_tag($tag,$allowedtags)) return $string;
  if (!preg_match(":<(.*?)>:",$tag,$match)) return $string;

  $delim = "@";
  $tag_str = $match[1];
  $tag_start = "<$tag_str(?:>|\\s[^>]*>)";
  $tag_end   = "</$tag_str(?:>|\\s[^>]*>)";
  $block = "$tag_start.*?$tag_end";

  return preg_replace("${delim}$block${delim}is","",$string);
}

function strip_comment_block($string) {
  $delim = "@";
  $comment_start = preg_quote('<!--',$delim);
  $comment_end = preg_quote('-->',$delim);
  $block = "$comment_start.*?$comment_end";

  return preg_replace("${delim}$block${delim}s","",$string);
}

and add the following calls before strip_tags at the head of clean_html:

$string = $this->strip_cdata_block($string,$allowtags);
$string = $this->strip_tag_block('<script>',$string,$allowtags);
$string = $this->strip_tag_block('<style>',$string,$allowtags);
$string = $this->strip_comment_block($string);

What I had missed (forgotten) was that the installation of the TinyMCE Advanced plugin adds a configuration page to the dashboard. Go to Dashboard -> Settings -> TinyMCE Advanced. There I have the ability to drag and drop the new editing buttons I want into the rows of editing buttons in the visual editor. I saved that, and the buttons now appear in the visual editor. I had thought they would appear in the visual editor by default after installation. I had forgotten that I have to choose the buttons I want.