More specifically: does bbPress have mechanisms for automatic table creation and updating like the ones described in the WordPress docs?
See: https://codex.wordpress.org/Creating_Tables_with_Plugins
Should I start my Foo plugin by creating a function foo_install()? And can that function call dbDelta()? (I don’t see dbDelta in my bbPress anywhere.) If not, what’s the recommended alternative model for creating tables to be used in plugins?
dbDelta is in bb-admin/upgrade-functions.php, same as it is in WP. 
You are of course sure that you have to create a new table?
Sorry — I missed dbDelta and didn’t have a WP install handy to compare with.
As for whether I need a new table: is it advisable for a plugin to mess around with adding columns to standard bbPress tables? I suppose I thought I could do less damage by creating my own.
My application: I want to add geolocation (latitude and longitude) to topics. From a strict DB schema point of view there’s no reason for my data not to go into the topics table.
Just extend the topics table?
Never insert your own columns into the bbpress core data.Use the meta or create a new table.
Just a warning the the bbpress api is still in a state of flux so some plugins will be obsolete or non-functional soon. For example my “My Views” plugin will be useless once the next trunk becomes stable as they’ve change the entire “views” structure and basically anything else dealing with a query. It’s somewhat confusing (and messy) to me and I’ll have to wait to see examples in new plugins.
It might be a bit confusing, because it is a complex plugin, but the Support Forum plugin uses the topic meta table to store topic support status. This data used to be in a column in the topic table but was moved to the meta table a few versions ago.
The basic usage is (with some guessing as to what you would call your data):
// To add
bb_update_topicmeta($topic_id, 'topic_geolocation', $latlong);
// To delete
bb_delete_topicmeta($topic_id, 'topic_geolocation');
The topic metadata is automatically included in the results when you call get_topic().
No table manipulation should be necessary.
Yeah, really avoid doing anything to the tables and use topicmeta instead. By far easiest for you and nicest for the users, too, plus the additional overhead is minimal.
The metadata is returned when you call get_topic() like Sam said.
$topic = get_topic();
echo $topic->topic_geolocation; //echoes whatever
Cool, this is exactly the kind of bbPress-specific best practices I need to know and am not going to get from “PHP and MySQL in 30 Minutes”!
Is topicmeta documented anywhere? I’m looking at the code and can’t say it’s entirely clear…
Hmm — actually, looking at SamBauers’ tip three posts back, I see a problem.
My intention is to build a Google Maps mashup plotting topics on a map. That requires me to be able to efficiently search the entire database for all points which fall within the bounding box of the map. (Actually that’s not quite true: I give Google’s API a list of points and it sifts through them for the ones that fit the current map view, but in either case I need to know the coordinates of a bunch of points at once.)
However, if I have to call get_topic() for every topic in the database in order to get its coordinates, that’s going to result in a ridiculous number of database hits every time I render a map. Right?
I believe I need a table, whether it’s bb_topics or one I create, which will let me access the coordinates all the topics in one query. Or is there an efficient way to do that using topicmeta and I’m missing it?
You could just SELECT topic_id, meta_value FROM topicmeta WHERE meta_key = ‘topic_geolocation’, AND more stuff applied to meta_value if you want. It’s doable in one query.
Hmm also don’t forget the do action at the end of the function:
do_action('bb_function_name', $topic_id, 'topic_geolocation');
I also have a question about this:
// To add
bb_update_topicmeta($topic_id, 'topic_geolocation', $latlong);
What does/should $latlong do/be used for?
Greetz
What? do_action syntax is like this:
do_action( $tag, $function_name [, $priority] );
$latlong is the value, in this case latitude/longitude.
Thanks for the suggestions. It’s good to know that topicmeta can be queried directly in SQL rather than having to serially retrieve topics and address it through PHP data structures.
However, I still don’t know whether I’m clear on the concept. Is the point behind the topicmeta table to map individual topics to particular bits of metadata, on the basis of one (topic, metadata key, metadata value) tuple per row?
If so, how do you efficiently handle the case when you need multiple pieces of metadata per topic? A geolocation is actually two floating-point numbers (latitude and longitude). Ideally I’d like to be able to treat them as such in my queries without a lot of packing and unpacking to squeeze them into one field.
Finally, another SQL newb question: are there peformance or other reasons why I can’t use a join? Because I actually need to give the Google Maps API info from columns in the topics table, too. Setting aside the point about geolocations actually being two values, could I do something like this?
SELECT t.topic_id, topic_title, topic_poster_name, forum_id, meta_value
FROM bb_topics t, bb_topicmeta m
WHERE t.topic_id = m.topic_id
AND topic_status = 0
AND meta_key = ‘topic_geolocation’
AND meta_value [meets some other magic condition]
There are lots of built-in functions for querying the topic meta, they are all in the same place in the code, so searching in the code for the functions I mentioned above will reveal them all.
Joining tables to create one query is better than using two queries to retrieve the same data. The new BB_Query class could easily handle the query you wrote up there.
By the way, I suggest you build your plugin against the latest trunk rather than the latest release.
Thanks, Sam.
I’m not sure whether to even touch your last suggestion, about using the latest trunk rather than the latest release. I see the trunk code browser at https://trac.bbpress.org/browser/trunk but I don’t know where to find it as one downloadable archive. And surely the trunk has new bugs and unfinished features, which is why it hasn’t been turned into a new release, right?
Can you give us any hints about what has changed that plugin writers need to know about?
P.S. Where do I find BB_Query?
Downloadable ZIP of latest trunk is via a link at the bottom of that page.
The trunk is pretty stable actually, and is more bug free than the latest release usually.
You are better off setting up a subversion client and “checking out” a copy of the code. You can then keep up-to-date on changes in the core with the click of a button.
Search the forum for info on using SVN to checkout a copy.
A lot has changed, the best thing to do is to trawl through the changelog on the Trac site. Only a couple of things have changed dramatically, how views works is one.
BB_Query is in the latest trunk in bb-includes/classes.php
