2718.us blog » wp plugin http://2718.us/blog Miscellaneous Technological Geekery Tue, 18 May 2010 02:42:55 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Hiding the WordPress Dashboard http://2718.us/blog/2008/07/10/hiding-the-wordpress-dashboard/ http://2718.us/blog/2008/07/10/hiding-the-wordpress-dashboard/#comments Thu, 10 Jul 2008 20:34:55 +0000 2718.us http://2718.us/blog/?p=48 I use WordPress as the backbone of a site I run, including using it for user authentication.  This means a lot of people who aren’t invovled in running the site are logging in and could see the dashboard.  Now, it’s not that there’s anything really secret there, but it makes things look a lot less “finished” to have users deposited on a page that has no relevance to them.  This is where the Hide Dashboard plugin from Patrick/DeepWave comes in.  It does a nice job of getting users to their profile page and generally hiding most of the dashboard things that regular users don’t need to see.

I, however, wanted a little more.  I wanted to make sure that regular users who might be, well, “curious” about the inner workings of the site and who have some knowledge of wp-admin URL structure to be unable to get at anything but their profile page.  To this end, I added a little to the code:

  1. // add after line 41, which reads:  if(!current_user_can('level_10')){
  2. if (strpos($_SERVER['REQUEST_URI'],'/wp-admin') !== FALSE
  3.     and strpos($_SERVER['REQUEST_URI'],'/wp-admin/profile.php') !== 0){
  4.         wp_safe_redirect('/wp-admin/profile.php');
  5. }

This should redirect any non-admin user off of any /wp-admin* page to /wp-admin/profile.php. This might, however, cause issues for mid-level users (i.e. authors/editors/etc may not be able to access needed functions) and I haven’t tested it thoroughly and there might be a better way to do this. YMMV.  See also some comment-discussion on these changes at the plugin’s own page: me Patrick me.

]]> http://2718.us/blog/2008/07/10/hiding-the-wordpress-dashboard/feed/ 4 Oh, so *that’s* why the WordPress.com stats plugin said I had no traffic… http://2718.us/blog/2008/05/01/oh-so-thats-why-the-wordpresscom-stats-plugin-said-i-had-no-traffic/ http://2718.us/blog/2008/05/01/oh-so-thats-why-the-wordpresscom-stats-plugin-said-i-had-no-traffic/#comments Thu, 01 May 2008 20:38:24 +0000 2718.us http://2718.us/blog/?p=32 It seems that some themes that I’d used as the bases for my own themes on my WordPress installs (other than this one) didn’t have

<?php wp_footer(); ?>

in the footer.php file, like they should, I guess, since that seems to be what the WordPress.com stats plugin needs to register hits.  I had been wondering why the numbers on my dashboards didn’t even remotely match my awstats numbers.

]]> http://2718.us/blog/2008/05/01/oh-so-thats-why-the-wordpresscom-stats-plugin-said-i-had-no-traffic/feed/ 0 Using WordPress for User Authentication, Part 2 http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/ http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/#comments Wed, 16 Apr 2008 18:08:33 +0000 2718.us http://2718.us/blog/?p=22 After implementing other pages that used WordPress to authenticate users and deal with access control, I went to move these pages off to a subdomain, and suddenly found that auth_redirect wasn’t quite working right.  When auth_redirect is called and doesn’t find a logged-in user, it redirects to login and passes the URI of the current page… well sort of.  It passes the request string, but it ignores the server part.  So, when the login page is done and tries to redirect, it’s going back to the main WordPress server, not the subdomain.  Fortunately, auth_redirect is a very simple function to duplicate and it is designated as pluggable–that is, a plugin can be used to redefine auth_redirect, so I’ve now got a plugin that overrides auth_redirect() with auth_redirect($use_current_host = FALSE) so that if I want auth_redirect to pay attention to the host, I call auth_redirect(TRUE).

This is all fine and good, but still doesn’t quite work, since WordPress is smart and won’t just redirect anywhere willy-nilly.  It will only redirect to authorized-for-redirecting servers (wp_safe_redirect, which doesn’t have any documentation in the Codex).  Though undocumented (or at least not well documented in the Codex), the way the authorized host list is handled allows for a plugin to add a filter hook that modifies the allowed list (since the allowed list by default only includes the actual WordPress server name and isn’t exposed as an option/setting anywhere).  Toss that hook into my plugin, add on a settings page to allow the admin to input a comma-separated list of allowed-for-redirecting hosts, and now I can use WordPress to authenticate users on subdomains.

If anyone is interested in this plugin, please let me know and I’ll try to clean it up engouh to make it public.

]]> http://2718.us/blog/2008/04/16/using-wordpress-for-user-authentication-part-2/feed/ 2