Hi Joe
Thanks for the feedback and the report.
This is Juan, lead Views developer. I was also able to replicate this issue, and I spent some time debugging it. To explain what is happening here I need some background. Sorry for the lengthy comment, but I promise it will be worth it 🙂
When applying a WordPress Archive to an archive page, we first check whether we are in that archive page. We do so using a WordPress action, named pre_get_posts, and we do it at the natural priority, which is 10 by default. Not sure whether you are familiar with WordPress hooks, but an action is just an event that gets executed at some point on the natural page render flow. So we have a callback attached to that action, on the natural priority 10, which means it does get executed not too early and not too late. In our callback, we check whether we are on an archive page, whether that archive page has a WordPress Archive assigned, and we initialize our rendering process in case all is correct.
Now, this other plugin The Events Calendar: Community Events does something on its own. It creates some faked pages, like this one to create an event over events/community/add, but aso some others over events/community/edit, events/community/delete, events/community/list, and some more. The way it creates them is not actualy creating a post for them, but it registers a permalink route, that matches those listed above, and when it detects that someone is accessing any of those routes, it loads the matching page: to add an event, to edit it, etc etc.
The main problem here is that all those routes, as they do not match actual pages, in the eyes of WordPress are basically the homepage with some dressing. That is why the mechanism thay this plugin uses to display its content, after checking that you are using one of their registered routes, later tells WordPress that this should not be managed as a home page, by turning a variable to FALSE. That check and adjustment is also done, surprise, on pre_get_posts, at the same priority of 10.
And now, here comes the conflict. When a WordPress Archive from Views is assigned to the home page, we check this very same variable, and as we register our callback eariler, we do get that we are in the home page, right before they decide and set that we should not be in the home page. That is why those dummt pages created by this community events plugins do display our WordPress Archive set for the home page: because in all truth, their dummy pages are the home page until they set it not to be.
What can we do there? Well, actually too little. The documentation for this very action states that is it OK to check whether you are in the home page right there, on this same priority of 10:
https://codex.wordpress.org/Plugin_API/Action_Reference/pre_get_posts
In fact, all the examples in that page will fail when used together with this plugin.
The solution can not be on our side. If I had to guess, I would say that the solution should be on this other plugin side. If you load a custom route that links to faked pages and you need to check whether you are in one of them, and then set that you are not on the home page, you need to do it as soon as possible.
The plugin is using this library here:
hidden link
If they accept a suggestion,I would recommend them to move the cllback for this action here:
hidden link
from the natural priority of 10 to maybe 0 or a negative value, so they ca be sure they do not cause issues on third parties, like they did on us.
Now, regarding what you can do, I would recommend opening a support ticket in their tracking system, explaining all that I tried to explain here. I would do it myself but as it is a premium plugin you do need to have a subscription. Of course, I am completely open to follow up with this and provide any extra reasoning or example that you might need in that ticket.
Hope it helps.
Regards.
