4 posts
  • Exclusive Author
  • Has been a member for 3-4 years
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
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
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
  • Elite Author
  • Attended a Community Meetup
  • Has been a member for 4-5 years
  • Sold between 100 000 and 250 000 dollars
  • Bought between 50 and 99 items
  • Exclusive Author
  • Most Wanted Bounty Winner
+2 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 .

3069 posts
  • Has been a member for 6-7 years
  • Won a Competition
  • Sold between 50 000 and 100 000 dollars
  • Bought between 10 and 49 items
  • Referred between 50 and 99 users
  • Exclusive Author
  • Romania
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
  • Elite Author
  • Attended a Community Meetup
  • Has been a member for 4-5 years
  • Sold between 100 000 and 250 000 dollars
  • Bought between 50 and 99 items
  • Exclusive Author
  • Most Wanted Bounty Winner
+2 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
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
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
  • Author had a Free File of the Month
  • Exclusive Author
  • Sold between 10 000 and 50 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
  • Serbia
  • Has been a member for 5-6 years
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
  • Elite Author
  • Attended a Community Meetup
  • Has been a member for 4-5 years
  • Sold between 100 000 and 250 000 dollars
  • Bought between 50 and 99 items
  • Exclusive Author
  • Most Wanted Bounty Winner
+2 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/

315 posts
  • Has been a member for 3-4 years
  • Sold between 10 000 and 50 000 dollars
  • Attended a Community Meetup
  • Exclusive Author
  • Bought between 10 and 49 items
  • Referred between 10 and 49 users
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
  • Exclusive Author
  • Has been a member for 3-4 years
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