I have done this in my theme, where all options pages write to the same array using the Settings API. However it is not a piece of code that I would want to write from scratch again - it is just not worth the trouble. You can take a look at Chip's tutorial on this topic. That does a very good job of handling a fairly complex scenario. I have a comment on that post that says how you can handle multiple options pages: <a href="http://www.chipbennett.net/2011/02/17/incorporating-the-settings-api-in-wordpress-themes/comment-page-1/#comment-17260">http://www.chipbennett.net/2011/02/17/incorporating-the-settings-api-in-wordpress-themes/comment-page-1/#comment-17260</a>. <br>
<br>The problem is this: you have 2 forms and you are, at any point of time submitting only one of them. So "Form 2" fields will be missing when you are submitting "Form 1" and vice versa, which blanks out the options pertaining to the form that is not being submitted. To tackle this, I made use of the fact that I already know what my fields are in the back-end. If I am getting the input for Form 1, I simply populate the registered setting with all the option values corresponding to the fields in Form 2. That way the array I am trying to save is always complete.<br>
<br>Sayontan.<br><br><div class="gmail_quote">On Mon, Feb 6, 2012 at 1:26 PM, Bruce Wampler <span dir="ltr"><<a href="mailto:weavertheme@gmail.com">weavertheme@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using SAPI and more than one db option:<br><br>This is a difficult question. In my own theme, I have found there are really serious issues with the Settings API when trying to track two sets of settings with more than a single HTML form - it tends to reset values back to false in a way I've never been able to figure out. I ended up restructuring my admin pages using a javascript show/hide script for settings groups, but wrapping all the settings in what is essentially is a single <form>, so all the settings are in one db entry. It was not easy to do.<br>
<br>From recent discussions on this group, it looks like it would be worthwhile investigating using *_theme_mod functions to keep theme settings instead of the general settings. There was a link to an article by Otto on how to use the SAPI validation function differently to keep the SAPI features while using theme_mod instead. <br>
<br>I haven't tried this yet, but think that perhaps the only one data base entry rules should eventually be replaced with use theme_mod instead - if it really can be compatible with SAPI.<br><br>It should be fairly easy to add a check in the theme to provide an automatic conversion from the general settings to theme_mod.<br>
<br>But this is not an easy thing - especially for themes with lots of settings.<span class="HOEnZb"><font color="#888888"><br><br>Bruce Wampler<br>Weaver II theme<br>
</font></span><br>_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Sayontan Sinha<br><a href="http://mynethome.net" target="_blank">http://mynethome.net</a> | <a href="http://mynethome.net/blog" target="_blank">http://mynethome.net/blog</a><br>
--<br>Beating Australia in Cricket is like killing a celebrity. The death gets more coverage than the crime.<br><br>