Forum Replies Created
-
this might interest you http://sushkov.wordpress.com/2010/04/04/scholarpress-buddypress/
has been pwnd – @windhamdavid(349) vs. @boonebgorges (379)
also in i’m a words with friends newb – “windhamdavid” but it should be the “sesquipedalian” look it up gibbs, it’s the queens english after all.
you should change those values now that you’ve published them online. and disable all plugins.
kaching – this works
@foralien – nice work. thk u!
I do however see these bits of goodness in the trunk which is indicative of my current structure and leads me to believe that the fault is as @rebootnow called it. It’s still asking for get_current_site() when displaying avatars on a secondary blog with multisite enabled.
+ if ( bp_core_is_multisite() )
+ $path = ABSPATH . get_blog_option( BP_ROOT_BLOG, 'upload_path' );
+ else {
+ if ( !$path = get_option( 'upload_path' ) )
+ $path = WP_CONTENT_DIR . '/uploads';
+ else
+ $path = ABSPATH . $path;
+ }
and
if ( bp_core_is_multisite() && BP_ROOT_BLOG != $current_blog->blog_id )
- $upload_dir = str_replace( $current_blog->blog_id, BP_ROOT_BLOG, BLOGUPLOADDIR );
-
- return apply_filters( 'bp_core_avatar_upload_path', $upload_dir );
thanks @johnjamesjacoby for the follow up and @rebootnow for the additional insight on this. I believe that tickets #2451 and #2469 are related because with multiblog enabled it’s still kicking an avatar path and upload relative to the wp_upload_dir(). I tested the 1.2 branch but I just svn sw’ed up to 1.2.5 and I see the that the trunk merge didn’t quite make it regarding avatar_upload_path(). There are no differences between the bp-core-avatar.php in the 1.2.5 tag and 1.2 branch? This one is outsmarting me thus far, I’m afraid to filter the core_avatar_upload_path with custom functions for future compatibility and the filters don’t exactly account for the structure of the avatar uploads if the upload path for the site settings is modified – as in something like such http://gzet.net/wp-content/uploads/avatars/ ~ when the rest of the sites adhere to the /blogs.dir/#/ protocol.
I don’t think that’s by intention. I haven’t dug into it that much, but It’s also happening on sub-directory installs and I’ll file a trac ticket. https://trac.buddypress.org/ticket/2451
http://dev.gzet.net/windhamdavid/
http://gzet.net/windhamdavid/
it’s a couple revisions short of 3.0 though and I suspect the rewrite problems may be related to another plugin.
https://trac.buddypress.org/ticket/2450thks ~ yes.. bb-config-location in _sitemeta works.
you might want to start with the wordpress documentation first ~ https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory
yup, i second some of these previous comments and I’ll miss my lost my “activity” which, for me acted as bookmarks in the forums, however.. on a positive note I will certainly give a thumbs up to the seemingly improved page load times and the new topics layout in lieu of the old forums.
I’m becoming a fan of WP-Invites and you might want to try this…
https://wordpress.org/extend/plugins/wp-invites/
It’ll allow you to dole out codes for users to signup and as far as tracing goes, I’d just generate one invite code for each existing member and it’ll store that invite code with the new user profile so that you are able to determine who the invitation was send from based on which user was giving the code. I’d even go so far as manually generating the code with the existing username in it so that you don’t have to go digging to determine whom signed up whom.
the api eh? (a large percentage of shared hosts are poor quality, we’ll never be able to fix that) my take is that at it’s core, it’s “the missing extended user profile framework for WordPress”. It would, in my feeble opinion act primarily as a framework api for extending those profiles. Some of the issues and limitations are really presented by wordpress and mu.. not Buddypress and in much the same way that bp extended the wordpress user profiles/functions we should tackle those head on as had been done with the improvements in the BP1.2 registration. There are infinite ways to build on those relational database fields. Focus exclusively on bp_xprofile _fields, and _data. It’s not that I’m anti-activity stream and the terms social network, life stream or whatever just seem to incorporate user profiles into some sort of relational scheme, be it friends, followers, ‘like’-ing, sharing or chronological micro blogging. Extending the stability, functionality, and interactivity of each component is the goal, but I’d prefer to see no dependency among core elements with one another. It’s fairly simple to build out a “social network” in other popular content management systems by extending the user database fields and in my day to day practice, I typically use only about 20% of the Buddypress core components for a WordPress project. Even though the hype is in the activity stream and the extensions for it (more facebook or twitter like), I side with @stwc in that “It also means that the platform has to have a robust set of tools for the administrator and moderators of the community “. A community (or ‘social network’) is just a set of users and to me, key items are a small footprint on the database and tight the integration with the existing wordpress user roles, permissions, registration and management. The api should ideally be flexible enough to accommodate any possible relational data between user profiles that a plugin author may dream of. I think the core integration between user profiles and the activity/blogs/groups/forums/friends illustrate the foundation of the api and should be as unified, consistent, and simple as possible with very little dependency or overlap in functionality. This would be impetus for creating a more standardized way to interact with the xprofile and be a good foundation for a solid api. lastly, thanks @mrmaz for starting the thread, being pro-active, getting the trac and api.buddypress and generally illustrating the potential of a solid api in regards to how well your links plugin and others can interact with the core.
ps.. death to PHP4 and fsck backwards compat
@jacco ~ in order to find the multi site functionality ~ you’ll need to enable it multi by adding this to the wp-config.php file
define( 'WP_ALLOW_MULTISITE', true );@jacco ~ in order to find the multi site functionality ~ you’ll need to enable it multi by adding this to the wp-config.php file
define( 'WP_ALLOW_MULTISITE', true );I think this a great idea for the wordpress track ~ I’m with @djpaul.. WordPress plugins should be able to declare a parent plug. I can declare that a piece of javascript has dependencies, or a theme, but not a plugin.. Are some of the more robust plugins (ecommerce, nextgen, etc) with sub plugins handling this? Someone should file an enhancement ticket.. this is very logical and would increase interest in child plugs, like those for BuddyPress.
its in bp-blogs/bp-blogs-templatetags.php
this is good news and the jquery fullcalendar plug … @mikepratt ~ thanks for tracking erwin down on it, bp-events was ahead of it’s time http://svn.wp-plugins.org/bp-events/. @kunalb this would make an ideal Gsoc project ~ events management for WP including ticketing management would put it over the top. For those of you interested in a fork of existing code, may I suggest ~ http://svn.wp-plugins.org/the-events-calendar/ & http://svn.wp-plugins.org/eventbrite-for-the-events-calendar/ this one was my fave, but it hadn’t been updated in years. http://svn.wp-plugins.org/event-calendar
mu or single user wordpress? the version info is not in the <head> but the /blog url indicates it’s MU. at first I thought PHP GD library, it’s not ~ you’re on a (gs) at media temple and I’ve tested there, and seem to remember running into this so I registered on your site to test (I like the cure anyhow) and I notice that your image url path is off ~ if you running from the sites/ directory with mu are there any other custom configurations to accomodate not running it from the root folder that might effect this url?
~ you may try “Settings” >> “Miscellaneous” Clear “Store uploads in this folder”-path
or ~ https://trac.buddypress.org/ticket/1970
or ~ https://buddypress.org/forums/topic/avatar-upload-issues/
or ~ https://buddypress.org/forums/topic/faq-how-to-code-snippets-and-solutions#post-11864
otherwise, try to make sure that your wp-content/blogs.dir/ have the proper permissions and that your uploads url settings are correct.
thks r-a-y ~ i just stacked bp_authz, simple_bp_privacy, and this other against one together and while sayer’s is the most robust (uhem Jeff, Get to work) ..both of these two others function properly as far as I’ve tested and will suit a good many users with a light footprint on the database.
one of those was me.. have you considered contributing it to http://svn.wp-plugins.org/
and if you can’t deactivate them, delete the files from the site since access violation implies that the permissions on the files are not correct ~ take a look here (https://codex.wordpress.org/Changing_File_Permissions) to make sure you have the proper permissions on the files
@mihaimihai ~ were your registration page failing on secondary domains, sub- domains/directories only or also in the root and when you say “multiple sites on different domains”..how are you mapping the domains, if you don’t mind me asking?
