Styles completely messed up

Thanks all for the work around. So I fixed my websites temporarily.

But … who came up with this dumb idea of changing fonts and sizes all over the place? This plugin should migrate into a website – not the other wy round.

Hello everyone, we’ve just released a dev version, 6.0.0.1 which implements some small but significant changes to the styling. You can now enable/disable styling elements to some or all parts of the plugin front-end.

Essentially the snippets I provided earlier can be achieved via the settings, the second snippet I provided won’t work either.

For upgrading dev versions, it’s just a few clicks in your dashboard:
https://wp-events-plugin.com/documentation/upgrade-dev-version/

If you have migrated to our new formats, and dismissed the undo option, do not upgrade! We’re made some changes to our HTML structures to make style choices more consistent, we’re implementing some tools to help update.

Bear with us a few more hours, I’ll also comment on all your feedback as there are some good points made here

Thanks @markus,
let me first say thanks for a powerhouse plugin. I love it.

I have managed to get the 6 version look like I want it to look, by disabling JS in plugin options. It then requires much less css to get it to where it was, and I don’t really need the functionality JS gives.

So I will not update to dev version yet.

However, in my mini calendar the month selector in the header section of the mini calendar, now does not follow neither my language nor the date format that I have set up, site wide and specifically in plugin.

With JS that worked properly.

I understand you have more pressing things to solve, but please when you find the time, can you help with this thing.

Thanks, and keep rocking.

• This reply was modified 2 years, 4 months ago by thisbit. Reason: I wrote the thing I did not intend. :)

-deleted-

• This reply was modified 2 years, 3 months ago by gb24.

-deleted-

• This reply was modified 2 years, 3 months ago by gb24.

Hi Everyone, thanks for your patience.

First things first, we’ve just released an update with lots of improvements in terms of flexibility for styling and formatting. Some highlights:

1. Advanced Modes – The usual ability to define formats in your settings page, but now you can disable this for some components and enable for others, so our default ph formats get loaded. Inversely, you can choose to load them all dynamically, or use only the settings page!

2. All these overridable formats can now also be reset individually to load the default format from our files. Helpful if you want to check out the changes (click the little undo icon next to each setting, settings aren’t saved until you click save).

3. Advanced Styling Options – The dev version introduced the ability to enable our styling in tiers, but now you can also choose to prevent a few font-related settings from taking over.

4. New template folder location – Aside from the theme, you can also upload your template files now to wp-contents/plugin-templates/events-manager/ – allowing theme-independent modifications.

Whilst not a 100% solution for anyone that made lots of customizations to EM, I’m hoping between this and our flexibility which has always been there in terms of hooks and templating there’s a way to get up and running with v6 using your old designs and migrating to new ones (or our new structures).

Generally speaking, most CSS classes were preserved, but we had to cut some ties with oddly named classes etc. to provide consistency and move onto modernizing the plugin.

I completely understand that when updating a plugin, you expect things to keep working. I use plugins too, and updating can be painful in times like this! That said, I also hope you can appreciate that these changes were necessary in order to enable us to make more improvements to the plugin at a foundational level.

We will inevitably still be making some changes, particularly to the booking forms and admin areas. However now with the base classes already in place it should be more consistent and less abrupt than this update.

I’ll end this reply now and address individual comments in a following reply.

@just4me67, @alfredo49, @stetson79 regarding !important;
I agree that it’s not good practice, however the authors of that concept don’t write plugins that run on thousands of themes that can do whatever they want. Getting a consistent look is very difficult, especially because many themes add generic styles with strong specificities we can’t control, such as:

#somethemeid .wp-content div { margin-bottom: 10px; }

Something like that makes it impossible for us to have something like this:

.em-calendar { margin-bottom: 10px; }

This wasn’t a decision we came to lightly, but the trade-off I believe is worth it in terms of compatibility generally. Also, you can now always disable our most generic !important theming via our settings page, use our CSS vars for certain overridden themes or simply override our !important styles with your own !important styles.

@thisbit
The JS issue please raise in another thread, we can look into it. Generally speaking, you will need JS for the full experience. However, we’ve tried to make it fall back to native ‘month’ pickers but some browsers still don’t support these.

@aprilschmitt27
You can still modify formats a always, but I’d be interested to know how it eats up real estate. Regarding indicators on a calendar, that sounds like maybe a CSS issue but I’d need to see it in action. @ ping me on a new thread about these.

@savoierider
I sort of addressed this in my previous reply. We had to break with some old classes because they were antiquatedly named and made some of the old CSS we left for bakcompatibility break our new styles.
That said, you always have the ‘nuke’ option which is to copy all the template files from the older EM version and override them (now you can also in wp-content/plugin-templates/events-manager)

@henningstummer
I’ll take the blame here ?? The font probably shouldn’t have stayed, at least not for new updates. It was always easy to override with a line of CSS in your Customzer > Additional CSS, but by default I agree that shouldnt’ be necessary. 6.0.1 will revert any upgrades to the theme default via ‘inherit’ and new installs will get the new font with the option to use the theme font.

END OF REPLIES!

On a note to @everyone here, I understand a sudden switch is hard… especially if you’ve spent time tweaking the old unstyled plugin into what you’d like on your site. I do hope, however, you give the new templates a try, we have a preview mode you could use, or give it a spin on a staging site. Some aspects you may want to change of course, that’s why we have formatting, templates, hoooks etc. and that’ll never change, but we hope there’s a good baseline for a prettier events plugin!

@msykes

I understand the reason behind 6.0.
But the power of EM was that there was little to none styling and we could use EM as we wanted and style it ourself quite easy if I may add. In my opinion that’s what made EM so strong. I doubt you could have know how many of your users/pro clients used this as a tool to make EM there own. That’s what made the big change to EM 6 for so many of us a terrible and horrible experience.

I can understand that some users have issues with that. Sometimes people just want to install a plug-in hit activate and be done with it. With EM after it was activated the fun began with customizing it to your site/theme our even company housestyle. That’s something that got lost with the 6.0 update. You solved it with the dev version 6.0.0.1.

This update was way too big and should have been beta tested by the pro users.

We’ll just have adapt some things, small and big… Still much appreciated work, thanks to the whole team!

@msykes
I really try to avoid css styles with !important. Sometimes it is necessary to use it but I don’t like to be forced to use !important in my stylesheet. Now I have to use !important to override your !important styles and to use !important in that way makes the CSS code confusing and the debugging will be hard, especially if you have a large style sheet.

@markus

First of thanks for all. Really apreciate the speed with which you reacted.

Regarding CSS specificity there are two reasons I think you are considering this in a wrong way:

First reason:

#somethemeid .wp-content div { margin-bottom: 10px; }

is not good coding practice but its more legitimate then

#someplugin .somelement div { margin-bottom: 10px !important; }

Because themes are resposnsible and should be responsible for the website style it is more ok, if they do specific style more so, then if a plugin does it. If a theme is not a good theme, that should not dictate your plugin practice (which in turn hurts good themes) but rather it is an issue theme authors should have to resolve.

Second reason:

There are things in your CSS I could understand the reasoning for being specific, for example the calendar view. But this should in my view relate only to general layout of the view, not font-family, colors and all that.

So, In my case its fine to turn all your JS off, but a more modular approach would be beneficial, where one could decide to turn on, or of different aspects of your css or js.

But, it is a great plugin, and as someone said, you may have not known, but your plugin is especially popular among the users that want to style the events themselves. Please just have these in mind in future updates.

Cheers

I have posted a detailed request of screen prints, in the EM Pro Support Forum. Thank you!

I updated to 6.1 now.
Thanks for the new options that is cool.

BUT new version again ovverrides the code I have placed in Formating for events, so I had to insert them again.
Do not do that, these are user overrides, otherwise it will require redoing on each update!!!

Best,
Elvis

It’s the biggest problem with the EM 6 update.
But they added a fix because most people aren’t happy with it. Not to mention some are furious.

You can disable the new class em and pixelbones under Settings –> General –> Styling Options (Advanced).

@thisbit

First reason:

#somethemeid .wp-content div { margin-bottom: 10px; }

is not good coding practice but its more legitimate then

#someplugin .somelement div { margin-bottom: 10px !important; }

Yes, you’re right but you’re forgetting something…. if you post the same content twice, e.g. two event lists, you can’t use the same ID. So, therefore we can’t write a CSS rule for dynamic IDs e.g. with a random number at the end to ensure valid HTML. Themes have that luxury to add a wrapper ID, we don’t due to flexibility.

That’s the reason. We’ve deliberated this a lot and !important really was the only option. At the end of the day, !important can still always be overridden, it’s just a way of being more specific.

Coding practices are not really targeted for developers making plugins, because we have to account for scenarios on website HTML structures for which we have no control over.

@thisbit (again) not sure what you mean about the overriding, please post a new thread and we can address it separately.

@crossroast I’m aware you have a few issues with a couple of layout/structure issues, I’ll get to your tickets ASAP, we’re going through them ASAP. Note though that in every situation you have full control to override anything we’ve made, so we’re as flexible as ever, we’ve just added styling which can be disabled. We overlooked disabling pixelbones in the 6.0 update, and fixed that within a couple of days, forcing it on ppl was never the intention.