Although the DWQA Questions and Answers plugin for WordPress has been updated to work with Multisite, it probably won’t work as expected. At the time of this writing, the problem appears to be new user creation and the multisite default functionality. In order to accept the DWQA default method of answering questions, which is that only registered users can post answers to questions asked by anonymous users, you have to allow them to register. First, on my Multisite subsite I had no option to allow user registration. Even after enabling it at my main blog as network administrator it was not available under the subsite options.
Other users have reported that once you are able to allow registration on a subsite, that clicking the link will redirect the user to the network main site and allow them to register there, which is probably not the desired action for a DW Questions and Answers site. It also allows that user to be login to all other sites on the network.
What would be desired here is either a separate login that is not tied to the wordpress registered users login, or the use of social apis so users could use an existing social account to login for posting and answering questions.
Going crazy following posts on the Internet trying to set permissions on your WordPress directory to get automatic plugin downloads and updates working? So was I. Several times on several sites. Trying to keep security in mind I didn’t want to give too much. After applying the DIRECT method to the wp-config.php file I had to do this to get plugins to download, create the directory and install. Keep in mind all permissions were the default except for this:
chmod 775 wp-content/
chgrp nobody wp-content/
chgrp nobody -R wp-content/plugins/
‘Nobody’ should be the user that the apache process runs under. You do not need to set permissions to 777.
If you get stuck being unable to login to WordPress because of a misbehaving plugin, you have a couple options.
You can login to your WordPress database using command line MySQL client or phpMyAdmin, and from there look for the wp_options table. If you are using a security plugin that changes table prefixes you’ll have to replace wp_ with your prefix. Once there, look for a value in the option_name column called active_plugins. You can find it like this:
SELECT * FROM wp_options WHERE option_name like '%plugin%';
This will give you a list of plugin options which you can examine. If you are using WPMU or WP3 Multisite and this is a globally enabled plugin, you’ll need to then use table name with the ID of the site in the prefix, like wp_2_options instead of wp_options. It used to be that option_name “active_plugins” would contain all plugins, but it appears from examining this that option_name “transient_plugin_slugs” contains plugins. If you choose to modify it, copy and paste the original value somewhere for easy editing and replacement once fixed.
The option I chose for this Multisite plugin that prevented login was to simply rename the folder of it in the plugins directory. That would cause WordPress not to load the bad files, because they were no longer in the expected location.
Once into the admin dashboard page, you can then disable the plugin completely and take whatever actions you need to repair, replace or trash it for good.