[Christoph]

I’m also having both issues that Cody described.
For months the plugin does not work properly.After each update there are new issues.
I have paid for it and expect a corresponding performance

[Christoph]

I’am still waiting for a solution.
I have paid for the script and can’t use it since weeks. That

[Christoph]

I still waiting for a solution for the problems.

[Christoph]

I haben the same problem.

Juan from the wp-type company postet this answer in the support forum. Maybe it helps to fix it:

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:
https://github.com/jbrinley/WP-Router
If they accept a suggestion,I would recommend them to move the cllback for this action here:
https://github.com/jbrinley/WP-Router/blob/master/WP_Router_Page.class.php#L93
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.

[Christoph]

@George

1. How often are you running imports?

Normally daily but in the we Event Aggregator we switch to “on-demand” and can’t import anymore as you know-

2. How many pages/sources are you importing from?

We usually import from about 300 facebookpages. We only import from facebook.

[Christoph]

This reply is private.

[Christoph]

Thank’s for your help Joseph, but this , of course,does not really solve the basic problem.
And the support doesn’t answer.

[Christoph]

Same problem here. Meanwhile I habe about 250.000! comments from Event Aggregator.
All events are set to “on-demand”.

[Christoph]

I am very angry. Nothing works.
Two days ago with your script I change the frequency to “on_demand”.

When I now try “Run_import” I always get the message “The daily limit of 100 import requests to the Event Aggregator service has been reached. Please try again later.” and nothing happens.

In the meantime the import history shows over 60.000 entry (see screenshot). It looks like the script try a update every few minutes. But no new events were created.

I really need a quick fix now!!

[Christoph]

Hi Leah,

thanks, your script is working.

I’m not sure what you mean- the default in EA is Daily, and I believe the default in Facebook Importer is Weekly. That said, if you had changed the Facebook setting to Hourly, then that’s how your Facebook imports migrated into EA.

In the old facebook importer tool I had switchof the schedule import. This was unfortunately not taken into the migration tool.

[Christoph]

Yes, I have use the Migration option.

I think I was wrong when I say “_in most cases_ EA wasn’t recognizing the event”
Only 1 event which was imported with the new EA was updated.

The Frequency for updates is “hourly” in the standard settings.
Who can I change the without open each of the over 300 entries?
It is possible to switch of scheduled import completely?

[Christoph]

Sorry to hear about these issues! Just to be clear, when you mention the “Views” plugin from Toolset, do you mean this one?

Yes I mean this one

1. Have you had this plugin activated on your site alongside our plugins for a long time? Or have you only recently installed that plugin?

I use this plugin and also events Calendar for a long time.

2. If you’ve had it installed for a long time, did these issues only arise after a recent update to that plugin? Or a recent update to Community Events?

Unfortunately, I do not know since when the error occurs. It may be after an update of the view plugin or the community plugin.

In the meantime, can you also elaborate on what you’re trying to use the Views plugin for in relation to the Community Events submission page?

I don’t need the view plugin for the community events, but for other parts of the block.

I hope you can help

Christoph

[Christoph]

I think the problem has something to do with the web site language
If I switch from german to english (us) language everything works fine again.

[Christoph]

I think the problem has something to do with the web site language
If I switch from german to english (us) erverythink works fine again.

[Christoph]

This reply is private.

[Author]

Posts