Go check it out and make sure to subscribe to the RSS feed.

Cheers,
Davide

Marcus was alerted by a user, and was super fast in updating.

Davide

• Fixed spelling typos
• Fixed warnings for bad location image uploads (e.g. too big etc.)
• Fixed error for #_EXCERPT not showing

Enjoy,
Davide

So why the long wait?

Well, mostly because under the hood the plugin is completely new.

As you might remember Marcus jumped in a couple of versions ago adding the category and attribute features. Now he’s a co-maintainer, and he spent the last few months reorganizing the EM code base. Events Manager 3.0 is quite similar to 2.2 on the outside, but everything has changed. Now it sports a modern, object-oriented, templated code base.

What does this mean for users?

Simple put, better support. Now that the code is tidy and modern it will be much easier to spot and fix bug. And it’ll be easier to add new stuff and mods.

Can I upgrade safely?

Indeed. EM 3.0 updates smoothly from 2.0. Still, if something goes wrong, we’ve made sure not to erase your old data, and’ve even included a “Migrate again” routine. If something wrong happens take a look at the new Help page, in the Events section of the menu.

If you are using EM 1.*, you should first upgrade to 2.2, and then to 3.0.

In any case it is always good practice to backup the your database before any upgrade.

Is that all?

Absolutely not, you will find out what’s ahed in the next few weeks. For now our focus is push 3.0 out, get your feedback and release 3.1 in a few weeks. Then… surprise!.

BTW

We’re here to stay

Davide and Marcus

Hum.

After investigating I come across this suggestion in the Codex:

Acceptance of HTML tags in the comments field is managed in the file kses.php, located in the wp-includes folder.

Open this file in a text editor, and locate the list of HTML tags near the top of the file. Each HTML tag is listed on a separate line, in the construction of a PHP array of allowed tags. Lines which begin with // are commented-out, or disabled, so lines which begin with // designate HTML tags that are not allowed in comments.

To stop people from posting HTML in comments, edit your kses.php file as desired to allow or disallow specific HTML tags in comments, by adding // to the very beginning of the appropriate lines of the list. To exclude all HTML tags, comment out all lines which allow HTML tags. Be sure to save your file when done.

That’s a start but hey, is the Codex really suggesting that I alter the WP core? Next update my all precious settings will go away. C’mon, we can do better than that!

In the kses source code I find this:

 
if (!defined('CUSTOM_TAGS'))
	define('CUSTOM_TAGS', false);
 
if (!CUSTOM_TAGS) {     
	etc

So basically I can redefine all the allowed tags structure in a constant. Not bad. But hey, do I really want to redefine both the $allowedposttags and the $allowedtags variables? Naaah…

So I scavenged in the source code and I came across a fit filter. I wrote a little function for my functions.php file; needless to say, this could have gone into a plugin.

add_filter('preprocess_comment','fa_allow_tags_in_comments');
 
function fa_allow_tags_in_comments($data) {
	global $allowedtags; 
	$allowedtags['span'] = array('style'=>array());
	$allowedtags['p'] = array();   
	return $data;
}

See? Much more concise than overwriting the variables. And more future-proof: if subsequent versions of Wordpress change the variable there is no constant barring the changes.

Cheers,
Davide

• Added a option to get events through a select
• Closed many bugs causing a notices/warning visible only in debug mode
• Closed a critical security hole discovered by Danilo Massa (to be released on May 10th)

The first point is the only proper feature, it allows you to use a select for the events venue. It’s something that comes in handy for people/organizations whose events take place in the same venues all the times.

The second point is something I should have done AGES ago. I put Worpress in debug mode and thus could see all the stuff that’s usually spitted directly into the error log. There were many small bugs, caused mainly by the lack of isset here and there. I believe there are still minor notice/warnings, but I got rid of most of them.

Point three is what urged me to release ASAP. Danilo Massa kindly notified me of a security hole in Events Manager, providing a simple one-liner to fix it. Since the vulnerability is pretty serious I hurried to apply Danilo’s patch and release 2.2.

This release is quite stable, it’s employed in a client portal, so you should have no problem with the upgrade.

Enjoy,
Davide

Here’s the changelog:

• Properly added Marcus Sykes as a contributor
• Added a full calendar
• Added an #_EDITEVENT placeholder
• Added Brazialian Portuguese localization and some translatable strings
• Added a today scope for events lists
• Increased to 3 te default lists limit
• Categories are now displayed in the events table
• Now weeks starts according to WP settings
• Moved the hide page option up for better access
• Attributes column was not created when the plugin was upgraded, fixed
• Added comment field to the RSVP form and #_COMMENT placeholder in RSVP email templates
• Added customizable title to small calendar
• Removed php short tags
• Changed RVSP ‘no seats available message’ for better English
• Bugfix: there was a time bug
• Bugfix: event_time not taken into consideration in ordering events, fixed
• Bugfix: on calendar for days after 28 on the event calendar view
• Bugfix: for events in days with single digit
• Bugfix: events link in the calendar now work with permalink
• Bugfix: today in next mont was not matched in the calendar
• Bugfix: _RESPPHONE was not matched in emails
• Bugfix: fixed security vulnerability, which could lead to sql inject attacks
• Bugfix: locations with apostrophe were duplicated
• Bugfix: bloginfo(‘wpurl’) instead of bloginfo(‘url’)
• Bugfix: now loading textdomain in the new (not deprecated) way

Most of the bugfixes, and some of the features, were sponsored by Sara of Paperlantern, to whom I am most grateful.

Also, I just got a haircut:

Cheers,
Davide

function approve_guestbook_comments($comment_ID) {
	$comment = get_comment($comment_ID);    
	if ($comment->comment_post_ID == guestbook_page())
		wp_set_comment_status($comment_ID,'approve');
 
}
add_action('comment_post','approve_guestbook_comments');

As you see it’s a super-simple tweak, but it’s quite effective.

Enjoy,
Davide

	* The $userdata array can contain the following fields:
	* 'ID' - An integer that will be used for updating an existing user.
	* 'user_pass' - A string that contains the plain text password for the user.
	* 'user_login' - A string that contains the user's username for logging in.
	* 'user_nicename' - A string that contains a nicer looking name for the user.
	*		The default is the user's username.

The other keys are user_url,user_email, display_name, nickname, first_name, last_name, description, rich_editing, user_registered, role, jabber, aim, yim; for more detal consult the source itself.

My script goes like this:

<?php
include 'wp-blog-header.php'; 
include 'wp-includes/registration.php';   
include 'wp-includes/pluggable.php'; 
ini_set("memory_limit","1024M"); 
ini_set("max_execution_time", "240");
global $wpdb;
?>
 
<h1>Importazione utenti EC</h1>
 
<?php
$connection = mysql_connect("host", "user", "password") or die("Unable to connect to MySQL");
mysql_select_db("database", $connection) or die("Unable to connect to the database"); 
$result = mysql_query("SELECT * FROM source_users ;");
	while ($row = mysql_fetch_object($result)) {
		echo "<strong>ID:</strong>".$row->id." <strong>login:</strong>".$row->user_name." <strong>password:</strong> ".$row->password." <strong>e-mail:</strong>".$row->email_address." <strong>name:</strong> ".$row->name." <strong>surname:</strong> ".$row->surname."<br/>";  
		// Add the ID to trick WP
		$add_id = "INSERT INTO ".$wpdb->users." (id, user_login) VALUES (".$row->id.",'"."$row->user_name"."' ); ";
		 mysql_query($add_id) or die(mysql_error());
		// Add the rest
		$userdata = array(
		 'ID' => $row->id,  
		 'user_login' => $row->user_name,
		 'user_pass' => wp_hash_password($row->password),
		 'user_nicename' => $row->user_name,
		 'user_email' => $row->email_address,
		 'first_name'  => $row->name,
		 'last_name'  => $row->surname,
		 'role' => 'subscriber'
		);                          
		wp_insert_user($userdata) ;
	}
}
 
 
mysql_close($connection);

Some highlights:

• Import all the WP files you need
• Change PHP memory and time limits if you have many records
• Explicitly encrypt the password with wp_hash_password. I have no idea why this is necessary, the WP code should do this by itself; but trust me, it is.

Since we are using the wp_insert_user() function, WP will crate records both in the users and in the usermeta tables.

A last warning. This huge amount of users could conflict with your php settings. To get WP working properly I had to add this line to wp-config.php:

	define('WP_MEMORY_LIMIT', '64M');

Without it I could not get the users list in the admin session. I also filed a bug, but this last line should keep you on the safe side.
Enjoy!