taffeljohan

https://codex.www.ads-software.com/Pages

Sounds like a plan, if there aren’t too many. Otherwise it will be a pain to hard code everything. Otherwise you could use custom fields on the pages to store parameters (tag names, for instance).

By the way, it should have been
$myTaggedPosts->query_posts('tag=chocolate')
(i left out the _posts part)

Glad I could help.

Um, typo?

You assign a value to $Track1 and then you try to use $Track13 in your foreach statement.

As moshu pointed out earlier, check the documentation on query_posts and the loop. You should only be using query_posts to modify the posts used in the main loop, nowhere else. Anywhere else, you need to create a new WP_Query object. Fortunately, this is very easy.

$my_query = WP_Query();

Then you can use $my_query->query_posts() to do whatever it is that you’re trying to do with query_posts(). And get predictable results.

I don’t know of plugins for this, but it is pretty easy to put in a template, just by creating your own loop at the bottom. Something like this is all you need:

<?php
$myTaggedPosts = new WP_Query();
$myTaggedPosts->query('tag=chocolate');
?>
<ul>
<?php while ($myTaggedPosts->have_posts()): $myTaggedPosts->the_post();?>
<li><a href="<?php the_permalink();?>"><?php the_title();?></a></li>
<?php endwhile;?>
</ul>

@neil T

I’m sick in bed and amusing myself by answering forum questions today.

With regard to your question about using the same tables in a second blog. You could just change the table prefix in the init action, while preserving the options. Put something like this in a plugin:

function table_prefix_switch() {
    global $wpdb;
    $options = $wpdb->options; //Save the site 2 options table
    $wpdb->set_prefix('wp_'); //The prefix to site 1
    $wpdb->options = $options; //Put the options table back
}

add_action('init', 'table_prefix_switch');

I haven’t tested this, but have used $wpdb->set_prefix() often for various hacks and switching blogs this way works well.

Look at wp-includes/theme.php.

It looks as if you could use the stylesheet and template filters to set the theme, just by modifying the values sent through to point to the theme directory you want. Everything else builds on those two.

Or you could define TEMPLATEPATH and STYLESHEETPATH (see wp-settings.php) to what you want. This will mean that WP tries to define already defined constants in wp-settings.php, but that wouldn’t be a problem in practice. Doing it with filters is aesthetically more appealing.

Use in_the_loop(). Defined in query.php.

Neil T and peterassman: There is a typo in the code.

CUSTOM_CAPABILITES_PREFIX should be CUSTOM_CAPABILITIES_PREFIX.

This (WP support) forum uses bbPress, forum software from the WordPress folks. Separate software, not a plugin, but designed so it can easily be integrated with WP (shared user database, for instance). Check it out at https://bbpress.org.

See:

https://www.ads-software.com/support/topic/212600?replies=7

Update: defining AUTH_SALT and LOGGED_IN_SALT in `wp-config.php’ as suggested in my previous post works for me. You also have to have code that defines COOKIE_HASH in the same way for all blogs; the default is a hash of the siteurl.

I think the problem is in the salt used to authorize cookies. See wp_salt() in pluggable.php. The salt is stored as a wordpress option, which means it depends on your wordpress installation, and even if you have shared user tables, the salt used will be different.

Looking at the code, there seem to be three ways to circumvent this:

1. Define AUTH_SALT and LOGGED_IN_SALT in your wp-config.php for each installation using the same values for each (if you have a shared wp-config.php, this is simple).
2. Use the ‘salt’ filter to alter the output of wp_salt() so it is the same for each installation.
3. Write your own wp_salt(). It’s pluggable.

The first option is definitely easiest, although it means having more keys and stuff in the same place.

I’ll try this out when I get a chance.