Hey folks,
great news, there’s a new Events Manager Official Website!!!
There are new docs, a rich feature list and much more.
We plan to keep it updated and we already have a couple of tutorial in store, ready to be published.
Go check it out and make sure to subscribe to the RSS feed.
Cheers,
Davide
If you’re using Events Manager, make sure you update version 3.0 or 3.0.1 to the latest version, as there was a major bug found in recurring events.
Marcus was alerted by a user, and was super fast in updating.
Davide
Hello folks,
a short post to notify that Marcus has pushed out EM 3.0.1.
Luckily 3.0 was quite stable, and the are minor bugfixes, but do update! Here’s the change log:
Enjoy,
Davide
Hello folks,
after months of apparent calmness Events Manager 3.0 is out.
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.
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.
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.
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!.
We’re here to stay 
Davide and Marcus
Scenario: I am using the tinymcecomments plugin to give some formatting capabilities to commenters.
With the latest WP update I realised the span tag was removed from comments; colors attributes are filtered by the kses filter.
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