[Developer's note: For other plugin developers looking for the solution, you need to make sure there are no files in the root directory of the zip file!]

Issue
This error is caused when you use the WordPress upload feature to install a plugin from the Add New plugin page. Unfortunately, this feature cannot handle a zip file that contains folders so it places the files in a subdirectory where WordPress cannot see the plugin header files to activate the plugin.

For example, the autoblogged.php file would be installed in a directory like this:
/wp-content/plugins/2.xx/autoblogged/autoblogged.php

Background
Since WordPress v2.8, there has been a feature to upload and install new plugins directly through the WordPress admin back-end by browsing for them on your local hard drive. WordPress will upload the zip file, extract it to the /plugins directory, and then try to activate the plugin. The problem is that since the AutoBlogged zip file contains the plugin files in a subdirectory, WordPress will create one directory with the name of the zip file and then the /autoblogged directory under that. Since that places the plugin file two directories deep, WordPress cannot find it and reports an invalid header. This same problem occurs with any plugin that uses subdirectories in the zip file, and there are many that do.

Solution
To correctly install AutoBlogged, you should use FTP or your hosting control panel’s file manager to upload the autoblogged directory directly under the wp-content/plugins directory. In other words, the full path to autoblogged.php should be:
/wp-content/plugins/autoblogged/autoblogged.php

If you have already used the WordPress upload feature to upload the plugin, you can fix it by moving the /autoblogged directory directly under the /wp-content/plugins directory.

Comments
Obviously, we could fix this ourselves by placing all the files in the zip file without any subfolders, which we tried for a short time, but then found that many users were confused about where to put the files when uploading them via ftp. By zipping them into the autoblogged directory it is pretty intuitive to upload that entire /autoblogged directory to the plugins directory in WordPress. Another benefit is that it allows us to place other files in our zip file that don’t need to be uploaded to your server.

We personally consider this to be a WordPress issue. One solution would be for them to recognize that zip files might actually contain subdirectories and unzip the files accordingly. Another solution would be to allow WordPress to activate plugins that are one or more directories deep under the /plugins directory. And of course, they really should fix their error message saying that our plugin header is invalid when in fact they just can’t find the file that they uploaded to the wrong place.

See Also:

http://wordpress.org/support/topic/280262

http://ijstyles.com/wordpress-2-8-issues-how-to-solve-plugin-does-not-have-a-valid-header/

http://wordpress.org/search/%22The+plugin+does+not+have+a+valid+header%22?forums=1

We are considering versions of AutoBlogged that work with other platforms, so if you have a specific request, please comment below.

By default WordPress will send a notification to any external blog posts referenced in your site, which show up as comments to the original post.  Sometimes you may not want to notify other blogs when you autoblog their posts.

Solution

To disable pingbacks and trackbacks, go to the Discussion settings in WordPress and uncheck the option Attempt to notify any blogs linked to from the article (slows down posting.)

To minimize the impact of compatibility issues with WordPress upgrades, we recommend the following:

• Create a test site to try out new releases before deploying them to your production site.
• Create full backups (all files and your database) before performing any upgrades.
• Check our Known Issues page before upgrading.

More Information

• Upgrading WordPress
• Upgrading WordPress Extended
• Common WordPress Installation Problems
• WordPress Release Archive

For information on any known issues with the latest WordPress releases, see http://autoblogged.com/support/kb/known-issues/

This occurs with hosting companies (such as Earthlink) that do not allow error messages to be shown but we also often see it with dedicated server configurations that are by default configured to a hardened state. It is definitely a good practice to suppress PHP error messages on a production server because they can reveal sensitive information about your server configuration. However, during development, testing, and deployment those error messages are necessary to identify problems. Before we can troubleshoot the issue you are having, we first need to be able to see what error message the server is reporting.

First Steps

The first thing you should do if you see this problem is to check your web root directory and the autoblogged directory for an error_log file. Some hosts are configured to suppress output errors but they will still log them to a file which you can review. However, some hosting companies also turn off error logging because these files can sometimes grow quite large (we once had a 6gb error_log file on a test server).

If you don’t have an error_log file, you might also check your hosting control panel. Some hosting companies only allow you to view the error logs through your some viewer on the hosting control panel. Finally, we occasionally–although rare–see hosting companies that output error messages as comments in the html, so it doesn’t hurt to view the source of the page where it is hanging.

PHP.INI File

If none of the above gets you anywhere, there are several ways you can enable error messages on your server. The best way is to edit the php.ini file if you have access to that. In the php.ini file there are a number of error-related configuration options (see http://www.php.net/manual/en/errorfunc.configuration.php) but these are the most important options:

• display_errors – This determines if errors are sent to the browser or not. This is the most convenient way to view error messages but this really should not be enabled on a production server.
• log_errors – This option enables or disables logging error messages to a file.
• error_log – This option determines the location and name of your error log files.

You can view the values of any of these settings in WordPress by going to the AutoBlogged support page and clicking on Show PHPInfo…

Here is a sample php.ini configuration that works well for debugging purposes:

display_errors = ‘on’
log_errors = ‘on’
error_log = ‘error_log’

The .htaccess File

If you are using a shared host or do not have access to the php.ini file, you may be able to enable error reporting through the .htaccess file. Here is a sample .htaccess configuration that will enable error reporting:

php_flag display_errors on
php_flag log_errors on
php_value error_log error_log

Note that if your server runs PHP in CGI mode rather than as an Apache module you will not be able to change these settings via the .htaccess file and you will get an Internal Server Error message. Furthermore, some shared hosting environments are configured to not allow users to set these values via the .htaccess file.

Here is a good article on controlling error handling via the .htaccess file: http://perishablepress.com/press/2008/01/14/advanced-php-error-hand…

Other Solutions

If you don’t have access to the PHP.ini file and your hosting company does not allow you to enable error messages via .htaccess, you might also want to check your hosting control panel to see if there is an option to enable error logging from there. If you still don’t have error messages at this point we actually recommend moving to a different hosting company. Our software works great with most hosting companies but if there is an error on yours and this company won’t let you see that error, we definitely suggest moving your site elsewhere.

Having said that, all hope is not lost. In WordPress on the AutoBlogged support page you can enable the options Enable logging to file when processing feeds and Show verbose debug info. This will create a file named _debug.log in the autoblogged directory that might provide clues as to what is causing the error or at least where in the process the error is occuring.

You can also open the wp_config.php file in the WordPress root directory and uncomment (remove the // at the beginning) or create this line:

define(‘WP_DEBUG’,true);

This will try to enable error messages via PHP, but may also produce a large of error messages and warnings that you can probably ignore. If you still are having problems, send us a support ticket to see if we can help. In extreme situations we may need to provide you with a unique autoblogged build where we add specific code to troubleshoot your problem.

Remember that the goal here is to find the error message or some other clue that will tell us what is causing AutoBlogged to halt feed processing. There are an infinite number of server configurations, platforms, software versions, and environment settings that can affect AutoBlogged but we can’t help much until we know where the process fails.

And finally, don’t forget to turn error messages off again (at least those displayed on the browser) when you are finished. You don’t want to be handing out information that might help someone break into your web site.

In one of our sample sites AdvertiserGuide.us, we are using the very cool Gazette Edition theme by WooThemes. The design of this theme relies heavily on the cross-fading featured images at the top, as well as thumbnails for each article, but most of the articles we were using simply didn’t have any associated images.

To fix this, we went to sites like istockphoto.com and www.sxc.hu to download both free and purchased stock photos that seemed relevant to the theme, yet generic enough to use with any article. We gathered 50 good photos, resized them all to the same size, and then renamed them 1.jpg through 50.jpg and uploaded them to our site.

Next, for each feed that doesn’t produce good images we added a custom field in AutoBlogged called Image. Note that the Gazette Edition theme specifically looks for images in this custom field. We set the value of the field as follows:

http://advertiserguide.us/img/[1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|
24|25|26|27|28|29|30|31|32|33|34|35|35|37|38|39|40|41|42|43|44|45|46|47|48|49|50].jpg

Below is a screen shot of that setting:

You can use post template syntax in your custom field values and bracketed values separated by pipes indicates to AutoBlogged to pick a random value from the list. In other words, AutoBlogged will randomly pick a number between 1 and 50 to create Image field values like these:

http://advertiserguides.us/img/13.jpg

http://advertiserguides.us/img/8.jpg

http://advertiserguides.us/img/41.jpg

http://advertiserguides.us/img/19.jpg

With just 50 images we do sometimes get two or more articles with the same picture on the front page but for the most part that isn’t that big of a deal and it greatly improves the look and professionalism of the site.