jmodjeska

If you have server or hosted account access, you can look at the wp_users table in your wordpress database to identify your username.

— jm

Before you make any changes directly to your database, make a backup: http://codex.wordpress.org/Backing_Up_Your_Database

I believe figaro is correct; a direct change in the database may be required. If you can login to phpMyAdmin, or have command-line access to the MySQL database, you can try running this query:

UPDATE wp_options SET option_value='UTF-8' WHERE option_id='36'

option_id 36 is blog_charset, which is what you’re looking for. Good luck!

Oops, sorry about that. I guess the sociable stylesheet loads after yours does. Two options: either edit the sociable.css stylesheet directly (same code as above) or add the “!important” flag after those changes in your site’s stylesheet. I just tried the second method and it worked, so give that a shot first:

.sociable-hovers {
	opacity: 1.0 !important;
	-moz-opacity: 1.0 !important;
	filter: alpha(opacity=100) !important;
}

Looks OK to me, my friend.

http://j.modjeska.us/imgs/kikicomm.jpg

Try clearing your browser’s cache. Favicons are notorious for persisting after you make changes.

Igneous: this is a “zero day attack” mitigation. There is no specific known security threat with using wp_ as the prefix, but I think the idea is that through obfuscation of your table names it might save you from some hypothetical future attack that relies on the knowledge that everybody using WordPress has identical table names.

DebNCgal et al: Regarding the process for changing prefixes if you’re on a hosted server:

Many hosting companies don’t allow ALTER rights (including, apparently, Godaddy). This is probably good, based on my limited knowledge of MySQL security.

There are numerous websites that explain workarounds if this is the case for you. For me, a nice safe process with plenty of fallbacks in case I !@#$ed it all up was as follows:

1. Backup your tables: http://codex.wordpress.org/Backing_Up_Your_Database (fallback #1: worst case, restore from this file)
2. Open the “.sql” backup file that you’ve just created in the text editor of your liking, and replace all instances of “wp_” with whatever your desired new table prefix is; SAVE AS a new file (fallback #2, you still have the original “.sql” file from step 1 in case this modified SQL dump file doesn’t work out)
3. Now, create a NEW empty database on your hosted server. This process varies by hosting company. For Godaddy users, for example, you just login to your hosted account, select Databases > MySQL > Create Database. Once you have your new database created, upload the modified “.sql” file to this database; that is, the .sql file with the new prefixes in it. You can probably use these instructions to accomplish this keeping in mind that you’re not *really* restoring from a backup, but populating a new database using your saved data: http://codex.wordpress.org/Restoring_Your_Database_From_Backup
4. Locate your wp_config.php file. Save a copy as wp_config.php.backup (fallback #3, you can revert to the “old” wp_config file, which points to the “old” and untouched original database). Edit the wp_config file so that it contains your new database information including the new username, database name, password, and $table_prefix (~line 11).
5. Now the fun part. Until now, you haven’t changed anything on your blog. It’s still using the original, unmodified database. Everything you’ve done until now has happened in the background with no effect on your website. Now you’re going to upload the modified wp_config.php file into your blog’s root directory. You’re telling WordPress to use the new database with the shiny new prefixes in it. If something goes wrong, just upload the backup wp_config.php file and WordPress will use the old, untouched database.

Like you, I’m nervous about any automated database modifications, so this process should give you the peace of mind that should something disastrous happen, you have several immediate options to revert back to the way things were.

NOTE: If you encounter the “You do not have sufficient permissions to access this page” error, follow these instructions here.

Hope this helps!

— jm

Please see here:
http://wordpress.org/support/topic/263350?replies=2

I looked everywhere for a solution for this but no luck, so I came up with a hack (works for “tickbox” effect only, as far as I know). You were on the right track, but shutter-reloaded.js doesn’t directly read the image data. In fact the relevant javascript file is tickbox.js, but even that one just pulls its data from the title attribute of the tumbnail image’s “a” tag. So, the solution is to modify the data that gallery.php puts into the “a” tags.

More information, example, and code here:
http://j.modjeska.us/?p=113

Hope this helps.