Category Archives: Troubleshooting

How to Forget Out-of-Range WiFi Networks on a Samsung Galaxy Phone

Samsung’s Android skin won’t let you tell it to forget a saved WiFi network unless it can see it right now. If it’s present, sure. If it’s out of range, it won’t let you tell it that no, you really don’t want it to automatically connect the next time you’re in range.

This is both annoying (your Galaxy S7 or Note 5 is going to keep looking for those networks all. the. time.) and a security risk (imagine someone sets up a rogue hotspot called “Starbucks WiFi” and you happen to park your car* or sit on a bench within range of it).

Note that the stock Android settings do allow you to fix this, with a Saved Networks section in the WiFi config. Samsung deliberately removed the feature** for some reason.

Apparently it used to be possible to remove saved networks using a third-party app, but new security protections in Marshmallow prevent that. (Ironic, that.)

Workaround (source):

  1. List all saved networks by going to Settings → Data Usage → More → Restrict networks. (This doesn’t let you remove them, just limit background transfers on them.) Take a screenshot if you have to.
  2. Remove the ones you don’t want anymore by tediously renaming your own WiFi hotspot to match each in turn [edit: you also need to match the security type (open vs WPA2)], removing them one by one in the regular WiFi settings, then renaming your hotspot back to its normal SSID.

It’s a pain, but at least it’s possible.

Update May 2017: The Android 7 update finally restores this capability directly in the Settings app, at least on the Galaxy Tab S2. You can now go to

Settings → Connections → Wi-Fi → Advanced → Manage networks

to remove saved networks of just turn off auto-reconnect on a case-by-case basis (so you can keep saved passwords). But for older Android versions, we’re still stuck doing it the long way.

*I once stopped at a Coffee Bean and left my tablet in the car. I don’t remember why I pulled it out when I got back in the car, but it had connected to the WiFi while I was grabbing my coffee. It couldn’t actually load anything but the login page because it was the real hotspot…but if it had been a fake hotspot, they could have intercepted or modified any non-encrypted traffic going on in the background.

**At best, Samsung forgot to include it when they wrote their own settings app years ago.

Using WP-CLI with WordPress 4.6 on DreamHost

I use WP-CLI from time to time to do maintenance on my WordPress sites that I host on a DreamHost VPS. But today I tried to run the search-replace function and found that wp wouldn’t run. Instead I got this error:

Fatal error: Call to undefined function apply_filters() in /path/to/wp-includes/load.php on line 317

It didn’t take long to confirm that WordPress 4.6 had changed things around, breaking the version of WP-CLI on my server. As it turns out, WP CLI 0.24 fixes this, but DreamHost is running 0.24-alpha.

So I tried installing the current version locally on my account, only to get a different error:

Fatal error: Class 'Phar' not found in /path/to/wp-cli.phar on line 3

I found this article very helpful for enabling PHAR support on a DreamHost VPS. I went into ~/.php/5.6/phprc (create this file for your version of PHP if you don’t have it) and added:

extension=phar.so
phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar

Once I verified that it would work by running /usr/local/bin/php-5.6 wp-cli.phar --info, I took the opportunity to (a) override the wp command with the local one and (b) make sure it used php 5.6 by adding the following alias to my .bash_profile:

alias wp='/usr/local/bin/php-5.6 ~/bin/wp-cli.phar'

This won’t be needed once DreamHost updates their WP-CLI package, but for now, it solves my problem faster than waiting for a response from tech support.

Redirecting HTTPS with Let’s Encrypt and Apache

The free TLS certificate provider Let’s Encrypt automates the request-and-setup process using the ACME protocol to verify domain ownership. Software on your server creates a file in a known location, based on your request. The certificate authority checks that location, and if it finds a match to your request, it will grant the certificate. (You can also validate it using a DNS record, but not all implementations provide that. DreamHost, for instance, only uses the file-on-your-server method.)

That makes it really simple for a site that you want to run over HTTPS.

Redirected sites are trickier. If you redirect all traffic from Site A to Site B, Let’s Encrypt won’t find A’s keys on B, so it won’t issue (or renew!) the cert. You need to make an exception for that path.

On the Let’s Encrypt forums, jmorahan suggests this for Apache:


RedirectMatch 301 ^(?!/\.well-known/acme-challenge/).* https://example.com$0

That didn’t quite work for me since I wanted a bit more customization. So I used mod_rewrite instead. My rules are a little more complicated (see below), but the relevant part boils down to this:


RewriteEngine On
RewriteBase /

# Redirect all hits except for Let's Encrypt's ACME Challenge verification to example.com
RewriteCond %{REQUEST_URI} !^.well-known/acme-challenge
RewriteRule ^(.*) https://example.com/$1 [R=301,L]

These rules can go in your server config file if you run your own server, or the .htaccess for the domain if you don’t.

Continue reading

Amazon Apps won’t Install on Android? Check Screen Dimmers

I mostly use the Google Play Store on my phone, but I have a few apps through the Amazon App Store. I recently found that I couldn’t update them — or the store itself. I could tell it to download the app, but at the point that I was ready to review the permissions and click on Install, the Install button wouldn’t respond. At all. Nothing. Cancel worked. Everything else worked. But not that one.

A forum thread pointed me to screen management apps. Lux, Twilight, etc. – the kind of apps that will alter your screen to red-shift it at night, or adjust brightness below the range of the screen’s backlight.

Sure enough, I disabled Lux from the pull-down, and the Install button worked. Once the update was done, I re-enabled it. Just an extra two seconds of work before and after.

It probably happens on other third-party app stores and stand-alone installers as well.

The cause wasn’t completely clear from the discussion thread, but reading between the lines and adding my knowledge of software and web development suggests that it’s a security issue: Apps like Lux and Twilight work by altering the appearance of the screen (“draw over other apps” permissions). It makes sense that Android would prevent installation (outside of its own privileged update system, anyway) actions when it can’t be sure that what the user sees is actually an Install button.

Imagine a malicious app that overwrites the screen to hide an Install button under something more benign. In web development, we call this clickjacking.

Anyway, that’s the issue and the workaround, and why I think it hasn’t been fixed in all this time: Fixing it would open up a security vulnerability.

Fortunately, the workaround is pretty easy!

Update: It occurs to me that Facebook also requires the “draw over other apps” permission, which was why I finally uninstalled it. I expect that might cause issues if chat heads are visible when you try to install/update an Amazon app.

Can’t Log into Feedly or Pinterest on Firefox 40? Check Ghostery!

I use Feedly to keep up with a lot of sites ranging from tech to entertainment. After upgrading to Firefox 40, I wasn’t able to log in using my Google account. The authentication pop-up would only bring up a plain HTML page saying, “Moved Temporarily The document has moved here.” The same problem occurs with Pinterest and Facebook login, though in that case the authentication pop-up is blank. Pocket also shows the “Moved Temporarily” message, but recovers. I’m having trouble logging into Disqus too. Lots (but not all) of third-party logins seem to be broken now.

Update: Ghostery 5.4.8 fixes the problem!

TL;DR: Use this workaround!

  1. Go into Add-Ons and disable Ghostery.
  2. Log into Feedly / Pinterest / whatever.
  3. Go back into Add-Ons and re-enable Ghostery.

A discussion on Google+ suggested disabling add-ons. I tried it, and was able to log in — great! But I wanted to know which extension was the problem.

After experimenting a bit, I found that disabling Ghostery allowed me to log into Feedly with Google.

Just to make certain, I logged out of Feedly, re-enabled Ghostery, and tried logging back in. Sure enough, I was back to the “Moved Temporarily…” error again. I’ve had Ghostery on this browser for a long time with no problems, and the about page shows that the extension was last updated toward the end of July, so I assume the problem is that something in Firefox 40 changed the way the browser, Ghostery and OAuth interact. I wouldn’t be surprised if it runs into issues with other privacy add-ons like AdBlock or Privacy Badger.

Fortunately, Ghostery can be turned on and off without restarting your browser. And turning it back on after you’re logged in doesn’t seem to interfere with Feedly.

I may go back and try to figure out the specific setting that’s causing the issue, but for now, I’m able to run both Feedly and Ghostery, so I’m not in too much of a hurry.

Update: Ghostery will be releasing a fix to resolve the bug, which turns out to affect quite a few sites. (via Feedly on Google+.) Update: Ghostery 5.4.6.1 is supposed to fix the problem, but it still breaks login on some sites, including Feedly and Pinterest.

Update: Ghostery 5.4.8 fixes the problem!