blog.arithm

Recent versions of WordPress have taken a queue from Janis Elsts’ One Click Plugin Updater and made it *much* easier to keep plugins up-to-date without having to fire up FTP. The problem is that WP seems to use permissions of it’s script files to determine whether or not plugins and themes can be uploaded to the server or not. Really WP should be looking at the target directory rather than the executing script; consequently I assume most folks just assign web server ownership to the entire WP source tree. Which, frankly, kind of freaks me out security-wise.

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.

Getting the following message when trying to use Flymake with PHP?:

“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.

svn cleanup seems to do this when there is a partially completed update in a directory. (I think..)  Try deleting the .svn/log file in the offending directory and doing svn cleanup again.

Thank you stackoverflow.

Strange but true.  And something that seems to trip me up once every other year or so.

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.

If you’re like me, back in the murky past your created a few (or several) Google Analytics accounts to track all manner of web sites and other online shenanigans.  And now you want to consolidate without losing any data.

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.

There’s lots of recommendations floating around the net for this, but try the following first:

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.

This is a frustrating one. Make sure that the user you are connecting as and the target directory have both the same user as well as group permissions.

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.

If you ever run across this while fighting with Hibernate, one quick fix is to instruct JDBC to turn the bad date values into NULLs, eg:

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.

This is a godsend. Wish I had thought about doing this before.


$ 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)


Recent versions of WordPress like to second-guess the internal and external encodings used by mbstring when assembling data from the database and spitting it out to blog pages.  Probably this works fine for most, but if you have an older database storing text as something other then UTF-8, probably you have a custom chunk of mbstring configuration in an .htaccess file or similar; perhaps like this:

php_value output_buffering 1
php_value output_handler mb_output_handler
php_value mbstring.language Japanese
php_value mbstring.internal_encoding EUC-JP
php_value mbstring.http_input auto
php_value mbstring.http_output SJIS
php_value mbstring.encoding_translation 1


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.