Deadpan110

Remember that editing a plugin or theme directly that you will loose changes upon an update.
WordPress recommends creating a child theme, it is safest to make changes there.
https://codex.www.ads-software.com/Child_Themes
ADDED:
You can also download a custom CSS plugin and add changes there.

I have recently tweaked my CSS on this plugin and I do feel that some CSS selectors and classes could be made better for advanced users.

BUT, try this for your button:

.mc_signup_submit input[type="submit"] {
float: right;
}

Firstly the slider uses WordPress transients to reduce database queries – so you may be seeing a cached result.

See line 744 in functions.php and uncomment:

delete_transient( 'catchbox_sliders' );

Secondly, you can add ‘post_type’ to the query (around line 757 in functions.php):

$get_featured_posts = new WP_Query( array(
	'post_type' => 'page',
	'posts_per_page' => $postperpage,
	'post__in'		 => $options[ 'featured_slider' ],
	'orderby' 		 => 'post__in',
	//'ignore_sticky_posts' => 1 // ignore sticky posts
));

It would be nice if this array used a filter instead for use in child themes, maybe our friendly catch-box developer can add:

$slider_query = apply_filters(
	'catch_box_slider_query',
	array(
		'posts_per_page' => $postperpage,
		'post__in'		 => $options[ 'featured_slider' ],
		'orderby' 		 => 'post__in',
		'ignore_sticky_posts' => 1 // ignore sticky posts
);
$get_featured_posts = new WP_Query($slider_query);

It is worth remembering CSS priority (personally I create a child theme to adjust CSS with my own style sheet loaded before the parent one).

Try this:

#slider {
background-color: #000000 !important; /* make priority important */
}

Another thing to note, your browser may be caching the original styles…
Read ‘Force refresh’ on this page: https://www.refreshyourcache.com/en/cache/

Another related change – this time for anyone that has customised their WordPress with a plugin that forces all WordPress content to SSL for logged in users.

The following ensures javascript comes from SSL if the page is SSL:

// Scripts
	if (is_ssl()) $myPluginURL = str_replace('https://','https://', WP_PLUGIN_URL);
	wp_register_script('blockui', $myPluginURL . '/sidebar-login/js/blockui.js', array('jquery'), '1.0' );
	wp_register_script('sidebar-login', $myPluginURL . '/sidebar-login/js/sidebar-login.js', array('jquery', 'blockui'), '1.0' );

Note to users, Version 1.0.7 now fixes everything I bundled into this Forum Topic.
The Group Heirachy plugin is now within the loop and even the Announce Group Plugin correctly reports what type of group the child group is set to!
Many Thanks David!

*topic now marked as fixed*

I think I may have over confused the issue and should have started a new topic (soz for that).

The new method of displaying private (and hidden) groups do work as expected – but even previous to the change, the join group button for each child group was actually for the parent group (from the loop).

I expect this to be a BuddyPress issue as I am guessing there is no sane way to rewind the loop as can be done for WordPress posts.

The problem lies within do_action( 'bp_directory_groups_actions' ) as anything using that call to action is unaware of anything other than the parent.

The best way of addressing this issue is to replace that action with your own filter and add the button from there, this way plugin users can easily remove or modify the filter anyway they choose.


//do_action( 'bp_directory_groups_actions' );
do_action( 'bp_hierarchy_directory_groups_actions', $subgroup );


You can then have a default function to create the button which users can remove or modify if they wish to within their theme.


function hierarchy_directory_group_button($subgroup) {
echo bp_get_group_join_button( $subgroup );
}
add_action( 'bp_hierarchy_directory_groups_actions', 'hierarchy_directory_group_button');


Everything else is perfect (the bp_get_group_type( $subgroup ) is broke for me because of another plugin).

I hope this helps – this plugin IS a fantastic addition to BuddyPress – keep up the good work m8!

Just had another look into echo bp_get_group_type( $subgroup ).

The reason I assumed it was not showing the correct group type was because my parent group is set to be a public announce group using the ‘BuddyPress Announce Group’ plugin.

The group type is modified using a filter by the Announce Plugin and assumes that because the Parent is an Announce group, the child groups also get displayed as ‘Announce ‘ + [group type].

Maybe this can still be fixed (it does suggest that BuddyPress is not aware of where it is in the loop – but again – I am still getting to grips with BuddyPress).

Hmm, that did not display as I had intended…
I hope you can still read it ??

Great work m8!

I also had to modify the output for group listings.

do_action( 'bp_directory_groups_actions' )

I am assuming that this does not work due to the listing not being in the loop (I am still getting used to the workings of BuddyPress).

The ‘Join Group’, ‘Request to Join’ and all the other buttons and content called within that action are actually for the parent container group.

I fixed that for my own purposes by replacing the action with:
echo bp_get_group_join_button( $subgroup )
Note: bp_group_join_button($subgroup) will not work due to a bug in BuddyPress (See: https://trac.buddypress.org/ticket/3057 )

I also have a feeling that there is also a bug within:
echo bp_get_group_type( $subgroup )
This seems to ignore the $subgroup array.

I am unsure of the exact procedure for making BuddyPress actually do its loop correctly so I would suggest the following fix:

Replace all the following:

<br />
<div class="action"><br />
<?php do_action( 'bp_directory_groups_actions' ) ?><br />
<div class="meta"><br />
<?php echo bp_get_group_type( $subgroup ) ?> / <?php echo bp_group_hierarchy_get_group_member_count_by_group( $subgroup ) ?><br />
</div><br />
</div><br />

With:

<br />
<div class="action"><br />
<?php do_action('group_hierarchy_directory_groups_actions', $subgroup) ?><br />
</div><br />

And then adding it all back in using an add action:


<?php
function group_hierarchy_directory_groups_actions($subgroup) {
?>
<div class="action">
<?php do_action( 'bp_directory_groups_actions' ) ?>
<div class="meta">
<?php echo bp_get_group_type( $subgroup ) ?> / <?php echo bp_group_hierarchy_get_group_member_count_by_group( $subgroup ) ?>
</div>
</div>
<?php
}
add_action('group_hierarchy_directory_groups_actions', 'group_hierarchy_directory_groups_actions');


This will not fix the problem and still use the current behaviour BUT will allow plugin users an easier way to change this output if they need to:


// possibly in a theme (or child theme) functions.php

function my_custom_directory_groups_actions($subgroup) {
// My own custom output would go here so there is no need to modify
//the plugin as changes will be overwritten on an update
}

//remove the plugin default action
remove_action('group_hierarchy_directory_groups_actions', 'group_hierarchy_directory_groups_actions');

//add my own layout
add_action('group_hierarchy_directory_groups_actions', 'my_custom_directory_groups_actions');

This kind of suggests things about the WordPress Plugin Repo.

I am unsure of how things operate now, but I noticed this post by accident and 10 months after the original post (I have received no email to update me on any comments).

This project was abandoned approximately 2 years ago due to lack of interest and time.

I have tried to search for a delete link – but to no avail.

Sorry.

I have just had a quick play around with the code, this is indeed a WPMU to WP3.0(MS) upgrade issue.

Using is_multisite() fixes the initial problem but then open’s up a whole can of worms.

For the main blog in the new WP3.0, the $wpdb->prefix would be ‘wp_’ for the main site on a standard install where as networks upgraded from WPMU are $wpdb->prefix = ‘wp_1_’.

I can not promise I will have time to look further into a solution over the next few days, but I will try (It should be a simple case of tracking down the relevant sections within the code and making sure the plugin knows the difference between a new WP 3.0 install and an upgraded WPMU one).

NOTE TO OTHERS…

Confirmed, this plugin works unless you have upgraded from WPMU to WP3.0 MultiSite – so this bug will not effect everyone!

I will keep this thread alive until the issue is solved (and I am willing to submit a fix – when I have some spare time).

Great and thankyou for the reply,

I now know where the problem is.

My WordPress 3.0.1 install was originally WPMU and the upgrade to WordPress 3.0 does not require that defined (if you set it, it breaks the main site).

WordPress MultiSite makes use of the is_multisite() function which always returns true for any WordPress install with MultiSite enabled (Even upgraded WPMU networks).

See the top of https://codex.www.ads-software.com/Create_A_Network:

NOTE: If you are currently running a version of WordPress MU, you do not need to complete these steps. your network is already enabled. Once you upgrade to the 3.x branch, you will be prompted to update your .htaccess rules for MultiSite.

It would be great if you are willing to fix – or – when I get time, I could submit a patch and then we can mark this forum thread as fixed!

I have just set up a self hosted blog for development and the dashboard feeds (etc) all failed to work.
RSS Error: A feed could not be found at https://www.ads-software.com/…..

It was due to PHP being compiled without the curl option, so this could also be a probable cause for some.

Use <?php phpinfo(); ?> to see if curl is compiled and enabled.

@donncha : I have made a tiny modification to wp-cache-phase2.php that enables my dynamically served page to output:

This page: 61 queries in 0.192 seconds.

On caching, WP Super Cache changes that section and saves the page with:

This page: Cached by WP Super Cache on October 18th, 2008 at 1:42 am.

This works on my wpmu install and should work fine within WordPress default by simply marking your section with:

<!--cache_stats-->
<strong>This page:</strong> <?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.
<!--/cache_stats-->

An example of it in action can be found within my footer at IND-Web.com

Would you like me to send you the file to look at?

PS, Many thanks for such a great plugin ??