ensemblebd

Same. Worked great first time I ran it.
But returning to the page, it never loads. 100% cpu core usage, eventually timing out or crashing.

By breaking the plugin code down, piece by piece, I have found that it stems from: meta_box_diagnostics() on line 518

Simply adding “return;” at the top of it, fixes the problem.

I believe it’s the recursive file counter.
For me, the diagnostics area is entirely pointless, so the above hack-fix works just fine for me. I don’t need diagnostics about my own server.
I don’t have any symlinks, so not sure why it’s looping infinitely. But not my job to find out nor fix it.
Figured I’d share though. Plugin is amazing and does a great job with everything else. Just not that.

p.s. on second thought, maybe this has something to do with open_basedir.

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

Adjustments made that resolve this, for your potential consideration.

/includes/class-custom-permalinks.php ::

private function init_hooks() {
//...
	register_activation_hook(
		CUSTOM_PERMALINKS_FILE,
		array( 'Custom_Permalinks', 'add_lookup_table' )
	);
//...

	add_action( 'save_post', array( $this, 'save_post' ), 10, 3 );
	add_action( 'delete_post', array( $this, 'delete_post' ), 10 );
}
public static function add_lookup_table() {
	global $wpdb;
	$charset_collate = $wpdb->get_charset_collate();

	$table_name = $wpdb->prefix . 'cp_lookup';
	$sql = "CREATE TABLE IF NOT EXISTS $table_name (
		cp_id INTEGER NOT NULL AUTO_INCREMENT,
		cp_hash BIGINT NOT NULL,
		ID INTEGER NOT NULL,
		meta_value VARCHAR(255) NULL,
		post_type VARCHAR(20) NULL,
		post_status VARCHAR(20) NULL,
		PRIMARY KEY (cp_id)
		INDEX 'idx_cp_lookup' (cp_id, cp_hash, ID, post_type, post_status, meta_value) 
	) $charset_collate;";
	
	require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
	dbDelta( $sql );
}

// fill the lookup table preemptively. Future updates to pages/posts will sync individually.
// useful for existing installations that want to avoid "grandfathering" over time, and start using the improved speed immediately.
public static function fill_lookup_table() {
	global $wpdb;
	$table_name = $wpdb->prefix . 'cp_lookup';
	
	// cleanup. Shouldn't be necessary, but here for safety, since the hash check we do later demands EXACT matching. And the code from before checks both with and without trailing slash, which would logically indicate that sometimes the meta_value would have a trailing slash..
	$wpdb->query("UPDATE $wpdb->postmeta SET meta_value = TRIM('/' FROM meta_value) WHERE meta_key = 'custom_permalink'");
	
	// just in case entries already exist, clean it and start fresh..
	$wpdb->query("DELETE FROM $table_name");
	
	// and then populate our lookups from existing data; if any.
	$wpdb->query("
		INSERT INTO $table_name (cp_hash, ID, meta_value, post_type, post_status) 
		SELECT 
			CONV(crc32(pm.meta_value), 16, 10), 
			p.ID, pm.meta_value, p.post_type, p.post_status 
		FROM $wpdb->posts p 
		INNER JOIN $wpdb->postmeta pm ON (pm.post_id = p.ID) 
		WHERE 
			pm.meta_key = 'custom_permalink' 
			AND p.post_status != 'trash' 
			AND p.post_type != 'nav_menu_item' 
			AND pm.meta_value != '' 
	");
}

public static function save_post($post_ID, $post, $update) {
	global $wpdb;
	$table_name = $wpdb->prefix . 'cp_lookup';
	$wpdb->query("DELETE FROM $table_name WHERE ID = $post_ID");
	$wpdb->query("INSERT INTO $table_name (cp_hash, ID, meta_value, post_type, post_status) 
		SELECT 
			CONV(crc32(pm.meta_value), 16, 10), 
			p.ID, pm.meta_value, p.post_type, p.post_status 
		FROM $wpdb->posts p 
		INNER JOIN $wpdb->postmeta pm ON (pm.post_id = p.ID) 
		WHERE 
			pm.meta_key = 'custom_permalink' 
			AND p.post_status != 'trash' 
			AND p.post_type != 'nav_menu_item' 
			AND pm.meta_value != '' 
			AND p.ID = $post_ID
	");
}
public static function delete_post($post_ID, $post, $update) {
	global $wpdb;
	$table_name = $wpdb->prefix . 'cp_lookup';
	$wpdb->query("DELETE FROM $table_name WHERE ID = $post_ID");
}

public function check_loaded_plugins() {
	// ...
	if ( is_admin() ) {
			$current_version = get_option( 'custom_permalinks_plugin_version', -1 );

			if ( -1 === $current_version
				|| $current_version < CUSTOM_PERMALINKS_VERSION
			) {
				self::activate_details();
				self::add_roles();
				// generate the lookup table on new plugin/db version.
				self::fill_lookup_table();
			}
		}
	
	// ...

/uninstall.php

//...

global $wpdb;
$table_name = $wpdb->prefix . 'cp_lookup';
$wpdb->query("DROP TABLE IF EXISTS $table_name");

//...

/includes/class-custom-permalinks-frontend.php ::

private function query_post( $requested_url ) {
	global $wpdb;
	$clean_url = urldecode($requested_url);
	$hash = hexdec(crc32($clean_url));

	$cache_name = 'cp$_' . $hash . '_#cp';
	$posts      = wp_cache_get( $cache_name, 'custom_permalinks' );

	if ( ! $posts ) {
		$table_name = $wpdb->prefix . 'cp_lookup';

		// phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery
		$posts = $wpdb->get_results(
			$wpdb->prepare("
				SELECT ID, meta_value, post_status, post_type 
				FROM $table_name  
				WHERE 
					cp_hash = %d
				ORDER BY 
					FIELD(post_status,'publish','private','pending','draft','auto-draft','inherit'),
					FIELD(post_type,'post','page') 
				LIMIT 1
			", $hash
			)
		);

		wp_cache_set( $cache_name, $posts, 'custom_permalinks' );
	}

	return $posts;
}

Unable to confirm the cause, as it seems to have just “gone away”.
Which definitely lends towards a compatibility issue.
We did update plugins and themes, so perhaps one of them was the cause.
Sorry I can’t provide better diagnostics/insight on this – but it’s definitely resolved.
Thank you!

Thank you very much, I will do so and report back asap.

That has to be the fastest plugin support I’ve ever witnessed in my life.
Not just in “ticket” response time, but in actually deploying a product update with haste!
Completely unexpected. I owe you a great deal of thanks and respect. And it won’t be forgotten.
Wishing you a great weekend!

Oh ok thank you! Yea maybe it was something on my side, we run PHP 7.3 NTS, and mysql 5.6, if that helps.
Anyway figured I’d report it just in case, have a great one!

Thank you!!!

Doesn’t appear to be working. Installed this plugin, installed DW QA, enabled it per screenshot #1, and then created a new schema for QAPage per screenshot #2.
Nothing shows up in source for QAPage.

I tried enabling it forcefully within the Edit page area; despite having blank fields for the “Question Title” , etc.
Nothing.

Confirmed saswp_post_specific_schema_output was called by post specific override.
Disabled it.
Stepped into the saswp_schema_output()
–> $Conditionals is false on the actual questions posts, resulting in immediate plugin exit.
–> $schema_type is always Article on all other pages, including those using the shortcode for questions (including the automatically created page /dwqa-questions/)
–> /question/ category page (produced by dwqa) also has no $Conditionals, immediate exit.

How exactly is this supposed to work? Certainly I’m missing something here..

Awesome thank you !! Exactly the info I was needing. Super fast response to boot.

I’ll try to reorganize the tier and give those posts a read as well. It sounds like there are definitely some options to improve this. And I think I understand the listing better now.

Thanks again!

So fast, thank you!!!!!
Has made my friday ??

Awesome thank you ! Looking forward to next update, we do like this plugin. ??

Great catch! That certainly explains it. Thank you very much ??

I think it was meant to be. We were already about to disable that plugin due to this.
Your plugin looks far better too, will be installing and likely purchasing yours instead.
Thanks again.

• This reply was modified 7 years, 1 month ago by ensemblebd.
• This reply was modified 7 years, 1 month ago by ensemblebd.

wp-content/plugins/responsive-pricing-table/assets/js/admin.js?ver=1.2.0

~line 65. loops over each input checkbox, and checks it.
Line in loop reads
$(this).prop('checked', true);
, which 100% of time checks an input box. So I believe jquery selector is incorrect or somehow triggering on the post page.
Any ideas?

See video as I step through with debugger (trigger attribute mod breakpoint, when click Update button on any post page, and in call stack, your plugin executes above mentioned code), which shows it checking the box via javascript included by this plugin

Am guessing something is causing it to load on admin pages in my instance?

• This reply was modified 7 years, 1 month ago by ensemblebd.
• This reply was modified 7 years, 1 month ago by ensemblebd.

Awesome thank you for the quick support!
Am unsure on these, I’ll get you that info here shortly. If it isn’t happening for you on your systems then there definitely must be something else causing it on my instance.

Will post back shortly with more, but sounds like something else is going on

Also have to manually take care of any filter suppression items.

vc_basic_grid_filter_query_suppress_filters for example, disregards our filters.