By Jeffro on July 1, 2009
Before making the domain move the other day, I made a mistake by deleting something I shouldn’t have from the database. It was the comment_karma field located within the wp_comments table. A long time ago, I remember installing a plugin called Comment Karma which enabled visitors to rate a comment up or down thus promoting the best user rated comments to the top.
I thought that by installing this plugin a long time ago, that it had created this entry in my database. Thinking another plugin left its stuff behind in my database, I removed it only to find out that removing it broke my commenting system to the point where the incrementer broke. To make matters worst, I didn’t do a database backup since I thought I was removing something plugin related. However, thanks to Michael Torbert, he helped me put the comment_karma field back in its location and once I did that, everything worked again.
So, when I dived into the WordPress-Dev IRC channel to see what this field is used for, someone said it was not used by anything in core and Michael told me he couldn’t find anywhere that field was being used. But, if it was not being used in core, why would it cause the commenting system to break when it’s removed?
The overall lesson here, don’t do ANYTHING to your database unless you backup first. Complacency is your enemy.
Posted in WordPress | Tagged backups, comment, database, karma |
By Jeffro on April 16, 2009
Today I wanted to talk about a problem which Justin Tadlock will be covering in more detail at some point in the future and that is, plugins which contain a CSS file to edit their style. Don’t get me wrong, Lester Chen is a great plugin author, but I find it increasingly annoying that after I make the necessary styling changes to his WP-PageNavi plugin so that it blends in with my theme, I overwrite those changes once I upgrade his plugin.
Based on what I’ve been told, it’s fairly easy to add a plugins stylesheet to your themes CSS file so that this sort of thing doesn’t happen. But, I wanted to raise the question if whether or not plugins should come with their own CSS file for editing or just store the styling information in the database so that end users don’t have to worry about messing around with the CSS in the first place? I’m pretty sure this is how Lester’s WP-Polls plugin works as I can define from within the plugin options page which colors the voting bars should be via hexadecimal color codes.
What are the drawbacks to storing plugin style information in the database versus a CSS file? On the surface, seems like adding the style information right into the plugins options table in the database is A OK to do.
Posted in WordPress | Tagged css, database, Plugins, settings, style |
Bad Comment Karma
By Jeffro on July 1, 2009
I thought that by installing this plugin a long time ago, that it had created this entry in my database. Thinking another plugin left its stuff behind in my database, I removed it only to find out that removing it broke my commenting system to the point where the incrementer broke. To make matters worst, I didn’t do a database backup since I thought I was removing something plugin related. However, thanks to Michael Torbert, he helped me put the comment_karma field back in its location and once I did that, everything worked again.
So, when I dived into the WordPress-Dev IRC channel to see what this field is used for, someone said it was not used by anything in core and Michael told me he couldn’t find anywhere that field was being used. But, if it was not being used in core, why would it cause the commenting system to break when it’s removed?
The overall lesson here, don’t do ANYTHING to your database unless you backup first. Complacency is your enemy.
Posted in WordPress | Tagged backups, comment, database, karma | 6 Responses