Forum Replies Created
>I had already worked out that ‘component_id’ => buddypress()->activity->id was wrong
No it’s not wrong, buddypress()->activity->id == ‘activity’, in replacing it with a hardcoded string you could possibly cause issues if activities id did change, where it will cause issues is if BP isn’t loaded then buddypress() will fail, a hardcoded value is safer in that respect.
>but it’s interesting to find that the source of the problem was that the codex example was (and still is, btw) hooking into the wrong action.
Again it’s not necessarily hooking into wrong action ‘bp_init’ does work, I used it recently on a register_post_type where issues arose on BP update as init ran before bp had re-activated, although that later priority may have solved that one.
So the reference to codex entry still being wrong is debatable, possibly it ought to be updated, and on that score the codex like the rest of the BP project is all volunteer work and any member has the ability to add, update codex pages if they see somethings wrong
> it’s not easy for us frenchies to write Codex articles.
Oh you don’t do too bad a job, the two of you, for frenchies that is
Actually I wasn’t commenting on the standard of article/s at all just on the separation of information.
@danbp Thanks for adding the link, there’s a fair bit of detail in that topic on support which really ought to be in the codex, almost a case where the post topic is better detailed than the codex entry which aint a good thing!
Not sure here why the split between the register cpt function and BP one, if there’s access to the cpt register args why not simply add the BP args to that, although if BP wasn’t activated it would be harder to check for that especially if the CPT was required regardless of whether BP active or not.
I sort of encountered the same issue but sadly can’t say what I did to correct whatever went awry.
You appear to have followed the codex example correctly, but maybe try the other approach and update your register_post_type() $args; ensure your definitely using the correct custom post type name, text domains etc and your template show filter is current i.e uses ‘bp_activity_show_filters()’
Remember to follow the naming convention as outlined in the codex guide for template hierarchy and that if wanting to create a standalone template i.e index-registration.php it will require all the ‘parts’ that constitute a WP template get_header/get_footer
Where did you get the idea that /registration/ was a valid directory? Look at the existing bp-legacy layout it’s there in black & white as to where files reside and in what directories
If you want to do this I suggest that you’ll need to hire a developer, as in the original response “but is no trivial task ” There’s little point suggesting where to start as unless you have pretty good PHP skills and a good knowledge of how BP works this will be a struggle to achieve.
What do your WP settings page ‘general’ show for urls, specifically ‘Site Address (url)’? Did you check the values here after the change over?
WP codex guide on this aspect:
Did you also visit the permalinks page under ‘settings’, just to ensure permalinks are re-freshed?
This is really a WP support issue as the problems rest with how WP is configured rather than issues specific to BuddyPress working.
Glad it’s resolved.
You might want to consider dropping that theme a note about this or at least check if they have an update to their theme. Themes that state a claim to something like BP support/compatibility have a responsibility to ensure their themes are kept up to date with possible changes in BP releases, BP releases tend not to have too many fundamental changes to template files but they do from time to time and those might be lost if templates overloaded to themes.
hmm expected that patch to be included in next WP release but hadn’t actually looked at what release the patch was added to, assumed if committed it would be next even if a point / minor version.
Glad it’s sorted, it’s an unfortunate issue, one that BP had to implement but we were aware of the issues that arose so are looking out for problems that sound as though this is the root cause.
I’ll close this thread as resolved.
This is likely an issue with necessary changes BP had to make setting is_page() to zero for BP pages, sadly causing a WP bug to manifest, WP has been patched to handle this issue.
You can apply this patch to WP core in advance of it being released to correct the problem – if that is this is the issue.
You need to explain just what you’re doing template wise with your site.
If you have updated to latest BP version then you should have correct templates, unless you have overloaded/copied them to a theme, have you?
Why haven’t you access to move files around? No cpanel, ftp etc to transfer files to a theme folder?
Why are you referencing files from the github account – not that you can’t just a bit unusual.
Is the directory you want, profile-loop and edit templates.
Registration page If you are on the registration page, BuddyPress will use the following template hierarchy: /buddypress/members/index-register.php The rest of the base templates as listed here.
If you now rename the existing file you have overloaded as per the instructions for working with BP templates in a theme or child theme to the above what will happen is that BP will consider it a template handling and indeed needing all the necessary template parts i.e header and footer and all parts in between – think of the file now as similar to your page.php template but with the register content where the page loop for title and content would be. You now can traet this file as standalone and modify as you require.
Why are you adding or trying to add styles via bp-custom.php?
Explain the actual issue rather than ask for a solution to a specific approach.
If you check the WP codex ‘enqueueing styles’ you’ll see that the function allows you to state a file that this one must look for and load after stated by declaring the files ‘handle’
Styles are best enqueued from functions.php in a theme, with BP you have the option of overloading the BP styles to your theme where you can edit them directly, so you have options and shouldn’t be running into issues with style cascade and specificity.
Re the P.S what exactly are you wanting to change? Some pages in the codex are in need of updating and is an ongoing process.
Those two fields do work fine, I suspect that you are working with an older version of the view & edit templates? The manner in which xprofile fields are looped to be displayed changed so you will need to grab latest versions of these templates from the bp-legacy directory in the core plugin.
Yes can confirm that there does appear to be an issue, but need to test this further on another install. It seems we aren’t rendering the input control on the profile edit field on the frontend.
If we can establish it’s definitely a core issue we’ll raise a ticket to get it looked into.
I ran across this the other day, and it’s been ticketed and will be looked into:
Ah oh, slightly harder possibly, try checking through the available tags though, something is probably achievable that is simpler than your initial attempt.
did you check the BP codex before embarking on above?
The docs is first port of call, we attempt to document as much as possible there on an ongoing basis, some pages are undergoing re-freshing & updating but still provide useful reference like this page:
Where you might try
Or scan through bp-core-template.php in the core files where you’ll find reference to:
which actually is a very simple check to see if !bp_is_user() && bp_is_members_component() the difference remaining can only be the members main directory.
Generally BP is well specified for template tags and ‘is’ function checks.
Yep we thank r-a-y for his due diligence on the mater and for patching WP core, which was committed a few days back so will roll out with next WP version.
Closing this thread as resolved then.
> and it must NOT be compulsory to join the group for the public groups. Why can’t this be done?
Perhaps it can be, suggest it on a trac enhancement ticket if you feel that strongly, by default groups need members, BP list participants in a group or at least can track things if people are matched with a group.
bbP forums is a standalone plugin that ties in to BP due to historical use of forums in groups, but you can create forums outside of BP groups and categorize/nest them but bbP support and documentation better explains how to setup bbPress, although we have a decent guide in our codex too just have a look through the docs but do come back with any questions you might have to doing this if things still not clear.
What problem? the initial comment is along the right lines Groups require members you can’t post or partake in them unless you join the group, perhaps take up the suggestion to create a forum outside of groups?
@peter-hamilton Hmm that used always to be the process, updating or posting to a group automatically joined you to the group if it was ‘Public'; The codex may need updating or we may have regressed, I’ll have a delve into that.
Yes you can create a single members page that exist at say the same level as standard WP pages and into that bring various elements from the user account to create a sort of single user landing page, doing this will depend on how comfortable with coding you are, as you are starting to get into the realms of custom work here.
BuddyPress certainly is a good fit for many sites along these sorts of lines, but out of the box it can only go so far and has to present a default setup that suits the majority, extending this to provide more custom requirements is possible, but you will need a certain level of skills – the codex is your friend though we have quite a few articles and guides there that will help.