Wordpress drill-down admin pages II

January 18, 2010

wordpress-logo-300x300I 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.

  • Share/Bookmark

Why execute php from a Wordpress Mu post

February 13, 2009

In the previous post I mentioned some issues with injecting php into a Wordpress Mu blog post. Some people probably don’t understand why would you want to execute php code from inside a blog post. Well the most obvious answer now that I’ve done some research and what seems to be the primary concern of Jim Groom and the many followers of the issue is the ability to configure and display dynamically aggregated RSS feeds for posts as well as doing some fancy stuff in the widgets. I can imagine the possibilities are endless.

But the obvious reason isn’t what initially got me started on the search to execute php from inside a post or page. I want to be able to add a set of custom fields to certain categories of posts and then execute sql commands against them. For example on an outdoor photography blog, for all posts in the ‘Trip Report’ category I might add some fields called ‘location’,  ‘mileage’, ‘meals’, ‘fuel’, ‘other_expenses’.  Then I could have a page called ‘Trip Expenses’ that would query all the Trip Report posts and display the results in tables, charts, and/or graphs. A Wordpress page with embedded php could create  fancy charts and graphs laid out however you like, like the Quickbooks dashboard, for example.  The page would re-calculate every time it’s opened. How sweet is that?

Another example:  On a blog chronicling a fitness program I could add custom fields to the ‘Daily Workout’ posts like ‘exercise_type’, ‘total_distance’, ‘total_time’, ‘5k_time’, ‘peak_heart_rate’, ‘two_min_recovery_heart_rate’, ‘etc…’. Then I could have a Page called ‘Treadmill Progress Report’ or ‘Bench Press Progress Report’ that spits out graphs based on the fields in all the Daily Workout posts.

Using this technique you could easily build simple database applications within a wordpress blog. You could also build large, complex applications like this but that would be silly, wouldn’t it?

  • Share/Bookmark