Jay

Do this all the time on projects, use wp_redirect()
https://codex.wordpress.org/Function_Reference/wp_redirect

Have you considered storing and checking against user meta data? Sounds like that may be more fitting.

@tranny – Can you provide more information in regards to your caching methods? Any sort of auto-minification of javascript going on, cloudflare rocket maybe?

Also, please verify there are not other JavaScript errors on the page via your native console inspector. If there’s a fatal error somewhere up the page when you turn on caching, it may interfere with the JavaScript I coded, not saying that I can’t be at fault as well, but I’ve confirmed this works well with W3TC, but does have problems when W3TC is working with cloudflare’s rocket in the past.

If you open issues on the github repo I get emails instantly. I rarely check this forum. Unless you have the deny option checked they shouldn’t get redirected just by hitting back. I’ll add this to my weekend list to check.

If it’s pure javascript, you’ll want to use admin_enqueue_scripts – https://codex.wordpress.org/Plugin_API/Action_Reference/admin_enqueue_scripts

If the ‘script’ you’re referring to is a plugin, well that’s an entirely different method and would more than likely require you asking the dev!

Not that this matters for you, and since this is about 1+ months old, I wanted to post here so future viewers are aware as well.

We had the same issue. Initial tweet would go out, but any future tweet would not. After a really long investigation last night it was actually two factors that played into it.

Factor #1
WP_Cron – We were using a system level cron job, following a tutorial from here: https://developer.wordpress.org/plugins/cron/hooking-into-the-system-task-scheduler/

However, the issue was with our host now allowing our tasks to fire from crontab under our user. Updating the code set the user as root for the cron fixed the issue for us:
*/5 * * * * root wget http://mysite.com/wp-cron.php &> /dev/null

With a quick cron testing plugin, I found the cron to be firing at this point.

Factor #2
W3TC – There’s a known issue with W3TC and cron jobs which use object data. WordTwit is one of those issues. See here: https://wordpress.org/support/topic/self-diagnosed-and-fixed-w3-total-cache-bug-in-faulty-object-caching?replies=9

Once I disabled database & object cache, our tweets started going out automatically again.

I elected to edit W3TC myself and put in the first patch mentioned by archon in tha thread. Once I did that, and re-enabled object cache, things seem to flow normal again ( with the added system cron fix from factor #1 )

This should do what you’re looking for. For future reference though, there’s a filter for comment data before insertion.
https://core.trac.wordpress.org/browser/tags/4.2.2/src/wp-includes/comment.php#L2260

You can also find all known filters here: https://codex.wordpress.org/Plugin_API/Filter_Reference#Comment.2C_Trackback.2C_and_Ping_Filters

The field is already ran through strip_invalid_text_for_column, which I’d hope does this already, but maybe not.

<?php
/**
 * Strip slashes from comment content
 * @param  array $comment_data Comment data
 * @return array               Comment Data
 */
function my_comment_filter( $comment_data ) {
	if ( isset( $comment_data['comment_content'] ) ) {
		$comment_data['comment_content'] = stripslashes( $comment_data['comment_content'] );
	}

	return $comment_data;
}
add_filter( 'preprocess_comment', 'my_comment_filter' );