Forum Replies Created
-
In reply to: Title page removed users and groups
The issues are being worked through on that trac ticket, but aren’t straightforward, the resolution should be included in the next release of BP, not sure that much can be done in advance of that by way of temp fixes but if something can be figured out we’ll post it here.
Did you check this aspect I mentioned a while back?
>and your template show filter is current i.e uses ‘bp_activity_show_filters()’
@petervandoorn NP there was no offence taken 🙂 more a concern in stating something was wrong, which can be a little black or white, and where it wasn’t necessarily wrong but different things work or are needed in different circumstances.
I wish I could remember what corrected the issue when I encountered the no show in the filter, just in case permalinks do figure in things – they do where registering CPT’s are concerned – visit your permalink page to ensure cache is updated?
In reply to: Remove formating from buddypress.js> this seems like fairy dust
Tend to agree, however it’s not necessarily core functionality it’s located in the templates directory and as such you can overload the file and any file there to your child theme and edit as you see fit, check the codex for explanations of the template hierarchy.
>After reading what you said about I looked at the ‘Activation’ drop down and it was set to login so I think that is where I went wrong.
I suspected it was – that was confusing WP. For the moment set activation simply to a new blank regular wp page named ‘activation’.
@studdlypig
The admin user or primary user that is setup when a wordpress site installed is always able to login directly, and it’s initally only that user that can activate plugins i.e BuddyPress so I’m not sure why you are having trouble with activation requests. /wp-login.php should allow the admin to login regardless of whether BP is activated or not.What account are you trying to login with, the admin user ID 1 ?
In the BP settings screen ‘Page’ tab what page have you associated to ‘Activation’ in the select box, as the redirect here appears to be the main issue and the WP link to login on the WP toolbar should redirect to the wp-login screen, which you can actually access directly by modifying your browser url so you can actually login as admin and manage your site.
fyi you shouldn’t have to trouble your web hosts to deactivate BP, using a control panel or ftp you can rename the plugins folder which will force a deactivation of the plugin or any plugin if they give trouble.
>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_footerWhere 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 😉
In reply to: Send reminder about not answered messageIf 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:
https://codex.wordpress.org/Giving_WordPress_Its_Own_DirectoryDid 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.
@shanebp great minds…
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.
https://core.trac.wordpress.org/attachment/ticket/24674/24674.2.diff
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.
https://github.com/buddypress/BuddyPress/tree/master/src/bp-templates/bp-legacy/buddypress/members/single/profile
Is the directory you want, profile-loop and edit templates.In reply to: How remove header/footer from Register page?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.
In reply to: How to add style css in bp-custom.phpWhy 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:
https://buddypress.trac.wordpress.org/ticket/6167
