All posts by Ben Kaplan

WordPress and their premature attempt to move us forward on MYSQL

0 comments Hosting, server, wordpress tips

Ok, so on April 1, 2015…no kidding…Wordpress announced they are officially supporting the newer charset utf8mb4 in WP version 4.2. This charset is available in mySQL servers version 5.5.3 and higher (I think). This is cool and all, rather hipster, and up to date with best security practices and all that. However, what they completely missed was the fact that a huge portion of the shared server world is running mySQL versions 5.0 and 5.1. If you try to migrate a WordPress site from a server (or local box) that is appropriately running something remotely current to a shared hosting account with the older database, your migration will fail.

Here’s the article where they describe the changes and the beginning of the conversation about how it’s an issue…

https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/

I’m sure there are thousands of developers wasting time figuring out how to fix this issue. I’ve not found an ‘easy’ fix. Here’s mine clunky version of migrating from development to staging/production…

  1. From phpmyadmin, or your favorite tool, do a full SQL dump.
  2. Run a script or manually change, the URL of the dev site to the new one.
  3. Run a script or manually change ‘utf8mb4_unicode_ci’ to ‘utf8_general_ci’
  4. Run a script or manually change ‘utf8mb4’ to ‘utf8’
  5. Import your new SQL dump into the new database.

This process assumes you’ve migrated the source code of WordPress already.

You can blame ISPs for not getting current, but I think trying to upgrade these older mySQL servers to something more current is an enormous headache for clients and ISPs a like. WordPress should really have paid attention to the reality of this situation and taken measures to mitigate the issue.

Happy hunting for an easier solution, but if you need, the above will work.

Grep find xargs regex and other great tools

0 comments *nix, command line, linux, server, unix

This is a little dumping ground for me to use to store useful recipes.

Find a file that was created between two ranges, say on the same day…

touch -t 201608200000 start
touch -t 201608202359 stop
find . -newer start \! -newer stop

Find all files with a particular name or extension and delete if you want

find . -name "*.bak" -type f -delete

Just run without -delete to review before you do it

Find files or directories with a certain permissions set, or without a certain permissions set

find files that don’t have permissions of 644
find /path/to/dir/ -type f ! -perm 0644 -print0

find files that don’t have permissions of 644 and change them
find /path/to/dir/ -type f ! -perm 0644 -print0 | xargs -0 chmod 644

counts all .php and .html files from the current directory that aren’t under the “includes” or “forum” directories.
wc runs wordcount on each file that matches. the “tr” through “bc” takes those numbers and adds them up.

find . -not \( -path ./includes -prune \) -not \( -path ./forum -prune \) -regex ‘.*/.*\(php\|html\)’ -exec wc -l \{\} \; | tr -s ‘ ‘ ‘ ‘ | cut -d ‘ ‘ -f 2 | paste -sd+ – | bc

Partial Content 206 error on fonts after a hosting migration

0 comments *nix, Hosting, wordpress tips

I’ve recently encountered an issue twice in the last few weeks where the font-face fonts on a website stopped working after a migration to a new hosting provider.

I used the nifty tool, Backup Buddy from iThemes, and all went well, except on the new server the embedded fonts weren’t rendering. :/

After many hours of searching, checking headers, and such, I bothered to look at the console output in Chrome and noticed that there was an error speaking to cross-domain issues specifically regarding the font files.

So what was the issue? In WordPress, you can set the WordPress Address and the Site Address separately. If one is www.somedomain.com and the other is somedomain.com (aka the sub-domain doesn’t match) then you’ll get this pesky error.

Hope that helps.

Tips for setting up your own LAMP stack in Mac OSX

0 comments *nix, command line, Hosting, IT systems, linux, server

Hey, this is NOT a comprehensive guide to setting up your own development environment, but I thought I’d post a few pitfalls I’ve discovered.

Most macs are set up out of the box to run apache found in /etc/apache2/. Normally, the system user and group for apache is _www. If you try to set up sites in /usr/HOMEDIR/Sites, it’ll likely give the files there the ownsership:group of YOURUSER:staff (or something else than staff). It either needs to be _www:_www OR YOURUSER:_www (and then you change the httpd.conf file to reflect YOURUSER for the User variable).

Also to edit any system files like that, be sure to edit as a super user or sudo.

Android Emulator

0 comments *nix, cross browser testing, css

Most of you know that you can install an Android Emulator on your computer to test apps and websites.

I’ve got the Android SDK installed so I can run an emulator. Recently, I removed an old version of the SDK and started from scratch. I’d installed it in a place I didn’t like and wanted to start over. The problem I ended up having was that the 4.x version that I installed had an insanely slow emulator. Here’s a nice little write by Mirko Juric-Kavelj up on how to speed up that emulator 🙂