Message of the day:
Security release 4.4.4 is out. Changelog: https://github.com/silverstripe/silverstripe-framework/blob/4/docs/en/04_Changelogs/4.4.4.md
SilverStripe 4 related information and questions.
right now trying to figure out what this error message means:
[Deprecated] Non-static method SilverStripe\Control\Controller::redirect() should not be called statically
well, think I am slowly getting there, maybe!
Because if it comes to Security... that's all my work
What are you trying to figure out exactly?
Thanks @null & @Firesphere for the info. The reason I was asking was I was struggling to find a way to use the relationship “backwards” & all my google searching led to being told that the relationship should be set up in the “correct” direction in the first place - but obviously I can’t change the existing group/member relationship direction!!! 🤣 I eventually found a way around it so that part is working.
Now trying to wade my way through the
Security class to figure out how to do the rest, but so far its as clear as mud!!! 🤣
When it comes to Members & Groups, the many_many would be "A member belongs to a group", because that's how historically membership works. When it comes to other relations however, it's a decision up to the engineer building the site. e.g. do you feel an article belongs to a category, or do you feel a category belongs to an article? This distinction is quite opinionated and should not be taken too serious in the ways it's words mean in a literal sense.
Group/Member is ancient, spanning several versions of SilverStripe. Perhaps that's the "new" way of doing things. Regardless, it's only a suggestion or convention, not gospel. Develop in the way that makes sense to you and your users
Entirely possible the relation is set up in that way for historical reasons.
@Hels Well I guess you can say also though that the reverse is valid too. In the CMS, you can also create a new group and then add members to that new group
On the docs website (https://docs.silverstripe.org/en/4/developer_guides/model/relations/) it states:
- For instance, in a many_many of Product => Categories, the Product should contain the many_many, because it is much more likely that the user will select Categories for a Product than vice-versa.
but that is the opposite of member & group - according to github, Member belongs_many_many Group but in the cms we create a member and choose groups for them to belong to….