Austin Matzko

Can you check the web server logs, then, and see if there are any error messages?

19MB is pretty big for an attachment. I wouldn’t be surprised if your host’s email server was rejecting them. You should contact your host and ask if there’s a maximum allowed size in sent emails.

• Make PHP 5.2 the minimum required version.
• Decorate all kinds of objects–posts, terms, etc.–with similar methods and properties, so they can all be Looped over.
• Make the admin more easily themable.
• Reduce the admin’s dependency on third-party JS, when it’s used globally throughout the admin (as opposed to discrete components like TinyMCE)
• Establish a consistent API for front-end and admin Ajax interactions.
• Build a better API for plugins to extend the nav menus.
• Make the uploader more versatile and flexible.
• Offer an API for sending messages to users (error messages, upgrade nags, etc., more robust than the transient hack).
• User capability handling that doesn’t rely on serialized data.

How big are the uncompressed backup files? If they’re huge it might be that your server times out before it can complete the compression.

I’m not familiar with the WP Mail Queue plugin, but I wouldn’t be surprised if it caused the backup emails not to be sent.

What version of the WP-DB-Backup plugin are you using, and what version of WordPress are you trying to use it on?

What is the error message?

What we can’t see from your code is where and when you’re attaching the callbacks.

When do you add the leprechaun_add_rewrite_rules callback? How is leprechaun_query used?

Probably a plugin is including this file twice and thereby causing the error. Try these instructions to disable all of your plugins, and then you can re-activate them one-by-one to discover the culprit.

The access depends on what your host allows.

Note that those instructions just have you rename the directory, not delete it, so it’s ok if you don’t have a copy on your personal computer.

You likely have an errant plugin or theme that is calling the function add_rewrite_tag() at the wrong point.

Here are some suggestions on how to disable plugins when you can’t access the admin.

Once you’ve done that, you can re-activate the plugins one-by-one until you discover the culprit throwing this error.

You probably have a plugin that is filtering out headers via the 'nocache_headers' filter. Try deactivating plugins one-by-one until the error goes away; then you’ll know which is the culprit.

It sounds like you might have the SUNRISE constant defined in your wp-config.php file, even thought the wp-content/sunrise.php file doesn’t exist.

Try commenting out the line that defines SUNRISE.

It looks like whoever wrote your code anticipated the 3.0 menus and calls wp_nav_menu, a function new to WP 3.0, if that function exists.

You can keep it from doing that (and thereby presumably use your previous system) by changing

if ( function_exists('wp_nav_menu') ) {
		wp_nav_menu( array( 'sort_column' => 'menu_order', 'menu_class' => 'sf-menu menu clearfix') );
	} elseif ( function_exists('pixopoint_menu') ) {
		pixopoint_menu();

to

/*
	if ( function_exists('wp_nav_menu') ) {
		wp_nav_menu( array( 'sort_column' => 'menu_order', 'menu_class' => 'sf-menu menu clearfix') );
	} elseif ( function_exists('pixopoint_menu') ) {
*/
	if ( function_exists('pixopoint_menu') ) {
		pixopoint_menu();

(I’m commenting out the code that calls wp_nav_menu)

If you change $post->ID to get_the_ID() does that make a difference? Like so:

<?php $gallery = get_post_meta(get_the_ID(), 'Thumbnail', $single = true); ?>
<img src="<?php echo $gallery; ?>" alt="" />

query_posts(
   array(
      'post_type' => array(
         'first_custom_type',
         'second_custom_type',
      ),
      'posts_per_page' => 10,
      'post_status' => 'publish',
   )
);

while ( have_posts() ) :
   the_post();

// etc.

EDIT: Whoops, missed your reply before mine.