I am making a simple HTML form in a plugin I am writing. I was thinking of using echo for all output, but I can't seem to control the formatting of the HTML outputted (for debugging, neat looking HTML, NOT talking about how the page looks to the user).

If I have an echo like:

  echo '<sometag>

It generates HTML like:


So I changed the echo statement to:

 echo '<sometag>';
 echo '<otherTag>';

and got HTML like:


Lastly I changed the echo statement to:

 echo "<sometag>\n<otherTag>"

But then WordPress turns the \n into a <br>!

Is the only way to have nicely formatted HTML to output the text with HTML outside of php?

Or is there a way to get echo (or print) just output what I send it?

OK - I found some code that points to a 'why'. It appears to me that the makers of this theme are using wptexturize and wpautop on all shortcodes, likely assuming that all shortcodes are their OWN (button, ui widget) shortcodes, and having wptexturize work on the shortcodes helps with some theme settings. I can think of perhaps better ways to do this...

I am writing a plugin for this theme, and will not be editing the theme, so I think I will tell them to use the [raw] shortcode route.

Theme code from /themename/functions/shortcodes/setup.php

 // Remove WordPress automatic formatting
 function theme_formatter ($content) {
     $new_content = '';
     $pattern_full = '{(\[raw\].*?\[/raw\])}is';
     $pattern_contents = '{\[raw\](.*?)\[/raw\]}is';
     $pieces = preg_split ($pattern_full, $content, -1, PREG_SPLIT_DELIM_CAPTURE);

     foreach ($pieces as $piece) {
        if (preg_match ($pattern_contents, $piece, $matches)) {
            $new_content .= $matches[1];
         else {
        $new_content .= wptexturize (wpautop ($piece));

     return $new_content;

 remove_filter ('the_content', 'wpautop');
 remove_filter ('the_content', 'wptexturize');

 add_filter ('the_content', 'theme_formatter', 99);

 // Enable shortdoces in sidebar default Text widget
 add_filter ('widget_text', 'do_shortcode');
  • 2
    PHP/HTML questions should be asked on StackOverflow. Feb 21, 2013 at 18:28
  • I think that this is a wordpress problem, in that I just figured out that things are different if I switch themes. Feb 21, 2013 at 18:38
  • That doesn't make it a WordPress problem... Feb 21, 2013 at 18:39
  • So this is my first post here, I have about hundreds on stackexchange, and would be happy to move it, but this problem will only happen in wordpress installs of some themes. Feb 21, 2013 at 18:44
  • 1
    Can you add to your question the specific, problematic code from the Theme? Feb 21, 2013 at 18:48

1 Answer 1


If this is plugin code there is NO REASON the theme would make a difference. My guess is it's a server issue (outputting of /n) or a WordPress function that changes the /n into <br>

I would check wpautop() as I find that sometimes it's this functions fault. See this post on the WordPress.org forum for more.

  • 1
    That should be true - unless the Theme is doing something it shouldn't be, like messing with post-content shortcodes, or doing other manipulation of post content, that would cause the observed breakage. Feb 21, 2013 at 19:23
  • @ChipBennett true true, I sometimes forget that there are bad themes out there :)
    – Brooke.
    Feb 21, 2013 at 19:25
  • 1
    As you can see from the theme code, I think you guys are right! Feb 21, 2013 at 19:29
  • If switching the theme changes the output, then it doesn't seem like a plugin is the logical conclusion.
    – Jake
    Feb 21, 2013 at 19:58
  • The theme makes the changes to code output by a plugin shortcode. Feb 21, 2013 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.