It’s very simple to activate, just add to your wp-config.php file the following:

define('WP_DEBUG', true);

But don’t do it in your site, otherwise you won’t be the only one looking at the warnings :|

http://codex.wordpress.org/Editing_wp-config.php

I’ve seen this question being asked around (e.g. here) and couldn’t find a helpful reply anywhere.

I had this same problem and since I couldn’t find a clean way of doing it I had to comment a line in one of the core files. In the file wp-includes/pluggable.php, function wp_new_user_notification(), you can comment the last line that reads:

wp_mail($user_email, sprintf(__('[%s] Your username and password'), $blogname), $message);


I would love a cleaner way of doing this, if you know one please let me know!

Note that with upgrades you will lose this change. Unfortunately there seems to be no way around this until WordPress supports a filter or some other mechanism to do it in a cleaner way.

Also note that this is different from disabling new user notifications that are sent to the admin email, for that there is an option in the admin panel.

This was done against WordPress Mu 2.9.2. Your mileage may vary of course! :)

Thanks Scott!

1) Keep the Simplicity – My greatest fear with WordPress is that people won’t stop adding more things to it. I like its smallness. The merging of WordPress MU in the upcoming 3.0 version is just one example of the unnecessary growing complexity of the WordPress code base.

2) Be more Open – Automattic keeps control of the only official plugin repository and WordPress only works with it. Reminds me of the Apple App Store and I for sure don’t want anything like that for WordPress.

For the 2011 Portuguese Presidential elections I will be supporting Fernando Nobre. Not that anyone cares but I thought I should mention it. For that reason I’ve added to my blog a small support banner linking to the campaign site.

I’ve also been thinking how I can contribute and help with the campaign, and how to enable people that are interested in helping out to do so effectively, besides the obvious sign-up for voluntary help at the campaign site.

If you have a WordPress blog, I’ve made public a widget you can use on the sidebar of your blog to display a small image banner just like the one I’m using. It’s an easy way of showing our support and it’s very easy to install:

1. Inside the WordPress admin, go to Plugins -> Add New and search for ‘Fernando Nobre’.
2. Click ‘Install’.
3. Inside the WordPress admin, go to Appearance > Widgets, and add the ‘Apoio Fernando Nobre’ widget where you want, then save the changes.
4. That’s it!

And here’s the link to the plugin page:

• http://wordpress.org/extend/plugins/support-fernando-nobre/

define ('WPLANG', 'pt_PT');

I then used poEdit, a localization tool that works with Mac OS X and that can be downloaded from the poEdit download page. In poEdit, from the File menu select ‘New Catalog’. Fill in the information there and in the ‘Paths’ tab put the plugin directory. In the ‘Keywords’ tab add the missing entries so it looks like this:

At this point it should recognize all the text strings in your code and present a screen where you can add the translations. After that be sure to save the file as pluginname-pt_PT.po, preferably in a directory called ‘translations’ or ‘locales’ (but anything will do). After that you’re all set. In your code you should load the translation like this:

load_plugin_textdomain ( 'your-plugin-name' , FALSE , '/your-plugin-name/translations' );

And strings should have the form:

_e('Choose a Category','your-plugin-name');

That’s it. Let me know if you run into troubles :)

Resources & Further Reading for the Geeks:

• http://codex.wordpress.org/Writing_a_Plugin
• http://codex.wordpress.org/I18n_for_WordPress_Developers
• http://urbangiraffe.com/articles/translating-wordpress-themes-and-plugins/
• http://urbangiraffe.com/articles/localizing-wordpress-themes-and-plugins/

This can be fixed this by setting “AllowOverride to All” in the httpd.conf file, in the relevant Directory directive section where MU is installed.

This can be quite simple to develop by putting together a jQuery tab container and iframes.

This could be further extended in a way that one single login would authenticate across all the WordPress installations. In this way we can manage the several installs from one single interface with full flexibility, i.e. we have exactly the same options as if we open separate windows and log into the installations.

Check out the example demo. Try going to Tab number 2 and logging in as user: admin / password: demo123

The Problem

Where I first stumbled was when from my plugin I tried to access directly the other plugin in the remote site. The code I was using for doing this was something like:


// create curl resource
$ch = curl_init();
// set url
curl_setopt($ch, CURLOPT_URL, "http://wordpress.mu/wp-admin/admin.php?page=myplugin");
//return the transfer as a string
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// $output contains the output string
$output = curl_exec($ch);
// close curl resource to free up system resources
curl_close($ch);
// print the result of the whole request:
print "CONTENT = ".$output;


And this wouldn’t work because although I was authenticated in the remote site via the browser, the session that the curl request creates is not, and so this request results in us being redirected to the login page.

What to do?

Ideally we want to do a POST request that we execute before and that authenticates us. I searched around on how to do this but couldn’t find anything. What I found was one of the many third-party applications that allow talking to WordPress remotely. I then looked at how they work and how they authenticate themselves.

Instead of doing a POST request to the plugin page like before, they do a POST request to the site’s index.php. A plugin is registered to catch a particular POST request. Then you simple use the WordPress function user_pass_ok(), that authenticates the user against the database.

Here I demonstrate how to do this using a GET request, because its simpler, but the same thing would work with a POST request.

add_action('plugins_loaded', 'unpackimport_createblog', -1);
function unpackimport_createblog() {
if(isset($_GET['myplugin'])) {
if(user_pass_ok($_REQUEST['username'], $_REQUEST['password']))
echo 'Authentication successful';
}


And the client request:

curl_setopt($ch, CURLOPT_URL, "http://wordpress.mu/index.php?myplugin=true&username=test&password=testpass");


Screencast

I wanted to show a working example rather than just saying this works so I did this screencast. You can also download the plugins yourself and try them out.

www.youtube.com/watch?v=Ort-IMmpo4s

Download

unpack_import_demo.tar.gz
dump_pack_demo.tar.gz

The basic of WordPress MU is that the user registers and upon the click of a button, a blog is generated for him, available to use immediately.

The default blog that is generated is the most basic thing you can get. It uses the default Kubrick theme, no plugins or widgets, and a bit of example content (a post, a page, a comment and some links).

I’m working on a WordPress MU project now and I had to change the default blog to something more elaborate. So I went and researched a bit what can be done and what is supported. Here’s what I’ve found.

There are a couple of MU plugins that allow you through an admin panel to edit some defaults (blog title, default theme, stuff like that). If you’re into that kind of thing see the New Blog Defaults plugin. But in fact what I wanted was something more along the lines of developing my default blog locally (in a local MU installation) and then deploy to the production site with minimum hassle.

I found another plugin called Blog Templates and with it you can create a template from a blog. This template will be saved in a different database table ‘wp_gp_templates’ and will contain posts, pages, links, post categories and some blog options. You can easily extend it by adding more options to be saved if you need to. You can then upload the template to the production server and it will be applied as a template to new blogs. Pretty cool.

exclude pages plugin

I had a plugin to exclude certain pages from the menu. This was a question of adding an extra option to be saved in the template. *

copying plugin settings

Information about what plugins are active is kept inside the options table and so it can be saved quite easily:

$newoptions['active_plugins'] = get_option(‘active_plugins’);

A problem with this is you still need to make sure all the plugins you had locally installed are on the server. Not a big deal but something to keep in mind.

copying widget settings

Widget settings are also kept inside the options table so it’s not a big deal to extend the plugin to also save them (you still need to work out which options to save though). Because normally widgets are registered from plugins you again need to make sure all the plugins you had locally are on the server.

theme

The theme name is saved in the template but you still need to manually make sure all the theme files are on the server, and if not, upload them.

post meta / custom fields

I extended the plugin to clone all of the meta items for a post. This seems to work quite well without any problems. I might work together with the plugin author to include this as an option in the plugin or maybe release the code here separately.

* A problem with this is that because the pages are excluded based on their ID, you need to be sure that the pages will be created with the same ID that is saved to the template (this is a problem if you have created pages and then deleted them because the IDs will not be the first ones).