TheGarage Tech Blog

I was in a discussion on the LinkedIn WordPress group where I recommended the BDP RSS Aggregator plugin for a user who wanted to do site wide post aggregation on a summary page. The I found out the plugin is no longer available from the original site and was thought to be dead.

Well, it might be dead but Jim Groom reports at the link above that BDP RSS Aggregator still works on WPMu 2.8.4 and I have it working on WPMu 2.9.1.1 so it’s a travesty for others not to be able to use this most excellent piece of work.

I can’t offer any support for the plugin (unless I work for you) nor can I say whether it will work with any future versions of WPMu but nonetheless, here ya go.

Download the BDP RSS aggregator plugin:
bdp-rssaggregator-0-6-3

I never did do a follow-up on the WordPress drill-down admin menus post. A lot of people continue to hit that article so I’ll take the time to give an example of how I easily resolved the issue.

The problem was that after an upgrade to WordPress Mu v 2.8.4a all my dynamically created, drill-down admin pages quit working because they now needed to be registered with WordPress for — completely understandable — security reasons.  As far as I can tell, the only way to register an admin page is through the menu system. Since I don’t want my drill down pages to be on the menu I needed a better way to do it.

One solution suggested was to just use the registered menu page as the callback to handle requests and that is for the most part what I did. The only issue with the solution is that the callback page has to also serve all the content since it can’t request an admin page that is not registered. Using one page to parse all requests and serve the appropriate content will get unwieldy for anything but the simplest of applications and if your application was that simple you wouldn’t be trying to figure out how to add custom drill-down admin menus.

I like modularity and easily managed code so my philosophy is that multiple small files are better than one huge file. I needed a way to solve the problem without breaking my philosophy or changing a lot of my existing code, which was already in multiple small files.

The idea is to build a container page to register on the admin menu and have the container page decide on which code to include based on analyzing the url. The included code can then handle and GET or POST requests and serve the appropriate page output.

<?php
/*
 * Descrition: gcgc admin page. This is the main container page
 * for all admin panels. All POSTS and GETS from all pages route
 * through this page and are handled by the appropriate included file.
*/
global $gcgc_Manager;
echo $gcgc_Manager->getHeader();
//analyze the url to determine which page to load

if (isset($_GET['panel'])){
    switch ($_GET['panel']){

    	case 'cache-admin' :
    	    include (dirname(__FILE__)."/gcgc-admin-cache.php");
    			break;

    	case 'vector-admin' :
           include (dirname(__FILE__)."/gcgc-admin-vector.php");
           break;

    	default :
           include (dirname(__FILE__)."/gcgc-admin-home.php");
    }
}else{
    include (dirname(__FILE__)."/gcgc-admin-home.php");
}

$gcgc_Manager->getFooter();
?>

I kept the above example brief but you can imagine that there can be an unlimited number of admin pages. And this way I didn’t have to change the included files at all — all I had to do was add the ‘&panel=’ parameter to existing request urls and problem solved.

Check out this WordPress blog that is comprised primarily of nothing but Brad and Beyonce Turkey’s Twitter feeds. Interesting concept, off-beat subject mater. Why are they doing it?

We looked after our Turkeys too well, and got attached. Help us decide which one to keep. The one with the most to live for by Christmas will be saved.

I was gaining momentum on the Geocache Manager WordPress plugin last week after solving a couple of longstanding problems with unauthenticated Ajax calls and a few Javascript quirks with Internet Explorer when yet another pesky problem surfaces. When I say pesky it means that I have been fooling around with it for several days without zeroing in on a solution, thus making zero headway on the project. To make matters worse, the problem lies with a feature that has existed from the beginning and had worked until I upgraded from WordPress Mu 2.7 to 2.8.4a last week.

In the admin panel I have a custom top level menu with two entries: a page for the map management and a page for options. The following bit of code…

function addAdminMenu(){
	add_action('admin_menu', array(&$this, 'gcgc_plugin_menu'));
}

function gcgc_plugin_menu() {
	$gcgc_relpath  = str_replace('\\','/',dirname(__FILE__));
	$parent = $gcgc_relpath.'/gcgc-admin-form.php';
  	add_menu_page('Private Geocache Manager', 'Geocache', 1,
                                 $parent, array(&$this, 'gcgc_admin_page'));
  	add_submenu_page($parent, 'Geocache Options', 'Options', 1,
                                 'gcgc_options', array(&$this, 'gcgc_options_page'));
}

function gcgc_options_page(){
	$gcgc_relpath  = str_replace('\\','/',dirname(__FILE__));
	include($gcgc_relpath.'/gcgc-options-form.php');
}		

function gcgc_admin_page() {
	$gcgc_relpath  = str_replace('\\','/',dirname(__FILE__));
	include($gcgc_relpath.'/gcgc-admin-form.php');
}

…will give you a menu like so:

That all works. The geocache admin form lists all the courses defined and for each course there is a link to load a new admin page for that course. This is basic functionality that has existed since the 1st week of development and suddenly the link no longer works. The link now generates a redirect to a sub-blog with a page not found. WTF! Where do you start at on that.

I admit I am a little weak on WordPress redirects and I am having a difficult time understanding why the redirect would go to a sub-blog in the WordPress Mu installation instead of the current blog. But aside from that I don’t understand why it started issuing a redirect in the first place when the code that generates the link hasn’t changed in like five months.

UPDATE: I fixed the redirect problem by deleting the sub-blogs. Now I am just getting a mangled url, like so:

http://gulfcoastgeocache.com/wp-admin/?c=1

So let's go over what I am thinking so far. I am of course using the wp-admin framework and have the faulty link set up similar to the pages accessed from the admin menu. The URL on the Geocache admin link is:

.../wp-admin/admin.php?page=private-geocache-manager/gcgc-admin-form.php

Then on that page there is an entry for each geocache course and each course has an anchor link to its own admin page, like so:

<a href=".../wp-admin/admin.php?
        page=private-geocache-manager/gcgc-admin-cache.php&id=20">
Geocache Name</a>

After checking the usual suspects -- verifying paths, searching for typos, confirming no function parameters had been inadvertently changed -- the only thing I can think of is that the drill-down admin page was working previously only due to a flaw in previous WordPress. I remember when putting it in that it seemed easy. Too easy.

Over the past few days I've done quite a bit of searching using every term anyone could probably think of having to do with registering an admin page that is not on a menu. Compared to other development platforms out there (Make no mistake, WordPress is a development platform) there just is not that much in-depth technical documentation outside of your standard stuff. There are many redundant articles on adding an admin menu, for example, but not much on adding a multi-page, drill-down admin system. You have to figure that out on your own. Either not many people are doing advanced development or they are very tight-lipped about their stuff.

This morning I finally came upon an article that at least verifies my thinking:

WordPress 2.8.1 contains changes to improve the security of plugins by ensuring that only correctly registered plugin pages can be accessed as well as only showing the link to the page to users who have the capability required in the add_x_page call.

The article makes no mention of dynamically created sub-pages accessed by means other than the WordPress menu structure but down in the comments I find a fellow traveler:

I already have add_action(’admin_menu’, ‘FUNCTION’); for my main settings page. However, there’s a plugin page which is not a menu link (but an inside plugin page which is referenced when the plugin settings are saved).

And the answer to my problem, if not the solution:

You cannot just link to pages that are not registered as this would make it easy to load up files which should not be loaded so you have two choices to fix your plugin.

He goes onto say that the workaround is to use a WordPress admin action hook or a call back to the main page to process the main form submissions.

I like to keep my pages small and manageable and this plugin will ultimately have half a dozen admin pages when all the features are added. As of now there are only three. But since I want many small files instead on one big file here is what I am going to do: I am going to create a main admin container page that includes the proper admin panel when loading based on the URL. Should have seen this problem coming and set up like this in the first place. Oh well. I'll report back when I get the changes complete.

Read the follow-up:

WordPress drill-down admin pages II

Now that I have solved the recent unauthenticated Ajax problem in my Private Geocache Manager plugin, it’s time to move on to the second big problem that has plagued me for a while. I wasn’t even aware of it until I tried to demo the system to a user who worked at a place where Firefox isn’t available. I developed the plugin entirely in Firefox using only what I thought to be cross-platform utilities. The only thing that would even be close to non-standard code in the entire script library is jsfade, which itself is not complicated and which clearly takes into consideration the Internet Explorer quirks when performing the fade effect.

Nonetheless I still have a couple of Javascript issues outstanding which pretty much kill the whole deal since the Google Maps API is entirely a client side, Javascript environment and a big majority of folks still use Internet Explorer.

The first issue is the getElementById method somehow can’t figure out that the map canvas div element is in the DOM tree when it clearly is, throwing an ‘object expected’ error. I am accessing the elements from ajax calls so the entire page has loaded at the time of the calls so the div has obviously been declared by the time it is accessed. I think what I have to do here is check to see if the element is in the DOM tree before trying to access it. Firefox is smart enough to figure it out but I guess IE needs more explicit directions.

The second issue is that my ajax call is throwing the dreaded ‘unspecified error’. Debugging shows the error occurs at the mySACK.runAJAX() line. It is a simple ajax call using a standard implementation of the Simplified Ajax Code Kit, or SACK, and the code works perfectly in Firefox.

    function readMapData(arg) {
      mysack = new sack(ajaxurl); //wordpress admin url for ajax hook
      mysack.setVar('action', 'getVectorMarkers');
      mysack.execute = 0;
      mysack.method = 'POST';
      mysack.setVar('id', arg);
      mysack.onCompletion  = loadOverlay;
      mysack.onError = function() { alert('Ajax error ... '); };
      mysack.runAJAX();
      return true;
    }

The onCompletion callback never fires nor does the onError callback. Since I know there is not an error on the server side the next place I need to debug is inside the SACK ‘onCompletion’ code, which I’m not too crazy about. This is where you go, hmmm, maybe I should have just used jQuery for my Ajax in the first place.

So instead of editing a bunch of code that isn’t mine (the SACK wrapper class) I downloaded and installed the MS Script Editor and used it to find the exact bit of code throwing the error:

  if (this.method == "GET") {
     var totalurlstring = this.requestFile + "?" + this.URLString;
     this.xmlhttp.open(this.method, totalurlstring, true);
  }else{
      this.xmlhttp.open(this.method, this.requestFile, true);
  }

I’m using POST method so it’s the last line throwing the error. This.request is set to the parameter passed when creating the new sack object, in our case the wp_admin url, so the code would translate into

xmlhttp.open('POST', 'http://.../wp-admin/admin-ajax.php', true);

And that’s the benefit of writing these posts. Many times you figure out the problem by the time you finish describing it. When I went to copy the ajaxurl from the editor I noticed a typo in the URL which Firefox can obviously parse but IE can’t–I had the first pair of slashes escaped, eg http:///gulfcoastgeocache.com….

Grr….

So that still leaves me with the aggravating problem of getElementById not working properly. I’m debugging that now. Once I get that one sorted out I will be 90% complete with the plugin leaving only the initial setup script and the options page to finish.

Anyone who does any tinkering with WordPress templates or plugins is likely familiar with the WordPress class for interfacing with the WordPress MySQL database, $wpdb. In the previous article here in The Garage, Viewer-facing Ajax in WordPress Plugin, I described a problem I was having with Ajax requests from the public side of a website from a user who is not logged in. Pesky little problem it has been.

In a nutshell, if the user is not logged in they do not have access to any of the built-in WordPress Ajax functionality so you have to write your own Ajax handler, which is not a problem until you need to access the database using $wpdb since the $wpdb class is not normally available to a page or script that is loaded outside the WordPress context. My research led me to a couple tricks around this limitation such as a template redirect or loading the core Worpdress files in the external Ajax handling script, eg,

include_once(‘wp-config.php’);
include_once(‘wp-load.php’);
include_once(‘wp-includes/wp-db.php’);

In theory, after loading those core files I can now make calls to the MySQL tables using the $wpdb class just as if I was logged in to the admin panel. In the back of my mind I am thinking that maintaining extra scripts for anonymous db access is a lot of work and loading the core WordPress files is a lot of overhead just to run a couple of simple queries. Really not optimal.

So I was still looking for a better solution even as I was working on making the above work when I stumbled upon the better solution. Somewhere around March WordPress released an update (v2.8 I believe) which has support for Ajax actions initiated by a user who is not logged in. Along with the ‘wp_ajax’ hook there is now also a ‘wp_ajax_nopriv’ hook that provides the same functionality but for users that are not logged in. So when your main plugin code is loading all you need to do is check to see if the user is logged in or not and then initialize the appropriate action hook.

//load nopriv ajax handlers for front-end ajax users not logged in
if ( is_user_logged_in() ) {
    add_action('wp_ajax_getVectorMarkers', 'getVectorXML');
    add_action('wp_ajax_getVectorMarkersText', 'getVectorXMLText');
} else {
    add_action('wp_ajax_nopriv_getVectorMarkers', 'getVectorXML');
    add_action('wp_ajax_nopriv_getVectorMarkersText', 'getVectorXMLText');
};

Using the ‘wp_ajax_nopriv’ hook allowed me get rid of a lot of code that was written specifically for displaying custom maps to users who are not logged in. It makes me very happy!

Evidently not too many people know about ‘nopriv’ as the info was difficult for me to Google down. (Click here to see the thread where I found the information.) The alternative methods are also discussed in the thread if you are not in the position to upgrade to the latest WordPress version with the ‘nopriv’ option. (Here is the WordPress Trac nopriv change documentation.)

I can verify that wp_ajax_nopriv also works with WordPress Mu version 2.8.2.

It’s rare that I can’t solve a programming problem no matter how complex and thus I rarely leave a question on a support forum. I can’t even remember the last time; probably over a decade ago. Here is one I left recently at the supposedly fantastic WordPress.org plugin support forum.

I am writing a plugin to manage map resources and I having a couple a issues that I have been unable to figure out. I have a test site set up here –> http://gulfcoastgeocache.com/

I am using the Google Map API and lots of ajax both admin and viewer-facing to display custom maps. On the viewer facing side I am using SACK to call a small php script that in turn calls the actual function inside the plugin class.

$gcgc_path  = str_replace('\\','/',dirname(__FILE__));
require_once($gcgc_path.'/gcgcclass.php');
$gcgc_Manager->getVectorXML($_POST[id]);

The class function:

function getVectorXML(){
    header("Content-type: text/xml");
    $parms = array('id' => $_POST['id'],
                   'id_type' => 'vector_id'
                    );                         

    $cachets = $this->getVectorMapData($parms);
    $xhtml = "";
    $xhtml .= "";
    if($cachets){
      $xhtml .= "";
    	foreach ($cachets as $c){
    		$xhtml .= "";
    		}
    }
    $xhtml .= "";
    die($xhtml);
  }

Works fine if the user is logged in but is failing if user is not logged in. More accurately, the ajax round trip succeeds but my xml response is -1 if user is not logged in. No data is coming back.

The codex example for ajax does not illustrate a cookie being sent on the viewer-facing side but this is where I am thinking the problem lies, but really I am at a loss for an idea right now.

This is my first WP plugin so I may be having a noob moment. I’ve been revisiting this issue repeatedly over the past couple of months and, I hate to admit, I can’t figure it out. Any help would be greatly appreciated.

I posted that five days ago and not a peep. I even bumped it a couple of days ago. Still nothing. I’m not sure if the question is too stupid to warrant a response or if maybe it is too hard. I think the only way to get a quick response, or any response at all, for that matter, is to leave your query in broken English and to ask a question that indicates you don’t have a clue about what you are doing.

I’m not impressed. If anyone has a clue about the ajax, please let me know.

I loaded Simple:Press forum plugin for WordPress yesterday and activated it in doncallaway.org, the mother blog of this mu installation, and it works fine. Simple:Press is a basically a significant database application hooked into the WordPress user manage and document management system.  Very, very impressive piece of work. Impressive is a pretty high standard for me and you wont hear me say “very, very” too often about anything. Looking under the hood, the code is clean and reads like a book, if you’re in to reading code. The code is probably is what earned  the extra “very.”

I liked SimplePress forum  so much that I activated the plugin for this blog. I probably wont ever use it here but I wanted to try it in another blog in the same WordPress Mu installation before I loaded the plugin into the  Gulf Coast Texas Outdoor Magazine site, where I do plan to use some kind of bulletin board system to provide a support mechanism for the bloggers.

Here’s the problem: It doesn’t work in this blog. Still works in the mother blog, but when I look in the forums panel in the WPmu admin screen for this blog, the only screens that display are user and group admin. Options, components, forums, and the other load a blank screen.

I think Simple-Press is probably what I need for my modest needs, but bbpress is probably the more capable bulletin board system and certainly is the one that has more value in learning how to use, so it’s not looking good for simple-press, though it is quite impressive for a wordpress plugin.

I need to add a contact form to some blogs so a quick Google  search turns up a nice list of WordPress Contact Form plugins. It’s a little dated but a great place to start looking. Read the comments for a couple of suggestions not on the list.

This blog now, along with Rumble Strips, lives in the don callaway dot org (dcdo) WordPress Mu installation configured with top level domains and sub-domains.   To the casual observer these are standalone WordPress blogs.  For each blog with a top level domain I can also have multiple blogs as sub-domains to that blog.

Sweet.