Hans Schuijff

@rsouzaam Great, thank you!

@j0aoj0aquim @rsouzaam The line of code is easy enough to solve, just check the return of the function for type before using it as an object.

Changing the line I mentioned earlier in something like this will solve it.

? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
? ? ? ? if ( ! is_object( $response_headers )
? ? ? ? || ! method_exists( $response_headers, 'getAll' ) ) {
? ? ? ? ? ? return [];
? ? ? ? }
? ? ? ? $response_headers ?= $response_headers->getAll();

or

? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
? ? ? ? if ( ! is_a( $response_headers,"WpOrgRequestsUtilityCaseInsensitiveDictionary" ) ) {
? ? ? ? ? ? return [];
? ? ? ? }
? ? ? ? $response_headers ?= $response_headers->getAll();

or something like:

? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
? ? ? ? if ( is_array ($response_headers ) ) {
? ? ? ? ? ? return [];
? ? ? ? }
? ? ? ? $response_headers ?= $response_headers->getAll();

Any of those should prevent the crash.

Looking more closely ate the code before the crashing statement, I’m guessing this function will crash when a pro version doesn’t have a license code. So that might have been the underlying problem. I don’t know what version you’re talking about, but it might explain why it hasn’t been reported here earlier.

Since the wp_remote_retrieve_headers() function may still return an empty array (instead of an WpOrgRequestsUtilityCaseInsensitiveDictionary object) when is_wp_error( $request ) returns false, it may be right to just check for the type of the header before using any methods on it anyway. Not crashing seems the more elegant way of resolving such issues.

Problem solved. Thank you!

Version 3.0.5 is crashing, because the files in /wp-dark-mode/includes/wppool/ are missing. Please correct.

@glycymeris , In my still open thread I have a reaction from TEC support. It is now an accepted support case for them, but no timeline as yet.

Masood (@masoodak) said:

Hi @hanswitteprins,

Thanks for reaching and bringing this to our attention.

Our development team has started tracking this in a bug report in our internal system, and a fix for this will hopefully be added to a future update of the plugin.

Many thanks for digging into this and sharing the details.

Kind regards,
Masood

(Ref: TEC-4613)

@ornanovitch Glad it helped.

It seems that the stuff that breaks things for me are often done for some technical dev related reason rather than for functionality that is important for me as a user. I’m not sure that’s a good thing.

F.i. I still have to remove manually the statements that hijack the post in /src/Tribe/Views/V2/Template/Page.php line 241 and 242 so my themes header can show event titles. It’s been reported by me, but for some use case (so it said?) it is still in. Using blame I only traced it back to a commit that wanted to split page and event template, but that’s not a concern for me. For me it only means my theme isn’t able to get the event title when it builds the header and I need to fix that myself.

or how switching to blocks means having metadata like tickets related to an event in the html so when I use the most populair (yoast) duplication plugin that has always worked for me on events, I now have to remove the tickets related tags in the code editor to clean up the duplicated event.

Perhaps the gutenberg site editor and newer versions of plugins will fix that sort of problems eventually, but until it does changes are not save enough and seems to need technical skils to implement in the sites. It should ideally be more dummy proof.

@masoodak Thanks for informing me. Hope it will get fixed soon now.

Kind regards,
Hans

Looking in the github repo, I think I found the commit that has caused all this trouble for us. Before this commit the editor toggle was saved in a static property, but this commit changed that to using the cache for test purposes. Helas it broke compatibility with Redis in doing so.

Commits on Sep 6, 2022
Cache the block editor toggle via cache object 
Using the cache object rather than <code>static::</code> values allows automated tests to expire the cache.
@borkweb

The link to this commit is:
https://github.com/the-events-calendar/the-events-calendar/commit/4fd81db59018fa05e02fe3a3e536a13f77e6c1aa

It seems to be merged in TEC version 6.0.1, so that explains why it broke since version 6.

Also I found that when I manually store the string value “1” in the toggle key in Redis, that the functionality seems to work, but of course that would hard code the outcome instead of letting the settings do that.

Please undo this commit or change the solution so it will work with Redis too. More details on what happens using redis, in the other thread.

@glycymeris I have added a new support thread for this issue and pointed to this one, so it would still have an open thread for this problem and I think the problem is now clear enough so it can be fixed easily when someone wants to do that.

Looking in the github repo, I think I found the commit that has caused all this trouble for us. Before this commit the editor toggle was saved in a static property, but this commit changed that to using the cache for test purposes. Helas it broke compatibility with Redis in doing so.

Commits on Sep 6, 2022
Cache the block editor toggle via cache object 
Using the cache object rather than <code>static::</code> values allows automated tests to expire the cache.
@borkweb

The link to this commit is:
https://github.com/the-events-calendar/the-events-calendar/commit/4fd81db59018fa05e02fe3a3e536a13f77e6c1aa

It seems to be merged in TEC version 6.0.1, so that explains why it broke since version 6.

Also I found that when I manually store the string value “1” in the toggle key in redis, that the functionality seems to work, but of course that would hardcode the outcome instead of letting the settings do that.

Please undo this commit or change the solution so it will work with Redis too.

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