Problems with hijacking the post by this plugin

  • Hi,

    I used the events calendar on several sites, mostly genesis using child themes, and found there are some problems in themes that use a page image and title in the header above the content. I’ve performed some customizations to the themes to get it working somewhat, but lately I dove some more into it.

    To my suprise the TEC plugin actively blocks the theme of showing post info or an image beloving to an event post, by replacing the post object by a mock object. That is problem for me, because there seems to be no other way of blocking that behaviour then changing some code in the plugin. And then after every update I have to again change that code.

    I’m trying to retain as much as possible of the genesis hooks and functionality (like sidebars and the page header), so I first changed the settings to use the normal page template of the theme, but then the featured image is not used, and I need to stop TEC from blanking out the post object.

    Right now all seems to work well when I comment out line 240 and 241
    in \wp-content\plugins\the-events-calendar\src\Tribe\Views\V2\Template\Page.php

    // Replace the Mocked post in a couple of places.
// $GLOBALS['post']      = $mocked_post;
// $wp_query->posts      = [ $mocked_post ];
$wp_query->post_count = count( $wp_query->posts );

    What plugin decides to block theme functionality this way? I don’t understand how you can think this is a good idea? Actively hijacking the theme without installing an obvious way to stop that behaviour? It cost me a lot of time to even find out that TEC did this. Not cool.

    I know the target audience of genesis and TEC likes coding, but I don’t like code that must be manually changed (and remembered) after every update.

    At least I now understand why a theme like Essence Pro (Studiopress) has had so much trouble displaying the correct page-title and why Breaktrough Pro doesn’t display the header image by default in event pages. It’s been an active sabotage of those theme’s functionality.

    Is this something you may reconsider? Please do, or give a workable alternative to manage this problem, without having to change the code after every update.

    Thanks,

    Hans

    The page I need help with: [log in to see the link]

Viewing 11 replies - 1 through 11 (of 11 total)
  • Thread Starter Hans Schuijff

    (@hanswitteprins)

    It’s a bit of a rant perhaps, but this functionality has also other effects related to plugins.

    Yesterday I noticed a layout “problem” with the event pagination and when I explored it, I found it was caused by the global $post variable’s ID being 0. I didn’t think about the hijacking at that point, but there had been a version update, so now I’m connecting the dots.

    The Sensei LMS plugin had no id the $post->ID could be 0 and just tested for the $post being an object, expecting it then would have a valid ID, instead of the mock ID it got, being 0.

    The 0 was then compared to a couple of ID’s in the setting, one of which was also still 0.

    So it marked the page as being a Sensei LMS page even though it was a single event and the the css belonging to Sensei LMS pages kicked in at that point.

    So I had invest time there and had to correct this false positive of occurring, writing an issue in the Sensei LMS github, informing them of this occurrence and so on.

    In the end this mocking and hijacking can have and has consequences that can perhaps cannot be overseen. Not great, for otherwise such a professional build.

    Plugin Author Matthew Batchelder

    (@borkweb)

    That is quite the debugging journey and I appreciate your efforts on that front! The mocking of the post solves a lot of issues on a number of sites, though, the use case that you have laid out makes the mocking of posts less than ideal. There is a way to disable the mocking of the posts without directly editing that file – and your digging helped me find the right filter!

    Placing the following in your functions.php file (or wherever you think is most appropriate) should do the same thing as your commenting out solution:

    add_filter( 'tribe_events_views_v2_should_hijack_page_template', '__return_false' );

    Hopefully that will help!

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    Thanks for the suggestion @borkweb. I tried it, but that filter removes the entire content of the events page (replacing it with a normal archive that shows the entire single event pages) and that is not my purpose. I just need the content of $post to stay intact so the normal page header will work on single event pages. So I still need to comment out those two statements.

    Hans

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    @borkweb By the way, another plugin that had trouble with this hijacking was Bills and Jareds shared counts plugin.

    On the single event pages I noticed that the Facebook share button was missing some data in the URL, that made the link fail (facebook didn’t know what I was trying to share) and I had to customize for that too and filter the_content instead.

    I don’t know what use cases make the hijacking necessary, but it is inconvenient the way it is forced now. Plugins and themes should be able to tell what single page they are on when building the page header.

    It is better to know and than customize when something needs to change, than have no info and have to dig into plugins to find out it is hijacking and erasing the data.

    Just erasing all the post data, until the events calendar is ready for it’s own loop-version, doesn’t seem very elegant. Before the hijacking WP has already determined on what page is is. Hijacking might solve a problem, but also forces other plugins an themes to add exceptions and workarounds for your plugin.

    It seems a bit rude to hijack anything like that. And if you do, the hijacker should also be responsible for make sure it doesn’t hurt “normal” functionality where others depend on and making sure those others can restore the normal state, without having to resort to changing the plugins code.

    Just my thoughts on this. Hope the problem will resolve at some point.

    @hanswitteprins

    Hi Hans!

    I ran into similar issues when I was working on my personal theme a few years ago. Seeing this post inspired me to revisit the problem.

    Here’s what is happening:

    When using a template from your theme instead of the default Events template (set in Events > Settings > Display > Events Template), the $post variable is not populated with the actual data immediately within the loop as is expected. This means that core WordPress functions like the_ID(), get_the_ID() etc do not work properly, breaking any functionality that relies upon the $post data.

    The $post data does not get populated with the actual data until “the_content” is called within the template.

    I am not sure why the plugin does things this way, but I’ve encountered multiple compatibility issues over the years related to this. I’m going to bring this up again, to see if there’s a better way this could be done without causing the problems.

    In the meantime, I was able to slightly modify Matts suggested snippet so that things work as expected on the single events pages without breaking the main Events page.

    Try the following: 

    add_filter( 'tribe_events_views_v2_should_hijack_page_template', function( $should_hijack ){

	if ( is_post_type_archive( 'tribe_events' ) ) {
		return $should_hijack;
	}

	return false;
} );

    Let me know if that helps with your scenario!

    Best,
    Sky

    • This reply was modified 2 years, 9 months ago by Sky Shabatura.
    Thread Starter Hans Schuijff

    (@hanswitteprins)

    Hi @skyshab ,

    Thanks for the addition. The conditional did the job, so I added it to my core functionality plugin. At least now I can update without having to change the plugins code.

    regards,

    Hans

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    Hi @skyshab

    Sorry, I spoke too soon. It seemed to solve one of my websites problem, but two others using different genesis framework themes, lost the specific event parts of the page. So this solution is not perfect.

    I think it only works when the page is build using the block editor for the event details and tickets. Otherwise the pages break using this hack. The website the snippet solved was build recently and uses the event blocks.

    Switching to all blocks removes some data from the presentation (no field labels in the views) and (more importantly) complicates the duplication of events. Most websites I maintain have reoccurring events that must be kept separate since they use tickets on a per event basis.

    With the html used as an extra metadata repository by Gutenberg cleaning after duplicating using the duplicate posts plugins isn’t that straightforward anymore and I have had to resolve to using the code editor instead of the visual editor to correct data after duplication. Probably it deserves it’s own duplication plugin.

    Also I find the presentation of the non-block version a bit more complete in it’s presentation, f.i. since the fields still have labels there and the two columns layout with smaller text is by default more lean. So I probably have to make custom views to add some labels.

    It’l get there, but it’s not an easy plugin to explore and debug when something isn’t working (or even loading). Not all good, sometimes a hassle, but luckily also a lot of good.

    Thanks again.

    regards, Hans

    Hi again,

    Ah, ok. I only tested that with a basic event made in the block editor.

    I’m still going to keep digging in to this, but good to know it at least helps with block based events.

    Best,
    Sky

    Plugin Support Abz

    (@abzlevelup)

    Hi @hanswitteprins,

    It seems like this thread gone quiet, and there are no further activities. We assume that this is already fixed or no longer applicable. I would mark this as resolved for now.

    If that is not the case, please let me know, and I will gladly remove the “Resolved” tag and try to help you further. Or you can create a new topic with the problem if you prefer.

    Best Regards,
    Abz

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    Hi @abzlevelup ,

    As I stated above the problem is still there when events are made not using the block editor. So more communication from my end isn’t needed. For now I still edit the plugin source before each update to fix that. Is the bug closed then? I think editing the plugin shouldn’t be necessary. But then someone decided to hijack the post for some reason and made it necessary. There is nothing more I can do from my end.

    regard,

    Hans

    @hanswitteprins

    Hi Hans!

    I removed the “resolved” status, as I am still working on this.

    I reached out to several members of our engineering team and have scheduled time over the coming weeks to discuss further.

    I will post an update as soon as there is any news to share.

    Best,
    Sky

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Problems with hijacking the post by this plugin’ is closed to new replies.