Forum Replies Created
-
I’ve posted a thread on Google Webmaster Tools forum in case it’s an issue with the sitemap rather than buddypress, but our search engine rankings have dropped dramatically since we installed the new Buddypress-powered site. (Hopefully we can fix this without moving away from Buddypress, but it’s such a key issue to us that we may move away from it if it can’t be resolved.)
The way I see it it’s either…
- An inherent issue with using Buddypress
- An issue with the members profile template (part of the custom theme)
- An issue with the sitemap
Ok, so I’m guessing that means they have been indexed in the past, but they’re not showing anywhere near where they were showing in the past, in terms of search-rankings. But crucially, looking at the Webmaster Development Tools dashboard where we submitted our sitemap, it lists only 317 out of the 658 pages as being indexed, and those pages that are refusing to be indexed are hostel profile pages.
Sitemap Indexed / Submitted
category-sitemap.xml 2 / 2
events-category-sitemap.xml 3 / 3
members-sitemap.xml 7 / 345
natters-category-sitemap.xml 2 / 2
natters-sitemap.xml 136 / 138
page-sitemap.xml 54 / 55
post-sitemap.xml 83 / 83
post_tag-sitemap.xml 2 / 2It doesn’t flag up any errors, it merely leaves them as unindexed.
There hasn’t been any errors returned when we submitted it on Google Web Development Tools; it just seems to have indexed pretty much every page on the map bar the profile pages…
Yup. Yoast didn’t automatically include the members profiles in the sitemap it generated so we added another sub-map specifically for that. And they all have a priority of 90%…
Some issue with the theme’s buddy press profile pages is my best bet, as you say, but we’ve not got any flash on there…
The robots.txt just says
User-agent: * Disallow: /wp-admin/which is pretty standard. The profile pages are under the ‘/members’ directory
(Here’s a link to the site)Further update: I’ve narrowed it down to the $aspect_Ratio variable in bp-core-cssjs.php on line 163 which I’ve used a hack to fix the variable for the time being.
158 <script type="text/javascript"> 159 jQuery(window).load( function(){ 160 jQuery('#avatar-to-crop').Jcrop({ 161 onChange: showPreview, 162 onSelect: updateCoords, 163 aspectRatio: 1.72817, // NEW HACKED LINE WITH FIXED-RATIO 164// ORIGINAL LINE aspectRatio: <?php echo (int) $aspect_ratio; ?>, 165 setSelect: [ <?php echo (int) $crop_left; ?>, <?php echo (int) $crop_top; ?>, <?php echo (int) $crop_right; ?>, <?php echo (int) $crop_bottom; ?> ] 166 }); 167 updateCoords({x: <?php echo (int) $crop_left; ?>, y: <?php echo (int) $crop_top; ?>, w: <?php echo (int) $crop_right; ?>, h: <?php echo (int) $crop_bottom; ?>}); 168 });Update: I added
<?php echo "Avatar size: ".bp_core_avatar_full_width()."x".bp_core_avatar_full_height()." (".bp_core_avatar_thumb_width()."x".bp_core_avatar_thumb_height()." thumb)"; ?>
to change-avatar.php and it output “Avatar size: 1920×1111 (86×50 thumb)” next to the crop, which is still only allowing a square ratio crop. (View screenshot)That means it must be to do with the cropper itself then, right?
YES PLEASE, what was that solution? The other ones I find are all out of date or don’t work.
Many thanks!
If anyone’s still struggling with enabling GD support on their VPS server, I found this tutorial very helpful.
Aaaah sorted – I needed to install gd support on my VPS server, which I fixed with a bit of help from this tutorial.
You can add the following code to your theme’s functions.php and change the crop size (FULL_WIDTH & FULL_HEIGHT, here set to 1920 x 1111) and also the thumbnail sizes to whatever you like, along with specifying maximum limits on the images uploaded.
// Resizes avatars define ( 'BP_AVATAR_THUMB_WIDTH', 50 ); define ( 'BP_AVATAR_THUMB_HEIGHT', 50 ); define ( 'BP_AVATAR_FULL_WIDTH', 1920 ); define ( 'BP_AVATAR_FULL_HEIGHT', 1111 ); define ( 'BP_AVATAR_ORIGINAL_MAX_WIDTH', 2000 ); define ( 'BP_AVATAR_ORIGINAL_MAX_FILESIZE', 819200 );Hmmm I wouldn’t call that a solution. Can you narrow it down to any particular plugins?
In my case it was ‘BJ Lazy Load‘ that needed disabling to make the difference. Do you have that plugin on your site, or is it a different one?
Either that plugin is the issue, or if it’s multiple ones then we could try and figure what they have in common and fix that.
I want to only allow private groups, so I’ve commented out the equivalent of lines 81-88 & 99-106 in create.php and 59-67 & 79-87 in admin.php. Now when a user creates a new group, it does only show the private option, but it remains unchecked unless they click on it, so if they don’t, the group’s status remains as ‘public’ when they continue to the next stage. How do you set the radio button to be checked by default?
