Options from same section should be stored as a single option in the db

[richardtape]

Title says it all really, but doing this prevents multiple calls to the database to retrieve more than one option. It's a generally accepted practice within WP.

[NateWr]

I'm familiar with the technique for post metadata, but I am not sure how to do it for these options using the WordPress Settings API. Each setting registers itself with WordPress with a call to add_settings_field() and register_setting().

Do you know of an example I can look at to copy their method? It will provide some backwards compatibility issues as well so I'll need to look into that.

[richardtape]

Best thing I can recommend is to look into how Easy Digital Downloads handles their options. I suspect it's just a case of appending [field_name] to the field names for each section i.e. name="sectionName[fieldName]"

[NateWr]

I've been doing some thinking about how to maintain backwards compatibility with this and I'm just not sure there's a good and reliable way to do it. So instead, I've flagged this to be changed for a 2.0 release.

However, I'll also write something to port the data from 1.x to 2.0, that can be easily initialized and run by any plugins/themes using the library. That way they can port their data on an as-needed basis, but we don't saddle the library with the need to check for old data every time it's loaded.

My plugin, Food and Drink Menu, is probably the only thing using this library at the moment anyway. But since I made it 1.0 when I threw it up (instead of 0.1 which would have made more sense) I'm going to go ahead and use the major.minor.maintenance versioning system.

[richardtape]

Hey Nate, good to hear you've been putting some thought into this. Architectural changes like this are tricky - always are and always will be. Worst thing that can happen is to have breaking changes which aren't backwards compatible (cough Advanced Custom Fields cough) so I fully understand your concern and need for this to be done correctly.

Frustratingly, the changes that would need to be made in the code are relatively simple and minor but they are potentially backwards incompatible (it all depends on how people are retrieving the settings from the database, really).

It'll be interesting to see how you approach going about this and I'd love to help in any way I can - just let me know.

[NateWr]

I put a lot of time into this today and came to the conclusion that the current structure is inadequate. The simple fact is that the library mistakes options groups for pages, and that leads to issues with how the data is structured in the database and how it is presented (even precluding the use of tabs).

Woops! I knew this thing wasn't ready for prime-time when I threw it up.

I have two basic approaches in mind. I'd love to hear your perspective on them. I am neither a particularly accomplished coder or a WP expert:

1. Allow plugin/theme authors to instantiate the library in compatibility mode. In this mode, it would look for get_option( 'option_id' ) if it couldn't find any value for get_option( 'group_id[option_id]'). This would allow data to port from one version to the next, but the plugin/theme authors would still need to check for both when retrieving the values on the front end. Although this provides some backwards compatibility, I don't like how much complexity it introduces to the code base. The whole point of the library is that it can be read and used very easily.
2. The other approach is just to bump to 2.0 and say it's not backwards compatible. I could still provide a simple way for plugin/theme authors to port their data within their products, but it wouldn't be built into the library. I'm leaning towards this approach because a) it keeps the code base clean, b) I don't think anyone is actually using this library yet and c) if they are, they are only using it for very basic purposes and probably won't need the extra features that will be added in the future.

Does that sound like a reasonable approach?

[NateWr]

I have switched over now ( 3513e7a ) so that the library saves all data on a page in a single row in wp_options.

I jumped to version 2.0 Alpha 1 for this, because it breaks backwards compatibility. Before I release 2.0, I need to write a simple utility to port data, so that anyone using the library (ie - me) can easily move with the library in their own themes/plugins. Then I want to have a beta period where I implement it on my own plugin before finally releasing a proper 2.0 version.

I also plan to implement tabs (#1), as that is fairly trivial now that the data architecture has been improved.

[richardtape]

Really interesting stuff, Nate. I’m looking forward to checking this out. Pun somewhat unintended.

On April 2, 2014 at 4:55:19 PM, Nate Wright ([email protected]) wrote:

I have switched over now ( 3513e7a ) so that the library saves all data on a page in a single row in wp_options.

I jumped to version 2.0 Alpha 1 for this, because it breaks backwards compatibility. Before I release 2.0, I need to write a simple utility to port data, so that anyone using the library (ie - me) can easily move with the library in their own themes/plugins. Then I want to have a beta period where I implement it on my own plugin before finally releasing a proper 2.0 version.

I also plan to implement tabs (#1), as that is fairly trivial now that the data architecture has been improved.

—
Reply to this email directly or view it on GitHub.

[NateWr]

267efc6 adds a simple method to port the data to the new format for those (probably just me) who are using this in production. I've provided some guidance on how to ensure the data is ported and how to retrieve data under the new structure.

Testing and feedback much appreciated. I'll move to a 2.0 beta soon and use it "in the wild" on my own plugin. If there are no major tragedies that ensue I'll release 2.0.

Thanks for prompting me to sort this out!

[timiwahalahti]

Hi Nate, thanks for this amazing library!

I'm commenting this issue because i think that there should be (at least) option to save settings as a single for each section, not for each page. I think that would make data structure simpler in most cases.

Example: I have page with three sections for different use cases (eg contact page, front page and footer) and each section has let's say 5-15 fields. I'm forced to get all those settings in situation where i need only one section. Also the naming would be more logical, because now the settings are not saved in multidimensional arrays. Section id's does not have any effect, now field id's needs to be prefixed with it to recognize field's correctly.

[NateWr]

Hi @timiwahalahti. This sounds like a nice feature. I've opened up a separate issue with a bit of detail: #10

I usually add features when and as I need them. So I may not add support for this any time soon. But I'm always open to PRs.