Maybe I made that post a little too difficult for average scientists to understand.
So, let me go another route and lets talk code....
First of all, let me just say that wordpress multi-user Nightly build is very well done and anyone can tell that major corporations are using this, but it is obvious that they are coding it to their structure.
However, let me say, who in their right mind did not incorporate the auto plugin activation for new plugins?
I mean you guys go to all that trouble to invent a simple multi user blogging system and yet, you dont even incorporate an option for new blogs that are created in the multi user environment to come with the plugins already activated for new blogs? Do you guys understand that the site admin is unable to disactivate the WP Backend Plugin Menu for all users! Because, if we do, then the user that created the new blog in the wpmu will have to either activate the plugins themselves or rely on a site admin to do it for them.
How ridiculous is that! Talk about security risks out the flippin wazzoo!
Anyways, I'm not here to lecture, but I would like to give a suggestion, please incorporate the auto plugin activation for newly created mu blogs.
What this means is, that what wpmu needs is the ability to already have the plugins activated and ready to go after a new user has signed up for the new blog, without the user or site admin having to activate manually for them.
Why did you guys not think of this! What happens when you have 2000 users sign up for blogs on your wpmu and then you expect these users to activate the plugins themselves or you expect the site admin to have to go through each blog to activate them for their users. Are you kidding me?
I know the MU Plugin Management (plugman) does very well for global purposes. But lets imagine you had to globally activate 100 blogs for that day manually. Now you think this is a simple process... But, oh wait... how much resource would it take to globally activate and continue to reactive all blogs for plugins to take affect.
This wpmu was not well thought out in regards to this type of process. We're talking major server crashes, server hangs and more chances for users to unknowningly screw up there blogs. Especially if your aiming these mu blogs to a young audience. Not everyone is a bloody genius.
Regardless, even if you take out the plugman management code that just makes the situation worse, since your default plugins that you inputted for admin will never activate, unless you manually activate for each newly created wpmu blog. Thats just nuts.
Anyways, lets discuss code. Since, most of you have come here to read about that.
Most likely there is a way to activate this type of policy either by a hook or within one of the wpmu php files.
The files to mostly look at it, would be:
wp-admin/upgrade-schema.php
wpmu-blogs.php
and
wp-signup.php
The reason to look at the upgrade-schema is because that is the default sql database information that is set for all newly created blogs in the wpmu database. Any information that is in this file will be the main settings for the wpmu blog, since the admin blog is the default mu blog, it stands to reason to grab the information from the admin default mu settings in the sql database.
However, most web hosts are so dang cheap that its not possible for some server hosts to allow you access to edit the sql database itself. Leaving most server owners with only the possibility of editing certain files in the ftp.
Which is fine, the code could be implemented in the schema.php file to allow for plugins to be automatically activated off of every newly created wpmu blog.
So, without the ability to edit the sql database itself, I am left with editing the schema php file. Changing the settings to the schema file yields interesting results, however, after changing the schema file, if the proper commands are not inputted correctly in that file; that those newly created blogs will use the schema updated commands, which if the commands are wrong could lead to future corrupted blogs based upon the hacked schema php.
So, obviously there has to be an easier way, but so far, if the wordpress authors havent figured it out, then it looks like a dark road for the future of wordpress mu blogging.
Now moving on,
without access to sql information or hacking it per say, the only way to get that information is by using the backup utility for wordpress which is backup plugin. Which most people wont want to use it since, if you leave backup plugin on, it allows your non site admins and other blog owners to back up and steal/hack your entire blog information. Unbelievable.
The backup plugin gathers the sql formatted information and then downloads it to your computer in tz/sql.
The file can be edited by notepad. However, the actual parameter code for the plugins in the active list under SITEADMIN>BLOGS>ACTIVE PLUGINS list shows exactly the proper information on how to input this into the active plugins list on the schema php. While it gives the entire command:
(Keep in mind that for this post, I replaced the plugin names.)
INSERT INTO wp_1_options
VALUES (39, 0, 'active_plugins', 'Y', 1, 'a:21:{i:0;s:16:"plugin1.php";i:1;s:32:
"plugin2.php";i:2;s:11:
"plugin3.php";i:3;s:13:
"plugin4.php";i:4;s:22:
"plugin5.php";i:5;s:14:"plugin6.php";i:6;s:20:
"plugin7.php";i:7;s:13:"plugin8.php";i:8;s:13:
"plugin9.php";i:9;s:12:"plugin10.php";i:10;s:14:
"plugin11.php";i:11;s:19:"plugin12.php";i:12;s:20:
"plugin13.php";i:13;s:9:"plugin14.php";i:14;s:23:
"plugin15.php";i:15;s:11:"plugin16.php";i:16;s:16:
"plugin17.php";i:17;s:14:"plugin18.php";i:18;s:26:
"plugin19.php";i:19;s:12:"plugin20.php";i:20;s:15:
"plugin21.php";}', 20, 8, '', 1, 'yes') ;
So, as you can tell from above, the code most likely is in its final form and probably needs to be put back into the activation form for it to work.
Especially when you try to incorporate it by jiggy riggin
it to the upgrade-schema.php>
add_option('active_plugins');
the code obviously goes before the last )
and a comma should seperate the setting vs the action.
Such as:
add_option('active_plugins',
a:21:{i:0;s:16:"plugin1.php";i:1;s:32:
"plugin2.php";i:2;s:11:"plugin3.php";i:3;s:13:
"plugin4.php";i:4;s:22:"plugin5.php";i:5;s:14:
"plugin6.php";i:6;s:20:"plugin7.php";i:7;s:13:
"plugin8.php";i:8;s:13:"plugin9.php";i:9;s:12:
"plugin10.php";i:10;s:14:"plugin11.php";i:11;s:19:
"plugin12.php";i:12;s:20:"plugin13.php";i:13;s:9:
"plugin14.php";i:14;s:23:"plugin15.php";i:15;s:11:
"plugin16.php";i:16;s:16:"plugin17.php";i:17;s:14:
"plugin18.php";i:18;s:26:"plugin19.php";i:19;s:12:
"plugin20.php";i:20;s:15:"plugin21.php"');
Now obviously this wont work, but the question is why?
What is the argument parameter to make this code add itself
to the active_plugins list?
I realize that if I ever change any plugins that I would need to find this entire code again in the sql database user files. Thats fine, but for right now I am trying to
find a simple way to auto activate the plugins for users
without having to go through each and everyone manually.
This seems like the easiest way of doing it, without
creating a whole new php script code. Which if anyone has
one, I'll be happy to buM it off of you and give proper credit. But, typically I would like to make sure that the wp backend plugin menus are not viewable for any non site admin, especially not to regular blog admins, because I dont want them messing with it.
Obviously I want all plugins, except backup.php active, so I'm not worried about this route.
However, if someone has an easier way or a safer way that
will not cause major crashes/corruption to the server/wpmu then of course I'm all ears.
But, since NOBODY on this forum has mentioned anything like this, I have to assume this is new territory.
Does anyone know the proper command to input into the schema that will make the active_plugins list code auto activate upon newly created mu blogs?
If not thats fine, I will continue to attempt to hack it till I figure it out, but I would rather save myself a few weeks worth of work for something easier or from someone that actually knows what this code means.
There are other pieces of the code that could be useful in the script for auto activation.
Such as:
activate_plugin
$plugin
$current_plugins
get_settings
wp-content/plugins/
So, I will play with those pieces of the code as well to find a simple solution, although I prefer a pre-existing built php code that can already work as a plugin.
Any help in this matter is truly appreciated.
I prefer serious suggestions, code cures.
I could care less for people with only half a brain.
JustMSW