Pre-pending the query with SET SESSION sql_mode = ”; worked for me:
Note that executing multiple queries separately did not work. Here I ran SET SESSION sql_mode =” first and then SELECT @@SESSION.sql_mode, which showed that strict mode was still active:
After the update of a MySQL server on a shared hosting account, strict mode was enabled with the NO_ZERO_DATE option and there was no way to change this. This meant that – among other things – I had to remove a default timestamp value of “0000-00-00 00:00:00” from multiple columns:
However this failed with error #1067 as other columns still used this invalid default. In other words, altering column A to make it compliant failed as column B was not compliant yet:
I’m not sure what the reasoning behind this is. However, temporarily disabling strict mode by pre-pending the query with
SET SESSION sql_mode = '';
let me make the necessary changes:
While this probably comes too late to help Pete, I hope it can help you.
The problem: You’ve used .htaccess / .htpasswd to restrict access to the wp-admin directory of your WordPress installation. However, when someone accesses wp-login.php, they can simply click “cancel” or press the escape key in the authentication dialog to reach the WordPress login page:
Click on “Cancel” here……and you still reach the WordPress login page (doesn’t look great, but works).
You also have to explicitly protect the wp-login.php file. Open the .htaccess file in the root directory (not in the wp-admin directory) and add something like this1:
Clicking on the JetPack sharing buttons in WordPress opens a new window with the parameter ?share=... added to the URL. However, instead of being redirected to twitter or Facebook or wherever you wanted to go, you’re redirected to the post itself again.
In my case, this was caused by the “Redirect ugly URL’s” setting in the popular Yoast WordPress SEO plugin (marked as “not recommended”, obviously for good reasons):
After unchecking this option, sharing worked as expected.
If you don’t want to disable this feature, adding “share” to the list of variables not to clean should also fix the issue:
Missing from the discussion is the fact that unencrypted content and unscrupulous ISPs present a small, but growing threat to Google’s business model. Google depends on ad revenue, and insecure connections allow third parties to tamper with data while in transit. ISPs can use this to their advantage by injecting their own ads. This is already happening: see here or here and this topic on reddit. It was also briefly mentioned in one of the comments under the original “ranking boost” announcement:
HTTPS ensures data integrity and would make ad injection not only technically far more difficult, but also most certainly illegal. This also explains why Google says that even simple “content sites” should use HTTPS: they might not collect any user data, but they can still serve ads.
“Being a good citizen of the web” and making the web safer for everyone sounds nice and is certainly something many people working at Google have in mind. However, it would be naive to assume that Google isn’t also looking out for it’s own commercial interests.