wilrevehl

That’s very insightful, thanks! We’ll look for anything messing with the main query.

@msaari based on your experience, what are the common plugins, functions or settings that would cause an activated Relevanssi to not provide the search results?

Thanks for all you do!

• This reply was modified 1 year, 6 months ago by wilrevehl.

@bundfegadmin we had a site hit with the same thing. Are you able to recall which database table(s) that SQL was injected in? Thx!

I was mistaken. It seems the issue is that something prevents your forms from loading when the browser is in Incognito mode or even simply using Brave with filters not even enabled. This was regardless of it being set to custom form or drop-in. I’ll send you an email where you can test it. Thanks.

@mrclayton your plugin seems to be working as expected on the stage. The most noteworthy difference between the stage and production is Cloudflare. That likely means some new Javascript dependency may have been missing. We’ll try again with Cloudflare disabled to see if that does the trick. Thanks.

Thanks for your prompt follow up. We’re going to move your plugin to a staging environment to run further tests on. Will send you the URL with an update then. Thank you very much.

I have the same issue but there were no apparent JavaScript errors. The payment info fields appeared to be there, but there were no actual input fields upon inspection of the html output. It was like phantom fields. I switched to the non-custom setting and it returned no forms at all.

Any insight would be greatly appreciated. Thank you!

I may have a similar issue. EMP doesn’t fully work on PHP v7+. The ability to view Future Events and Search are missing in the admin UI from EMP 5.6 on once the server is running php 7+.

I’ll plan to try this patch to see if it makes a difference. Thanks.

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

I was having the same issue and to resolve it, I just needed to change the fully spelled state name to the shorthand version, so Ohio became OH and then it started to show the map.

Hey Justin,

I can confirm this is indeed an issue regardless of theme switching. I had my menu locations assigned in Appearance > Menus prior to using your plugin from the Customizer. Immediately upon Import of your .dat file, all the menus ended up pointing to locations that don’t even exist. Two theories come to mind:

1. Your pointer for menu locations is referencing the wrong object.
2. There’s some discrepancy between locations saved from the traditional menu editor and those saved with the new one in the Customizer.

Let me know if anything turns up, thanks a lot.

Alright, here’s a fix. It hasn’t been tested for empty or much of anything outside of our environment, so use at your discretion:

if ( !class_exists('Go_AWS_S3_CF_Extension') ) :

class Go_AWS_S3_CF_Extension {

	protected static $_instance = null;

	function __construct() {
		//wait for the initiation of the AWS S3 plugin
		add_action( 'aws_init', array( $this, 'init' ), 30 );
	}

	public static function instance() {
		if ( is_null( self::$_instance ) ) {
			self::$_instance = new self();
		}
		return self::$_instance;
	}

	/**
	* Init this plugin
	*
	*/
	public function init() {
		//add filter for upload_dir so we can edit the url to use the S3/CF one
		//https://www.ads-software.com/support/topic/theme-customizer-image-previews-broken?replies=4#post-7112563
		add_filter( 'upload_dir', array( $this, 'upload_dir' ), 1 );
	}

	/**
	* Filter for WP's upload_dir
	*
	* hooked: upload_dir
	* @see https://developer.www.ads-software.com/reference/hooks/upload_dir/
	* @returns array directory object
	*/
	public function upload_dir( $dir_obj ) {
		//get the current site's url
		$site_url = get_site_url();
		//set replacement pattern
		$url_pattern = '~'.$site_url.'~';
		//replace first instance of string when S3 is active but the site is using the site_url
		$dir_obj['url'] = preg_replace($url_pattern, $this->get_s3_url(), $dir_obj['url'], 1);
		$dir_obj['baseurl'] = preg_replace($url_pattern, $this->get_s3_url(), $dir_obj['baseurl'], 1);

		return $dir_obj;
	}

	/**
	* Get AWS S3/CF URL using the plugin's global
	*
	* @returns string s3 url
	* @see plugins\amazon-s3-and-cloudfront\wordpress-s3.php::48
	*/
	private function get_s3_url() {
		global $as3cf;

		$scheme = $as3cf->get_s3_url_scheme();
		$bucket = $as3cf->get_setting( 'bucket' );
		$region = $as3cf->get_setting( 'region' );
		$domain = $as3cf->get_s3_url_domain( $bucket, $region );
		$url = $scheme . '://' . $domain;
		return $url;
	}

}
endif;

/**
 * Create instance of Go_AWS_S3_CF_Extension
 */
$go_aws_s3_cf_extension = Go_AWS_S3_CF_Extension::instance();

Cheers,

Hopeful news. I was able to run a crude test with add_filter( ‘upload_dir’, ‘s3_upload_dir’, 1) where I preg_replace the get_site_url with my cloudfront one. This resolves the aforementioned. I’ll see if there’s a place I can hook into your plugin to attach it to those settings dynamically.

Update, attachment_url_to_postid fails to return a post_id when your plugin is activated, at least in the case where cloudfront/custom domain is being used.

I got back into this issue today and here’s what I found:

1. In WP_Customize_Media_Control line 748, the wp_prepare_attachment_for_js param $value is injecting the url string of the attachment and not the ID
2. wp_prepare_attachment_for_js looks for a post ID of the attachment so this thing can be flexible for sizes.
3. Because the wrong type of param is injected, wp_prepare_attachment_for_js fails right away and becomes useless.

We need to figure out what causes the url and not the id to be used.

Looks like it ultimately uses this: wp_prepare_attachment_for_js