Skip to:
Content
Pages
Categories
Search
Top
Bottom

Guys….. What is the point of including filters if…

  • Avatar of alealealeo
    alealealeo
    Participant

    @alealealeo

    BuddyPress provides code filters (apply_filters) to override various things, and they are great. However, they only apply to new things that happen in the system, if you have months of BuddyPress statuses, groups, etc, any new filter overrides you add aren’t applied to them as everything is stored in the database as static HTML… Even if you change languages on your site, any existing status/group update/etc strings remain in English forever!!

    Surely this can’t be right? Defeats the entire purpose/flexibility of filters!

    Can you at LEAST regenerate the statuses or similar to update everything with the new filters?

    I was tearing my hair out for hours trying to understand why add_filter wasn’t working! Really, really, really, really frustrating stuff….

    Thanks in advance for any tips on this big problem!

Viewing 11 replies - 1 through 11 (of 11 total)
  • Avatar of @mercime
    @mercime
    Keymaster

    @mercime

    @alealealeo suggestion: file new ticket at http://buddypress.trac.wordpress.org/
    log in using WP username and password.

    Avatar of alealealeo
    alealealeo
    Participant

    @alealealeo

    But strictly speaking, it doesn’t seem like a bug, it seems like it was intentional way of working.

    Can a BuddyPress staff member confirm there is nothing we can do about this in the current version? Is there any way to rebuild or regenerate the data to use filters/code alterations?

    When you save activity data to the database, surely the “translatable/filterable/variable” parts of strings (such as “X posted an update”, etc) wouldn’t be included and would be put together using functions?

    The way it is now (and without being able to rebuild) customizing the plugin seems strictly limited by nature.

    everything is stored in the database as static HTML

    Wrong. What specifically are you looking at? The Activity table?

    Avatar of alealealeo
    alealealeo
    Participant

    @alealealeo

    Hi Paul,

    Oh you are right, I didn’t word my original message properly, I was referring 100% to the activity messages, they seem to be fully stored in the database.

    Do you know if there is a way around this problem?

    Avatar of Henry
    Henry
    Participant

    @henrywright-1

    @alealealeo this only applies to activity stream items. Think of it as a snapshot of what happened at that point in time – text strings are written to the database. When querying the database, that info isn’t going to change – regardless of any filters or translations you’ve set up.

    Avatar of shanebpdev
    shanebp
    Participant

    @shanebp

    @henrywright-1

    The OP is mixing 2 ideas.

    1. He complains that filters on saving data aren’t retro-active.
    2. He wants the activity strings to be built dynamically instead of hardcoded into the database.

    Re 1 – I don’t know of any filter on save that will handle prior existing data. The very idea is unworkable. Instead use a filter on the display. That is inefficient but will handle prior data.

    Re 2 – That would require a major re-write of the activities code. Building dynamic strings would have some advantages – but speed is not one of them.

    Avatar of alealealeo
    alealealeo
    Participant

    @alealealeo

    @shanebp

    1- I do understand this, but if you change a filter and use it like that for a while, and then want to change it again, your existing data will stay unchanged. To me the solution is to not have a filter for things that won’t be able to be manipulated later on.

    2- Building dynamic strings may be ever so slightly slower, but it’s the reason I love WordPress – To have the power to easily and dynamically change data.

    The main reason I want to make changes to the code is because BuddyPress currently provides a specific way to output things, example:

    “Author Name posted an update in the group [group avatar] Group Name, 14 hours, 00 minutes ago”

    A: None of the links have a class set (except for the time) Meaning that I can’t add CSS to increase the size of “Author Name” without affecting “Group Name” and vice-versa. So I was trying to manipulate the filter to add a class.

    B: I want to change the order of the output, for example if I increase the size of the group avatar I would want to move it from where it is completely. Not very flexible for people who want to make the line work/look a certain way.

    Another example of this problem is the avatar sizes:

    If you define the avatar sizes, example:
    define ( 'BP_AVATAR_FULL_WIDTH', 300 );
    any avatars from activity/groups previously created will still use the old avatar size.
    So if you set it to 300, and then I want to change it in the future to 100 and change the design/CSS, all the existing activity will still show 300 and look bad with the new CSS.

    WordPress works this way to with image thumbnails, however, you can force a regeneration of them using a plugin.

    In short, I am finding that BuddyPress is a great plugin but it seems to me that for the activity (the most important aspect of the plugin) you are stuck into using/showing it how the BuddyPress developers decided was the best format/look, because changing it via filters will result in headaches if I install my custom filters on a site with existing BuddyPress data.

    If there were a way to regenerate the activity database to update everything with the filters/sizes set, that would solve most of the more obvious problems.

    Avatar of Henry
    Henry
    Participant

    @henrywright-1

    @shanebp – Re 2: dynamic strings would certainly have some advantages. I wouldn’t throw a tantrum if the core devs decided to develop something like this :)

    Avatar of @modemlooper
    @modemlooper
    Moderator

    @modemlooper

    There is a bit of discussion on this in a trac ticket http://buddypress.trac.wordpress.org/ticket/3856

    Avatar of alealealeo
    alealealeo
    Participant

    @alealealeo

    Thanks for the link, although I noticed it was opened 2 years ago and has been pushed over time until it has reached the 2.0 milestone, not too promising!

    But yes that is exactly what I was trying to find, and I didn’t even think of multi-language issues with the current code.

    At least now I fully understand exactly whats’ going on :)

    I figured you were referring to the Activity table :)

    Basically, we thought the way we do it now was a good solution several years ago. We were particularly concerned with how large the Activities DB table(s) might get, as we expect them (and probably still do) to be the tables with the largest amount of stored data as every other component adds stuff to the activity stream. If I remember correctly, the idea was that storing the entire string would be the quickest approach — and with the state of BuddyPress’ code base all those years ago, it was probably the right decision.

    Several years later, the shortcomings are now fairly obvious — can’t filter it easily, if you change how the string is constructed – only new items have that new format, the old items keep their old format, can’t translate it very easily.

    This is likely to be changed in a near-future release to a more dynamically constructed string of text, and the ticket @modemlooper linked to is a good place to keep an eye out if you’d like to help us build it.

Viewing 11 replies - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.