David Levine

Thanks for the response @mikes41720 !

To my knowledge, most nags in Yoast SEO are both less jarring (e.g. the redirect nag) and dismiss-able for a time (e.g. the nag on update).

This new one is huge, and keeps coming back every single time. On mobile, it takes up literally half the screen.

Surely there is a way to make it less obtrusive and bring it in line with the other upgrade nags you use throughout the plugin!

I have to look into the GDPR plugin a bit more.
On one hand, I am a fan of DRY and if there’s a plugin that already handles 99% of what’s needed then theres no reason for yall to duplicate the functionality. On the other, the only time I collect private info is either via registration/profile edits (which 4.9.6 on its own seems to cover) and via Social Login, so (without having actually tested it yet) installing another plugin seems a bit like overkill.
Will spin up a dev with the plugin this week.

Re the mockup itself:
“Simple Register”:
The way the button is loaded, it seems that the two checkboxes only apply to WP register and not Social Login. If that’s the case, we still need a disclaimer (By logging in you agree to our Privacy Policy); if its not the case, then the Social Login button needs to be hooked in a way that those checkboxes still apply.

“Register with consents”:
Putting aside that GDPR does not require explicit consent for agreeing to the Privacy Policy, if there is a ‘required consent’, than it should be marked as required on the consent popup (and perhaps disable out the register button until the required items are selected).
Also noted that you switched the consent to a simple checkbox instead of a yes/no selector per item, despite your comments above about the efficacy of using checkboxes. Not the biggest deal – and if its coded like the rest of the plugin, then Im hoping itl be easily changeable with a template hook.

PS: Im still not a fan of checkboxes before the register (Be it the 4.9.6. default functionality or for nextend).

Really exciting news ??
Keep up the amazing work @sc0ttkclark (on both plugins)!

As a total aside (perhaps I should open a new topic), I use TEC on the nonprofit license, and the plug-in has literally changed everything about how we empower our community. Beyond leaving feedback on ideas, and a kudos on our calendar page, are theres other ways for us to give back – e.g. prs to the GitHub, and if so what’s the best way to get started?

@nextendweb
Just want to stress again how grateful I am for this dialogue and your desire to gather feedback ??

I think the consent screen should appear after the oauth authorization to prevent consent-nag at the login flow. (There is no way to know who is the user if she/he does not authorize at Facebook.)

So you answered your own question about the flow. It needs to be Login button -> oauth screen (that lists all the possible data that the user might consent to -> consent dialogue -> success (and only the data that the user consented to or is required by the TOS is saved to the usermeta).

Your mockup states that all consent must be accepted, but as far as I know you can not force freely given consent. You must allow people to continue without giving you consent on that part.

Just to clarify myself on this point:
There are two types of data were receiving from FB, data that requires explicit consent and data that doesn’t.
For data that doesn’t require consent it needs to be in the ToS, and the TOS needs to be agreed to upon login (doesn’t need a check box, but rather ‘by logging in you are agreeing to’ is enough).
For data that requires consent, it shouldn’t be ‘all or nothing’ but granular with justification for each data item.

Regarding my example which used a required field: you must allow the user to continue to use the site even if explicit isn’t granted, but not necessarily give them the ability to use social login. However, since the data item requires explicit consent, it needs to be agreed to, and not included in the TOS.
As imo a checkbox before the login button seems out of place, I gave an example on how it should be handled within the use of a consent screen. This is advanced usage of GDPR, and there’s no requirement that Nexend provides this functionality; but if you were to that’s how I believe it should be handled.

Somewhere I saw several consent screen examples and checkbox was the worst and the best was Yes/no option where the user must decide whether to give or not give consent.

Wholly valid point ?? My fault for the hastily-made mockup.
Just keep in mind that that radios should be for each data item, and that ‘disagree’ shouldn’t be used as a button option on the bottom of the dialogue, because it’s unclear to the user that they continue to the use the site if they do disagree to giving consent (my point above about requiring consent for a specific data item notwithstanding).

Looking forward to the next iteration of mockups, and some other voices in the convo ??

Re rescinding consent, looking at the 4.9.6 beta the tools are already there.
This one shows the ToS, so the user needs to edit it to specifically point to the privacy policy (either through nextend or on their own), and you just need to style the plugin so its clear the notice applies to both the form and the social login button.
this is for making sure anything nextend saves is exportable by the user,
and these filters will let users rescind consent.
Should be enough to tap into these tools (I hope).

This mockup for Registration/Login is less pretty than yours (done via a webapp on my phone), but I think it gets the point across:
https://imgur.com/ZMwtPgu

@nextendweb.
Stupid me – I was on mobile, and tried zooming manually.
From my comuter:

Register Flow:
So as I said above, you need to prominently display a link to the TOS before the login, so it changes/combines part of your flow. You need to separate out what requires consent and what doesnt, and what you’re using the consent for.
The flow becomes
Step 1: Login form. Same style as #1, except no need for a checkbox, and instead its a “By Logging in with facebook you are agreeing to our <link ToS />“.
Step 2+3: Explicit Consent + Facebook. I’m kind of leaning towards the FB Login followed by the Site Consent (#3) because that way you’re stilling getting the data required to use your site, instead of potentially scaring them away altogether by asking for consent.
This is definitely true if you plan to provide granular consent for each ‘justification’ as recommended by the GDPR, but just as valid if you’re getting a scarebox of agreement tos.

Regardless, disagreeing should NOT take you back to the login, you are more than allowed to gather social data for contractual reasons (which dont require optin), and only optin to additional non-primary data purposes.

Login Flow
You do not need to request new consent (or contractual agreement), if users have already granted consent or logged in and therefore accepted the TOS, so a lot of this is redundant.
Also, am I not mistaken, or can’t new users be created via the “login” as well, if they dont currently exist?

IF: the login is only for existing users, then #3 is enough, and the FB permission request only appears if they revoked permissions ONLY on facebook.
If its for both new and existing users, then its what I about the register flow:
Step 1: Have a disclaimer “by agreeing to…” above the link. If its an existing user, then follow the rest of the flow for #3 with only a FB prompt when necessary, and if its a new user, then continue Steps 2 + 3 of the register flow (my comments above).

Link Accounts
By being a user, theyve already agreed to the site’s TOS (assuming it was displayed on non-NextEnd register form, which it is required to law), so Im pretty sure you dont need to link to it here. Again, Im not a lawyer, so Im not sure about this point.
As for a popup vs a checkbox for the *data that requires consent*, I’m honestly torn.
On one side, theyre already on the page that allows them to edit/define information, so checkboxes do seem like a more natural fit (plus you get rid of the extra screen).
On the other side, there is something to be said about flow consistency. And, as a site owner, I do like the idea of forcing them to make a decision about whether to give consent or not, but I’m not sure if that’s worth the cost to the user.

@nextendweb

First off – wow, really happy to see you’re taking serious steps for this and gathering feedback.

Bearing in mind I’m not a lawyer, and as such an only relating what I was told by mine:

1. You only need ‘explicit consent’ when using the data is not for ‘contractual obligations’. E.g. you can use their email to send purchase receipts but not marketing emails, their name if they are logging in to use a forum, etc.
2. You need explicit consent for each piece of information you’re requesting.
3. You need to prominently display the site terms they’re agreeing to by using ur services contractually, and get their consent before you save any of their information.

The imgurs are blurry in that it’s hard for me to tell which things are happening in the different parts of the flow, but responding to your original questions:

1. There are two things that need to happen. First a notice on top of the login button: ‘By signing in you are agreeing to (ToC link)’. That covers any of the information you’re requesting from social that you’re using to provide your service. In the ToC the site author has to list each thing they’re requesting and why it’s needed to provide the service.
Next, you need to request consent for every nonconsentual thing. Legally I’m not sure if this needs to be before the request to the oAuth or after the data is return but before it’s saved to your database. My personal opinion is that its weird for FB to list a bunch of fields the user approves, and only after you ask if you can use them vs FB just listing the agreed to fields, but what do I know.
Regardless, the ideal (from both a legal and user POV) is that each data item is listed with a separate checkbox including both what is being requested and why. E.g. ‘I agree for you to use my profile picture when displaying comments’ or ‘I want my birthday do be displayed on my profile page’ or ‘Use my email to send me marketing messages and site comments’.
In other words, the plug-in should let you choose a data item to request from the oAuth, whether consent is required for the specific item, and an optin to be displayed if so.

Regarding revoking consent, I’ve yet to take a look at the new tools in the 4.9.6 beta.
It’s the site owners responsibility to delete all data associated with the revoked request, but assuming that WP itself is going to handle these, all you guys would need to do is hook into the display of what items they can withdraw consent from, change the permissions so the info isn’t resynced on the next login, and use the wpfunxtion to delete the metadafield that item is associated with.

Thanks for the quick reply @erishel !

Did what you suggested. Link is here https://tribe.uservoice.com/forums/195723-feature-ideas/suggestions/34097266-speed-up-tec-and-improve-scalability-by-migrating

• This reply was modified 6 years, 11 months ago by David Levine.

bump!

Update: Some creative searching on the Tribe Forums found me this snippet for a shortcode of all used events/venues on the site.
I then did a mysql query of wp_postmeta for all the _EventOrganizerIDs and _EventVenueIDs (this kb article for list of TEC postmeta fields), that were NOT LIKE the huge list of values that were output from the above shortcode.

Scrolling through the backend so far, and it seemed to fix the current broken events, but it wont do anything to prevent this from happening again.

Thanks for the reply Geoff!

It happens both with the built-in Paypal and both WooThemes and Angelleye’s Paypal plugins in a normal flow, and with all other built-in gateways if you programmatically wc_create_order on a non-ticket.

Keep up the amazing work – your plugin has had a huge impact on our local community, and if there’s ever a way for us to contribute back (in addition to proudly displaying the ModernTribe logo on our site), I’m sure Im not the only volunteer coder who’d love to help out!

[Marking as resolved]

I see a few ways to handle it:
1. Use the WordPress defaults.
2. Find the classes with get_intermediate_image_sizes()
3. Let the user type in the new image_class manually.

PS: u have a donation link?

I’d suggest making sure you don’t have anything in the textbox at wp-admin > Events > Settings > Licenses > Event Aggregator

You mean to say I *shouldnt* be using my Event Aggregator license?

Hey – Yep, even with 4.3.2 I’m stil; getting the same message…