[@jeffsayre Participant 17 years, 2 months ago]

@Devweb

In your get_user_name_display() function, you also need to declare $bp as global, otherwise it will not be able to pull the data from $bp->displayed_user->id.

So, do this:

function  get_user_name_display() {

global $wpdb, $bp;

[@jeffsayre Participant 17 years, 2 months ago]

If you look at the roadmap, there is no mention of an photo album (or gallery) plugin. That does not mean it will not happen, it just means that it is not a priority up through v1.4. It also does not mean it will not happen before v1.4.

As with all open source projects, community contribution can significantly drive a project’s evolution. If Manoj, or someone else, comes up with what Andy (and the community) believes is an acceptable photo album component, it could get merged into BP core. Will that happen before v1.4? Will that happen at all?

Right now, Manoj’s plugin is a strong candidate. But, it does have a ways to go. In speaking with Manoj, he has said that he is waiting for v1.1 to come out before he upgrades and improves his plugin. That makes sense.

I have also discussed with Manoj the desirability to evolve his plugin into an overall media plugin–not just for photos. I personally believe that having a photo album plugin as a core component is of limited use in this day and age. Any core BP component, in my opinion, should offer as wide of a range of services as is practical. Here is what I said in another thread:

It would be nice to see an option to upload other media types as well. People not only have photos, but video, audio, text, pdf, and other document formats that could all be organized around the concept of media.

An album, then, would be a user’s place to add all the media types that they wished to share and organize. There could be sub-albums with an option to group by date, by media type, or by category or tag.

[@jeffsayre Participant 17 years, 2 months ago]

Up until an hour ago, this thread had not seen any activity for over 7 months. There have been many significant changes to the BP codebase since then. So, whatever issues the OP may have had will surely not apply to the current BP version.

Arghagain, please read this thread for your information.

I’m closing this thread as it is too old to be of use for additional discussion.

[@jeffsayre Participant 17 years, 2 months ago]

get_edit_html() is a method in the BP_XProfile_Field Class. You will not be able to stick it into bp-custom.php and expect it to work. That is not how methods function.

Also, this method will be deprecated in v1.1. I would recommend that you look at the v1.1 code in trunk. Otherwise, your custom coding may not function the way you expect when you upgrade.

[@jeffsayre Participant 17 years, 2 months ago]

Some additional info on using the themes: https://codex.buddypress.org/getting-started/installing-buddypress/

[@jeffsayre Participant 17 years, 2 months ago]

@morgenvrij

We need more detailed information about your setup. Please start a new thread by posting your issue and including answers to these questions.

[@jeffsayre Participant 17 years, 2 months ago]

That is a hard one to advise you on. But, read this thread — especially the two posts by Andy (the 4th and 16th posts). Perhaps that will give you sufficient information to make up your mind.

[@jeffsayre Participant 17 years, 2 months ago]

Terrific! I’m glad I could help you out.

[@jeffsayre Participant 17 years, 2 months ago]

I should point out that the two tables that the latest trunk drops are not in my database even though I am running 1.0.3. Should I manually recreate the tables and see what happens? If I activated the 1.0.3 plugin it should have recreated those tables don’t you think?

You know, reading your question just made me realize the solution. I should have thought about this before–especially since I referred to it in my first post. For the activity table(s), this constant is what I indicated above:

define ( 'BP_ACTIVITY_DB_VERSION', '1300' );

The “1300” is the key. When you installed the trunk, the constant in bp-activity.php was set to this:

define ( 'BP_ACTIVITY_DB_VERSION', '1716' );

When BP needs to update any of its tables, it does so by incrementing a DB constant. When you log into WPMU’s backend as Site Admin, a routine runs and compares the DB version number in the DB with the one in the BP component code.

Since 1716 is greater than 1300, the update procedure ran when you installed the current trunk version. When you reinstalled (downgraded to) v1.0.3, since the constant stored in the DB was greater than the one indicated in the older version of bp-activity.php, the “upgrade” function did not run.

So, what you need to do is go into the wp_sitemeta table in the DBs backend, and search for the meta_key entry “bp-activity-db-version”. Change the meta_value number for that record to something lower than 1300. Then, log into WPMU’s backend as Site Admin. The upgrade routine will fire this time since 1300 will be greater than the artificial number you just entered. Your old tables will be reinstalled and your widget start working again!

[@jeffsayre Participant 17 years, 2 months ago]

You can either use the default BuddyPress parent theme (which is actually called bp-sn-framework) and child theme, use the default parent theme with your own child theme, or use the parent theme to make your own, custom parent theme and then add your own custom child themes.

[@jeffsayre Participant 17 years, 2 months ago]

Were you running 1.0.3 on your live site before this mess up? Or, where you running 1.0.2 or earlier?

The reason I ask is that the widget API changed in WP 2.8 and I believe Andy did not change to using the new Widget Class code in bp-activity-widgets.php until 1.0.3. So, are you sure that it was working before if you were using 1.0.3?

[@jeffsayre Participant 17 years, 2 months ago]

@Ishimwe-

Posting in a thread that has not seen activity for more than 2 months will not get you anywhere. Please read this post.

[@jeffsayre Participant 17 years, 2 months ago]

I am not aware of any BP-specific plugins that enable such a feature. Perhaps you should make a request in the BuddyPress Features Group or offer to pay someone to build such a plugin on the BuddyPress Job Board.

[@jeffsayre Participant 17 years, 2 months ago]

Your welcome.

[@jeffsayre Participant 17 years, 2 months ago]

@andrlind

Seeing how you have not received a response from mattyabsley, I suggest starting a new thread and answering these questions.

[@jeffsayre Participant 17 years, 2 months ago]

@Tiptap

You’re welcome!

[@jeffsayre Participant 17 years, 2 months ago]

Roy, what I think happened is that your activity tables were rewritten when you installed the most recent BP trunk. If you’ve been using the tagged version of 1.0.3 ( the one that is available via the big, orange download button) and not the trunk version of 1.0.3, then this is what happened.

In the newest version of BP, two of the original three activity tables are eliminated. Going forward, only one table is required. When you upgraded your live site to trunk, it eliminated two of the tables. When you reinstalled the earlier version (the tagged version 1.0.3) it reinstalled the two tables that were eliminated. But, they would have no data to display–at least at first.

Look at bp-activity.php in your 1.0.3 reinsall. Does the first line say thing?

define ( 'BP_ACTIVITY_DB_VERSION', '1300' );

Now, look at the bp-activity.php file from the most recent trunk (r1643 at the time of this post). Do you see the change in the schema-especially these lines of code?

/* Drop the old sitewide and user activity tables */

$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_user_activity" );

$wpdb->query( "DROP TABLE IF EXISTS {$wpdb->base_prefix}bp_activity_sitewide" );

With the older version now reinstalled, and data being written back to the old tables, are you starting to see activity being reported in the widget?

[@jeffsayre Participant 17 years, 2 months ago]

I have not heard about this issue before. I would suggest, if you have not tried already, that you disable all your plugins. If the problem goes away, then start enabling the plugins one at a time until the issue reappears.

Also, have you checked your server’s log files to see if something is repeatedly showing up?

Finally, I know that the multi-lingual plugin has a debug mode. That might help shed some light.

[@jeffsayre Participant 17 years, 2 months ago]

@Peterverkooijen-

As far as I know, there will not be any underlying changes to WPMU’s database schema (design). Therefore, it will be the same old issues you’re trying to address. But, being able to design a custom registration page will help to address some of the current systems short comings.

This all comes back to what we have discussed in the past. WPMU–in its current incarnation–is blog-centric, not user-centric. Until that gets addressed, the only option is to custom code work arounds.

[@jeffsayre Participant 17 years, 2 months ago]

Tiptap-

Make sure that you declare bp as global in your index.php file:

global $bp;

[@jeffsayre Participant 17 years, 2 months ago]

Okay, several issues to discuss here:

1. I created a new function in wpmu-functions.php

   Why modify a core WPMU file to be used in a BuddyPress theme file? Instead, create this function in your bp-custom.php file. That why, when you upgrade BP, your changes will not be lost–assuming that you do not delete your bp-custom.php file.

2. The user ID field does not contain string content. So:

   u.ID = %s

   should be

   u.ID = %d

3. What you are after is grabbing a member’s ID and then using that to pull their login name (username). I don’t think that the variable $username is available for the function call–at least not the way you are trying to reference it. I would use this instead:

   $bp->displayed_user->id

   You will need to declare bp as global in your members-loop.php file.

[@jeffsayre Participant 17 years, 2 months ago]

@mat_

So now, can i start using that new architcture ? how ? do i have to download the last build from the trac ?

You have two options: install the latest trunk from SVN, or wait for version 1.1 to be released in the next few weeks.

@Andre

Will it still be an option to use any WP blog theme (with BP widgets) for “home” in conjunction with the BP (child) member theme?…And how would that even work, if the “home” theme (i.e. a good old fashioned blog theme) potentially has its very own parent theme? Can a child theme have two parents?

Any well-designed WP theme can be used as a parent theme. Unlike with us humans, child themes can only have one parent theme. Of course, a given parent theme can have many child themes.

Here’s a useful article on making child themes that goes into great detail. Especially look at the resources he provides at the bottom.

Perhaps jjj can chime in here as he is the consummate theme designer–much more so than I.

[@jeffsayre Participant 17 years, 2 months ago]

If you inspect the html (view source in your browser), you can see the code that is used.

[@jeffsayre Participant 17 years, 2 months ago]

Incidentally, where do you get the information on 1.1 from? I’ve had a quick look, but couldn’t find anything.

If you keep up with the code changes in trunk, you can see how BP is evolving. Also, you can pick up bits an pieces in IRC.

[@jeffsayre Participant 17 years, 2 months ago]

I wouldn’t put any more time into this issue as custom registration/signup templates will be possible in v1.1.