[Barry]

Hi Iris,

I’d be happy to take a look but please bear in mind the degree of support we can offer for any custom code you have does tend to be limited (it may also take us a little longer to help with this sort of request).

Can you share your code via Pastebin, Gist or some other comparable service? Otherwise we’d have to manually rewrite it from your screenshot.

Thanks!

[Barry]

This reply is private.

[Barry]

This reply is private.

[Barry]

This reply is private.

[Barry]

Hi Joanna,

I’m sorry first of all for the long delay in responding. Does this continue to be an issue (I see you are using the latest version of The Events Calendar which is great and additional fixes have rolled out since my last update)?

If you are, could you leave a couple of examples on your site and link me to them and also provide the corresponding Facebook URL?

Thank you!

[Barry]

This reply is private.

[Barry]

This reply is private.

[Barry]

Awesome!

[Barry]

Ah, ok – I see what you mean – and I’m glad you’ve got something in the works to resolve it. Depending on how that works out, you may also find the following snippet useful:

add_action( 'plugins_loaded', function() {
	if ( ! class_exists( 'Tribe__Events__Tickets__Eventbrite__Main' ) ) {
		return;
	}

	$eventbrite = Tribe__Events__Tickets__Eventbrite__Main::instance();
	remove_action( 'tribe_events_update_meta', array( $eventbrite, 'action_sync_event' ), 20 );
}, 20 );

This could be added either to a custom plugin (preferred) or else to your theme’s functions.php file.

Good luck!

[Barry]

Thanks for the notes, Andrew.

Perhaps the risk has diminished enough at this point to remove these lines from the next release?

To clarify this a little: the to-do item related to the extra safety check. If we do revisit and decide there’s no longer any risk, then we would still make the tribe_notice() call (it just wouldn’t be “wrapped” up within an if block).

I would rewrite the query, except I can’t figure out where it’s being generated from

A large number of the queries that run are composed dynamically and I’m unable to point you to a piece of source code where you’d see it expressed in a single block, because that’s not quite how it works.

You could probably capture and alter each query before it’s executed (I imagine this is what Project Nami itself does, to translate between SQL dialects) but that’s far beyond what we can help you with.

I added a Project Nami Support suggestion to the UserVoice page… hopefully other users who are required to use MSSQL will vote it up, and Nami compatibility will be added to your test suite.

Fantastic, thanks for doing that. It will be interesting to keep an eye on that and build a sense of how many users out there might also like to see this.

For the time being, though, I’m sorry to say we can’t assist further with Nami/MS SQL specific issues.

Thanks again and I do wish you luck with your project.

[Barry]

Hi Robert,

Though I see you marked your question as “Resolved” we have had similar reports from other users (even though we shipped fixes aimed at resolving this).

I’m going to link this forum topic to our current bug report and once we’re able to ship a fix we’ll be sure to update you.

Thanks!

[Barry]

This reply is private.

[Barry]

Hi there William and Russell,

We’re sorry for the disruption and realize this must have been a frustrating experience.

It’s VERY COMMON (I’d dare say the norm) to NOT have write/create access to /tmp as a non-root user.

I agree 100% that this is something we can and should anticipate.

In fact, for that very reason, we do already test to see if we have read/write permissions before trying to iterate across the directory. Based on your feedback there is clearly a case we’ve missed and so we’ll make some changes to ensure this doesn’t happen in the future.

When YOUR product isn’t working well for ajax queries, and I turn on YOUR logging, I lose 8+ hours of work. And you wash your hands.

Nobody is washing their hands of the problem — we’re here to help. Andras put forward some solid suggestions and left it open for you to come back if they didn’t help or were not viable.

We’re also not “pointing the finger” at your host — we understand that a configuration where the system temporary directory is inaccessible is a valid one and, as I noted, we have code in place that is intended to handle that (the fact that it doesn’t is, again, something we’ll rectify as quickly as we can).

I’m glad however that you were able to patch things, though as you realize it would be optimal to unwind any direct changes to our plugin code to give you a clean upgrade path up until we ship a fix for the problem.

To that end, could you add a new file to your mu-plugins directory (typically this is located at wp-content/plugins/mu-plugins) containing the following code:

<?php
# Disable logging
add_filter( 'tribe_common_logging_engines', '__return_empty_array' );

This should have the effect of forcibly shutting down our logging and you can undo any custom changes you made in preparation for our upcoming releases.

Let me know if that helps.

[Barry]

Hi Chris,

I’m sorry we raised your expectations there!

Though it’s not unlikely we’ll see rich REST API integration across a larger swathe of our plugin suite at some future point I’m unable to offer an ETA on this functionality at this time.

Do stay tuned though and be sure to periodically check-in on our blog for all the latest news 🙂

[Barry]

This reply is private.

[Author]

Posts