??? isn’t is_site_admin in the bp-core-wpabstraction? I’ll check if it uses it before bp-init
Yes but you can’t be sure bp-core-wpabstraction.php is loaded until bp_init fires. Regadless, try to use current_user_can() instead.
I’m a bit offended at having some of my work in this “Hall of Shame”; a message or email to the plugin developers would have been more polite.
I’ll update my plugins as and when I get time; client work continues to take priority.
It’s a lighthearted hall of shame, I’m calling them out because it’s important. The updates take 5 minutes, we can’t continue to have BuddyPress crash because of plugins every time it updates.
Not sure why ‘offended’, this matter cuts to the core of the issue of third party plugins causing potential damage to projects such as BP, I would have thought experienced plugin authors would have got this matter dealt with straightaway if as Andy says it’s a matter of 5 minutes work.
I understand the pressures of work and time constraints having, as I do, to work 7 days a week to hold a small web dev company together but comments like ‘I’ll update my plugins as and when I have time’ ?! is a comment like that really necessary?
I guess there are no experienced BP plugin authors because BP hasn’t been around for a long time.
It’s important to get this topic out there and the frequently used plugins fixed quickly. Otherwise people will have strange feelings every time an update for BuddyPress comes out. That hurts BuddyPress.
(I don’t understand though: is there really no way to take care of “white screens” from the other side – from WordPress side? Like a try…catch fatal error thing which would deactivate the plugin causing the error?)
@Magganpice – yes there is a fatal error catcher when activating plugins, but not when a plugin is deactivated on upgrade.
# BuddyPress Restrict Group Creation
# BuddyPress Sitemap Generator
both use
add_action( 'bp_init',
but i just noticed restrict group used wp_head so i’ll change that to bp_head
@etiviti (rich!) – Yes, but the code needs to move to a separate file as it’s as simple as referencing a BP function in that code and it will break. It’s risky.
ah the loader.php way (i had the older check)
When the new and cool bp-org site comes online – possible to have a plugin developer group where best practices, codex updates, etc can be communicated? (just auto assign the user when it picks up the plugin?)
also what about instances where we need to modify items before bp_init? is loading the file on bp_core_loaded ok? (only way I can get restrict group to function properly)
OK, you can take me off the Shame List. I’ve just put new versions of Group Forum Subscription and Enhanced BuddyPress Widgets into the repo that use the loader method. HIGH FIVE FOR MYSELF!!
@etiviti (rich!) – Modifying items before bp_init is fine in the main file, but you must be careful not to reference any functions in BuddyPress.
Hem…
Is it possible to have BP updating without wipping out the previous version .mo file from bp-languages ?
Or at least a warning message telling “bp was succesfully updated, but thi erased your language file. You can upload a new language file at https://i18n.trac.buddypress.org/browser
It is a bit annoying for us foreigners, to suddenly have all in english after each BP update.
Ihttps://i18n.trac.buddypress.org/browser
I know, this should be on trac under Future enhancement, but not only 3rd party plugins authors need to be remembered to correct their work.
A bit off topic but – yes, I’m committed to making this happen in 1.3.
BuddyPress External Group Blogs
DOES NOT WORK! It still pulls in the same blog posts over and over again.
Burned! Yes I need to fix it – but this is for plugins that break BuddyPress upgrades
haha fair enough Sorry, just want to use that plugin. *removing match from your ass*
updated BuddyPress Restrict Group Creation to use a loader file (0.1.5) and will look into the sitemap stuff in a few days (need to update it with other features)
“Remove The Stone of Shame… and attach The Stone of Triumph!”
Most of all, I would like to see:
– BuddyPress Album+
– Welcome Pack
…in the “good plugins” list. Many of the other BP-crashing plugins don’t even work Now which is better: not working at all in BP 1.2.x or BP crashing in 1.2.x? I say: not working at all may be better for BuddyPress reception – because it is clear that the problem is a plugin problem and not BuddyPress.
The first time I got a “white-out” I was frustrated with BP, didn’t immediately think of the plugin developers.
My offer to bring this a step further: for “Welcome Pack” and “BuddyPress Album+” – based on an hourly rate of $60 and the 5 minutes needed to correct the plugin, I will donate $5 via PayPal each if they get corrected by the end of the month (2 or 3 days). Even though I have already updated to BP 1.2.3 by deactivating those plugins temporarily.
Hmm… Isn’t it possible to add something like this to the bp core code:
1. Require BP-specific plugins to have a special trigger in the plugin header like “Type: bp-plugin” or simply “BP-plugin: True”
2. At activation and upgrade, double check those plugins to make sure they are BP safe. If not, refuse to register them and give these errors:
- “The plugin you are trying to activate contains functions that can’t be found in the installed versions of WP/WPMU and BuddyPress. They are : etc…”
- “Sorry, this plugin can’t be registered because it does not check if BuddyPress is active.”
- “Sorry, this plugin can’t be registered because it uses an old method of BP detection and needs updating to use bp_init loader method.”
You know maybe the problem is us lowly users. If we didn’t depend on plug in developers so much to keep their projects functioning then it wouldn’t be an issue.
I never saw this as an issue with Single user WP plug ins so this is all new to me.
What I don’t understand is, I always assumed that plug in developers had other services that were paid services and creating plug ins was a way to not only contribute to the platform, but to show their expertise and make their names known in the community.
If a plug in goes unfixed and crashes a users or a company’s website, and support for it goes unanswered..how does that help you as a professional ?
And when you do release a premium paid plug in in the future, why would I take a chance that you won’t go missing in action again when it comes to support?
And why would I contribute to a plugin that doesn’t work and hasn’t been updated or answered support questions since late 2009?
Unfortunately some of what could have been/would have been some of the most used plug ins are on that list with no sign of the original developer updating them.
So now, instead of contributing to that developer for their hard work, I have to hire someone else to make it function correctly or build me a new one.
That really sucks.
I’m with Magganpice. I’d be more than happy to make a contribution to Buddypress Registration Options and Ahjira Recent Sitewide Articles, if they would just update them so they actually work.
@Andy Peatling – Very sad to be in hall of shame
1) Version 0.1.6 of BP Album+ that is posted on the WordPress plugin repository checks that BP is installed exactly as you have specified. Can you be a bit more specific about the defect?
2) I completely agree that current_user_can() is a better way to check for permissions in various plugin operations; and we will switch to the new function at the next BP Album+ release as per your request. In the meantime, why is using is_site_admin() so bad? Doesn’t current_user_can() just pass the call to is_site_admin() ?
/**
* Whether current user has capability or role.
*
* @since 2.0.0
*
* @param string $capability Capability or role name.
* @return bool
*/
function current_user_can( $capability ) {
$current_user = wp_get_current_user();
if( is_site_admin() ) <—- *NOTE*
return true;
if ( empty( $current_user ) )
return false;
$args = array_slice( func_get_args(), 1 );
$args = array_merge( array( $capability ), $args );
return call_user_func_array( array( &$current_user, ‘has_cap’ ), $args );
}
^F^
Hi guys.
Try to use the new way to check that BP is active.
But, I got this problem :
Before, I had :
function bp_maps_init() {
require( dirname( __FILE__ ) . ‘/bp-maps.php’ );
}
if ( defined( ‘BP_VERSION’ ) )
bp_maps_init();
else
add_action( ‘bp_init’, ‘bp_maps_init’ );
now, with
function bp_maps_init() {
require( dirname( __FILE__ ) . ‘/bp-maps.php’ );
}
add_action( ‘bp_init’, ‘bp_maps_init’ );
The plugin brokes. Seems the hooks aren’t fired as it should or something like this :
My file bp-maps.php loads a file called “bp-maps-members-map.php”.
In this file, several functions are hooked
add_action( ‘bp_before_directory_members_content’,’bp_maps_members_map_link’); // this one fires
add_action( ‘plugins_loaded’,’bp_maps_members_map_screen’); // this one not
the function bp_maps_members_map_screen isn’t fired…What’s the problem ?
Tnx.