[buddypress-trac] [BuddyPress Trac] #6095: Define behavior for group status
buddypress-trac
noreply at wordpress.org
Wed Jan 21 15:48:35 UTC 2015
#6095: Define behavior for group status
------------------------------------+-----------------------------
Reporter: tandreatta | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Groups | Version: 2.1
Severity: normal | Resolution:
Keywords: has-patch dev-feedback |
------------------------------------+-----------------------------
Comment (by boonebgorges):
I think that individual properties like this on `BP_Groups_Group` objects
is a clunky approach. We should store these properties on the group type
objects instead, and fetch them from there dynamically. I do like the idea
of having `BP_Groups_Group` methods for getting the information, but we
probably can't rely on this for a first pass, because we don't use real
`BP_Groups_Group` objects everywhere. Notably, in a `bp_has_groups()`
loop, the returned objects are *not* proper group objects. We can and
should fix this, but it's probably a bigger task than is necessary to get
the basic functionality in place here.
>> Running status names through ucfirst() will not work as a general
solution.
>
> But it works for defaults (public, private, hidden). And there are
filters. And there is translation support.
Not all languages use `ucfirst()`-type capitalization in the way that we
do. It won't be the case in all languages that the internal label will be
a meaningful label. The internal keys for the group types should *not* be
translatable - they're stored in the database, and should be persistent
and reliably the same from the point of view of the code. Etc. But these
are implementation details that can wait until we have a better sense of
what we want the group type API to look like.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6095#comment:9>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list