Helen Hou-Sandi

As an aside about searching, since it is currently driven by Google, it may help to include more:recent4 as a keyword, which will sort heavily by date. You can also try recent1, recent2, or recent3 to see how those work out. No guarantees, but I find specifying that to be useful from time to time. Not making excuses, either, although I wouldn’t want to be tasked with writing a search engine and don’t really wish it on anybody else, either.

I do not understand why the people who make huge bucks off wp don’t invest in core development.

As Jane mentioned, some of us do, actually. But it could (and should) be more. https://ma.tt/2012/05/wp-businesses-and-contributions/

There’s a ticket for better UI for page on front, which I think this would fall under. https://core.trac.www.ads-software.com/ticket/16379

I don’t know where you are implementing this form, but this sounds like a basic PHP contact form. You build an HTML form, process the data in PHP, build a $message (which is just a string), and mail it. If you don’t know how to do that and do it securely, you really should reconsider using a plugin.

I don’t understand what you’re looking to do here – why are you looking at the pluggable wp_mail() function? If you’re collecting a phone number, you need a form that a user enters it in, and then you need to put the phone number into the text of the $message that you send. wp_mail(), which is essentially just a wrapper for PHP mail(), doesn’t have a phone number argument.

It’s not a sick joke, and the 404 thing had nothing to do with it. It’s more like discovering the flight simulator in Microsoft Word 97. More about Easter eggs in software and media: https://en.wikipedia.org/wiki/Easter_egg_%28media%29

Actually, this is what we call an Easter egg, something silly hidden away that only happens if you poke around and do something weird, like trying to compare a post revision to itself. At least, the self-destruct thing you’re describing sounds like the Easter egg.

That, however, does not explain why you are getting a page not found error with your host, but since it’s your host’s 404 and not the WordPress 404, I would bet that you need to go Settings -> Permalinks and hit save. If this doesn’t fix it, your host may not support pretty permalinks.

In pre-3.3, the plugin does alter the submenu colors – you can look at blue-admin-bar-older.css to see how it’s done there. There are no changes to submenus for 3.3, which are now light blue on hover, but you can use Firebug to figure out which CSS selectors to use, or look at wp-includes/css/admin-bar.dev.css to see everything that core uses for CSS.

RC2 is awful late, so no ?? It’s also not really an alpha/beta thing, since it’s been happening since before 3.3. Here’s a ticket on the issue (delete from menu happens with the item’s actual deletion, not trashing), might be more related ones out there: https://core.trac.www.ads-software.com/ticket/19038

Honestly, I personally don’t really find this unexpected; I would probably be annoyed if my menu items disappeared just because I accidentally trashed something. I just tested and the menu item is removed when you permanently delete it. Unless this is happening for you differently?

I think it’s been like this since nav menus were added, or at least I remember running into it a couple of times. I just tried it in 3.2.1 and it does the same thing – the menu item remains but it goes to a 404 because the page is in the trash.

Ticket closed as fixed for 3.3 ??

I’ve pushed an update that works if you have BP_USE_WP_ADMIN_BAR set to true. I’ll keep looking at the translucent gray one that BuddyPress uses by default – not quite sure where to go with it yet.

Oh, that’s a good idea. I don’t use BuddyPress very regularly so I hadn’t thought about it. I will put it on my to-do list!

A lot of the responsive stuff was reverted due to not testing well: https://core.trac.www.ads-software.com/ticket/18863 . It will be revisited for 3.4, hopefully including mobile. That said, mobile devices were never a goal for 3.3.

TinyMCE needs a min-width so that the toolbar buttons don’t escape. They don’t wrap, so even if there weren’t the min-width or you overrode it, they will overflow and look bad anyway. This was how it was before 3.3. It’s all CSS, so I would think that you could override it if you really needed to and remove/move some buttons while you’re at it. I personally haven’t tried using wp_editor() on the front-end just yet, and don’t know how well TinyMCE works on all mobile devices, so I can’t say anything definitive in that arena.

I’d say to hold off on a ticket for now, as it is something known and there’s no chance of any enhancements making it into 3.3. Since previous versions had collision problems with TinyMCE toolbars anyway (and will continue to if there are added buttons), it’s not a new bug.

What did you do before that got rid of the 500 error?

This may not be the cause of the problem, but you might try:

function pagination_april( $query ) {
    // in 3.3, use is_main_query() instead
    global $wp_the_query;
    if ( $query->m == 200504 && $query === $wp_the_query ) {
        $query->set( 'posts_per_page', 1 );
    }
 }

add_action( 'pre_get_posts', 'pagination_april' );

You shouldn’t need to set $query to a new WP_Query, but rather just do $query->set( 'posts_per_page', 1 );.