Skip to:
Content
Pages
Categories
Search
Top
Bottom

Forum Replies Created

Viewing 25 replies - 1 through 25 (of 174 total)
  • @dwenaus

    Participant

    I experienced this exact same problem on a site I recently upgraded from an older version of buddypress/bbpress. Private group replies were available in users’ activity stream to non-logged in users even. I turned off all plugins with no affect.

    @dwenaus

    Participant

    this page https://codex.buddypress.org/releases/1-5-plugin-compatibility/ is out of date, and my plugin BuddyPress Rate Forum Posts is compatible. the above page was tested on an older version. How can I update that list?

    @dwenaus

    Participant

    my plugin https://wordpress.org/extend/plugins/buddypress-rate-forum-posts/ is compatible and has been for a while now. The version they tested on this page https://codex.buddypress.org/releases/1-5-plugin-compatibility/ was an out of date version. how can this be rested and updated?

    @dwenaus

    Participant

    @josemv thanks. Yes, my plugin can rate anything, so posts of course. But it’s not been launched yet. I’m looking for someone who wants it for their site so I can tidy it up for final release. it’s 95% there.

    @dwenaus

    Participant

    Looks pretty cool!

    @dwenaus

    Participant

    hmm. I guess no one wants this anymore!

    @dwenaus

    Participant

    Heads up: the combined plugin in underway, and will actually be a very powerful plugin where users can vote/rate/like ANYTHING in wordpress and buddypress. I’m developing this for another client, who is paying for the core functionality to vote on images, and they don’t need all the fancy stuff that usually comes in a plugin, such as nice admin options, translation, hooks, filters, etc. They also don’t need to vote groups, forum posts, blog posts, custom post types, blog comments, activity items, etc. With donations I’m also going to write scripts to convert old plugin data to the new plugin, same with group reviews plugin.

    If people in the community would like these things, then please make a donation so i can do the extra work and release it properly to the community as an excellent, flexible, extensible, strong plugin. If not donations come it, it will just be for rating images using BP Albums. Even small donations count, so don’t be shy. Paypal donations to deryk@bluemandala.com. I will include all donors in the plugin read me, so please mention any website you’d like me to link to.

    To be clear, this plugin is happening 100%, it is already being built. All donations go to the things the community needs that the client does not, as mentioned above. So don’t worry about making a donation and it not being released. :)

    And as a perk, I’ll email early versions to anyone who makes a donation. (if any of this is getting unethical from an open source standpoint, please let me know!)

    @dwenaus

    Participant

    @imjscn it won’t be a beast, it will be … poetry :)

    and in case anyone else is reading this thread in the future regarding the in-depth discussion about using db tables or not, I wanted to mention one thing I learned.

    You can insert or update the wordpress database – existing tables or your own – using nice built in class functions. for example:

    `
    $wpdb->mytable = $wpdb->base_prefix . ‘mytable’;
    $values = array(
    ‘col1’ => $myval1,
    ‘col2’ => $myval2,
    );
    $wpdb->insert($wpdb->mytable, $values);
    `
    doing things this way, you gain all the security features of the wordpress database class, and don’t have to work about preparing or escaping the query. it’s done for you. $wpdb->update also exists. more here: https://codex.wordpress.org/Function_Reference/wpdb_Class

    @dwenaus

    Participant

    Update: I took the approach of using my own db tables. and so far very smooth sailing. Once I got the hang of setting up db tables and handled db schema updates, everything is crystal clear and easy to work with. I’m glad I took both routes. and for any future custom content I will definitely use custom post types and taxonomies, but for this kind of specialized functionality that is not really content, custom db tables is much cleaner in my opinion. (Perhaps a hybrid approach is sometimes the best approach, it all depends.)

    @imjscn the plugin will probably only handle activity comments as a whole. You will be able to like, rate or vote on them (or all three at the same time!). I’ll add hooks and filters in the plugin so you could probably limit rating for activity comments on your special custom post type.

    @dwenaus

    Participant

    I think the plugin will be called Rate Vote Like Anything. And I’m building it with those three systems in mind:
    Rate: you can rate things 1 to 5 (or whatever scale)
    Vote: you can vote thumbs up or down (1 or -1)
    Like: you can like something

    So it probably will work to replace other voting systems. I’m going to take your advice and do my best to include an API so that others can use the plugin for any type of content. I’m going to replace my other BuddyPress Rate Forum Posts plugin. Tens of twenties of people (!) have asked me to extend my other plugin to rate blog posts and comments, so this new system will do it.

    And as far as group rating is concerned, I’ve already built the star rating aspect for another site. you can see it in action here http://www.fashionsalade.com/2011/02/street-people/my-icons/rebeca/ (you need to login via facebook first).

    The major benefit of this new plugin is that it will have shared ‘karma’ from all the items you create. Some people will want this, others might not. But it’s a cool feature that I really like. Site admins can also decide which items will be karmable (i think i just made a word up).

    I’m also not making it BP dependant, Although I’m guessing it will mainly be used on BP sites, as wordpress already has things like GD post ratings – but that plugin is a beast.

    After suffering most of yesterday while stretching custom post types to do my bidding, I’ve decided to create new tables today. and now i’m at peace :D However it was a great exercise to do, and I got to dig into wordpress core much more than I normally do, which is always fruitful. Thanks so much for your encouragement.

    @dwenaus

    Participant

    storing meta data in an array is good for simplicity, but it fails when I want to do any type of query on that data.

    Boone, Good points about the date I can use those. And what you say about the back up makes sense too – it goes both ways, it will bloat the table AND it will definitely get backed up.

    Thanks for listing the hidden things that you get when you use the custom post type api. When dealing with custom *content* I think they are all very relevant (such as you wiki plugin). However when dealing with meta content such as Ratings and Likes, it breaks down a bit.
    – Yes caching is nice, but I can deal with that using the wp’s nice caching functions, I will loose out on other fancy caching methods, but its good enough.
    – I believe I will already get proper query escaping because I’ll be using the $wpdb class and prepare the query accordingly.
    – different database setups – very good point, no argument here
    – post revisions, I have no need for this, in fact I have no need for title, content or excerpt which causing wp_insert_post to fail, so I need to artificially create a title just to be able to post. this makes me think I’m abusing the system rather than using it.
    – I have no need to loop through this rating meta data.

    While it is almost always a good idea to use the built in APIs for all the reasons you outline and more, sometimes it is not. I think there are some rarer cases when using the API is a hindrance. It’s kind of like someone using wordpress to build a gigantic e-commerce store – sure you can do it – but maybe you should have started with magento instead. I feel that my plugin is in the middle and could go either way.

    This exchange has been quite fruitful, thank you for the great discussion.

    @dwenaus

    Participant

    i’m going down the road of custom post types and taxonomies with reservations. i’m coding it now, and while it’s strange, it will work.

    My one concern is this: ratings on various posts, groups, photos are not really content, rather it is meta content, so storing each rating as a custom post seems a bit weird. It is going to bloat the posts table, which will affect people backing up.

    Yes it will be good for caching for plugins that cache the posts, but that is about the only benefit I can see. The actual coding of the plugin is MORE complex because of using custom post types and taxonomies. For example, things like dates inserted as a custom field will work, but not as elegantly as in mysql.

    Food for thought.

    @dwenaus

    Participant

    the cause of the error is either the readme file Tested up to: line or the main plugin file Version: line. If you put any BP version info in there, this website balks and throws that error. It seems to only effect plugin authors that are being extra helpful putting BP version info in their plugins, so it should be removed.

    @dwenaus

    Participant

    Boone, The images i’m talking about are from the BP Albums+ plugin (which soon will be upgraded to the gigantic BP Media plugin) which as no meta table for album photos.

    If all you wanted was Average ratings across all objects, then another custom post type would be fine. but what i really want is total or average ratings for each single item (post, group, bp album image, forum post).

    maybe a hybrid approach would work. For those objects that have a meta table, use that (groups, posts, users, etc.). And for those objects that don’t (bp album images) maybe create a ‘shadow’ custom post for each item.

    yes, you are right, I should not be calculating this on the fly, although I it would be so much simpler if mysql did it on the fly using COUNT!

    @dwenaus

    Participant

    @djpaul and @boonebgorges, I hear you about the caching. that is one big bonus. I can make big ugly queries and know that they’ll be cached. If I ‘roll by own’ then I’ll have to build caching myself (but it’s not that hard).

    I looked at the meta_query functions, and they seem quite sufficient for most queries, they only thing they are missing are the powerful mysql abilities such as GROUP BY, COUNT, DISTINCT, and mysql’s cryptic but powerful date range functions. Much of this can be done in php with more flexibility, but sometimes it’s nice to do a single query and get exactly what you want.

    The most common need for this plugin, is to display the combined vote/rating/likes of a content object. I can pretty easily figure out how to do that with MySQL, but how to do it quickly with custom post types/taxonomies?

    For example, i’m looking at a list of images, and I want to see the ratings of each image. I can’t really store it in my new rating custom post type, do I store it in some site option? seems kinda odd, or do I create a new custom post type – one for each object type – seems kinda odd, or do I use taxonomies. Or do I store it in the meta table of that individual object such as post_meta, group_meta. etc. this will not scale well because some objects have no meta table (such as images).

    any insights into these things would be greatly appreciated.

    @dwenaus

    Participant

    @djpaul oh boy – I was hoping you wouldn’t say that! ;) Can you tell me why you are re-writing it, and if you’ve started any difficulties you’ve encountered.

    Here is my initial db scheme with examples (initially visualized as a mysql table)
    rating_id – auto-generated
    object_id – id of object being rated. ie. post_id, group_id, bp_album image id, forum_post_id
    object_type – type of thing beind rated. ie. group, blog post, album image, forum post
    rater_user_id – the user_id of the person doing the rating (need to be logged in)
    owner_user_id – the user id of the person who ‘owns’ the object being rated
    rate_type – either ‘like’, ‘vote’ or ‘rate’.
    rate_value – value of rating/like/vote. Like can only be ‘like’, vote is 1 or -1, rate can be range from 1 to 5.
    date_rated

    maybe I’m being too flexible with the different rate types and I should just stick to one type, such as Facebook style ‘Like’. but then that leaves out a lot of functionality for amazon and app store style ratings. it would be nice if these were consolidated in one area, but maybe too ambitious.

    Looking again at custom post types/taxonomies I can see how the custom post type will be an individual rating, and the owner of that custom post type will be the rater. I can add a custom field for the user id of the object owner. It looks like the object_type would be a custom taxonomy, and the id of the object rated would be another custom field. The value of the rating could either be a custom field or maybe a taxonomy.

    Should I be connecting up the object being rated or the object owner using custom taxonomies? if yes, then I’m having trouble visualizing that.

    thanks!

    @dwenaus

    Participant

    Boone, thanks for the feedback.

    I’m still a bit hesitant to use custom post types. Maybe the query powers are good enough but in some cases where I want to get meta information about all ratings, won’t I run into problems when my data is separated into the posts table and the posts_meta table. I’ll have to do some complex joins and what not. But if I make a custom DB table, I can just use GROUP BY or DISTINCT to get what i need quite quickly. I’m thinking of stuff like Highest Rated XYZ or Most Rated ABC. These things won’t fit so well into the custom post type/custom taxonomy mould. Any more thoughts on this?

    @djpaul – I see in your (totally awesome) achievements plugin, that you use a few custom db tables. Do you have any thing to add regarding your choices. I’m thinking this ‘Rate everything’ is more akin to that plugin.

    Also, I’m thinking this plugin will be a bit more like Facebook ‘Like’ than an actual star Rating. but we’ll see what comes out in the end.

    @dwenaus

    Participant

    the problem is that the script i wrote for BOW required that I branch the initial plugin. In order to get the blog comments to work, the settings needed to be saved in a multi-site format. Since then I’ve updated and improved the main plugin (without blog comments). It would take some work to re-integrate this code and provide an upgrade path to existing users so they would not lose their old rating/karma data. For this reason I don’t want to release the plugin I made for BOW. however he is free to pass it around if he likes. the best solution would be for someone else to invest in this re-integration. I could also put it up on github, but again, i don’t want to have two similar yet separate plugins in the wild. maybe I’m being to cautious. anyway.

    @dwenaus

    Participant

    following up on John David Smith’s comment. It seems that his bbpress folder went missing during the upgrade to WP 3.1 and then BP 1.2.8. Very strange. I uploaded the folder again to where it belongs and went through the manual install and it was fine.

    @dwenaus

    Participant

    @davidhund this project is going forward as we speak, Boone is working on it today even. Any donations are welcome, and will certainly speed up development.

    @dwenaus

    Participant

    thanks :) I guess I’ll delete my bug report.

    @dwenaus

    Participant

    I eventually built a plugin that allow people to rate forum posts: https://wordpress.org/extend/plugins/buddypress-rate-forum-posts/

    @dwenaus

    Participant

    @babelsheep yes this is possible and a good idea for a plugin. However If all you need is a job board and you don’t need social networking then I believe there are wordpress plugins that do this well.https://wordpress.org/extend/plugins/job-manager/ is one choice but there are others.

    @dwenaus

    Participant

    Thanks for the feedback. Are there any other people interested in being sponsors for this plugin? @finni3 it would be similar to the BP wiki plugin in functionality, however it would actually work. And it would be rock solid so that no users’ data is lost (which is the great downfall of the wiki plugin). Also, you could comment on pages as well as edit them. @Bpisimone it would be possible to have a global directory, but probably not in the first round – but it would not be hard to do.

    @dwenaus

    Participant

    Thanks every for the feedback. If there are any more supporters please post. @nit3watch – as a rule I try to never change the plugin code. Either I use css to tweak what I want or ask the authors to put in actions or filters. It just saves so much time in the end and you never have to worry about updates ruining your site. my 2 cents.

Viewing 25 replies - 1 through 25 (of 174 total)
Skip to toolbar