<div dir="ltr">With a casual read, this seems really, realty simple. Don't ever "save" anything without actual confirmed user interaction (behind a nonce, at minimum).<div><br></div><div>I cannot give you better advice without seeing code, but it is *never* a good idea to make permanent changes of anything without a proven case where the user "did" something.</div>

<div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div>-Otto</div>
<br><br><div class="gmail_quote">On Sun, Mar 16, 2014 at 7:02 PM, Bruce Wampler <span dir="ltr"><<a href="mailto:weavertheme@gmail.com" target="_blank">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">

<div dir="ltr"><div><div><div><div><div>Back for another grandfathering request.<br><br></div>Previously, the requirements were that themes not touch the database for Preview. The new requirement is to not touch the database until the user actually does something to save settings.<br>


<br>I've tried really really hard to meet this, and it is turning out to be a major disaster for a significant fraction of my users as they try to update to the latest version of the theme. I have literally spent 20 or 30 hours on this problem, and simply cannot reliably skip touching the database when the admin page is opened.<br>


<br></div>For unreproducible reasons, about 10% of the time, people are losing all their previous settings when the update to the newest version that doesn't touch the database. In previous versions, the theme always would either create a new settings option in the database, or update existing settings (somewhat like an update to WP often does for the database).<br>


<br></div>Given that people do not always update their theme, and that there is also a Pro version, and that the items in the saved option have changed over time, there is some incompatibility across versions that is simply breaking things. My best guess is that there may be some interaction with the Settings API. Given that it is essentially impossible to reproduce, and likely has something to do with old and new versions, I just can't find a solution that doesn't wipe out the settings of some of existing theme users when updating to the latest version.<br>


<br></div>I don't anticipate being able to reliably find any solution to this. 90+% of the time, the update works perfectly, but for some combinations of previous versions, it breaks. Rather than subjecting that small, but real percentage of users to losing all their work (some have made backups and can their work restored, but some haven't), I would like to request an exception to that requirement. The update process has worked reliably for several years now, but trying the meet the new requirement is apparently beyond my ability.<span class="HOEnZb"><font color="#888888"><br>


<br><br></font></span></div><span class="HOEnZb"><font color="#888888">Bruce Wampler<br>Weaver II theme<br></font></span></div>
<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></div>