Forum Replies Created
-
We ended up implementing our own versions of bp_activity_latest_update(). Try adding something like the following to your bp-custom.php. Then remember to change the call in your member-header.php file to call your version of the function.
function ka_activity_latest_update( $user_id = false ) {
echo ka_get_activity_latest_update( $user_id );
}
function ka_get_activity_latest_update( $user_id = false ) {
global $bp;if ( !$user_id )
$user_id = $bp->displayed_user->id;if ( !$update = get_usermeta( $user_id, ‘bp_latest_update’ ) )
return false;$latest_update = trim( strip_tags( bp_create_excerpt( $update, 40 ) ) );
return apply_filters( ‘bp_get_activity_latest_update’, $latest_update );
}In reply to: Remove the ‘view’ button in the activity stream@lincme – this thread mentions a filter for the view button in the profile area: https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/remove-permalink-view-link-from-profile-container-request/#post-57691
I haven’t investigated it yet.
In reply to: Remove the ‘view’ button in the activity streamHi @lincme.co.uk; yes, that kind of puts a nice full stop on its display.
It doesn’t get rid of the problem of ‘dots’ being added on other elements you might want (like the delete option) though.
I’m solving it, by putting my own simple API calls in bp_custom.php (I guess they’d work in functions.php as well) to return the items I want from the activities_template uncorrupted:
my_activity_action(); returns just the action field without the meta stuff being forced in
my_activity_time(); so the time of the activity (rather than time since) can be displayed
has_delete_permissions(); used in conjunction with bp_get_activity_delete_link to just display the delete link if appropriateThen, modifying entry.php to call these functions instead.
An improved set of API functions would make theming a lot easier – would be good to know where the invite thread is.
It’s a pain to have to use a filter and override the core function simply to remove a presentational element (the view link).
The API needs to be much more granular here (e.g. get_the_activity_name, get_the_acitivity_description, get_the_activity_permalink), rather than echoing large monolithic strings from a single function.
This would make it much easier to design and develop child themes.
In reply to: profile field typesWe’d like arrays as well… where new profile field data can be added to the array dynamically.
e.g. we want our site to have a profile field where you enter your employer. It should allow the member to enter several different employers, creating each different employer field dynamically as needed. (This is fairly standard on networks such as Facebook and LinkedIn).
Is anyone working on this, or know of an extension?
In reply to: upgrading 1.0.3 site to 1.2.4@jeffsayre – thanks for the link (I missed the codex article in my search). This is a new client who already had the 1.0.3 site.
Fortunately, the client wants us to develop a new theme from scratch – so, our only core issue is ensuring the member profiles, connections and data (including blogs) are preserved.
In reply to: topic.php so first post has unique cssfollow up: it should work in IE7+ , as well as all the usual standards browsers (Safari, Firefox, Chrome, etc.)
Apparently, you need to make sure you have <!DOCTYPE defined for it to work in IE7+
In reply to: topic.php so first post has unique cssWhat CSS did you write?
You’ll need something like:
ul#topic-post-list li:first-child {
…
}If that doesn’t work, which browser are you using? If you are on an old browser, the first-child selector might not work.
Check here for more info on first-child: http://reference.sitepoint.com/css/pseudoclass-firstchild
Note for development: Firefox (with firebug extension) or Safari with the developer menu is a good choice… you can view (and experiment) with css direct in the browser. Once you’re happy, you can then test in IE.
In reply to: topic.php so first post has unique cssCan’t you just do this in css without changing any code? Have you tried just using the first-child selector, something like this:
ul#my-topic-list li:first-child {
my-css: nnn;
}In reply to: CoSign single sign on@DJPaul – thanks for the feedback… we’ll see what happens.
I didn’t know if there were any ‘obvious’ mods that BP was doing to standard WP sign in (e.g. in the front end sign in, rather than via wp-admin, or in mapping user ids to all the enhanced profile fields), that raised warning flags.
Ok, ignore me… there’s a whole lot of CSS controlling it in default.css
In reply to: SPAM Domains to add to your block listI’ve now deleted the register pages inside the bbpress folders, and that seems to have halted the spam registrations for now. Fingers crossed
@gyonis – the post has only been up 21 hours, and also is quite intimidating to read through (it may have been better to ask each question individually!)
Any some pointers:
Q1. You’ll need to write some PHP code, and also understand the BuddyPress hook function concepts.
There are already some posts on modifying the admin bar, e.g. https://codex.buddypress.org/how-to-guides/modifying-the-buddypress-admin-bar/
If your list of blogs is fixed, it should be straightforward. If you want it to dynamically add newly created blogs to the dropdown list, I suggest taking a look at the code in /plugins/buddypress/themes/bp-default/blogs/index.php as a starting point
Q2. I suggest setting up a blog in your install for the NGO Directory, with new users added as contributors… they would then be able to create posts in that blog, but it would need your admin approval before the post goes live.
You could then use categories for each country, and tags to say what type of NGO they are (or simply have another set of orthogonal categories for type). For a simple ‘code free’ solution, you would then just put a sidebar widget in that provides a menu of all the categories and / or tags.
[A more powerful solution (extra features for the NGO), would be to give them an entire blog, instead of a single post for their organisation… although tagging and categorising blogs is / was a nightmare (Burt Adsit did some work on this, but I think it is out of date now).]
[Perhaps the best solution would be to add NGO’s as a different type of member in BuddyPress. i.e. users can register as themselves or as their NGO… Create a BuddyPress group to hold the NGO members, and have country, etc. as searchable fields in the profile. We gave up on a similar 2 types of member project, but there the challenges were considerable, yours may well work with this approach.]
Q3.1.1 You can add additional fields using the ‘custom field’ area of the edit post form. This isn’t particularly user friendly though, so you might want to look instead at something like the flutter plugin, which lets you define separate fields.
Q3.2 Posting from the front end is the ‘Holy Grail’ ! Check out P2 Blog… a theme that was developed by WordPress / Automattic, but seems to have gone very quiet. My wild speculation: @Andy (the developer of BuddyPress) wrote a blog post about P2… I wonder if that means we can look forward to the P2 blog front end features making an appearance in BuddyPress soon. Any comment @Andy?
To do what you want, you’ll definitely need some development skills (PHP), a decent working knowledge of WordPress code, and an idea where to start investigating the BuddyPress code (I doubt if anyone apart from Andy has a good working knowledge of it).
In reply to: SPAM Domains to add to your block list.. I forgot to add, we’ve also disabled blog administrators from adding new users
In reply to: SPAM Domains to add to your block listI’m getting about 50 spam registrations a day on one client site since the start of this week.
We’ve modified the register slug, changed text on the register page, deleted the wp-signup.php file, and implemented the following in our .htaccess file:
# BEGIN ANTISPAMBLOG REGISTRATION
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .join-lorem*
RewriteCond %{HTTP_REFERER} !.*mydomain.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://mydomain.com/spam-prevention [R=301,L]
# END ANTISPAMBLOG REGISTRATION
Still the spammers are getting through.
Turning off blog creation / new user registration is not an option… otherwise, there would be no point in trying to offer a blog platform / social community.
Asking users to wait until their application to join is approved, or asking them to fill in additional fields at signup will just hamper the chances of them signing up and using the site.
Anyone have any suggestions?
I don’t want to tell clients: “we’ll build on BuddyPress for you, but you might have to remove 100s of spam blogs every week”
Note: the problem is worse than just the backlinks they create, it also reflects badly on the professionalism / appearance of your site, as their spam posts show up in activity streams, in aggregators (such as showing recent site wide posts and so on).
This is a serious problem.
Note: a lot of these registrations come from a small number of IP addresses, is there anyway to block certain IP addresses from registering?
@Andy – I understand the developer logic / enhanced power of the forums-groups concept. Unfortunately, though… it causes a headache for the clients we are building sites for:
They are used to the plain simple concept of standalone forums. No amount of explanation gets me past the response “but, I still don’t see why I’ve got to create a group, when all I want is a forum”.
In one case, the client has decided they are going to run SimplePress forums integrated with BuddyPress to get around this ‘problem’.
Perhaps, it would be less of an issue if it was our own site that we were running and maintaining, but we are developing for clients who will administer the system themselves and struggle with / or don’t see the need for forums-groups setup.
I guess it’s the old marketing adage: “it’s much easier to sell them something they want, rather than to sell them something they don’t know they want”.
@Andy – yes, I was going to try and delve into that filter (the one on bp_get_activity_content_body, or did you mean a different one), and I guess I need to get in to the data structures in the activities_template.
I’m a bit confused though… I only want to return something different when it’s being used in the specific instance of fetching sitewide posts. If I add the filter, won’t it affect all uses of bp_activity_content_body?
In reply to: Should I still use bp_custom.php in BP 1.1.x?A further thought (comments / corrections appreciated):
If you make your modifications in bp-custom.php it will affect your entire BuddyPress installation (regardless of which theme you are using)
If you make your modification in functions.php it will only affect the theme where you have made the changes. i.e. select a different theme and you will lose the changes.
In reply to: Advanced Recent Site Wide Posts Widget@suzanne – widget isn’t working for me on 1.2… is this a known problem?
In reply to: Advanced Recent Site Wide Posts Widget@suzanne – nice work, thanks.
Just seconding a couple of things already mentioned:
- It would be nice to be able to specify blogs to exclude (e.g. We only want to show user posts; we don’t want the admin blog id 1, and blog id 2 which we use for a help, to show). I realise this means extending or bypassing the BP core function
- It would be great if it had the option to pull a thumbnail image from the post to display
Yes, usability is a big challenge.
Here’s my 10 cents worth. Note: I come from the perspective of generally seeing BuddyPress as a tool to implement vertical social networks that would typically connect with / enhance Facebook and other social platforms.
What you are saying is very reasonable to debate. I’m not sure it’s a role for the core BuddyPress project (or a fork thereof), but can certainly see the need for it in a large number of BuddyPress based sites.
The Challenge
To build the system you suggest, the remaining challenge is how to handle blogs whilst appearing not to give the user a separate admin system (the rest is all handled by the front end already).
I understand where you are coming from, and also have clients for whom this is a major headache.
The core BuddyPress / WordPress needs to be a broad flexible system, to allow us to build as wide a range of systems as possible (as our clients / users demand). Unfortunately, as you point out, for a lot of developments this provides a lot of ‘excess interface’ that leads to end user confusion.
Our challenge as developers is, therefore, to build on BuddyPress (or take away from BuddyPress) to ensure we present a clean consistent interface to users in our finished developments.
Dealing with blogs
If the site is going to give end users a rich blog feature set (e.g. choosing themes, positioning widgets, and creating category structures), then I don’t see how we can avoid exposing the wp backend.
In this situation though, you could perhaps re-theme the admin backend to ensure a consistent look and feel with the front end. This is a lot of work, and we don’t go this far with our own site developments, instead we opt for the very partial solution of just rebranding the backend (using plugins from WPMUDEV).
If you are only going to allow the end users to have minimal blog features (e.g. posting a story), then a clean front end only solution is more viable (have you looked at plugins such as: https://wordpress.org/extend/plugins/front-end-editor/ ?)
Or, if we are not going to offer blogs, then simply turn them off.
I thought I’d read something on ‘post from frontend’ features in WordPress 3.0, but might have been dreaming it.
In reply to: Nothing appearing under “My Blogs”Note:
the /wp-admin ‘workaround’ of course only fixes the problem of accessing the dashboard / adding stories.
It does nothing to fix the problem of the Blog Directory not working.
In reply to: Nothing appearing under “My Blogs”@djpaul can you explain to us why you’ve downgraded this to minor in the trac system?
It seems to be causing major headaches to a number of developers
In reply to: Nothing appearing under “My Blogs”I’ll second it being a major bug as well (although perhaps not critical)… the workaround being to use /wp-admin… which is far from ideal for end users
Thanks @r-a-y … I just found that thread, and have contributed on there. I’ll close this thread.
