Hans Schuijff

I dove a bit in Redis and think I might understand something now.

It seems that Redis stores all simple values in string type format (or at least it doesn’t store any boolean values as boolean), so when you try to store a boolean value to it, that value must be type converted to a string value. php translates false to an empty string and true to a string with the number 1 in it, so that might explain the empty string return value of the get.

I have checked the Redis cache and it contained the key wp:tribe-events:tec_editor_compatibility_toggle_blocks_editor with an empty string value, so it is found by Redis and it will not return null or true/false as result of it. Instead it will always return the string value of the initial false that is stored as an empty string, and TEC doesn’t translate that to the falsey value of false.

When I remove the key and refresh the page the key is added again with again an empty value.

So redis will find always find the key (and not return false or null), but with a value that is of no use to TEC, since TEC always checks for boolean or null to determine what to do.

I am not sure where the value exactly is added, since I haven’t seen a call to the redis::set() method being executed. But from what I understand of the code in TEC it must be a type translation problem that causes it.

It could probably be solved by TEC by not trying to storing a settings in boolean format in the cache.

Also it seems that TEC stores the value in redis independent on what page I am. Refreshing a Redis settings page also added the key back to the redis cache. I would have expected that to happen only on an event admin page.

Well that must be enough for this error I think. The problem is clear, now TEC needs to decide if the plugin will change as a result. For now TEC and Redis are incompatible

I think I have found what causes the event calendar to fail for us. We have Redis setup on our environment and when I disable the object cache there, it works like it supposed to. When I enable the Redis object cache it fails again. Is that a know issue and are there solutions available, besides not using Redis?

Don’t know why it only fails in the events calendar v6.x. Version 5 didn’t have this issue for us.

Alright, I looked somewhat further and notice that the difference between a local setup that does open the block editor and my production/staging system that doesn’t happens the first time Tribe__Events__Editor__Compatibility::is_blocks_editor_toggled() is executed.

In the system that shows the block editor correctly the first time that method is executed it first checks the cache value and when it is null it will continue to the end where it sets the cache value to null too and returns the null value to Tribe__Events__Editor__Compatibility::is_blocks_editor_toggled() that then continues and sets the value to boolean true.

The system that doesn’t show the block editor follows the same logic, but bails out early when an empty string is returned instead of null. So in that system the logic that should set the cache with the true-value is never executed.

When I check Tribe__Cache::get() it calls wp_cache_get( $this->get_id( $id, $expiration_trigger ), $group ); but that call returns a different value on both systems.

In the system that opens the block editor wp_cache_get() returns the boolean value false and in the other system wp_cache_get() returns an empty string and that causes the problem further on.

I don’t know why there is a difference in response of wp_cache_get(), but that is where the problem originates.

Hi,

Always disappointing when support has no solution and then tries to close a thread without one. Helas not the first time this happens. The last advice I got here was to wait updating untill the problems where solved, but they aren’t solved and the thread is now marked as such. I don’t understand that.

I’ve done some digging on my own and found at least a thread of the problem in the code. I don’t understand it is not traceable when more people have the problem and I myself have it on different implementations on different hosts.

Trying to trace it using var_dumps I end up in the method Tribe__Events__Editor__Compatibility::is_blocks_editor_toggled_on().

The first statements are:

$cache     = tribe( 'cache' );
$cache_key = 'tec_editor_compatibility_' . static::$blocks_editor_key;

$is_on = $cache->get( $cache_key, '', null );
if ( $is_on !== null ) {
	return tribe_is_truthy( $is_on );
}

A var_dump() on $cache shows:

object(Tribe__Cache)#19401 (1) {
  ["non_persistent_keys":protected]=>
  array(1) {
    ["is_divi"]=>
    string(7) "is_divi"
  }
}

And $cache_key contains ‘tec_editor_compatibility_toggle_blocks_editor’.

Then $cache->get( $cache_key, '', null ); returns ” (an empty string) what makes $is_on !== null true
and makes tribe_is_truthy( $is_on ) return the value false.

So if I understand it correctly the key does not exist in the cache and so the function returns false and the legacy editor is shown instead of the block editor.

The problem that needs solving then is why doesn’t the cache contain a value for the key “tec_editor_compatibility_toggle_blocks_editor”?

In settings the option for using the block editor is checked, so it should return true.

Is that of any help or do I need to dig further?

regards, Hans

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