sluggo

Found it! stevejohnson, if you’re still listening, this is what you have to do:

Open wp-includes/js/tinymce/tiny_mce_config.php in an editor and go to the line that starts “$mce_buttons = apply_filters(‘mce_buttons'”. You’ll see the list of buttons on the toolbar in there. After “‘wp_help’,” add “‘code’,”. Reload and you should see the button.

Special bonus: I found a bug in there which is unrelated to this but still interesting. The button “wp_adv” toggles the “advanced” toolbar. The contents of the advanced tool bar are kept in between “wp_adv_start” and “wp_adv_end”. But in that file, “wp_adv” is *after* “wp_adv_start”. This means that the button to display the advanced toolbar is *on* the advanced toolbar! So there’s no way to turn it on, apparently. If you swap “wp_adv” and “wp_adv_start” in that same file, you’ll discover a whole bunch of new neat stuff.

Yes! What happened to the HTML button? I use that with almost every post. This is a serious loss of functionality. How can it be restored?

You can’t really put tabs in web pages; browsers will condense them down to one space, like they do with multiple spaces. If you need to include them, you have to include them in pre tags; but I think WP’s editor will still throw them out in that case.

I have a feeling you’re thinking about web pages the wrong way if you’re trying to insert tabs. What are you trying to accomplish? There’s probably a better way.

Thanks!

Never mind, forgot about post tags. Found the answer here.

How large is your upload? If it’s greater than 2MB, you need to increase the value of upload_max_filesize in your php.ini. And if it’s greater than 8MB, you also need to increase the value of post_max_size.

You also have to increase the size of post_max_size in php.ini.

This isn’t relevant to your main problem, but I wanted to point out that that <div> is unnecessary. You can just do this:

<h3 id="someword">Some word</h3>

Any body tag can take an id.

I don’t think this is a Windows error. I’m running on FreeBSD and seeing the same behavior. As a workaround, I changed the ModRewrite line so that it only sends real links (rather than everything) to index.php, so at least people get Apache’s 404… but I’d much rather have WordPress handle the errors so that it can match the theme. This seems like a bug to me.