good start – no great start!…
a couple of comments (most are nit picky) and some security issues that need to be cleaned up…
I would suggest a permission for who can give thanks and who cannot… see some commented out code along that lines but would suggest finishing that off
you have it hardcoded to 7 levels… wouldnt be that hard to start with 7 and if it fills up, offer more slots…
some folks may not want to lose the member stats to show the thanks stats… would be nice to have both… or maybe a template tag that users could use anywhere to display it… you have created some of what you call template tags, but they are all called via hook… might be useful to have some that users could call from anywhere such as the stats in the sidebar… see our template tags plugin for some examples… maybe even a template tag for the most thanks posts or most thanked authors…
I suspect the columns are not dropped because you are not actually uninstalling – just deactivating… I dont see an uninstall option for the plugin on the sp plugins panel… look at a couple of our plugins (pm, subs, etc) for the hook ‘sph_plugins_active_buttons’ to see how to offer the proper link for uninstall which will call the other hook you have set up…
you have a bunch of empty directories… I would just remove those… of course, you may be waiting until done! 
when you have icons or css, you should offer users an easy way to swap in their own… for example you icons do not match or look good in our sp theme… not really your problem, but you want users to easily be able to swap… so we have set up a system where users can simply put the icons or css in their corresponding sp theme and it will override the ones you provide with the plugin… that way they dont have to edit the plugin itself and potentially lose changes on updates… this can be done for icons, css and template files (you only have the first one)… but check some of our plugins for use of sp_find_css(), sp_find_icon(), and sp_find_template() to make easy on users to match their theme… again, you currently only really would use sp_find_icon()…
you will have a problem with plugin activation multiple times… if a user customizes the options, then deactivates the thanks plugin, the next time they activate it, all their options will be overwritten… in the install function you should first check if your options already exist… if so dont reinstall the options… only do the options setup if the option does not exist… same for the column creation… there may be something you always want to do, such as activate an auth, on activation if you had removed it (like one should) when the plugin is deactivated…
when you submit your form, you are calling spPmValidateForm()… why? what if the user does not have the PM plugin active? you will get an error…
another nit, but you only have a single admin panel… IMHO, it takes up too much real estate to have its own accordion menu… I think it would be better as a menu item under components, ie Thanks Options… that way the accordion doesnt get too tall… see the policy doc or other plugin for how to add your menu to an existing accordion vs adding a new one… of course, its your plugin so you can do what you want – we give you the power to decide!
a little confused on what you did for the rank stuff… did you just replace the forum rank?? I see forum rank title, but then some points… not sure what it means… again, would suggest a template tag that folks would add to their theme to display in the user info area (where rank appears for each post) vs replacing something or forcing it in a specific location… that is the power of template tags… the user can show it wherever they want… allows maximum customization and power for the user… yes, they have to add the template tag to their sp theme template file, but it can go where they want…
Now… on to the security problems…
You have some issues that would allow mischievous persons to get a hold of your site… There are lots of places where you put raw, unfiltered data directly into the database… someone could easily do mysql injection to get key info from the database and take control of your server… anything that goes in the database should really be sanitized before sending to the database…
One example of this would be in your function sp_plugin_thank_the_post_do()… you have a form there with a lot of hidden input… hidden is not really hidden – just not displayed… anyone can easily adjust the value of those inputs with tools built into every modern browser… when you submit the form, the ahah routine is directly sending those values to the db… I could modify the input with sql injection and you would directly enter into the database… ANYTHING that comes from user input or could come from, needs to be sanitized…
so in your ahah routine, this:
$post_id = $_POST[‘current_post’];
would become
$post_id = sp_esc_int($_POST[‘current_post’]);
that will sanitize the input and remove any injection attempts… likewise for non integer inputs, there is sp_esc_str()… there are also numerous other filters in the sp-api-filters.php api that can be used… take a look at some our examples when some might be used… so check all your input ($_POST or $_GET) variables for sanitization…
also, you are using $_SERVER[“REQUEST_URI”] to come to the same page… its possible to spoof that… I would either use the sp_build_url() function and the current $sfvars to build the current url or the permalink element of the current object (ie $spThisTopic, $spThisPost, etc) to be on the safe side… the latter would be easier…
any ways… that’s enough for now but seriously, a great start!!
