Change wordpress dashboard RSS feed

If you ever feel like you want to change the source of the news items on the wordpress dashboard (Not wordpress.com, sorry if I got your hopes up there) here is how to do it.

You can either add the code that follows to your themes functions.php or you can add the it to a plug-in. Just change the returns from the function to match your feed URIs and titles. There are two feeds the primary, which by default is the “Development Blog”, is limited to about 3 entries and the Secondary feed is much more open.

If you’d like to delete the feeds the just set the return to “”, doing this helps dashboard load time a lot.

/*
Plugin Name: Dashboard RSS replacement.
Plugin URI: http://www.completelypointless.co.uk/
Description: Changes the dashboard RSS to something more interesting.
Author: James R Whitehead
Version: 1.0
*/
function change_dashboard_primary_title () {
return "Completely Pointless";
}
function change_dashboard_primary_feed() {
return "http://completelypointless.co.uk/feed/";
}
function change_dashboard_secondary_title () {
return "BBC News";
}
function change_dashboard_secondary_feed() {
return "http://newsrss.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml";
}
add_filter("dashboard_primary_feed","change_dashboard_primary_feed");
add_filter("dashboard_primary_title","change_dashboard_primary_title");
add_filter("dashboard_secondary_feed","change_dashboard_secondary_feed");
add_filter("dashboard_secondary_title","change_dashboard_secondary_title");

That’s it, nothing too onerous or perplexing. I will say however that if you’re distributing themes or plug-ins that it would be nice to let wordpress keep their feed in there.

Restricting WPMU sign-up.

Restricting the ability to sign up to new wpmu blogs is unfortunate but necessary to get away from all the spam bloggers out there. They make life hell for everyone.

This simplest means of hindering their progress is a plug-in that checks to see the login status of the person trying to create a new blog.
<?php
add_action("signup_header","ICITAreYouAllowed");
function ICITAreYouAllowed() {
if (!is_site_admin()) {
header("location: http://{$_SERVER["HTTP_HOST"]}");
} else {
return;
}
}
?>

Something like the above dropped into the mu-plugins folder would make it hard, if not impossible, to create blogs unless you where a site administrator. Nice for locked down sites but not very useful for sites that want to be open. You could change the “is_site_admin” to a check for logged on user with “user_level_0” access. This would add an extra step to the sign-up process and would require that the user provide a few more details before they can move on to the process of creating a blog. This would eliminate the scripted bot blog creation but would not stop the manually created spam blogs.
That leaves us with a problem. Either lock it all down and the admin has to do it manually upon request or leave it open and be forever fighting fires.

As a result of the above I’m going to create a plug-in that gives you the following

1. Drop down menu to choose the minimum account level to allow blog creation. i.e. level_0 to level_10 or “site admin”
2. Option to choose to give users blog create access once they have X number of moderated comments on the site. This may also help get people posting comments to other blogs. Of course it could also lead to people posting youtube-esque comments just to get to the magic number.
3. As part of the last one I may also introduce a comment voting system (different plug-in) and only trigger when a certain quality has been reached.
4. Add an option that states you should have been a member of the site for at least X amount of time before you can create accounts. Couple that with the post count and it should make it a lot easier to spot and block the spammers.
5. Will have to include the option to have the settings available for each site on the one mu install. So blog creation on each site can be controlled on a site by site basis.
6. An option to pick up the wp-login form from a kind of page template in the plug-in folder or the theme folder. Would allow you to style it uniquely for each of your themes.

WARNING: These are my personal notes and there is no time frame for this. I can see this turning from the simple code above to something quite large. 😀

Steps for installing WP Mu as domain manager

The following is the basic procedure for installing WordPress mu with more than one domain name so that you only need one install to control several domains. I’m creating this document to help me see all the steps I’ve take so that I never have to figure it out from cold again and to help me with the writing of a plug-in that will allow me to do this via a very simple interface.

1. Install mu on your domain {e.g. yourdomain.com} and ensure that wildcard domains are processed by mu. Entering [ramdom].yourdomain.com should take you to a prompt to create a blog of [ramdom].yourdomain.com unless it already exists that is.
2. Park the new domain {e.g. newdomain.com} using your servers management back end. This will be different on each hosting provider and may not even be available so if it is not obvious you’ll need to contact your provider.
3. Create a new blog {e.g. newdomain.yourdomain.com} and test it.
4. Get into a position where you can edit the db.
5. Run SELECT * FROM wp_blogs WHERE 1and look for the blog you just created and make a note of its blog_id.
6. Edit the domain cell. Will currently be set to newdomain.yourdomin.com and we want to change it to newdomain.com. If we assume the blog_id is 9 the following command would do. UPDATE wp_blogs SET domain="newdomain.com" WHERE blog_id =9 LIMIT 1
7. We now need to edit the other references to the sub-domain and point them to the real domain name. If you run the following you will find 3 references back to http://newdomain.yourdomain.com change them to http://newdomain.com/ and be sure to keep anything that comes after the domain name. i.e. /files/. Again we assume the blog_is is 9 SELECT * FROM wp_9_options WHERE option_value LIKE "http://%"
8. Your site should almost work at this point. Give it a test, you should find it all looks as you expected until you try to login to the backend. That is what we’ll fix next.
9. We need to add a new site to the wp_site table so that we can use the backend admin. INSERT INTO wp_site (id,domain,path) VALUES ("9","newdomain.com","/");We can use the blog_id as the value for id if it has not been used before, if it has been used then just pick a number that’s not been used and make a note of it. The value of domain should be that of the new domain {e.g. newdomain.com} and the value of path should normally be “/”.
10. We now need to go back to the wp_blogs table SELECT * FROM wp_blogs blog_id = 9 and edit the site_id to be that of the id we set up in step 9. So that would be UPDATE wp_blogs SET site_id=9 WHERE blog_id =9 LIMIT 1. Change the site_id to that which you previously chose if it is not the same as the blog_id. I like to keep them the same to aid my admin but there is no technical need to do so.
11. Site meta needs to be configured to allow administrators to change the site settings. This command will set the user called admin as site_admin if site_id == 9 INSERT INTO wp_sitemeta (site_id,meta_key,meta_value) VALUES ('9','site_admins','a:1:{i:0;s:5:"admin";}');If you need to change the admin name to something else, say “administrator”, you will have to change the s:5 to match the size of the new word. In the case of “administrator” it would be set to 13.
12. To enable site plugins the following is needed. INSERT INTO wp_sitemeta (site_id,meta_key,meta_value) VALUES ('9','menu_items','a:1:{s:7:"plugins";s:1:"1";}');