Web development - gonnalearn.com

How to temporarily turn SQL strict mode off in phpMyAdmin

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:

Example

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:

Result:

While this probably comes too late to help Pete, I hope it can help you.

How to Display Full Query Results in phpMyAdmin

In phpMyAdmin, the results of some queries can be truncated, as shown below:

This isn’t due to the size of the browser window or any error on your part; phpMyAdmin simply truncates the text.

The solutions is very simple:

Click on the + Options link above the results.
In the options menu, select Full texts.
Click on Go to re-execute your query.

Once you’ve done this, phpMyAdmin will display the complete results of your query:

WordPress: Prevent access to wp-login.php when the wp-admin directory has already been protected

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:

…and you still reach the WordPress login page (doesn’t look great, but works).

The solution

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 this¹:

AuthType Basic
AuthUserFile "path/to/.htpasswd"
require valid-user

You’ll have to replace path/to/.htpasswd with the path to your .htpasswd file (which should exist if you’ve already restricted access to your wp-admin directory).

Now, if someone cancels the authentication dialog, they’ll be directed to the default “Error 401” page:

Detailed information on authentication on Apache servers can be found in the official documentation. While there are lots of terrible articles out there which only regurgitate incomplete information for SEO purposes, I did find a comprehensive tutorial on how to protect wp-login.php and the wp-admin directory here.

Note: You may still want to install a WordPress security plugin like Cerber. This is how I discovered that I had forgotten to protect wp-login.php on one of my websites.

¹ Wondering why I didn’t include the AuthName directive? The text is not shown in Chromium-based browsers.

WordPress sharing button opens new window with same post

The problem:

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.

The solution:

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:

Unencrypted content: a threat to Google’s business model

Google’s recent announcement to give a (currently still small) ranking boost to websites using HTTPS is undoubtedly going to make the web safer for everyone.

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.