Morgan Estes

Update: after some more searching, it’s actually breaking on a hyphen in the email address, not the ampersand. When the script calls const e = t.data.split('-') it expects e[1] to be the stringified JSON string, but with a hyphen in the email address it only gets a portion of the data, and fills e[2] with the rest.

So I just realized that I thought that site was on WP 5.4, but it was still on 5.3. I moved it to staging and upgraded to 5.4.1 just a bit ago and that seems to have fixed the problem without any other changes, so maybe a conflict between Kadence 1.8 and WP 5.3?

I just enabled SCRIPT_DEBUG on production, reloaded a basic page that has a handful of headings, and clicked in one of them. That brought up a whole bunch of React warnings, but the two that stood out to me were these:

Warning: React does not recognize the isPressed prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase ispressed instead. If you accidentally passed it from a parent component, remove it from the DOM element.

Warning: React.createElement: type is invalid — expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it’s defined in, or you might have mixed up default and named imports.

Stepping through the browser led me to find an element type of type:342/withToolbarControls</<(props) somewhere around Edit in each of the headings that has the problem, which looks like there’s a typo in the source or problem with the build script that’s leaking text into the return for the elements. It may be the heading, or the column or row that it’s nested under, but I’ll have to try changing it offline so I don’t kill the content on production if I want to find out more.

I can recreate it in Firefox (regular and Developer Edition), Chromium, and Safari on macOS, and others on the team are using Chrome on macOS and Windows, and Edge on Windows. At least one other dev was able to recreate it locally, but I can’t, so it’s possible there’s a plugin conflict somewhere we haven’t narrowed down to.

Yep. I’m on 5.4, and am not using the Gutenberg plugin.

Hey OKC neighbor! We’ve used a paid plugin called Event Aggregator to send events to multiple calendars. It is pretty straightforward to set up and was quick to integrate. Once it’s set up, it runs on a schedule so you don’t have to mess with it too much.

On a recent project, we used it to pull events from sites into a single aggregator site. It doesn’t have push capability to go from the main to the other calendars, but you can also set it up on the receiving end and pull from the main site.

Hope this helps get you going!

https://theeventscalendar.com/product/event-aggregator/

I can’t reproduce locally. I have found that sometimes plugin updates fail and remove some of the plugin files, but not all. Deleting the plugin and reinstalling it from the dashboard will ensure you have the latest version running, but that’s all I can suggest from the info given.

Hey @jakemason, we’ve been working with WPEngine on this but don’t have an easy solution in place yet. One thing that has worked for others has been to contact WPEngine support, let them know you’re using this plugin and the error you’re seeing, and ask them to apply the ruleset they’re using for bigwing.com to fix it for your site. I don’t know exactly what that rule/config is, but they have it documented internally somewhere.

I’m just starting to help out with this and hope to have a fix, or at least good documentation of a fix, soon(ish). In the meantime, WPE support has been very helpful in getting the changes made when you open an issue with them.

• This reply was modified 7 years, 8 months ago by Morgan Estes. Reason: fixed the name of the plugin and added that I don't know what the WPE rule is that gets applied

I noticed after some more testing that my change only loads the CMB2 stylesheet on the main options page but not any of the tabs. If it needs to load on the tabs pages, that’s a different hook that fires (because if course it is :/).

I’m happy to share another patch to load those styles if they’re needed in the tabs.

Sorry for the formatting, here it is again:

class Maintainn_Tools_Dashboard {

	/**
	 * The hook suffix for the options page.
	 *
	 * @var string
	 * @since x.x.x
	 */
	protected $options_page = '';

	public function add_network_options_page() {
		$this->options_page = add_menu_page(
			$this->title,
			$this->title,
			'manage_options',
			$this->key,
			array( $this, 'render_page' )
		);

		// Include CMB CSS in the head to avoid FOUC.
		add_action( "admin_print_styles-{$this->options_page}", array( 'CMB2_hookup', 'enqueue_cmb_css' ) );
	}
}

I have a small patch that will set $options_page so the dynamic hook fires at the right time and loads the stylesheet. It sets Maintainn_Tools_Dashboard::options_page from the hook_suffix returned by add_menu_page() so it can be added to the right action for the network page.

class Maintainn_Tools_Dashboard {

	/**
	 * The hook suffix for the options page.
	 *
	 * @var string
	 * @since x.x.x
	 */
	protected $options_page = '';

	public function add_network_options_page() {
		$this->options_page = add_menu_page(
			$this->title,
			$this->title,
			'manage_options',
			$this->key,
			array( $this, 'render_page' )
		);

		// Include CMB CSS in the head to avoid FOUC.
		add_action( "admin_print_styles-{$this->options_page}", array( 'CMB2_hookup', 'enqueue_cmb_css' ) );
	}
}

• This reply was modified 7 years, 9 months ago by Jose Castaneda. Reason: fixed code

Awesomesauce! I’m planning to install and test it on some client sites in the coming days. Looks like it’ll be a nice addition to my toolset.

It’s working now. Thanks!

Cool beans. Here’s my environment info if it helps:

$ wp cli info
PHP binary:	/usr/local/php56/bin/php
PHP version:	5.6.19
php.ini used:	/etc/php56/php.ini
WP-CLI root dir:	/usr/local/wp
WP-CLI packages dir:	/home/<user>/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:	/home/<user>/wp-cli.yml
WP-CLI version:	0.24.0-alpha

Hey @andym3kt, the CNAME is saved in the options table, but gets rewritten to https:// on the fly to prevent the conflicts with the Storage SSL support. In your case when you have a Azure CDN with SSL support, you can bypass the URL rewrite with a filter to ensure your CNAME gets used.

Include add_filter( 'windows_azure_storage_allow_cname_https', '__return_true' ); in your theme’s functions.php file or in a plugin to enable your SSL CNAME CDN (that’s a whole lotta letters!).