Import Largo 0.3->0.5.5.3 update functions

[benlk]

Changes

This imports the old Largo update scripts.

• Imports inc/update.php from Largo 0.5.53
• Imports the of_get_option() function so we can read from the Options Framework
• Imports the of_set_option() function so existing largo update functions can operate upon the Options Framework before we import those options into the new settings
• Within the largo_perform_update() ajax call, create a section for all optionsframework functions so that we only run those if there is an optionsframework instance in the database
  • a home for Database Update Scripts #1417 functions
  • this is the only place in the logic where we should of_set_option( 'largo_version', largo_version() ) to store the post-1.0 largo version number in the Options Framework. Any other place/time would break the update logic.
• Create largo_optionsframework_to_theme_mods(): an optionsframework -> theme_mods update function, with Theme Modification API detection so that it runs iff there is no theme_mods set yet.
  • example included: migrate the 'site_blurb' setting, for Add migration scripts for site blurb  #1423
• Rewrites the largo_need_updates() check to use largo_need_updates_0() for versions of Largo using the options framework and largo_need_updates_1() for versions of Largo using the Theme Mods API. These functions were named based off of their respective Largo versions.
• in largo_activatIon_maybe_setup, change the conditions to:
  • do not run setup if the theme mod version number is set
  • do not set the theme mod version number if the optionsframework exists, because we'll do that during the update process.

Questions

• Do have any reason to keep any of the LESS recompile functions from the Custom LESS stuff? Largo 0.x uses LESS; 1.x uses SASS, and the variable names aren't likely to stick around. We don't need to recompile for 1.x and in fact the files that we'll compile against will be gone.
• Do we need to keep any of the homepage upgrade functions?
• Should pre-1.x functions be broken out into a wrapper that checks for the existence of the Options Framework, so they don't run on fresh Largo sites?
  • yes, probably
• Do we need a theme_mods preservation function similar to the old Largo's options framework save function for "back up the options before running the update"?

[benlk]

Do we need a theme_mods preservation function similar to the old Largo's options framework save function for "back up the options before running the update"?

That's a question for when we start writing post-1.0 update functions.

[benlk]

Still to do on this:

• a wrapper for all optionsframework functions so that we only run those if there is an optionsframework instance in the database
• the optionsframework -> theme_mods update function, with theme_mods detection so that it only runs iff there is no theme_mods set yet: this will eventually contain the transition function described in Add migration scripts for site blurb  #1423.
• a theme_mods-based largo_needs_update check so that we can put later stuff in there

[benlk]

This is ready for review.

For testing purposes on the site_blurb portion of the script, I used an old copy of the c-hit.org database.