A completely separate database, or do you mean a separate table (or group of tables) which would be easier.
oops,…. sorry … i meant tables 🙂
also some light on
$network_id vs $site_id vs $blog_id
🙂
site_id is the ID of the entire network. Not an individual site.
Blog_is is one of the included sites on the network.
basically, you’ll be making a global table, and not putting it in the blog-specific tables. also, you’ll want to either force network activation or have it run from the mu-plugins folder.
no comprehendo 🙁
by “site” do u mean restricted to one domain, like
http://www.domain.com/blog1/
http://www.domain.com/blog2/
http://www.domain.com/blog3/
…
…
or is it just a classification? then what is network_id,
also … so in my “table”, i would just have to add a column “blog_id”?
M.
i am forcing network activation, while it is still in the plugin folder.
also … so in my “table”, i would just have to add a column “blog_id”?
Yes, that would correlate to each of these:
http://www.domain.com/blog1/
http://www.domain.com/blog2/
http://www.domain.com/blog3/
ok,
and again do we have any write ups somewhere for network_id and site_id, am still not clear on those…. if you could help.
M.
You won’t need network id, it’s just a variable. site_id is the ID of the entire network. unless you want to support multiple networks, you won’t need that either.
current_site maybe.
(No, there’s no decent write ups)
If you’re letting each user create a list of links – why not use the internal Link Manager (blogroll)?
🙂 /links/ … i did look into it, but i need a tad more elbow space here….
Thanx for your help 🙂
M.
If your plugin is not a “must-use” plugin and is installed to the plugins directory rather than mu-plugins, you’ll need to keep a couple things in mind when creating your global tables.
- If you create the tables through a register_activation_hook callback, use $wpdb->base_prefix and not $wpdb->prefix to prefix your tables.
- If you register a deactivation hook to remove your tables, know that it will remove the tables when the plugin is deactivated for any blog, so you will need to add some kind of check to make sure the plugin is not activated elsewhere. I increment a site option whenever the plugin is activated in a blog and decrement it when it is deactivated in a blog. If the option is 0 or less, I remove the tables. I’m not sure this is the most efficient method but it does work.
Hope this helps!
you’ll want to either force network activation
so how do i do that again?? :feelinDumb:
completing the whole plugin i find my plugin still active for only the main site!
what i have:
deactivate_plugins($plugin);
....
stuff : wp 3.0 =>wpmu
....
activate_plugin($plugin, 'plugins.php?error=true&plugin=' . $plugin, true);
but since MULTISITE is already defined ‘false’ is wp-settings.php, it falls back to activating it for the site 🙁
do we have a way out for this?
@ryan Willis – im just using hard coded prefix (‘wpp_mpp_’), keeps away and still smells wordpress
2. still have to test it but am using ‘deactivate_plugin’ action hook, and is_super_admin() and is_main_site() to skip things.
the above is not a work-for-all solution, but the way my plugin works, this is what i found to be good (NOT tested though)
