Forum Replies Created
-
I just noticed that the create group link form is showing even if I am not logged in, which is bad. I think maybe you are trying to add a link to a group that you aren’t a member of, as that would not work behind the scenes.
I will get this resolved before final is tagged.
Any programmers out there who want to contribute to the analysis can follow the progress on the Trac wiki here https://trac.buddypress.org/wiki/NextGenApi
You and I are on exactly the same page.
I think it would be cool if there was a BP core release and/or a BP “with goodies” release that shipped with maybe the top 20 plugins that are up to snuff code-wise already bundled with it but not activated.
I vaguely recall that ticket, and will dig it up to see what angle you took to solve the base component puzzle.
Going to attempt to get this thread back on track with a summary of what I am seeing so far.
The hot keywords in no particular order:
social networking
community
niche
plugin
extend/extensible
framework
There seems to be a general consensus that BuddyPress is an application that allows even novice techies to easily add a social network or community component to their WP site. It provides the most essential tools for achieving this “right out of the box”. Since everyone is marketing their site to their niche, BuddyPress needs to be configurable and flexible enough to allow them to pick and choose what features are right for them and to select those features from a deep directory of solid plugins.
There are many pros and cons to coordinating an effort like that. Development of this project is very organic, and developers come and go frequently. It would be bad if there is a specific functionality that everyone has marked as a high prioroty, and we are all sitting around waiting for a developer to get it done, and then he disappears.
The best advice I can give is to poll the community before you invest in a plugin to see if anyone else is working on the same thing. If you are working on a plugin, make it’s development as public as possible so that if the functionality it provides is needed for the core, the community is aware of it and can have a discussion about whether your plugin should be merged.
I think generally though, the future of BuddyPress will prove to be plugins. There are going to be solid core features to get people up and running quickly, and an API that allows for more advanced extensions without as many headaches.
The next generation API code will be well documented with PHPDoc (assuming everyone is cool with that), and I hope that we can have a section of the codex where the auto generated documentation for each release can be accessed for easy reference. Once the code is documented it will be much easier to recruit people to contribute to the BuddyPress codex.
I think it is going to be hard to distinguish where the definition of the project ends, and the marketing of the project begins. There is a lot of terminology out there. Some is real, some is hype. I think most people are smart enough to look past the slogan and see the product. I don’t have a problem with using the terms “social network,” and “community” interchangeably. There is a subtle difference, but I think its possible to make BuddyPress a good foundation for both types of projects. In the end we all benefit by having a larger user base.
I definitely am thinking along the same lines as you when it comes to reducing the amount of coupling between components. Over time I would like to see a shift where components are only interacting with each other’s APIs or through the core API, instead of so much overlap. I think a lot of this will happen naturally as we refactor out the duplicate functionality and move it higher up the chain. I am a huge fan of “coding to an interface.” This is a challenge while having to support PHP4, but I think we can still make large strides towards a decoupled approach.
Thanks for all of the comments everyone! Keep them coming.
That is good news!
Highest Rated = highest average vote
Most Votes = highest total votes
@dennis_h
Thanks for the report. I will try to see what the conflict is.
@markpea makes a good point about the wording of the question. Don’t be afraid to comment on where you see BuddyPress going from your perspective.
As far as who is going to lead the process, I was brought on as a core developer primarily to make contributions to the API. The software is a community project however, so I am not going to do any leading. I am going to make contributions in the hopes that they are widely approved of and accepted by the community.
If you have tested 0.4-beta please post on this thread even if you haven’t encountered any bugs!
Click on the share button in the link listing and select the “Group” radio, then pick a group from the list.
Please post again once you have tried 0.4-beta. I don’t want to clutter this thread with 0.3.x support.
Regarding changing the slug, it is not recommended because I have not received any feedback on how well it works. If you are willing to test it and give feedback that would be great!
No activity stream attachments until we can integrate something into the core (1.4 or later).
The API parses the remote HTML file and sorts all of the images it finds in order of priority, jpgs, then pngs, then gifs.
Right now the remote image size must be between 2048 and 51200 bytes (checked with a HEAD request).
If the images are not in that range, or their site’s server has some kind of anti-hotlinking blocking, or if the image’s server does not support a HEAD request, then they will not show up in the thumb picker.
The API will attempt a HEAD request on up to 24 images, and will stop once it has found 12 images that allow a remote referrer, and are within the byte range (above).
If you have any ideas to improve on this algorithm, let me know
i think this is the wrong thread to ask that question
I need some feedback from you guys on activity attachments.
I have spent quite a bit of time working on the API for attaching content to activity items, and near the end here I am really struggling to make it work without modifying the core. The right way to do this is to integrate my API into the core starting with 1.4. Of course that is probably months away from release, which is a short term bummer.
Do you guys want me to release 0.4 with all of the group integration and re-link features now? I really wanted to get activity attachments in there, but like I said its proving to be difficult and time consuming to make it work as a plugin.
I am testing against the 1.2 branch. You should maybe try clearing your browser cache in case the old JS is still loading.
Group links is already done and working in the development version.
Still unsure if I should add this tag to my plugin header. Shouldn’t it be up to the site admin to decide how the plugin is activated?
Just a heads up that I am still working on 0.4. I have been chipping away at it over the past few weeks. I can’t give an ETA, but just wanted you all to know that this plugin is still being actively developed. I am currently putting in about 10 hours a week into it.
0.4 is going to melt your heads.
Shortcodes are for embedding in posts, did you mean template tag?
Here is the code that “should” work to do what you want, but I have not tested it.
<?php
if ( bp_has_links( array( 'newest', 'per_page' => 3, 'category' => $your_category_id ) ) ) {
while ( bp_links() ) {
bp_the_link();
// you will need to output your custom HTML here based on
// what you need from links-loop-item.php
}
}
?>@stwc, foxly
That defect was fixed in the 0.3 branch a while back, I just haven’t put out a point release yet.
https://plugins.trac.wordpress.org/changeset/215107/buddypress-links/branches
Are you guys able to duplicate these issues on a clean install of BP w/ default theme active with BP-Links and no other plugins?
I have spent so many hours chasing down problems only to find out it was due to a plugin conflict or custom theme issue, I am pretty paranoid about it.
I am going to try to get a 0.4 beta out this week with that functionality.
@agrunder
Before I release 0.4 I am going to do a lot of WP single testing. Support for that is still in its infancy.
You can change that with the filter ‘bp_get_link_userlink’
That function is just a wrapper for bp_core_get_userlink() so you could instead use the ‘bp_core_get_userlink’ filter to change the behavior of user links install wide.
@agrunder
I have added the feeds idea to my list of requests. If I get a bunch of requests I will consider adding that feature.
Link avatars are already stored in a separate directory under wp-content/blogs.dir/files/link-avatars. I wonder if maybe this is not the case for single WP? I still need to do a bunch more testing.
The thumbnails that are uploaded are handled very much like the other BuddyPress avatars, and nearly all of the functionality for handling them is re-used as far as code goes. Right now the original “should” be getting resized down to 450×450 on upload, and then a copy down to 150×150 and 50×50 after the crop. All of these dimensions are determined by BP constants.
The thumbs are scaled down via CSS depending on the situation. For instance the 50×50 is used exactly as is.
I have not received much feedback at all regarding real world spam issues with Links, but I know eventually there will be a problem. I want to wait to tackle spam when there are real world use-cases to solve, not hypothetical ones.
What you described is very similar to Digg, and I think would be a cool feature, but maybe not to handle spam. I have planned from the beginning to allow users to set a threshold for negative rated links that would prevent them from showing up, for instance anything rated -5 or lower, don’t show me. The admin could set the default value.
Thanks for taking the time to submit some valuable feedback.