Skip to:
Content

bbPress.org

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#1550 closed enhancement (wontfix)

bbp-admin: Consolidate individual get_option() calls into one entry

Reported by: r-a-y Owned by:
Milestone: 2.0 Priority: low
Severity: normal Version:
Component: General - Administration Keywords:
Cc:

Description

I noticed in bbp-admin that each settings field is saved as its own individual get_option().

Would be nice to consolidate all "_bbp_*" options into one entry in the DB.

Change History (4)

#1 @johnjamesjacoby
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Incorrect. :)

These options are added to WordPress's autoload routine, so the options are grabbed and cached automatically by WordPress. Putting them into 1 option means loading them into an array and extracting them into variables or otherwise serializing and unserializing them when we need to check them, rather than relying on the object cache to do its job.

#2 @r-a-y
11 years ago

So all WP plugins should preferably save each option separately?

This goes against most of the articles I've read on the subject (including some written by respected Wordpress devs like Otto):
http://web.archiveorange.com/archive/v/g3jJ6WVZweexzznYttq7

As you can see in the thread, there are two sides to each argument! Now I'm wondering which side is right (if there is a right answer).

Is what nacin says here relevant for bbPress?

Re: object cache - this means that Wordpress admins would need to install an object caching plugin in order to take advantage of this though.

#3 @johnjamesjacoby
11 years ago

Like anything else, it depends on the option, and when it needs to be available. In the case of bbPress, since it works in tandem with existing WordPress functionality (potentially on any page because of Widgets) it makes sense to have them auto-loaded.

What Otto suggests is great advice for the average developer and plugin, to avoid using a bunch of get_option() calls on settings that aren't auto-loaded. What Nacin mentions there is exactly what we're talking about. The way the WordPress object cache works, even without additional plugins, is anytime something is queried through a core WordPress API convention, its results are held in the object cache. From that point on in the page load, any additional calls to that same query will hit the object cache instead of the DB. This works for loops, meta, taxonomies, etc... It's why you can load 1 post with get_post(), and use a ton of get_post_meta() calls, and not hit the DB 100 times. The results of get_post() get cached, and the rest is smooth sailing.

Things get complicated when you start talking about having multiple loops and queries and users, etc... Caches invalidating each other, mass hysteria. It doesn't happen often if you stick to using the core WP functions, and it's part of why something like BuddyPress isn't as efficient as WordPress. At it's core, every unique user query is a DB hit, and obviously community sites have more users doing more things.

Cacheing plugins for WordPress basically just try to shove different pieces of the process off into specialized buckets that know when to invalidate their specific content. Object caching plugins can take the common queries that change very rarely, and retain that query somewhere in memory. Other plugins like W3 Total Cache provide CDN's and caching page output to flat files that don't even load up PHP.

Custom post types are huge for developers looking for simple solutions to storing data, but they also provide immediate integration with the internal object cache. bbPress 2.0, for example, drops right in and plays perfectly with any existing cacheing plugin for WordPress. It's pretty slick the way it just works. :)

#4 @r-a-y
11 years ago

I still agree with Otto for the most part though. Also, the array approach is even advocated in the new plugin dev book by Ozh, Justin Tadlock et al. for autoloaded options.

But, thanks for the in-depth write up, JJJ. Really appreciate it!
There's much I still need to learn about memory, DB performance and object caching in *Press.

Note: See TracTickets for help on using tickets.