4 posts
  • Has been part of the Envato Community for over 3 years
  • Sells items exclusively on Envato Market
chipbennett says


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.

814 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 1+ items on Envato Market
  • Contributed a free file of the month
+3 more
rvision_ says



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.

731 posts
  • Has referred 500+ members
  • Has sold $125,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+7 more
mordauk says

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 .

3072 posts
  • Has referred 50+ members
  • Has sold $40,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Had an item featured on Envato Market
+5 more
wickedpixel says

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.

731 posts
  • Has referred 500+ members
  • Has sold $125,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+7 more
mordauk says


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.

814 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 1+ items on Envato Market
  • Contributed a free file of the month
+3 more
rvision_ says


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?

814 posts
  • Has referred 1+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 1+ items on Envato Market
  • Contributed a free file of the month
+3 more
rvision_ says



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.

731 posts
  • Has referred 500+ members
  • Has sold $125,000+ on Envato Market
  • Has collected 50+ items on Envato Market
  • Elite Author: Sold more than $75,000 on Envato Market
+7 more
mordauk says

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/

316 posts
  • Has referred 10+ members
  • Has sold $10,000+ on Envato Market
  • Has collected 10+ items on Envato Market
  • Has been part of the Envato Community for over 3 years
+2 more
SyamilMJ says

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.

4 posts
  • Has been part of the Envato Community for over 3 years
  • Sells items exclusively on Envato Market
chipbennett says


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.

by
by
by
by
by
by