Message of the day:
Welcome to SilverStripe | Current stable: https://goo.gl/C4F1T9 | Feature requests: https://goo.gl/EcQ34L | Community Forum: https://forum.silverstripe.org | StripeCon EU 2019! https://stripecon.eu
If you have any SilverStripe related questions, please supply the version of Framework you're using.
Did you flush? 🚽 =
Permissions are controlled separately to Members.
All people that can sign in, are members of some type. All members are people that can sign in. They sign in through the log in form. The log in form (by default) references the built in Member object. The built in Member object thus must reference all members. PERMISSIONS are what you are worried about - authorisation is something complimentary but very separate to authentication.
I'll try to frame it differently :)
Am I being too cautious?
(give you the trots)
What's everyone's experence with using the Member class for handling Frontend users? As opposed to a separate class. Something about Frontend members (public) being inside the same collection of objects as CMS users separated by one field gives me the trots.
And another SS2 site was switched off after an update to SS4 👯♂️
who had this idea to put "previous" and "next" strings in css's content property... That's not the way to make it easily translatable
Where? Which module?
custom code on a project where I "just" added fluent for i18n