Robin Hislop

Downgrading to 1.5.3 re-instates the tabs.

I have the same problem – all the product tabs in the Product Data meta box are blank, except for the General tab. Deactivating the plugin brings them back. I’m on version 1.5.5.

I’m getting the same error on an installation where it was working fine. I am running Imsanity 2.4.2 on PHP 7.2.

GD module is installed:

GD Support enabled
GD headers Version 2.1.1
GD library Version 2.1.1
FreeType Support enabled
FreeType Linkage with freetype
FreeType Version 2.3.11
GIF Read Support enabled
GIF Create Support enabled
JPEG Support enabled
libJPEG Version 6b
PNG Support enabled
libPNG Version 1.2.49
WBMP Support enabled
XPM Support enabled
libXpm Version 30411
XBM Support enabled
WebP Support enabled

The PHP memory_limit is 512M, which should be plenty.

If I disable Imsanity and upload an image, the standard WP crunch process generating thumbnails etc. works fine, so it does seem to be a problem with the plugin.

Any ideas?

Thanks, that worked perfectly.

OK, on further investigation, tribe_get_events does do the trick as it is effectively a wrapper for get_posts so I can pass my tax_query into it.

This is what I ended up using:

$args = array(
	'posts_per_page' => get_option( 'posts_per_page' ),
	'order_by' => 'post_date',
	'order' => 'DESC',
	'tax_query' => array(
		array(
			'taxonomy' => 'tribe_events_cat',
			'field' => 'slug',
			'terms' => $category,
			'operator' => 'IN'
		)
	),
	'eventDisplay' => 'custom'
);
$events = tribe_get_events( $args );

Thanks for the pointer Barry.

Thanks for the reply Barry, but I’d already read that documentation and the tribe_get_events function doesn’t allow to filter by category, which is what I need.

The get_posts query I have written should return all posts with post_type “tribe_events” regardless of EventStartDate, so something must be filtering the output, I suspect there is a pre_get_posts hook somewhere in the plugin code.

Thanks David, that is most helpful.
As you suggested, I removed the category parameter from the shortcode but was still getting an empty set for all searches. It turns out that the tax_query parameter requires a closing comma in the array (why??!!), so it should be:
tax_query="array(array('taxonomy' => 'attachment_category','field' => 'term_id','terms' => array('53'),'operator' => 'NOT IN'),)"
As this has solved my most pressing problem, I will come back to solving the other part via hooks at a later date when I have time.
Many thank for your detailed help.

A better solution is to replace the malicious file with an empty file. The files are now harmless but are not deleted so don’t trigger the file recreation.

Of course, identifying what process is recreating the deleted files should be your next priority…

I solved this by only using alphanumeric SHA passwords i.e. don’t use any symbols. There seems to be some sort of character encoding issue with symbols. Be warned, this makes your SHA keys slightly less secure…

I have had this too on a hacked site. I cleaned up everything I could find, but one malicious file keeps reappearing after being deleted. My (temporary) solution is to block access to the file with htaccess:

<Files mailicious-filename.php>
order allow,deny
deny from all
</Files>

I’d also be curious to find out how to identify the process resurrecting the deleted file.

For anyone having this problem, I found the easiest solution was to include the following in my themes functions.php:

function set_wp_test_cookie() {
	setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
	if ( SITECOOKIEPATH != COOKIEPATH )
		setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}
add_action( 'after_setup_theme', 'set_wp_test_cookie');

Wow, setting the SHA-IN and OUT keys to be alphanumeric worked! It must have been a special character encoding issue then. Thank you!

One last glitch I’ve got to iron out – if the customer cancels an order on the Barclays page, they get taken back to the site with an order confirmation message. I assume this is because of the following line:
'CANCELURL'=>$order->get_checkout_order_received_url(),
I tried changing it to:
'CANCELURL'=>$order->get_cancel_order_url(),
but this caused an error on the Barclays page.

Strange, I had to change lines 451-4 to:

'ACCEPTURL'=>$order->get_checkout_order_received_url(),
'DECLINEURL'=>$order->get_checkout_order_received_url(),
'EXCEPTIONURL'=>$order->get_checkout_order_received_url(),
'CANCELURL'=>$order->get_checkout_order_received_url(),

to enable endpoints for the plugin to work with WooCommerce 2.1x.

I’ll try this with alphanumeric SHA-IN and OUT. Will update how it goes.

OK, that sounds promising. Before I implement this, can you paste the code where your plugin is setting the following please: ACCEPTURL, DECLINEURL, EXCEPTIONURL, CANCELURL, BACKURL, HOMEURL and CATALOGURL

Many thanks for your help.

Nope, sorry I’ve not resolved it. Using PayPal at the moment…