If you’d also rather avoid recursively chown’ing the WordPress tree to your web server, then simply give web server ownership to three files in the wp-admin directory: plugin-install.php, plugins.php, and update.php. Of course the web server will also need to own the plugins directory (and everything therein), as well as the wp-content directory itself. The “upgrade automatically” links should now work without kicking you to the “Connection Information” screen.

“Flymake: Configuration error occurred while running. Flymake will be switch OFF”

This threw me, though it probably shouldn’t have. If you’re seeing it as well, double check two settings in your php.ini file:

1. The error_reporting setting needs to include E_PARSE. I personally like to use error_reporting = E_ALL | E_STRICT. This shows everything that the PHP compiler thinks you are doing wrong.

2. Also double check your php.ini file for display_errors = On. I almost always forget about this when setting up on a new box because I tend to override php.ini with .htaccess values.

Finally, triple check your command line php settings with a quick $ php -i, which dumps the content of phpinfo() to the command line.

Thank you stackoverflow.

If you use the -e/–execute option while loading a dump, MySQL silently ignores -f/–force.  In other words, MySQL will not execute force.

But if you pass the same data in via a pipe, MySQL will beat the hell out of anything malformed and cram whatever it can into the database.

MySQL:  The Gandhi of databases… unless armed.

For some reason Google’s patent reply to this (probably) common interest is to state that transferring account data is not possible.  But actually it’s quite easy.  At least, it’s quite easy once you’ve played around with your various Google accounts for a few hours and finally figured out how administrator assignment works.

To do a “transfer”, all you have to do is:

1. Create the new Google Account to which you want to transfer control.
2. Log in as the original Google Analytics Administrator account.
3. Assign a the new account “Administrator” access.  (Edit -> Users with Access to Profile -> Add User)  Be sure to give this new user the “Administrator” access type.
4. Login to the new account.
5. Change the original Administrator account to “User” (don’t forget this step)
6. Delete the original account.

Easy peasy.

Just note that if you have a bunch of analytics site data all tied together under one profile, then all of it will transfer together.  As far as I can tell, there is no way to uncouple this.  And this is probably what Google is referring to when they say that ownership cannot be transferred.

Make sure that the user and group permissions for the account and the home directory match. For example, if you are logging in as:

account:x:521:500::/some/directory:/sbin/nologin

then make sure that the home directory defined for “account” is at least readable and executable by user 521 and group 500.

For example, if you are chroot jailing a particular user, given this entry from /etc/passwd:

username:x:100:200::/ftp/directory:/sbin/nologin
(where 100 = “username” and 200 = “somegroup”)

Make sure that the user and group permissions of the directory match what is set in /etc/passwd:


$ ls -lah /ftp/directory
drwxrwx--- 4 username somegroup 4.0K Mar 24 23:56 .


Posted this one since I’ve probably solved it, and then promptly forgotten the solution, at least three times.

jdbc:mysql://localhost/test?zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=UTF-8&characterSetResults=UTF-8

Your mileage side-effects may vary.

More excellent Java + J2EE tips (and lots of other stuff in Czech) here.


$ diff source/worksforme.php <(ssh -n me@liveserver cat /home/me/source/worksforme.php)


You can also compare files on two remote hosts.


$ diff <(ssh -n me@testserver cat /home/me/source/worksforme.php) <(ssh -n me@clientserver cat /home/me/source/worksforme.php)


WordPress’s second-guessing will break this, resulting in a bunch of garbled posts. To fix, comment out this chunk of code in wp-settings.php:

/*
 * In most cases the default internal encoding is latin1, which is of no use,
 * since we want to use the mb_ functions for utf-8 strings
 */
if (function_exists('mb_internal_encoding')) {
        if (!@mb_internal_encoding(get_option('blog_charset')))
                mb_internal_encoding('UTF-8');
}

With this gone, WordPress will stop second-guessing and custom encoding translations should flow through just fine.