[theme-reviewers] Failure of review for my theme (Ahimsa 4.0)

[// ravi]

On Mar 18, 2012, at 9:27 PM, // ravi wrote:
> 
>> For example, see how Twenty Eleven outputs its custom link color CSS rule (look for the twentyeleven_print_link_color_style() function, hooked into wp_head):
>> http://themes.svn.wordpress.org/twentyeleven/1.3/inc/theme-options.php
> 
> 
> Thank you for the reference. I will check it out and at this point, I am almost convinced to move to the DB.
> 

After much mental waffling, I have started looking at migrating to DB options for all my user customisations. The data I store will be of three types: one is a bunch of colour settings, which are easy to store as variable/value pairs in the WP DB. Second is a bunch of CSS specifications which I could treat as a giant string and store as a single option in the WP DB. Third is custom footer material (JavaScript supplied by vendors such as Google Analytics, etc), which again I could store as one large string in a single option. Earlier, these were all saved in files in WP_CONTENT_DIR/themestore/ahimsa and (for Unix systems) symlinked into TEMPLATE_PATH, so that the user could just use Dashboard -> Appearance -> Editor to edit them. Now that they may go into the DB, apart from the current colour settings which are already in Dashboard -> Appearance -> Ahimsa Options, I will have to provide a couple of TEXTAREAs to edit the CSS customisations and footer.

My [hopefully final!] question[s]: do you see anything wrong with this approach? Second, the add_option(), etc, Codex pages note that the data is serialised by these functions, so I am guessing arrays of arrays, etc, will be handled gracefully. But is the data also sanitised or escaped to prevent SQL injection, etc?

Thank you,

	—ravi