Jo Landers

I am marking this as resolved, b/c the person who originally reported the issue has not gotten back to me, nobody else has reported this problem, and I am unable to replicate it. Based on all of that, I don’t think the reported issue has anything to do with this plugin.

No idea why; the plugin code is pretty straight-forward and uses the built-in WP hooks and functions as much as possible.

You’re saying this is an intermittent error, so I probably can’t reproduce it… What happens if all your other plugins are disabled, you are using the built-in theme (twenty-twelve? twenty-thirteen?) and this is the only plugin running?

Please enable WP_DEBUG and error messages by adding the following to your wp-config file:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );

Then deactivate all your other plugins and switch to a wp theme (twenty-twelve or twenty-thirteen) so we can also check if it’s an issue with your theme.

If you don’t see any errors with that set-up, it’s not a problem with the plugin itself, but may be something that only happens in combination with your theme or other plugins. If that’s the case, the next step is to reactivate your theme and check again, then your plugins one-by-one, until you can identify what combination triggers the error.

When you see the error again, stop, and send me the exact error message including error code that your server is throwing, what operating system your server uses, what error messages, if any, WP_DEBUG is showing, your WP version, a complete list of active plugins, and the last thing you activated before you started seeing the error again.

Hi podpirate,

Thanks for the heads up, sorry for the late response (WP does NOT email developers when someone posts a question here).

I don’t say this plugin is compatible with WPMU (it’s a lot of work for me to setup and maintain a WPMU sandbox just to test plugins I’m giving away, so I stopped doing it). However, AUTH_COOKIE is defined at /wp-settings.php and your error is being generated in wp-includes/pluggable, so it seems unlikely it has anything specifically to do with my plugin.

It almost sounds like files are not loading in the correct order, so AUTH_COOKIE isn’t being defined before something else that needs it calls it. It could also be something to do with a combination of plugins (unless you tell me this was the ONLY active plugin at the time), or some other issue I can not even guess… Just for fun, you could try adding a line of code at the top of my main plugin file that says if ( !defined('AUTH_COOKIE') ) require_once('/www/vhosts/wordpress-stable-mu.local/wp-settings.php'); and see if that solves the issue for you (if it does, please let me know).

If/when I have paying clients that are using WPMU (and therefore other reasons to set up and maintain a WPMU sandbox environment) I may revisit this issue, but for now I’m going to mark it resolved, since the plugin isn’t currently tested for use in a WPMU environment and so far (fingers crossed) you are the only person who has reported this issue.

– jo

No, though it would be pretty easy to modify a copy of the code to set it up as a 2nd plugin which would create a 2nd widget. At a minimum, you would need to change the text domain, plugin unique id and the options id the plugin uses to save its preferences. There might be some other settings you would need to change, as well, to make sure it didn’t ‘collide’ with the first one, and you would probably want to change the description so you could tell the different ones apart when you were looking at your plugins list.

One more note regarding MAMP and MAMP Pro (or any development server) – Make sure you test your .htaccess file on the ‘real’ server before going live (or put it in a temporary folder within your live site and check out specific settings where the public won’t see them). For example, I use php in my css files. On my development server, using MAMP Pro, I need this line in my .htaccess file:
AddHandler application/x-httpd-php .css

But the ‘live’ server doesn’t handle php in the stylesheets correctly unless I change it to:
AddHandler application/x-httpd-php5 .css

Even though both MAMP Pro and my live server are both using the same version of php.

Re: MAMP vs MAMP Pro – the big difference is that it is MUCH easier to set up multiple virtual hosts and configure each to match the server on the live site (and the latest version provides some SSL support, though you do have to set up a non-ssl and an ssl-enabled host for the same virtual host to get it to really work).

This lets you do things like have multiple client sites, each in a separate folder (and with their own database), using the exact same structure the live site will use, and test them using something like https://www.myseite1.dev, https://mysite2.dev, etc. (I set up my local sites using the exact url of the live site, but replace the .com [or whatever] portion with .dev), instead of accessing them using ‘localhost/mysite’

If you work on multiple client sites, it’s much easier going this route, since you don’t have to change your MAMP settings everytime you switch client development sites, and all the url’s and ‘include’ files work the same as the live site will.

It’s possible to hack MAMP (not PRO) to do something similar by editing the httpd.conf file each time you add/remove a new development site, but MAMP PRO lets you do this from the ‘Hosts’ interface, which is much easier (after spending lots of time doing the hacking, I decided to spend the $59 for the upgrade)

Hi Cathy, I’m the author. As the description states, this isn’t so much a plugin (with admin interface and ability to save to the WP database) as a few lines of code to call a function to display content on the dashboard that has been hard-coded into the file (though you could change that very easily to use content from an include file instead if you wanted…)
I have written a full featured version (several hundred lines of code instead of just a few) which includes an admin interface and saves the content to the WP database, but I have to test under 3.2 before releasing. Check back in a few weeks.

Looking at the code, it appears robots-meta.php expects a field in wp_posts named robotsmeta (see line 59 of the code: $robotsmeta = $post->robotsmeta;).

I added the field as a varchar length 32, and it now seems to work. Not thrilled about modifying the database (would have preferred the robots-meta.php file inserted into wp_postsmeta instead), but this did not require any changes to the plug-in code. The older versions of the plug-in probably took care of adding that field for you when you installed it…

Looking at the code, it appears robots-meta.php expects a field in wp_posts named robotsmeta (see line 59 of the code: $robotsmeta = $post->robotsmeta;).

I added the field as a varchar length 32, and it now seems to work. Not thrilled about modifying the database (would have preferred the robots-meta.php file inserted into wp_postsmeta instead), but this did not require any changes to the plug-in code.