So my question is this… What is really broken? WordPress or the plugin? Does the user really know for sure? Could it be another plugin that is causing the problem? Is it the browser? Does this really give an accurate accounting of a plugin’s compatibility? I honestly don’t think so.

Do I think that if a plugin is working for someone and not working for someone else that the person that the plugin IS working for will even bother to make a special visit the site and click the Working button? – NO, I don’t. It’s like the plugin comment area; if something isn’t working someone will comment. If it is working – they never comment. No one has ever visited my plugin page hosted on wordpress.org to make a comment that the plugin was working.

To truly reflect an honest and fair compatibility value, every plugin user experience would have to be recorded. I personally don’t think it’s going to happen. As a result, most of the information regarding the compatibility of a plugin with any specific WordPress version will be distorted because more people tend to visit the hosting site looking for solutions than those that don’t need them – for that reason I think more people will click the Broken button than those caring enough to click the Working button. I believe that people will shy away from installing and trying a plugin because of this; I find the entire thing irritating.

Matt and company should stop making changes to WordPress that give people the impression that their plugins will break and their sites will stop working. Arbitrarily adding a Plugin Compatibility box to the hosting site under the guise that it somehow measures Plugin Compatibility with WordPress is a joke.

• Temporarily change the permissions on the NAVT directory to 777.
• Reactivate the NAVT plugin.
• Change the NAVT directory permissions to 755

As of version 1.0.29, NAVT needs to create a file in it’s own installation directory – the file is only created once. If it can’t create the file then it will not display the NAVT List menu item.

You may find that the Word Press automatic plugin upgrade routine removes all files from the previous version and you may have to temporarily change the permissions on the NAVT directory after upgrading. Make sure you change the permissions back to 755 after activating the plugin.

Several people have offered solutions for the PHP include statement that is used to include the wp-config.php file and some of the code has been published in comments on this site. I didn’t make change to the plugin until recently… I just haven’t had the time. In version 1.0.28, I decided that instead of attempting to include the wp-config.php using a relative path from the location of the NAVT installtion directory – I would simply create a file on the fly that contained the name of the Word Press installation directory. NAVT knows the name of the installation directory but the ajax code in the plugin does not. The new file is called wp-root.php and it is created/located in the directory where NAVT is installed. The file is created only once and only when NAVT realizes it doesn’t exist. The ajax portion of NAVT includes the wp-root.php file to obtain the name of the WordPress installation directory.

Version 1.0.29

In version 1.0.29, I decided to add a code to ensure the NAVT installation directory had writable permissions and then change the permissions back to 0755 after the file was created. If the file cannot be created for some reason, the plugin will not work. If you do not see the NAVT Lists Tool item in your WordPress dashboard try changing the NAVT installation directory permissions to 0777 using your favorite FTP program or your web site dashboard application. Go to your web site using your browser then using your FTP program or web site file manager, look for the wp-root.php file in the NAVT installation directory. If it exists then change the directory permissions to 0755. If it doesn’t exist then the directory did not have the correct permission settings – try it again.

Now that the JQuery Team has released a stable version of their User Interface library I’m seriously considering rewriting the NAVT interface (once again). There are a few things about the current NAVT interface I’ve never been completely happy about. In addition, I think the code base is becoming a bit bloated – maybe its just time for a rewrite.