Issues with events manager pro 2.6.8

Plugins Plugin Support
1

Hi, the last days I had an issue with an update for events manager pro (2.6.7 → 2.6.8).
The update was marked as “compatible with CP” but when I tried to update I first got this error message:
PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Then I did the update manually by uploading via FTP. Activating was no problem but than, trying to add a new event or editing an existing event, the editor was not usable anymore. Just an empty box…

So I contacted the support team. They said that EM-Pro should be compatible with WP4.9.x and ClassicPress. Then I did set up a test system and they could reproduce the error that the editor is not usable anymore. And they fixed the problem really quick.

This is the explanation I was given:

After a little debugging, the fix was relatively simple, we use wp_date(), a function introduced in later WP updates. It’s the kind of thing most event or date-driven plugins would probably switch to. However, we have our own internal date functions that check for compatibility, we should have used that to begin with as that now fixes the problem.

Check it out, does it work for you now? The file changed is events-manager-pro/add-ons/coupons/coupons-admin.php

I’m surprised ClassicPress hasn’t implemented that function, just to prevent unnecessary breakages in plugins.

I think it was Marcus I wrote with, and we agreed that this should be posted in this forum here.

Yes, supporting wp_date(), even as a polyfill would greatly increase ClassicPress compatibility with newer plugin updates, as date_i18n() was the previous version of this function and it’s simply a replacement of the same. If you can suggest it to them, that’d be appreciated!

I am posting this here now so that the proposed adjustment can be implemented in future versions of ClassicPress.

Best wishes!

1 Like
2

@james this seems important.
If plugins working with WP 4.9 start to use function introduced during WP 5.x release cycle, they can basically maintain compatibility while expressing issues like this one because CP has not the new function.
I think changing the function for one single plugin can harm many others which use the old one, is there a way to implement both?

3

The problem as I see it is that CP would end up just like WP5.6 (without the block editor of course). Each time WP introduces a new function or filter or whatever, are we expected to add it to CP?

There were 150+ new filters/hooks added in WP 5.0.0 alone so it’s an impossible task to add them all. Admittedly, many of them are block related but even so, it’s still a lot. And one of the key goals of CP is, of course, to keep it lightweight.

I’m not saying we should never backport a new function. Some could be useful. But we do have to be very selective.

In this case, it would be very easy for developers to do something like:

if wp < 5.0 then date_i18n()
else wp_date()

and in doing so, they retain compatibility with a much greater number of installations. Remember, something like 20% of WP users are still on version 4.9 or less.

3 Likes
4

@1stepforward this was my idea also.
We have to accept that CP is slowly but surely differing from WP.
This means that plugin devs need to use checks like the ones you mentioned to make sure the plugin still works with CP.
I am reflecting on a way to make these information available, because it’s possible that a plugin dev is not aware of that.
Also they clearly were thinking it “should” work with CP but it’s obvious they didn’t test. They were able to replicate the issue so I wonder if testing before releasing would have shown the issue.
The sentence “if it works with 4.9 it should work on CP” is starting to have some caveats…

5

There is no should work … if it does work on WP 4.9, it will work on CP 1.x. In this case, it didn’t work on WP 4.9 – so, rightfully, there was no chance it would work on CP. This isn’t a caveat in our reasoning; it’s a lack of developer testing and, instead, a reliance on assumptions that don’t hold true.

It’s not our responsibility to make up processes and procedures and documents to account for a lack of testing. Developers must take personal responsibility for their plugins/themes being compatible with WP 4.9 if they want to claim that compatibility.

8 Likes
6

There’s a similar issue here:

1 Like