John Morris

Hello Christa,

Yes, this plugin is still actively supported and updated. I have been extremely busy for the last two or three months, which temporarily slowed the rate of support and updates, but development definitely continues.

Tweet This works with the latest version of WordPress on my testing sites. The “compatible up to” on the plugin listing will be updated with the next plugin update.

Good idea!

I will look into adding this capability to the plugin, but I unfortunately won’t have time to devote to this feature for a while. It is very complex (payment processing, user payment status tracking, et cetera) and will require very, very careful planning to be implemented effectively.

That is not currently a built-in feature. You could design your own version of it utilizing the JavaScript or CSS hook mechanisms the plugins provide, but there is a fair amount of complexity behind making that work.

I will look into adding this capability to the plugin, but I unfortunately won’t have time to devote to this feature for a while.

Thank you for the list!

Several of those plugins I use on a regular basis, and can likely rule out. The others I will install on my dev website and see what happens at my earliest opportunity.

Aha! Evidence! Yay! A list of plugins would help immensely. If you are uncomfortable posting what plugins you run publicly, you can email them to me using the contact form on the plugin’s website: https://tweetthis.jtmorris.net/contact/#contact-form-116

Sorry for the delay in response.

I am unable to replicate this behavior, but that error message is a catch-all error thrown by the WordPress Settings API, which Ad Blocking Detector uses extensively.

Unfortunately, the most common cause of this error is not the cause now (or it would happen for everybody), so it will be extremely difficult to debug.

One suggestion I have that might work is to uninstall and reinstall Ad Blocking Detector if you have not already. I doubt that will resolve the problem, but it might.

—–

If reinstalling does not work, then I do not have a quick solution, unfortunately. I will look into it, but the Settings API, and this plugin’s code used to interact with it is complex and difficult to debug, so it will likely take me a while.

I apologize for the inconvenience.

Hi jayPEG,

I’m going to give short answers (TL;DR version) to the questions, then at the end, go into a bit more detail that may help your assessment a bit more.

1) No known issues with bots, with one caveat. Bots generally see both the “ad blocker detected” content, and the “no blocker detected content.” This means if one of those content items is determined to be important content by the bot, it will treat that as part of the page. This may be a problem if you put a text plea at the top of your page, before the main content, as the bot may think that’s part of your content. It does not, however, upset or interfere with the bot itself in any way.

2) No known issues with front-end proxies. However, it is possible, if the front-end proxy blocks JavaScript, that Ad Blocking Detector will not be able to detect ad blockers, but that blockage often causes numerous other problems on websites anyway. In this edge case, Ad Blocking Detector will fall back on its default assumption of no ad blocker present.

3) No known issues with caching plugins. However, other performance improvement methods may cause problems. A few users have had issues with JavaScript enhancement plugins that load files asynchronously, and plugins that minify and/or combine JavaScript files.

—–

Now the longer version.

Ad blocker detection is accomplished via JavaScript. Using JavaScript, the plugin looks at the page for items that should appear on the page, if not blocked by ad blockers. If any of the items are not present, Ad Blocking Detector assumes an ad blocker is to blame.

JavaScript is code executed client-side, meaning by the visitor’s web browser. This means that if the visitor’s web browser is properly (more on this in a moment) receiving and executing JavaScript, everything should work without issue.

GoogleBot, and most bots, do not execute JavaScript. This means Ad Blocking Detector does not function for those bots. It does not change page content. Understanding how this affects the bots, then, requires understanding how Ad Blocking Detector outputs content to the pages in the first place. That is the focus of this article on the plugin’s website: https://adblockingdetector.johnmorris.me/how-this-plugin-works/. Basically, both potential pieces of content are in place on the page, but the ad blocker detected content is visually hidden until Ad Blocking Detector unhides it. Since Ad Blocking Detector does not function, the ad blocker detected content is never visually unhidden. However, just because something isn’t visible on the page, does not mean the bot will ignore it. That just depends on how smart the bot is. Most are pretty dumb in this regard, including GoogleBot as of this time, and swallow everything, visible or not.

Front-end proxies should not cause any problems unless they stop or interfere with JavaScript. Some have this as an option, many (most?) do nothing in this regard by default. IF the proxy allows JavaScript through, there should be no problem as all ad blocker detection is done client-side, after passing through the proxy. Proxies can slightly skew Ad Blocking Detector’s statistics collection if widespread and using regularly changing IP addresses.

Pure caching plugins shouldn’t cause a problem, because they still serve the JavaScript files normally. Performance plugins, however, may cause problems if they alter JavaScript files. Understanding this requires a bit more depth of understanding of one detection method… JavaScript file blocking detection.

One way Ad Blocking Detector finds ad blockers is by looking for a JavaScript file that many ad blockers will stop from loading due to its name (advertisement.js). It determines whether the file loads or not by having that file set a variable. If the variable is present and set, it assumes the file loaded. If the variable is not present or unset, it assumes the file did not load. So, if some well-meaning plugin comes in and prevents the file from loading, delays the file from loading until after the rest of Ad Blocking Detector, or renames the variable in the file without renaming it the same way in Ad Blocking Detector’s other file, Ad Blocking Detector will yield a false-positive.

The false-positives can be stopped by disabling JavaScript file detection (an option in the plugin settings). This decreases the detection effectiveness. The decrease can be more than offset by providing a CSS wrapper as detailed on the plugin’s website here: https://adblockingdetector.johnmorris.me/detection-improvement-user-defined-wrapper-css-selectors/. This is a recommended step, if situationally possible, anyway.

—–

I hope this helped. Let me know if something needs clarification or you have further questions.

Unfortunately, I don’t have any other suggestions other than switching the “Insert Shortcode” button behavior, at this time. It’s a currently ongoing investigation, but I have absolutely no idea what is causing the bug, and since I can’t replicate it, my ability to randomly try changes and observe the affect is severely stymied. As I said, I have put in dozens, if not hundreds of hours into this problem, and still am when I can.

My latest, and so far unhelpful path to a solution is to look at the source code of other plugins with similar interactions and see if they do anything different. I have yet to find any plugins that do this in a manner I haven’t tried, and none of them have visible bug reports indicating this problem that I can follow.

—–

I started writing a secondary plugin to do that wrapping that you mentioned, but stopped as it will encounter the same issues as Tweet This. The WordPress editor (which is a modified TinyMCE editor) is supposed to provide a certain JavaScript object when it has finished loading. Plugins, such as Tweet This, are then supposed to use this JavaScript object to interact with the editor (by inserting content at the cursor location, in the case of Tweet This). (source code for finding this object available here – lines 59 through 95).

To the best of my knowledge, this bug happens because that JavaScript object, for a small number of users, either isn’t there when it is supposed to be, or doesn’t contain the appropriate functions (both possibilities seem to occur).

Adding another toolbar button will encounter the same problem… the necessary JavaScript object to do the wrapping in the editor isn’t there when it is supposed to be, or isn’t properly structured.

—–

It’s possible that jQuery Mobile is interfering… It does a number of strange things to links and buttons, that might collide with Tweet This’ intended actions. However, Tweet This doesn’t use jQuery Mobile (it uses jQuery and jQuery UI, but not jQuery Mobile).

For information, here’s the part of the code that loads every jQuery item Tweet This uses in the admin dashboard.

wp_enqueue_script( 'jquery' );
wp_enqueue_script( 'jquery-ui-core' );
wp_enqueue_script( 'jquery-ui-dialog' );
wp_enqueue_script( 'jquery-ui-accordion' );

– and –

//	jQuery UI theme.
wp_enqueue_style('tt-admin-jquery-ui-css',
     TT_ROOT_URL . 'assets/css/jquery/cupertino-theme/jquery-ui.min.css',
     false
);

If another plugin were using jQuery Mobile, then the problem should go away when Tweet This is the only active plugin. Unless your theme is using jQuery Mobile, and for some unknown reason loads it in the post editor.

Can you track down what is loading jQuery Mobile? Does this problem still occur if you use one of the default WordPress themes (TwentyFifteen, TwentyFourteen, or TwentyThirteen)? If it’s a free plugin or theme, I can install it in my testing environment and see if it causes the problem to appear for me, then determine a way to work around it. If jQuery Mobile ends up being at fault, it shouldn’t be too difficult to fix that.

Hmm. That is very strange.

Can you go to the edit page, and click those failing buttons and do those actions that do not work, then send me the output of your web browser’s JavaScript console.

Instructions for finding and sending JavaScript console output are available on the website for one of my other plugins (https://adblockingdetector.johnmorris.me/how-to-collect-javascript-console-output/). The text in the console will be different than illustrated in the instructions, but the method for obtaining the text is the same.

You can either submit the JavaScript console output here, or email them to me directly, if you’d rather keep the results private, by using the contact form on the plugin website: https://tweetthis.jtmorris.net/contact/

Hopefully, this information will help me track down the issue and resolve it quickly.

At this time, Tweet This does not include a mechanism of tracking clicks.

This is a feature I hope to add at some point in the future, but it will add, and require developing, a significant level of complexity to the plugin.

Hi steelmaiden,

Ad Blocking Detector offers hooking mechanisms for both JavaScript and CSS. You can utilize the ad blocking status in any way that works with those two languages.

You can find an introduction and examples for both mechanisms on the plugin’s website:

CSS: https://adblockingdetector.johnmorris.me/combine-css-and-ad-blocking-detector/

JS: https://adblockingdetector.johnmorris.me/combine-javascript-and-ad-blocking-detector/

I’m sorry you’re encountering issues with this plugin.

For other users who have experienced this behavior in the past, this is a symptom of one of two potential problems.

The first is a plugin conflict. Try disabling plugins and seeing if the problem still occurs. Especially any plugins or themes that manipulate or modify the WordPress editor (adding toolbar buttons, modifying behavior, et cetera). If disabling a plugin fixes the problem, let me know the name of it, and I may be able to circumvent the interference.

—–

If disabling plugins does not work, then, unfortunately, this is a manifestation of a rare bug that has interfered with Tweet This for some time. For some users (and sometimes only intermittently), the WordPress editor is not accessible programatically, like it is supposed to be. This means that Tweet This can not insert the shortcode automatically. For some users plagued by this, it is detectable and an error message results. For others, it’s not detectable and Tweet This fails. In your case, it would be the latter.

I have spent dozens, if not hundreds of hours trying to remedy this rare problem, but I can not reproduce it, and it affects a tiny percentage of users. This makes it very difficult for me to work on it. Nearly every plugin update for the past year has included something aimed to resolving this issue, but each attempt is a shot in the dark, and I’ve only managed to reduce the number of users experiencing the problem a bit.

If you fall into this second problem category, I unfortunately have no quick fix. You can tell Tweet This to display the shortcode for copying and pasting by changing the “Insert Shortcode” Button Behavior setting under the Tweet This’ settings page Shortcode Creator Dialog section. Setting Screenshot: https://1drv.ms/1VT9GMd. Resulting copy & paste dialog screenshot: https://1drv.ms/1VTa4dv. This will allow you to utilize the Shortcode Creator dialog box, but will involve one additional step after clicking “Insert Shortcode.”

—–

I’m sorry if the suggestions above are not helpful, or do not resolve the problem.

I’m sorry you’re encountering issues with this plugin.

For other users who have experienced this behavior in the past, this is a symptom of one of two potential problems.

The first is a plugin conflict. Try disabling plugins and seeing if the problem still occurs. Especially any plugins or themes that manipulate or modify the WordPress editor (adding toolbar buttons, modifying behavior, et cetera). If disabling a plugin fixes the problem, let me know the name of it, and I may be able to circumvent the interference.

—–

If disabling plugins does not work, then, unfortunately, this is a manifestation of a rare bug that has interfered with Tweet This for some time. For some users (and sometimes only intermittently), the WordPress editor is not accessible programatically, like it is supposed to be. This means that Tweet This can not insert the shortcode manually. For some users plagued by this, it is detectable and an error message results. For others, it’s not detectable and Tweet This fails. In your case, it would be the latter.

I have spent dozens, if not hundreds of hours trying to remedy this rare problem, but I can not reproduce it, and it effects a tiny percentage of users. This makes it very difficult for me to work on it. Nearly every plugin update for the past year has included something aimed to resolving this issue, but each attempt is a shot in the dark, and I’ve only managed to reduce the number of users experiencing the problem a bit.

If you fall into this second problem category, I unfortunately have no quick fix. You can tell Tweet This to display the shortcode for copying and pasting by changing the “Insert Shortcode” Button Behavior setting under the Tweet This’ settings page Shortcode Creator Dialog section. Setting Screenshot: https://1drv.ms/1VT9GMd. Resulting copy & paste dialog screenshot: https://1drv.ms/1VTa4dv. This will allow you to utilize the Shortcode Creator dialog box.

—–

I’m sorry if the suggestions above are not helpful, or do not resolve the problem.

Hmmm.

This appears to be a bug with certain versions of PHP, the programming language used by WordPress and its plugins, when certain features are enabled, under certain website page load conditions.

PHP Bug Report: https://bugs.php.net/bug.php?id=59298

Unfortunately, I can’t do anything about PHP bugs. Tweet This is beholden to any and all PHP idiosyncrasies and flaws.

However, others stymied by this PHP bug have made one or more changes on their end that worked for them. Some of the more common and promising fixes seemed to be:

1. Disable the APC caching feature of PHP.
2. Upgrade PHP to a more recent release.
3. Preventing PHP’s APC caching from caching the problematic files using APC filters.

However, I can not recreate this problem so I can’t give specific feedback on which of those methods, if any, work. I can only repeat anecdotal comments from my research into the bug.

Implementing any of these potential fixes will be dependent on your web hosting provider. You will need to look into their documentation or contact them to see if they are feasible, and if so, how to accomplish them.

My personal first attempt, and likely the easiest, would be to upgrade PHP if not using the latest available. Many, many web hosts choose to use older versions of PHP by default (5.2.x and 5.3.x are most popular despite their age), but have mechanisms for using more recent versions (5.6.x is the current latest release). At a minimum, I would find what version of PHP my web host had me currently using, then upgrading by at least one minor version number (the middle number). For example, if my version were 5.3.4, I would look to upgrading to no less than 5.4.0. Ideally, however, I’d upgrade to the absolute latest available through my web host.

—–

This bug has prompted me to accelerate some research into techniques I have wanted to do for a while, the net result of which may allow me to altogether circumvent the important code that PHP is mishandling.

However, there are a lot of potential consequences to the changes I am envisioning, and the changes are moderately complex. As such, I have no timeframe for when and if I will complete this, and at this time, I’m only making an educated guess as to its ability to circumvent the problem. If possible, I don’t suggest relying on this being a fix, in lieu of the suggestions above.

Glad the errors went away!

The automatic insertion method is known to fail in two situations that are possibly related. The first cause of failure is plugins and themes that alter the WordPress TinyMCE editor, or add another on the editor page without taking appropriate precautions. The second is the WordPress editor being programatically unavailable, and thus unavailable for Tweet This to add content to.

Unfortunately, 9 times out of 10, I can not replicate this behavior, and thus can not experiment to track down the problem. I have invested hundreds of hours creating attempting random fixes, but I haven’t yet found the universal cause or fix. Originally, I was treating those as two distinct and unrelated failures, but my latest theory is that they are related to plugins in use.

I have recently begun asking users experiencing problems like this to send me a list of their installed and activated plugins (and if they’re willing, to deactivate all plugins and see if Tweet This’ problem persists). In addition, I ask for Tweet This’ console log output (this will be different than what you posted before, now that the error has been fixed).

If you would be willing to send me a list of plugins (and possibly test if the problem remains with no other activated plugins), and the new console output, I may be able to track this problem down once and for all.

If you’d rather not post your installed plugins publicly, you can email them using the contact form on this plugin’s website: https://tweetthis.jtmorris.net/contact/#contact-form-116.