Dear All,
Our recent update of Events Manager 6.0 was arguably our biggest update since inception and has mostly been a great success. We’ve been talking with a lot of our users over the past few weeks who’ve been extremely happy with the new look and layout of the plugin.
At the same time, such as big change in HTML styling and structure inevitably meant that a lot of users are also running into various issues when upgrading from version 5 to 6. I’d like to address various concerns and points that have been raised to me over the past few weeks.
If you’re not a developer or designer, this may get technical… if so you could just read ‘Our End Goal‘ below and skip to ‘The Silver Lining‘ near the bottom.
If you’re looking for information on upgrading, whilst I recommend you read this anyway, check out our migration/upgrade guide.
Our End Goal – A Better Events Plugin
Firstly, I would like to say that anybody that has run into issues updating has my utmost sympathy and, additionally, my apologies. Our intention is certainly not to update without regard for those already using our software, quite the opposite; we hope the following post will help you understand the reasoning behind it and where we’re heading with this.
Our mission is to create a solid Events Management framework which enhances any event and is accessible to as many people as possible; both the organizers and end users alike. Moreover, we want a solid framework for developers to enjoy using when implementing event solutions for their clients, much like how we ourselves fell in love with extending WordPress with plugins!
The above mission is the essence of why we started some 10 years ago and remains the same to this day. One of the things that sets us apart from other plugins is our flexibility for developers and advanced users alike, providing minimal styling and a myriad of ways to customize every aspect of how events are displayed and function on your site.
This latest update focused primarily on the UI side of things. We’ve revamped large parts of the front-end facing part of the plugin, particularly the presentation of events through searches, calendars, lists, etc.
Are we breaking with flexibility?
Many users have written to me, worried that we’re going to prevent Events Manager from being a flexible events plugin with minimal styling that they can mould to their needs, largely why they choose it in the first place. In fact, this is quite the opposite of what’s happening!
All our previous flexibility features are there to stay. In fact, we’ve added more hooks, templates and ways to extend our plugin in 6.0! Additionally, we’ve made it easier for those that may want to extend small parts and leave the rest to us as we improve the plugin over time.
Firstly, all our new CSS changes can easily be turned off in our settings page. You can turn them off entirely so they have no effect on the HTML, or select fine-grained choices of specific areas in the plugin where you may or may not want our CSS to take over. Don’t want it? The choice is always yours, you can disable it!
With templating, previously you could extend our templates within the wp-content/themes/yourtheme/plugins/events-manager/ folder. This is still possible, but we’ve also added another layer where you could add files to /wp-content/plugin-templates/events-manager/ and avoid adding files to your themes which may require automated updates, and lose those custom files during updates.
We’re also big fans of allowing you to use formatting on our settings page, without the need to touch PHP files. That remains the same, and we even added new formatting options for different parts of the plugin. In 6.0, we’ve added the option to dynamically get formats hard-coded from files in our templates (which you can override as above!), but you can also override any of these within your settings page as you always could.
Additionally, you always have to option to override any of our CSS with our own CSS, it’s simply a case of adding more specific rules to override ours. Moreover, we are making use of CSS variables which will allow you to make sweeping changes with a line of CSS code.
Ultimately, if you want to keep your previous setup as per version 5, simply copy the ‘templates’ folder in events-manager over to one of the overriding folders described above. That would prevent ANY of the new changes we made recently from permeating into your custom setup. That said, you’ll start missing out on new features as we keep adding them, such as enhancement to event submission and booking forms, hence the challenge we’ve faced.
The Challenge
Given we have previously provided very minimal styling and an open canvas with regards to routes of customization, a good portion of our users have painstakingly created amazing aesthetic tweaks to our formats, templates, CSS and their own themes to make events look just the way they want, having little or no interference from our own plugin styling and basing this off templates which have remained unchanged for many years now. It’s certainly no surprise that when an update breaks all that hard work, frustration follows!
This is where we ran into a double-edged sword with flexibility and our quest for version 6; There’s endless scenarios of ways people customized our plugin for we needed to account for when making a new UI. Pair that with the possible combination of our settings, it made testing pretty tricky.
For those wondering, we tested the new update on roughly 20 themes, including all the default WP themes starting from Twenty Twelve! We also tested them on some commonly used plugins, such as Divi, Astra, Genesis, Storefront, Bootsrap themes and more.
With that in mind, we’ve tried to maintain the structure of large parts of our templates intact, especially with regards to where class names are located so that users’ CSS will still apply.
However, new CSS technology makes many things possible which were not 100% compatible with some of the template structures still present up to version 5. Formats we allow you to modify in our settings pages also had minimal content, structure and layout which limited how we could effectively push out aesthetic changes.
A “Clean Break”
A clean break sounds nice, but obviously not feasible and, in fact, wasn’t even necessary. We have fortunately been pretty consistent with our structuring of HTML, and the main effort with regards to rewriting code was on the CSS level, and some root CSS class names allowing us to turn our CSS styles on/off.
Additionally, we have also strived to remove the use of id attributes in favor of class names, along with some more consistent naming structures in places where appropriate (we have also tried to keep old classnames there if possible).
Therefore, the recent update mainly works off having added two classnames, em and pixelbones. em mainly focuses on specific structuring of content, pixelbones focuses on providing a consistent set of basic layouts across themes.
Introducing ‘pixelbones‘
Many will have encountered the greatest changes to their site due to the pixelbones CSS class and its underlying CSS rules.
The reason for pixelbones is simple, we needed to create a consistency layer across the millions of themes out there which often have their own aggressive CSS selectors and make theming our content very difficult. In turn, pixelbones aggressively overrides CSS rules to ensure consistent layouts in our plugin content.
pixelbones is a project we started with our other plugin, Login With AJAX, with the intention of creating a solid styling structure which prevented themes from breaking layout and styling. It’s based off the Barebones CSS framework, which was in turn based off the Skeleton CSS framework. Frameworks all assume that you’ve got full control of your site styling, adding rem stylings to the body tag, lovely @media screen assumptions on screen sizing and more. Plugins don’t have that luxury, we install ourselves onto themes with styling rules that we can’t possibly predict, so we’ve adapted the minimal framework concept into a plugin-compatible CSS framework that only affects parts of a webpage, i.e. our plugin content.
The challenge we’ve faced is being able to add a layer of styling to our plugin without breaking others’ styles. In many cases, the themes mentioned earlier would add styling using ids such as:
#content p { padding: 10px; }
The above prevents us from stlying our paragraphs without the use of ids, which then becomes invalid HTML should we want to include multiple lists on the same page.
“pixelbones aims to do just that, providing a consistent layout of basic HTML elements such as forms, buttons, paragraphs, links etc. but aggressively so that anything within our enclosing HTML can have some certainty of aligning and looking right.
We appreciate that this may be a contentious approach to styling, and whilst that may be true for some users who want more control of the event structures, this idea was born out of the (very) frequent requests for customizations of the style in their themes. The important thing is that the choice always remains yours and you can turn this styling off in our Settings > General > Styling Options section.
We hope to keep tweaking this subset of CSS rules to allow greater flexibility with regards to providing a consistent look, both for you and us, whilst allowing your themes to do what they do; make your site look good! In all cases, we keep our styling overrides with Events Manager content.
The Silver Lining
As you read this, if you’re one of those users who upgraded to 6.0 and ended up with a very different events plugin to what you had before, I again sympathize with any pains you’ve experienced getting things back to what you’d like in terms of looks. I’ve been there, having updated a crucial plugin only to find that it broke my site and the result was hours of work to get things working again.
The silver lining I can offer is that this update opens up the realm of possibilities. There are a lot of requested features that simply could not have been implemented with our templates in version 5, we were experiencing a lot of bottlenecks on that front which stifled innovation greatly.
If Events Manager is an integral part of your business, or at least the events your business runs, then whilst you may have experienced some pains here with this update, they are growing pains and I sincerely hope you’ll end up with a much better plugin that will empower you for years to come! In that sense, think of the time you’ve spent getting 6.0 in line with your site as an investment for the future.
Case and point, two weeks after 6.0, version 6.1 and Pro 3.0 is about to be released as I write this. This is the first step of many to provide many new features to both free and pro plugins; this one being the breaking up of ticket and booking meta storage so that we can do many new things. The first new Pro features already available being attendance monitoring, printable PDF tickets including QR scanning.
Future improvements will now include changes to the booking admin area, such as better ways to locate and administrate bookings, guest booking access, Gutenberg integration, waiting lists and many features we’ve been itching to implement but have been blocked by limits in our design UIs.
Conclusion
I hope the above will give some perspective as to why such a sudden change was necessary. With big changes can come big improvements, and we hope we’ve also achieved (and will continue to achieve) that.
I hope you hang on for what’s going to be an awesome new part of our journey!
We’d also like to thank everyone for their encouragement, patience and positivity, the vast majority of those who did run into frustrations due to upgrade issues have remained calm and constructive, handling themselves with grace and a level of persistence which will no doubt result in awesome event websites, powered by Events Manager!
Wishing you all the best,
Marcus
Lead Developer