deko

If you’re connecting directly and not using WP functions to do it, then no, it shouldn’t modify $wpdb and thus won’t break anything.

Or so I thought. I am, in fact, connecting directly:

mysql_select_db('wp11');
$sql = "select cat_id, cat_name ..."
$result = mysql_query($sql);
...my code here...

This script is called in header.php in blog12 (which uses database wp12):

<?php include $myscript.php ?>

The inclusion of this script breaks ALL template tags (not just get_posts) that appear after the inclusion of the script.

(The Loop does not appear to be encumbered.)

As a work-around, I insert this code immediatley after the inclusion of the script:

$db = mysql_connect('localhost','username','password');
if ($db) { mysql_select_db('wp12'); mysql_close; }

This is a hack, to be sure, and I’m still trying to figure out what’s going on and the best way to resolve it. Suggestions welcome.

If you’re wondering why I’m calling a script run against one blog’s database while in a page of another, the purpose is this: blog11 is like a “front page” that contains several categores. Some of these “categories” are not wp categories per se, but rather separate blogs in and of themselves (it’s all transparent to the user).

For example, when a user clicks on a link to “Category X” (in the “front page” blog11), he may be taken to the posts in blog11 that are in that category, or he may be taken to a separate blog, such as blog12 in the above example.

This configuration has two key advantages: it makes it easy to segregate stuff so I can break off a database into it’s own site if I want, and it reduces database size.

Perhaps that is precisely the problem: the $wpdb variable needs to be reset after a user script is run against a different database.

Template tags used in pages that belong to a particular blog do not reselect that blog’s database on each use.

Therefore, since I’m running scripts in one blog’s page that select data from another blog’s database, the $wpdb variable needs to be reset after running these scripts.

Then all my template tags will work perfectly and we’ll have world peace and no more baby seals will die.

I prefixed the username_wp12 database tables with wp12 by making this change in wp-config:

$table_prefix = 'wp12_'

Now I’m getting these kind of errors from the loop:

WordPress database error: [Table ‘username_wp11.wp12_posts’ doesn’t exist]
SELECT COUNT(DISTINCT ID) FROM wth_posts WHERE 1=1 AND post_date_gmt <= ‘2006-06-14 13:57:59’ AND (post_status = “publish” OR post_author = 1 AND post_status != ‘draft’ AND post_status != ‘static’) AND post_status != “attachment”

So it still wants to go after the wrong database.

Interestingly, get_posts() appears to be working.

I think the issue may have something to do with another script I use in the page. I open a connection to wp11 and select some things (that I could not do with a template tag). The script connecta to the database, selects the wp11 databse, and runs a query. Then, later in that page, I try to use get_posts(), expecting it to use the database for the current blog which is stored in wp12. My guess is that whatever is behind get_posts does NOT select the database f1rst, and therefore since I last selected wp11, it by default uses wp11.

That might explain the errors. The question remains, however: If I am making my own calls to one database, and expecting wp to use another database – in the same page, how do I ensure that the db1 databse is selected, the conx gets closed and the other db is selcted? Shoud I modify the $get_posts function?

Actually, no. Since there are two separate databases, I don’t see how that could matter. But I will go ahead and give it a shot. I’ve tried everything else…

10-4. Thanks!

<?php get_posts('arguments'); ?> has an offset argument, and query_posts looks interesting.

But I’m unsure if I can get the behavior I’m looking for without some kind of page state mechanism.

I can envision a way to select some number of posts, but I will need to know whether posts 5 thru 10 or posts 11 thru 16 are currently displayed in the page… this info must be maintained in some page/session variable, no?