You do not need to use a server-side HTML Parser for this, that would be completely overkill imo. The following is an example that obviously could be broken by certain HTML constructs, but for most mark-up it would not have a problem what-so-ever - and will be much more optimal than a server-side HTML parser.
$html = '
<h2>My text one</h2>
<h2>My text two</h2>
text ...
<h2>My text three</h2>
';
preg_match_all
/// the following preg match will find all <h2> mark-up, even if
/// the content of the h2 splits over new lines - due to the `s` switch
/// It is a non-greedy match too - thanks to the `.+?` so it shouldn't
/// have problems with spanning over more than one h2 tag. It will only
/// really break down if you have a h2 as a descendant of a h2 - which
/// would be illegal html - or if you have a `>` in one of your h2's
/// attributes i.e. <h2 title="this>will break">Text</h2> which again
/// is illegal as they should be encoded.
preg_match_all(
'#(<)h2([^>]*>.+?</)h2(>)#is',
$html,
$matches,
PREG_OFFSET_CAPTURE|PREG_SET_ORDER
);
replace and rebuild
/// Because you wanted to only replace the 2nd item use the following.
/// You could however make this code as general or as specific as you wanted.
/// The following works because the surrounding content for the found
/// $matches was stored using the grouping brackets in the regular
/// expression. This means you could easily change the regexp, and the
/// following code would still work.
/// to get a better understanding of what is going on it would be best
/// to `echo '<xmp>';print_r( $matches );echo '/<xmp>';`
if ( isset($matches[1][0]) ) {
$html = substr( $html, 0, $matches[1][0][1] ) .
$matches[1][1][0] . 'h3' .
$matches[1][2][0] . 'h3' .
$matches[1][3][0] .
substr( $html, $matches[1][0][1] + strlen($matches[1][0][0]) );
}
I have no idea why many are stating to use client-side JavaScript for this change, PHP stands for PHP: Hypertext Preprocessor
it is designed to preprocess hypertext. The OP has only ever mentioned PHP functions and tagged this post with PHP so there is nothing leading towards client-side.
True whilst client-side can and should be used where possible to alleviate processing from the server-side, this should not be recommended for core structural tags like headings - which will be relied upon by screen readers and search engine bots. At best client-side JavaScript should be used to enhance a user's experience. If you use it to critically augment your site's capabilties you had better be sure your enitre userbase supports it.
Now however, if any of you had mentioned Node.js and JSDOM I would have quite happily agreed.