Hans Schuijff

Same problem here. Just to share it is more widely spread.

First not able to even run the preview for running on php v8.1.x, next on php 7.4.x being able to migrate, not getting the block editor anymore. So undo the migration and going back to tec v6.0.1 and again migrating, and it seems to work, until upgrading the plugin again and no longer getting the block editor.

It makes me not trust the current version and I reset the system to an earlier state for now. For now I returned to an earlier version without the migration, so I both have the block editor and the tickets are shown properly again.

In php 8.1 I saw some fatals about the logging and DateTime receiving a null argument, what is deprecated.

That’s probably due to version 1.x of the monolog dependency, instead of version 2 or 3. Using dependencies that are not meant for php8, can been seen as a problematic choice. So why keep using them?

php 8 still also causes lots of deprecated log entries, by both WP and all kinds of mainstream and premium plugins, so that’s a shame, since using current php versions should be the preferred way.

In php 7.4 I didn’t see concrete clues in the error logs, but haven’t checked the console.log, so perhaps that would have given some info. It’s to complex for me.

For now I wait on a more stable and (production) tested version. To many moving parts to quickly problem solve this breaking upgrade. Hope someone more experienced will figure it out.

sharedcounts.com replied, and points to Facebook for the problem:

Facebook had rolled out an update on how the counts are shared which causes the differences on the counts for every API call. From our observation, this affects URLs with relatively low counts.

This update was actually rolled out on June 2021. We are working on this and hopefully we can get more accurate calls as soon as possible.

I understand, Bill, but since you choose to use this service I thought those results would also be of interest for the plugin and other users. I imagine you choose this api because you expect it to give accurate social share info.

I have passed the question through to sharedcounts.com too and am hoping to get some response there. Since I think it’s an api problem I will close this issue here.

thanks,
Hans

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

Hi @abzlevelup

There is no reason for more interchange until the tribe_is functions work again. Are they fixed yet?

regards,
Hans

Hi @nicw ,

Sorry for the delay. I think I use the plugin you mention although I have downloaded from www.remarpro.com. I use the latest version 7.03.

I also have reported the bug to mollie and in the response Niklas (@niklasinpsyde) replied that the plugin doesn’t yet support woocommerce blocks.

Also it has rolled back the attempt to support it in version 7.0.2 so it is a known problem in Mollie’s plugin. I don’t know what is the timeline of this, but it obviously is an inconvenience since the block editor has been the WordPress standard for some time now.

For now I have chosen to disable WC Blocks since our shops cannot function without a functioning payment gateway.

regards,
Hans

Hi @skyshab

I haven’t tested your conditional suggestion, but it might also work. Thanks also for the gist, that solution is already part of my core functionality, but perhaps the other responders still need it.

My current workaround is enough for deciding when to use the_content instead of the normal genesis loop. Before this I used the more granular version that is suggested in the support pages, but actually for the genesis integration this is enough and I don’t have to know what view the archive uses.

For anyone the needs the same, here is the code I found to work…

function is_tec_archive() {
	if ( ! is_tec_active() ) {
		return false;
	}
	if ( ! \tribe_is_event_query() ) {
		return false;
	}
	if ( \is_singular() ) {
		return false;
	}
	return true;

}

function is_tec_active() {
	return class_exists( 'Tribe__Events__Main' );
}

Thanks, Hans

Hi @skyshab ,

Thanks for the acknowledgement of the bug. It seems this part of TEC is not ready for v2 and advising to switch back to no longer supported views (that come with warnings that they would be killed as of august 2021) seems a bit odd.

Since the tribe_is_event_query() is still functioning properly I have for now just used that to check if I’m on a event page, but in the end there should be a functioning way to determine what page a visitor is on.

That the plugin doesn’t signal that it isn’t working properly might also be a problem. If it is a known bug that is there for many months now, a log warning or something might also be appropriate.

I hope at some point the bug will be fixed.

Thanks & regards,

Hans

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 @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

Hi @niklasinpsyde

That might explain it. Then perhaps with the new version it will be solved and I will wait for that.

But it is worrying that even when I don’t actually use the blocks the plugin still can cause the payment gateway to completely disappear and block customers from payment without some clue of why. Since everything WP is going Gutenberg, block support is becoming more than a luxury, but I appreciate the plugins are becoming ever more advanced and complex.

Hope it will be solved soon.

Thanks,

Hans

Hi Niklas,

Thanks for your response. I understand it must be something abnormal, since woocommerce and mollie are so widely used that a mayor problem like this could not remain in the software if it was widely occurring. Such problems are often not easy to pin point to an individual plugin.

I now have updated WooCommerce to version 6.2.1 again and found that when WooCommerce Blocks is disabled it works (at least for now). So there might be a conflict betweeen your plugin and WooCommerce Blocks. I don’t know which plugin is the cause, or should solve it, but it might be wise investegating.

I can give you access to our staging environment if you want to check something there. I now have reported the issue to WooCommerce Blocks too, so I don’t know where the action should lay.

Regards, Hans

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

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

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.

• This reply was modified 3 years, 1 month ago by Hans Schuijff.