Forum Replies Created
-
Okay, I’ll go backwards part way up the list of answers:
Please provide a list of any errors in your server’s log files. how do i check?…hosting is through GoDaddy.
GoDaddy provides different levels of access to server error logs depending on your hosting plan. Contact customer support and ask them.
Your next step is to try an isolate the problem. First, you switch back to the default theme and see if the problem goes away. If it does, then you most likely have an issue with your default theme. Contact the theme designer and ask for assistance.
However, I’m guessing it is not a theme issue but either an issue with one (or more) of the many plugins you have installed and activated or an issue with your mail server. Your server’s log files should help you in determining if there is a server issue with sending mail.
But, until you can get at your server’s log files, you can investigate possible plugin conflicts–and you might actually find the problem in doing so.
What you need to do is go through the standard procedure for finding plugin conflicts. Deactivate all plugins except BuddyPress. Since it is the BP registration mail messages that are in question, you must keep BP activated.
Now, the first step is to try the registration process with just BP activated. If the registration goes through without an issue, then you can start to suspect that the issue is caused by one of the other plugins (or some combination of them acting together).
So next you begin reactivating your other plugins, one at a time. Each time you activate a plugin, you test to see if the issue occurs. This means that you only have one additional plugin activated besides BP. If the problem does occur then the issue could actually be with the plugin you just activated. You make a note of that possibility, deactivate it and move on to the next plugin and test it the same way. Each time, you note what happens. You may find other plugins also cause the issue to return.
Finally, you activate all the plugins that appear to not cause a conflict and see if the issue returns. If it does not, you now know that you can at least use that subset of plugins together without causing this particular issue.
What can you do when you find a plugin conflict?
- Make sure that you are using the most recent version of that plugin and that it is compatible with the version of WPMU you’re running
- Contact the plugin developer and ask for their assistance
- Simply deactivate that plugin and not use it. You may be able to find a substitute plugin
- Report your plugin conflicts back here so that the community can benefit as well.
In reply to: Buddypress and IntenseDebateAs IntenseDebate exports your WP comments into its own system, your issue is more than likely caused by IntenseDebate misbehaving. Your best bet is to post a question on their support forums and let them help you track down the cause. I found these two related threads:
http://getsatisfaction.com/intensedebate/topics/intense_debate_comments_gone_missing
In reply to: Buddypress and IntenseDebateHow can i enable intensedebate plugin for all the blogs sitewide.
Looking at the WP plugin repository for this plugin, it does not indicate that it is meant for WPMU.
Doing a quick Google I found this discussion on the IntenseDebate blog:
Go 7 or 8 comments down and you’ll see this reply from Beau Lebens:
BuddyPress runs on a WPMU install, and ID is currently in use on a number of WPMU sites. There’s currently no way to “auto-activate” it for every blog created, but you can definitely activate it (and go through the install process) for each different blog you create on a WPMU install.
In reply to: Download all trunk files?First, always read the “readme.txt” file before proceeding with any WPMU or BuddyPress upgrade.
Before installing BuddyPress from trunk, you need to make sure that you are running WPMU 2.8.4a. If not, you need to deactivate all WPMU plugins, upgrade WPMU, and then try again. The latest WPMU version can be found here.
Once you’ve installed BuddyPress, make sure you move the theme files into their proper location.
In reply to: welcome widget bugAre you using the default theme that comes with BuddyPress or a custom theme (3rd-party theme)?
In reply to: welcome widget bugClosing this post as it is a duplicate.
In reply to: Automatic Group JoiningSince groups are currently “owned” by a single user–that means that every group is started by one user who is the admin–it is not possible to create groups without any members.
Although a plugin could be written that automatically creates a group using the Site Admin’s ID for the creator_id in the groups table. Thus, the Site Admin would be the initial group admin and its only member–until other members were automatically added to it based on the datum in a given profile field.
In reply to: Talk to Andy Peatling tonight on TalkShoeWill there be popcorn?
Okay, we have a couple pieces of information, but need more. Please answer the questions here.
In reply to: How to make a safe community?We all know bp 1.1 is coming out sometime this month, what is the best estimate for bp 1.2?
We do not have any estimated dates for official BuddyPress verison releases. But, just guessing, I would say that BP v1.2 will come out sometime between mid October and Late December of this year.
In reply to: How to make a safe community?Yes. I will post a link here to the plugin’s announcement link.
But, just to be clear, the Privacy Component is not scheduled to be officially released until an estimated date of October 19, 2009. That means version 1.0 is not expected to be released until that time or later. Again, that date could be changed depending on a number of factors.
Also, up until the official release (version 1.0), it is considered to be in testing mode only. That means Site Admins are strongly discouraged from using the component in production environments. I do realize that some Admins choose to disregard such warnings and that is their prerogative.
Of course, just as with all free, open-source products, once this component is officially released, it does not mean that it comes with any guarantees other than it has been sufficiently tested and appears to be ready for prime time!
In reply to: comment activity recordThe function bp_activity_record will be deprecated in BP v1.1. In its place, a new function has been created: bp_activity_add().
Before you spend time coding a plugin that will not work with v1.1, I suggest visiting Trac and seeing how the new function works. In fact, there has been quite an extensive re-write of the activity stream codebase, so there could be a number of changes that you need to bone up on.
In reply to: How to make a safe community?That has been mentioned before in the past couple of months and a number of members are using it.
However, it has limited privacy controls and when BP v1.1 comes out, it will no longer work as it relies on a function that will be deprecated.
Also, it requires modifying a core file, which is never a good idea. But, there is no issue with using it until the Privacy Component comes out.
In reply to: How to disable a member?What you need to do depends on what name is in question. Is it the member’s first, last, or nick name? Is it their full name which is displayed in the profile pane of BuddyPress? The data for those names are stored in two different places.
Also I editted his name from admin dashboard, but the name does not change? Is this a bug?
Since usernames (login names) cannot be changed, you must have tried changing either the first, last, or nick name. Did the questionable name even appear in any of those fields? Did you also select the newly-changed name in the “Display name publicly as” drop down list?
But, based on what you are saying here, I assume that the questionable name is the member’s BuddyPress full name. This can only be changed in the profile pane by the user. Currently the only recourse a Site Admin has is to go into MySQL’s backend and find the questionable field in the wp_bp_xprofile_data table.
Make sure that whatever changes you made to the user’s name in WPMU’s backend, you make in this table as well.
Just to give you a little more background into what is happening:
- When a user updates (changes) their name in the Full Name field in the BuddyPress profile pane, the changes do propagate throughout the MySQL DB. The datum in the following tables are properly updated: wp_bp_xprofile_data, wp_users, and wp_usermeta
- But, if you make changes to a user’s nickname field in WPMU’s backend, the changes are written to wp_usermeta only for that field. The changes are not written to the wp_bp_xprofile_data or wp_users table. You can have the changes written to the wp_users table if you select the proper value from the “Display name publicly as” drop down list. But, they are never written to the corresponding BuddyPress table.
- Finally, and this is even more confusing, changes to the nickname field are not written to the first name or last name meta values in the wp_usermeta table. Conversly, if you change the first name and/or last name fields, they are not combined and also written to the nickname field in wp_usermeta
So, there could be improvements in the way WPMU handles user name changes. But, it is a WPMU issue since changes at the Site Admin level in the backend are controlled by WPMU and not BuddyPress.
In reply to: How to make a safe community?The privacy component is focused on providing users the ability to control who has access to their data. It does not offer tracking, which is more like a spying program–for lack of a better phrase.
Yes, the component will be released as a beta-version plugin that anyone can test. I have set a tentative beta-release data of September 21, 2009. It depends on a few factors, but it is a reasonable estimate.
In reply to: How to make a safe community?r-a-y
There are a number of new hooks and an array object that need to be available for the privacy component to function. Although the alpha versions may work with v1.1, the full-blown version is really targeted for v1.2 and will require that as a minimum.
Concerning your wire post, for some reason, I believe that I never received that email. Strange, since I do have all my email notifications set to “Yes”.
But, to answer that specific question, your direct calls to xprofile fields should still function properly. Since you are pulling your data directly from the table and not from a templatetag function, you should be fine. Now, if you want your direct calls to be subjected to privacy control, then that is a different matter. You would then need to pull your data after the fields array has been filtered.
There is a separate table that gets installed that handles all privacy object settings. The privacy component filters the fields array that populates the profile page, removing any field-level elements that a given user chooses to hide from a given viewer category.
In reply to: How to make a safe community?No, the privacy component will not be included in v1.1. It is on the roadmap to be a core feature of v1.2.
But, first, we need to do some private alpha testing. Then some non-private beta testing–meaning available to all. Once all the kinks are worked out of it, Andy will evaluate it and decide if it meets the criteria to be merged into the BuddyPress codebase as a core component.
Will there also be a feature like “hiding my activities” ?
The privacy component will offer a user a full suite of privacy control options for:
- profile privacy filtering at the field level
- privacy filtering activity stream by action
- privacy filtering friends list and hiding the “Add Friend” button
- privacy filtering the groups list
- deciding who can instant message you
- privacy filtering for blogs
- privacy filtering wire posts and deciding who can post on your wire
There are also features for Site Admins that allow them to determine which privacy components are enabled (by default, all are enabled).
In reply to: Plugin to show components to registered Users onlyThat’s the problem with following a thread that was started more than 2 months ago! There have been many, many changes to BuddyPress’ codebase since that time.
One of those changes is that BP now runs in /plugins/ and not /mu-plugins/. Move your bp-custom.php file into /plugins/ and see what happens.
In reply to: How to make a safe community?I’m currently finishing the BuddyPress Privacy Component. A private alpha test will be out within a week. It gives users the ability to set fine-grained privacy control (viewing rights) over all their data.
In reply to: BP-custom in the wrong placeThe codebase is the final authority. Look at line 9 of bp-core.php. It tells you exactly what to do.
/* Place your custom code (actions/filters) in a file called /plugins/bp-custom.php and it
will be loaded before anything else. */
if ( file_exists( WP_PLUGIN_DIR . '/bp-custom.php' ) )
require( WP_PLUGIN_DIR . '/bp-custom.php' );In reply to: Help wanted: 2 hours paid serviceI’m moving this to the “Miscellaneous” Forum and locking the thread as anyone who is interested can contact arezki at the above email address.
For future requests, anyone in need of help or who wishes to offer their services should use the BuddyPress Job Board.
In reply to: BP-custom in the wrong placeYou place your bp-custom.php in /plugin/, not /plugin/buddypress/.
In reply to: opensocialSometime in 2010.
In reply to: Help with Restoring my website databaseRead through this WPMU Codex article on changing your site URL. It should provide the assistance you need.
In reply to: Upgrade to 1.03 – forced to install WPmu 2.8.4a?From which version of WPMU were you upgrading? If from 2.8.2 or older, did you see my post above?
Had to dive back into the bp-core to remodify all the changes…I mention this because there is a certain level of knowledge in coding that is necessary before many of us can follow the instructions of Burt and other brillianto’s. Unfortunately, we don’t have that knowledge so the quick and dirty for us users who are trying to make buddypress operational is to simply cut and paste code in the core, write down in a researcher’s notepad akin to a research scientist titrating drops of transylvanian serum into Frankenstein’s bloodstream.
AHHHH! Stop!
Of course you’ve had all the issues you mentioned above!. You are traipsing around in the codebase, modifying core files like there’s no tomorrow. Even if you are a “brillianto” programmer, you do not touch core files unless you are helping patch bugs or providing new functionality to the overall project.
Why? Because whenever you upgrade, ever single core hack you’ve made will be erased. What are your options? Either install other’s plugins that provide the functionality you’re after, write your own plugins, or place your code changes in the bp-custom.php file. But, never, never, never change the core code. If you do, you will have the issue you’ve mentioned above.
