Benny

Hi Darian,

They can check and see it this is failing (and thus the blocks aren’t registered)

https://github.com/the-events-calendar/the-events-calendar/blob/master/src/Tribe/Editor/Provider.php#L20

I tested that and that isn’t failing.

I think the cause is that most event block assets are only loaded when $current_screen->post_type === ‘tribe_events’.

@donbowman would like to build a block pattern using Event blocks, but when he tries to do that using BlockMeister the check above of course will fail because post_type is not ‘tribe_events’ but ‘blockmeister_pattern’.

So when he looks in the inserter (when in the BlockMeister pattern editor) he only sees the Events List block, non of the other Events blocks will be available.

I guess this incompatibility will be the same for any block pattern builder/manager plugin.

Maybe a solution would be a setting in Tribe Events for allowing other post types or a filter?

Also:

I just noticed that the plugin sends old style template tag values to Sendinblue to be merged with a new language style templates. They show (unprocessed) up in the merged email, e.g.:

This email was sent to {{ contact.EMAIL }}

So basically currently it is not possible to use custom templates in the plugin.
I hope that the plugin will be soon updated to become compatible with the new required template language used in the Sendinblue back-end.

• This reply was modified 3 years, 4 months ago by Benny.

Hi @lephenixdelafamille,

No, I did save actually everything!
Because of another problem I am facing, new templates weren’t showing op in the select input boxes, I save everything and try to refresh the template list by logging out and logging in again. After everything I set was gone, even the title of the form was default again. This happend a few times before it daunted to me that it was caused by the logout/login.

Best regards,
Benny

I learned that the hard way too ??
@sendinblue, I don’t understand why this isn’t improved yet?

Hi @spacedmonkey,

I confirm, it works now!

Maybe this helps:

qTranslate adds for any option in the DB a filter to process its content:
add_filter( 'option_' . $option, ...

In your class Simple_Cookie_Control_Public you read the option in the constructor.
It seems this happens before the plugins_loaded action and thus before any third party plugin has a chance to add option filters.

The plugin is: https://github.com/qtranslate/qtranslate-xt
This is a fork of qTranslate-X.

But I am pretty sure the same problem will occur with any multilingual plugin.
The author of Polylang expalins the issue here: https://polylang.pro/dont-take-any-action-before-plugins_loaded-is-fired/

Since everything within the plugin is registered via hooks, then kicking off the plugin from this point in the file does not affect the page life cycle.

I understand, but then one of your internal hooks is maybe running your code to early because the translation plugin isn’t initialized at that point and isn’t able to offer it’s translation functionality.

Yes, I see (and know) the dilemma.

In my own coded blocks I would use ‘block deprecation ‘ but I am not sure if this is also possible in the context of extended core blocks?

BTW: I quick-fixed this for the moment by removing the empty() check. After this the plugin activated but the same error popped up on another location:

Likewise in your class-notice.php, method has_notices() also produces that fatal error on:
return ! empty( $this->get_notices() )
I fixed this by replacing that line with:
return sizeof( $this->get_notices() ) > 0;

• This reply was modified 6 years, 8 months ago by Benny.

Hi Adeel,

For CloudFlare, you don’t need to provide any additional detail in the plugin since it does not provide a CDN URL.

So we don’t even have to select ‘Activate CDN’ because Cloudflare acts on its own because it has full DNS control?

Breeze is compatible with CloudFlare.

Do you mean by that, just that they technically don’t conflict or that Breeze enhances it somehow? How?

I confirm that this bug was fixed in v1.0.6

I confirm that this bug was fixed in v1.0.6

Any ATA on when this bug will be fixed also?

Why didn’t you increase the version number (it is still 2.0)?

Because of that the WordPress built-in update mechanism won’t kick in for existing users. For them the only way to get the new version is a manual reinstall, but unless they read this post, they wouldn’t even know the 2.0 version changed.

You also didn’t update the changelog.

Great to hear. But in order to use your service over https the plug-in should be updated too. The plugin now calls
https://www.tiviclick.com/plugin/js/?account_id=
which should be changed to
//www.tiviclick.com/plugin/js/?account_id=

By making the call protocol-relative it will work regardless the protocol (HTTP or HTTPS). If this isn’t changed the popup will still be blocked because of the mixed content issue.