WP Router Placeholder Page

[Joe]

Just updated to latest versions and my community page is now broken. If I deactivate the Views plugin built by WP-Types, the issue resolves. Running the same setup on another site (www.alabamabirdingtrails.com) I do not have an issue. Both sites are built with Views. Any help greatly appreciated.

[George]

Hey Joe,

Thanks for reaching out.

In your post you say, “If I deactivate the Views plugin built by WP-Types, the issue resolves.”

This is indicating that code within the WP-Types plugin itself is hindering things here, so I would recommend opening a support thread with the WP-Types folks about why their plugin might be acting up here.

Please do keep us posted on what they say!

In the meantime, I’m wondering:

1. Can you share what your site’s Permalinks settings are? These are visible in your wp-admin in Settings → Permalinks. Are they set to /%postname%/, for example?

2. You say, “Running the same setup on another site (www.alabamabirdingtrails.com) I do not have an issue.” Is this site hosted on WP Engine, like http://www.tourwestalabama.com is?

3. If you leave WP-Types active and do all of the “Flush permalinks” steps listed on this article, do you get any improved behavior? → https://theeventscalendar.com/knowledgebase/fixing-http-404-errors/

Thank you!
George

[Joe]

Permalinks are set to post name. (/sample-post/) on the Tour West Alabama website.
on the Alabama Birding Trails website where community events is working permalinks are set to http://alabamabirdingtrails.com/2016/10/25/sample-post/
But, permalinks are set to post name on the alabamacommunitiesofexcellence.org website with the same build and things are working there. So it doesn’t appear to be this issue.

All sites are located on WP Engine.

I cloned the site to a staging area on WP Engine and now I get the following error (only on staging):
Warning: Missing argument 2 for WP_Router_Page::get_title() in /nas/content/staging/westal2015/wp-content/plugins/the-events-calendar-community-events/vendor/wp-router/WP_Router_Page.class.php on line 144

When I deactivate the WP-Types Views plugin, the community events plugin works on the test site as well.

[Joe]

FYI, the link is broken as of 4.3, not just the latest version as I thought earlier. I reverted to an older version and it did not resolve.

[George]

Hi Joe,

Thanks for testing things and reporting your findings. I cannot reproduce any issues with this behavior, and we don’t have any other reports of this behavior, so this seems to be clearly caused by WP-Types.

Have you opened a support thread with them? If so, what has their diagnosis been thus far?

We unfortunately can only provide very limited insights into other plugins, so I’m afraid to admit that I don’t know why WP-Types is breaking things here.

Please do keep us posted on what the WP-Types have to say about these issues!

Sincerely,
George

[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.

[Joe]

I was able to resolve the issue by removing control of the “Home/Blog” in my archives selection. I wasn’t really using it anyway, so it wasn’t an issue for me, but it did take some troubleshooting on the part of the WP-Types folks. The explanation above makes sense. Hope this post helps others.

[George]

Thanks for sharing this, Christoph! And for the update, Joe.

Open a new thread any time if other issues or questions arise.

Cheers,
George

[Author]

Posts