bkelleher

@joelcj91 much appreciated, and thanks for the reply and consideration!

Digging in, I believe this is because my network_site_url() returns the path to my WordPress installation, which in this case, is not the same exact as the root of my WordPress site. For example, my WordPress is installed in https://example.com/subdirectory, and my site is accessible at https://example.com/, so my WP_SITEURL constant is https://example.com/subdirectory, causing this function to return that URL. My Google Analytics do not include /subdirectory in the path so they always return 0 results. Would we consider adding an option to adjust the base URL that is requested for each post or page? Or consider an additional check for the home url compared to WordPress installation url?

I made an adjustment on my local instance in core/modules/google-analytics/stats/class-request.php line 229-233 to adjust for my WordPress installation URL not matching my home URL and my problem was resolved, but this is a short term patch to test this theory.

Who maintains this plugin?

I found a temporary fix that can help this problem (usually happens at scale/with caching plugins).

+1 having same issue, same versions.

An update – it seems as though the public preview is made eventually, but it can take up to 5min to stick and appear as visible.

Interesting that you are so concerned with a moderator flag on a comment like that, if he agrees with the request, does it matter where he sits?

Here’s the image again, sorry for the restricted access:
https://www.dropbox.com/s/pwovir1r62zu6de/Screenshot%202017-01-06%2010.04.22.png?dl=0

To say that everything “should” be compatible is a very dangerous mentality, especially for a platform as large as WordPress, running (supposedly) 10% of the internet. This is not to say that WordPress prevents you from installing or updating a plugin that is not compatible or has not been given enough information to be deemed so, but some better UI indicator that that might be the case might help those who manage 200+ WP sites to quickly identify that they should not proceed with all of the updates.

Lets take W3 Total Cache, the plugin that made me write this post. For those who have used it, W3TC is an enormous plugin that has a ton of functionality. According to www.remarpro.com, it has over 1+million active installs. It is not the burden of WordPress to make sure this plugin is compatible at the time of beta/production launch of the next version (4.7), however the moment 4.7 is released, 1+million sites that WILL break with a core update. Yes, the responsibility is on the plugin authors to fix any incompatibilities since the time 4.7 was announced, but that is not always feasible for a plugin of this size. 4.7 was announced mid October, and released early December, giving less than 2 months for compatibility testing and fixes. It is likely all plugin/theme authors have other responsibilities and might not be able to fix or even identify all bugs/incompatibilities, especially with large plugins. Now, when early Dec. comes around and 4.7 is released, all of those sites will break. It is unrealistic to believe that 1+million people will avoid updating to 4.7 on a whim that they have researched every plugin they use to make sure it is compatible.

The information is generated by the WP community, not the authors, in terms of compatibility feedback. It relies on users to say it is broken, and in this case, www.remarpro.com was fully aware of this broken compatibility. In the WordPress backend, most people read “Compatible up to: 4.6.1” and “Last Updated: 3 months ago” to be a generally modern and recent plugin that should work, but it might not. Hell, some of the best plugins have compatibility up to 3.2 and get the job done fine today.

I could see this functionality being built into a plugin, but the idea of it being shoved in a plugin sort of goes against the principle it is seeking to aid/solve. A simple compat check between plugin versions and core versions on the updates and plugins pages with a small badge to flag anything certainly incompatible, and perhaps a warning before proceeding seems like a useful enough feature to include in core, something that could prevent possibly millions of users of extremely popular plugins from accidently breaking their sites. Just take a look at how many forum posts are out there trying to figure out how to get back into the admin panel/deleting/disabling plugins through the DB/FTP, or another access method. You are right though, not every request of this nature should be included in core, it just seems like this is a relatively easy feature for the tradeoff of possibly hundreds/thousands/millions of sites not accidently breaking on a plugin/core update.

AMP gives very good reasoning for not including anything but the content of the article, as everything else has been abused by content creators over the years.

Do you have another search plugin activated? I had the plugin “Relevanssi” active, and filter[s] would not work while it was active.