Note, this article revisits an article I previously wrote, “WordPress Multisite and the Disregard for Plugins”. For one thing, that title was a little too broad, hence, this article’s title, “WordPress Multisite Activation and its Illogical Disregard for Plugins” which corrects that mistake. Secondly, I previously discussed Marco Cimmino’s Cimy User Extra Fields as a cornerstone in my solution. Since then, I have further analyzed WordPress core and come to a different yet equally valid solution. I will discuss the merits of each in turn later, but first, what do I mean, Illogical Disregard for Plugins?
Two years ago I began my quest to “port” Register Plus Redux to WordPress for Networks/Wordpress Multisite. I thought this would be pretty simple, in fact I was hoping to make most of my existing code work in both scenario, perhaps with some type of overloaded hook function to funnel variables to one common function. I quickly learned that WordPress MS (my preferred name), with its signup/activation system significantly deviates from single WordPress’ registration process. In fact considering the hacky, silly way I implement my own “activation” system, via user email verification and administrator verification I found WordPress MS’s system to be a significant improvement over my own which alters the user_login to isolate “unactivated” users (one I’m looking to steal via my own ‘signups’ table in a future revision). Regardless, systematically, WordPress MS signup couldn’t be any more different from WordPress registration, down to the user experience which brought its own problems.
My real problem began, and ended with activation, that which follows the signup. Following a valid signup, Redux was able to store added fields, first name, last name, additional fields, invitation code, etc in WordPress’ signup table in a meta field. However, I could not, following any amount of effort restore that stored meta data. First I thought I was ‘misreading’ the meta data from the database, which seemed odd considering the simple nature in which it was stored. Then I though that these were unrealized hooks which brought me down a terrible path of analyzing what and how hooks are defined and activated in WordPress core. I learned that hooks aren’t so much defined, you can hook to any string, so long as a do_action or apply_filter uses that same string, that hook will activate. So that debunked that fear. Eventually I just had to find another “working” plugin, which brought me to Marco Cimmino’s Cimy User Extra Fields. There might be a few others out there, but the market for WordPress MS Signup alternation seems pretty slim so Cimy appeared to have a real choke hold on this corner of the plugin field.
Cimy’s solution involved “must-use” code, that is another php file that must be manually placed in WordPress’ mu-plugings folder. Must use plugins load regardless of all else, they cannot be activated, deactivated, installed or uninstalled within your WordPress control panel. They exist, therefore they run. Cimy’s separate mu-plugin in turn called to the regular plugin, this making the entire plugin a mu-plugin. This worked, and I thought it might be the only solution, until I prepared to open a ticket on WordPress Trac to complain about this behavior. In the process of isolating the behavior I came to notice that there was a flag, WP_INSTALLING, checked when loading plugins from wp_get_active_and_valid_plugins. I didn’t think much of this, it seemed fair to assume plugins aren’t loading during WordPress’ installation process. Then I had my epiphany. wp-activate.php throws up this WP_INSTALLING flag. That brought me full circle and I thought I finally understood the full extent of my problem. Not that I understood why, but at least I understood how. Digging deeper, and stepping through WordPress initialization I realized WP_INSTALLING isn’t checked against network activated plugins. Now I had an alternate solution. Still no explanation, but again, two solutions for this quirky behavior is better than none!
The nice thing about network activation over must-use is that network activation can be handled completely within WordPress’ control panel. You install the plugin as always via the Plugins menu, then click Network Activate. Simple enough. Must use can be installed via the Plugins menu, but as I mentioned earlier means administrators must open up a FTP session or such and move files from the plugins install directory into the mu-plugins directory. Both solutions ultimately lead to the same conclusion, the plugin will be available to every site in the network and, most importantly, actually work. Both solutions also have the same flaw, the plugin is available to every site! Each site’s administrator need not activate the plugin, they don’t get any choice. In the case of Redux, I put a lot of effort to ensure that by default, Redux modifies nothing. You most activate features from Redux’s settings in order for it to alter any of WordPress’ default behavior. Other plugins may not be so respectful. All of which is beside the point, I chose to encourage administrators to network activate Register Plus Redux. I find that to be a simpler solution. Must use isn’t impossible, or even difficult to “activate” yet I find it troublesome that you cannot easily disable Redux, you would have to go into the mu-plugins folder and delete Redux’s must use php file, or at least move that file out of the mu-plugins directory. That isn’t very, “easy” in my opinion. Like I said neither approach appears to be wrong, but I have my own preferences.
Long story short, Register Plus Redux now works on WordPress Multisite. The whole exercise has forced me to move further along with my code decoupling. It’s been a todo of mine to break my monolithic php file into pieces, so that only utilized code is loaded. Redux 3.9 has turned into quite a monster. I expected to roll out some of these “big” features over 3.9, 3.10, and ultimately 4.0. But I guess I’m making up for the lost two years of development all at once!
Finally, and most importantly, I completed my initial 3.9 code base. I created a new tag on WordPress SVN and have sent a request to plugins@wordpress.org to have Redux back online in the plugin repository. I hope to hear back soon so that you can enjoy Redux without needing to leave your control panel. In the meantime, here’s a zip file for anyone interested. Break it as best you can so that I can make a better plugin. I’m back in business and hope to have 4.0 finished sometime before 2014! In store, a revised user verification system (à la WordPress MS), full functionality for WordPress MS (currently some features aren’t ported over, customized emails and autologin to name a few), and, perhaps pie-in-the-sky, but a shortcode droppable registration/signup form so that you can register users anywhere. I wouldn’t mind playing with user creation from the back-end, as is, if you have added fields during registration, you’d have to create a user then edit that user to enter the same information. That isn’t ideal, but just quickly reviewing WordPress admin code, I don’t see anyway to alter the new user form. I may have to make a separate Expanded Add User page or something along those lines. Not my dream project but something I kick around in my head for completions sake. Rant over, enjoy Redux 3.9, I hope the whole world does soon enough!