BuddyPress.org

Or at least supply us with a little more of a detailed explanation of what’s happening ‘Help’?

Then change those permissions!

alpha – https://wordpress.org/extend/plugins/bp-group-categoriestypes/

alpha – https://wordpress.org/extend/plugins/bp-group-categoriestypes/

@Pisanojm https://wordpress.org/extend/plugins/buddypress-badge/

@warut Thank you. Badge is working well in test install WP 3.0.1 – BP 1.2.5.2, subdomain structure, and upgraded from WPMU 2.9.2. Cool

@christinarule –

other than the check for mod_rewrite.c, you have the same .htaccess that I have in a default install, with permalinks set to /%category%/%postname%/ (http://playground.21inspired.com is a simple default install).

My .htaccess:
# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Unfortunately, this is beyond my area of expertise. Hopefully, someone else can help you get rid of index.php in your urls, and get the blog & BuddyPress urls resolved correctly.

Other quick thoughts: is your .htaccess in your site’s root directory? Do you have other .htaccess files in the subdirectories? Does your server support mod_rewrite?

Anyone able to help?

Sure, that is one place. But I still get different times in Sitewide Activity, a jQuery FullCalendar script that works fine in WordPress site without BP, etc.

I am on customized BP 1.1.3 + WP 3.0, but judging from hnla’s comment the issue has not been fully fixed in the latest versions. Anyway I’m trying to figure out where to fix it, where in the code, where in the database.

.htacess

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

wp-config:

<?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, WordPress Language, and ABSPATH. You can find more information by
* visiting {@link https://codex.wordpress.org/Editing_wp-config.php Editing
* wp-config.php} Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don’t have to use the web site, you can just copy this file
* to “wp-config.php” and fill in the values.
*
* @package WordPress
*/

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘***’);

/** MySQL database username */
define(‘DB_USER’, ‘***’);

/** MySQL database password */
define(‘DB_PASSWORD’, ”);

/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);

/** Database Charset to use in creating database tables. */
define(‘DB_CHARSET’, ‘utf8’);

/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’, ”);

/**#@+
* Authentication Unique Keys.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define(‘AUTH_KEY’, ‘put your unique phrase here’);
define(‘SECURE_AUTH_KEY’, ‘put your unique phrase here’);
define(‘LOGGED_IN_KEY’, ‘put your unique phrase here’);
define(‘NONCE_KEY’, ‘put your unique phrase here’);
/**#@-*/

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a unique
* prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = ‘wp_’;

/**
* WordPress Localized Language, defaults to English.
*
* Change this to localize WordPress. A corresponding MO file for the chosen
* language must be installed to wp-content/languages. For example, install
* de.mo to wp-content/languages and set WPLANG to ‘de’ to enable German
* language support.
*/
define (‘WPLANG’, ”);

/* That’s all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . ‘wp-settings.php’);

If you use custom profile filters plugin (https://wordpress.org/extend/plugins/custom-profile-filters-for-buddypress/) and add a field labeled “Twitter”, user can enter their Twitter handle and the plug-in will automatically convert it to their Twitter URL. No need to enter URL.

Just thought I’d mention that I had this issue and solved it by checking that the blogs.dir folder AND ALL SUBFOLDERS, RECURSIVELY, were set to ownership by ‘apache’ and had 775 permissions.

This took some time to trouble shoot, as it turned out my host was only setting the blogs.dir folder to ownership by ‘apache’ and not its sub-folders. I had to specifically ask a second tech support guy to check the sub-folders for me before I figured this out.

‘apache’ needs to be the owner on apache machines, the rest should have the main ftp user as the owner (you may have to enable group permissions so you can still edit them)

I Hope this article I wrote helps: http://erikshosting.com/wordpress-tips-code/buddypress-avatar-upload-failed-fix/

I would post about this on the WordPress.org multsite forum:
https://wordpress.org/support/forum/multisite

Since this is most likely a problem with your network settings after switching hosts.

I’m also seeing the same issue using WordPress 3.0 and Buddypress 1.2.5. Zero BP plugins installed.

Email gets sent, user clicks on it but still gets the activation code screen. Enter the code results in an error message about the code being incorrect.

It’s not a very good first impression.

Per WordPress licensing, plugins and themes really should be free and people should charge for support and customization. If someone is selling ‘support’ under the guise to sell themes or plugins and not giving support it’s their own fault if somebody releases the paid plugins to everyone.

The best way to go about it, in my opinion, is to release themes or plugins as a free version and then have some with paid support and more options.