WP Theme Forward Compatibility - Shortcodes/CPTs

rvision_ said

chipbennett said
As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

In my case it belongs. I am doing a serialization of an custom options object and I need this. Exported data is a plain text.

Why is this a problem?

Why do you need a custom options object?

In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

chipbennett said

rvision_ said

chipbennett said
As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

In my case it belongs. I am doing a serialization of an custom options object and I need this. Exported data is a plain text.

Why is this a problem?

Why do you need a custom options object?

Because I have strongly-typed options. Each option type is a class that returns either boolean, array, string or number. I don’t have to cast or check on the theme front-end what is the return value. Array is well, just array – array of anything/any type.

Base64 is used only for import/export.

rvision_ said
Because I have strongly-typed options. Each option type is a class that returns either boolean, array, string or number. I don’t have to cast or check on the theme front-end what is the return value. Array is well, just array – array of anything/any type.

That’s really easy to do with WP Settings API .

chipbennett said
In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

Sometimes it’s better to read all settings in one call. Wordpress setting api sets individual options – asking from it 30 settings can look pretty heavy.
Same thing with custom fields – If you need to display 10 posts and every post has 10 individual settings – I think is better if those 10 settings are placed inside a single post custom field.
I really like the options that wordpress gives by default, but sometimes you pretty much need to optimize the data reading actions.

wickedpixel said

chipbennett said
In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

Sometimes it’s better to read all settings in one call. Wordpress setting api sets individual options – asking from it 30 settings can look pretty heavy.
Same thing with custom fields – If you need to display 10 posts and every post has 10 individual settings – I think is better if those 10 settings are placed inside a single post custom field.
I really like the options that wordpress gives by default, but sometimes you pretty much need to optimize the data reading actions.

You can easily store all settings with the Settings API in a single option. If you need an example of how to do it, you can see how it’s done in Easy Digital Downloads. Technically I use four settings, but that was only for better separation.

mordauk said

rvision_ said
Because I have strongly-typed options. Each option type is a class that returns either boolean, array, string or number. I don’t have to cast or check on the theme front-end what is the return value. Array is well, just array – array of anything/any type.

That’s really easy to do with WP Settings API .

I haven’t seen anywhere in the documentation anything about type. Can you enlighten me?

mordauk said

wickedpixel said

chipbennett said
In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

Sometimes it’s better to read all settings in one call. Wordpress setting api sets individual options – asking from it 30 settings can look pretty heavy.
Same thing with custom fields – If you need to display 10 posts and every post has 10 individual settings – I think is better if those 10 settings are placed inside a single post custom field.
I really like the options that wordpress gives by default, but sometimes you pretty much need to optimize the data reading actions.

You can easily store all settings with the Settings API in a single option. If you need an example of how to do it, you can see how it’s done in Easy Digital Downloads. Technically I use four settings, but that was only for better separation.

Actually in terms of performance it doesn’t matter. When you mark your options with $autoload=true, they will be all loaded in a single db query.

rvision_ said
I haven’t seen anywhere in the documentation anything about type. Can you enlighten me?

I wrote up / recorded a tutorial on how I did it: http://pippinsplugins.com/how-i-built-settings-system-easy-digital-downloads/

greenshady said
I have a plugin I’m building where this will work in both Theme A, Theme B, as well as fall back gracefully to the plugin defaults with any other theme. I’m not sure about the policy of linking here in the forums, but it’s on my GitHub page.

That is one super awesome plugin.

wickedpixel said

chipbennett said
In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

Sometimes it’s better to read all settings in one call. Wordpress setting api sets individual options – asking from it 30 settings can look pretty heavy.

That one setting (actually, that one DB entry) can and should be an array of Theme options. If you, for whatever reason, need explicit type-casting, you can do it in the register_setting() sanitization callback.

Same thing with custom fields – If you need to display 10 posts and every post has 10 individual settings – I think is better if those 10 settings are placed inside a single post custom field.
I really like the options that wordpress gives by default, but sometimes you pretty much need to optimize the data reading actions.

Custom post meta data can also be retrieved as an array of key->value pairs, or as a single-key value. No need to reinvent that wheel, either.