Easy-digital-downloads: EDD is not GDPR-compliant

[Shelob9]

I'm concerned about getting our site to be GDPR-compliant by May. Is there a timeline for GPDR compliance tools in EDD?

[pippinsplugins]

For U.S. companies see http://www.ibtimes.com/eus-gdpr-what-will-american-companies-have-do-comply-2573002

[pippinsplugins]

@Shelob9 this is high on my todo list to work on soon so we'll likely have updates soon.

[Shelob9]

@pippinsplugins There is time. I just started working on a plan for Caldera Forms. I wanted to make sure that EDD was working in it too as that's the other bug collector of data on our site besides analytics companies.

[davidsherlock]

@Shelob9, what is required to make EDD GPDR-compliant?

[scottbuscemi]

One part of GDPR is the ability for customers to delete their own data.

If this is to become a feature of EDD, I would hope that the actual transaction data wouldn't be deleted completely so reporting isn't goofed up. Perhaps a transaction would simply be attributed to an 'anonymous' customer?

[davidsherlock]

I can build this as a plugin, we would need to consider comments, reviews, front end submissions and commissions as well (assuming the “user” is a vendor).

Sent from my iPhone

On 28 Dec 2017, at 16:02, Scott Buscemi [e-mail] wrote:

One part of GDPR is the ability for customers to delete their own data.

If this is to become a feature of EDD, I would hope that the actual transaction data wouldn't be deleted completely so reporting isn't goofed up. Perhaps a transaction would simply be attributed to an 'anonymous' customer?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[mindctrl]

WooCommerce has some good info here: https://woocommerce.com/2017/12/gdpr-compliance-woocommerce/

[scottbuscemi]

I was surprised that their post didn’t include any information about any
changes they’ll be making to Woocommerce.

On Thu, Dec 28, 2017 at 9:52 AM John Parris [e-mail]
wrote:

WooCommerce has some good info here:
https://woocommerce.com/2017/12/gdpr-compliance-woocommerce/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/6216#issuecomment-354327903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEIs0DPQ9lGXRMEG3wCzu5LZxeGL0xglks5tE9V1gaJpZM4QviKu
.

[cklosowski]

This should probably be something maintained within EDD itself, I think a plugin would require many people to miss compliance. While it is a requirement for compliance, I'm curious if this would be something that all sites could benefit from.

We could include it (which would then easily allow extensions to remove their data via filters, etc), and allow store owners to enable the feature. Thoughts here @pippinsplugins on where it should live?

[pippinsplugins]

I am not entirely decided on this but I think I would prefer that this live within an add-on, actually.

I view GDPR the same way I view VAT, which we do not fully support in core.

If we add full support for GDPR then we should likewise add full support for VAT and other country / region specific laws (thinking of Germany here). When do we determine when and when not to support non-global regulations?

I suppose my main hesitation in adding GDPR specific features is "when does it stop?" conundrum?

At this time I'd like to propose that compliance features be built through a free add-on that we (EDD) put on an "officially approved" recommendation list. This would include creation of FAQs for it on our main documentation portal.

[cklosowski]

I think, with the reasoning above, I agree with @pippinsplugins actually. We would want to be able to work with whoever builds this (if it's not in-house) to be sure it works with all extensions that connect with customer data, so that we do not end up in a non-compliant state due to some extension data not being removed.

[mindctrl]

WP core has a GDPR initiative: https://make.wordpress.org/core/tag/gdpr-compliance/

[Basilakis]

@pippinsplugins @cklosowski Any update here?
The dates are really close right now :-)

[pippinsplugins]

@Basilakis No. We are closely watching what WordPress itself decides to do (see link above) and we'll then follow suit.

[cklosowski]

Right now I'd say we need to see what 'tools' the core team makes available to Plugin developers. There is a lot of talk around a couple solutions:
1) Creating a way to register certain data as private
2) A Request log, for site owners to work through.

I think one of the important things that EDD will have to monitor is compliance with other eCommerce data laws like VATMOS which requires keeping customer data for a timeframe, however, if that user requests to have their data anonymized/removed, what implications does that have for the store owner to remain compliant from an accounting/tax perspective?

Sounds like the Core team has some ideas moving forward on how to build out some of these 'audit' tools, and if possible I'd prefer that we simply hook into those, instead of building a whole new UI for it.

I'd for one think that we need to keep transactional data in place. If a user decides to request their data be scrubbed, I feel like we need to keep the payment record mostly in tact however some of the data is important for tax reporting for the business owner (like the billing address) , we could simply scrub the customer data to be anonymous, while still unique.

https://make.wordpress.org/core/2018/02/19/proposed-roadmap-tools-for-gdpr-compliance/

[RavanH]

I think one of the important things that EDD will have to monitor is compliance with other eCommerce data laws like VATMOS which requires keeping customer data for a timeframe, however, if that user requests to have their data anonymized/removed, what implications does that have for the store owner to remain compliant from an accounting/tax perspective?

The new GDPR law does not trump other EU laws like VATMOS. This means that even though personal data may be scrubbed, the transaction itself including billing address (or at least country?) must indeed remain in the database...

[cklosowski]

Thanks @RavanH! Appreciate that feedback. Do you have a reference for that? Just wanting something we can solidly share in our docs later if that comes into question.

[cklosowski]

Just updated the title of this, it was GPDR when in fact it's supposed to be GDPR

[katmoody]

Very interested in how this is progressing, as we use EDD with our BackUpWordPress plugin for Human Made and are working toward GDPR compliance overall. I was trying to pinpoint specific issues or things we would need to track for EDD to be compliant. Has work begun on the addon yet?

At this point, specifics already noted above include:

• ability for customers to delete their own data
• (for the site owner) knowledge of where the information itself is stored and server/database locations

[katmoody]

Has anyone else put together a full use of all EDD data that is collected for Audit purposes?

[cklosowski]

@katmoody We're looking into getting a documentation source available for what EDD stores. We're still awaiting some decisions from WP Core to see if they are going to offer us as plugin developers some tools for this, or if we're all going to have to roll this ourselves. I'll put something preliminary together early next week from the EDD side of things.

[katmoody]

Thank you @cklosowski - We're going through a full review of all our sites and an audit, and I needed to have all the personal data listed for that. As I complete the included EDD info, I will add or link to that list here for you guys, maybe it can be useful for others who are auditing their data as well.

It does look like WP Core is considering some hooks/filters that plugin developers can use but I've not gone through the Trac to see what has been done or planned specifically ;-)

So far, our audit has revealed the following personal data via EDD, though I'm still looking for anything that will in turn identify a customer or could be combined with other data to identify a customer. I'm not including data used for other plugins though some extension info is included by default (license key and transaction id is mapped to the payment processor for example).

• Full Name
• User ID
• Customer Email(s)
• Payment ID
• Billing Address
• License Key
• Site Url (license activated)
• IP Address (upon sale)
• Transaction ID (after sale)
• 'Send Product Updates' Update Emails
• Product Receipt (by email automatically, by PDF as requested)

The key factor in this audit is to determine what information we actually have, whether we need it and if so, for what legal purpose. As a reminder:

Lawful basis for processing

1. Consent
2. Necessary to perform contract
3. Necessary to comply with law
4. Necessary to protect vital interests of data subject
5. Necessary in the public interest
6. Necessary for our legitimate interests

From there, we have a spreadsheet to keep all the other information for each data type, like more specific info on why it's needed, who has access, what type of protection it has, etc.

Let me know if I've forgotten something specific!

[cklosowski]

@katmoody Some of this data, while unique is not identifiable to a user though. That's the major thing we've got to determine. We cannot, for instance, just remove a transaction ID from a gateway or a billing address (or some subsection of it) due to VATMOS, as that would possibly pull a site owner out of compliance for those taxation laws.

This is where it starts getting very conflicted/complex. Some of this data, I believe, has to be in tact (possibly made anonymous?) in order for stores to not break the law as well. Because of some of these things, a customer ID would have to remain (to an anonymous customer) so taxation and what not could be reported correctly if audited by the revenue enforcement.

I've started our internal doc for our team to review and start auditing. Once we have more we'll get something up publicly so we can move forward.

[JeroenSormani]

I currently got no resource to back any of the following up, but isn't the removal of data based on the 'right to be forgotten'?

If thats the case, wouldn't it be only for public data, allowing for orders to remain in tact as private data?

[cklosowski]

@JeroenSormani From what I can read on the official documentation page (https://gdpr-info.eu/), its' not just about 'public data' but about being able to 'profile' a person based off the data collected. That means while we may have to keep the payment history in tact including transaction IDs, items purchased, some billing address information for taxes, we can likely remove non-necessary data like the name, email address etc and make them anonymous as in while I can build a profile, I cannot tie that profile to a given individual because I now know nothing about who that person is, just that they are a generic 'record' with no means of contact.

I do have a concern/question that I thought about this morning and that has to do with financial institutions and disputes. For instance, PayPal can allow a dispute up to 180 days after purchase, but a right to request deletion has to be processed within 30 days of request...which means a user could purchase, request deletion and dispute within the valid timeframes.

The likely hood of winning a dispute is already low in some cases, but not having any data except the transaction ID could make that difficult. I'm still reading more into this but I'll keep posting my findings/questions once we have more info.

[katmoody]

My reading was that any data that could lead to the discovery of someone's identity. On the Transaction ID and such things, the only reason that they can currently lead to someone's identity is that they are all linked together. Removing the link back to the specific user would likely work, or anonymizing it?

The request to be deleted is just that, a request. If the data has to be kept for financial reasons (ie for VAT or tax filings) then my understanding is that the request can be denied for that reason as the other law overrides it. But I'm no lawyer and am just as confused as everyone else on a lot of the info I read.

[mindctrl]

Update from WP core: https://make.wordpress.org/core/2018/03/28/roadmap-tools-for-gdpr-compliance/

[cklosowski]

This is exactly how I read it...and my perspective on it as well :)

The request to be deleted is just that, a request. If the data has to be kept for financial reasons (ie for VAT or tax filings) then my understanding is that the request can be denied for that reason as the other law overrides it. But I'm no lawyer and am just as confused as everyone else on a lot of the info I read.

@katmoody Thanks for your feedback. I appreciate it greatly.

[lalunecreative]

I'm pretty concerned about this one ourselves, as we also do a lot of business over seas, both in digital downloads and in services and we're letting our lawyer audit our data to conform to GDPR and in general serve our customers better privacy policies, terms of agreements and transparency.

If you guys are having trouble distinguishing the international laws and what should be done/not done, especially in regards to "when does it stop" and what you should support or not then hiring a lawyer who specializes in these sorts of matters is probably the best idea. I'm certainly not leaving it up to me. Even I have a lot of trouble grasping all the minute details of GDPR, not including VAT or the EU's crazy cookies policy. Thankfully we don't apply to some of those as a U.S based company, and thankfully we have a lawyer that specializes in trademark, privacy and copyright laws.

That being said, if you'd like I can maybe advise you on whatever advice she gives me when we've completed our audit which of course is soon since the deadline is looming.

I know at least my main concern for EDD is either in core or a plugin ability is to give the user some form of opt in to delete their account on the account page, even if some notice displays that certain things like transaction history and such still remains. I imagine some sort of notice either as a shortcode or a popup would display explaining exactly what's kept and not kept in that instance. That's what makes the most sense to me anyway.

It's also likely the terms of agreement checkbox will have to be modified in some way as well or there will have to be a second one for privacy purposes. With GDPR you can't have a user agree to a privacy policy agreement if it's included with some other form of contract (i.e terms of agreement), they have to be separated under GDPR compliance.

Forgot that the user needs to be able to download their data generated by EDD as well.

Core's solutions for GDPR are pretty great, but if your site has the wordpress back-end closed off to users, then that data needs to be able to be accessed say from the EDD account shortcodes page.

So if Core adds the things they're wanting (ability to download user data, ability to delete accounts) etc that just needs to be accessed in a way that EDD users can get to it if the admin is closed off.

[d9media]

Yep, this is a big concern for us too. From my perspective, EDD has to make sure their software is compliant with EU law when EDD is available for purchase in the EU. Please keep us updated on the plans.

[Basilakis]

So the end question is

Are we going to wait for WordPress Core and if they fail, we have to pay tons of shitload money :)

[pippinsplugins]

We are working on EDD-specific solutions that will compliment WP core's but will also be independent of those.

We'll have updates soon.

[cklosowski]

How about some updates _now_ :)

I've been spending quite a bit of time looking at the plugins out there that do some of this work (outside of core, but we will support core when things are in a more stable state). Today I finished the first work on an addon for WP GDPR Core
https://wordpress.org/plugins/wp-gdpr-core/
https://github.com/WP-GDPR/wp-gdpr-core

This plugin WP GDPR Core supports a front end shortcode, which allows a person to submit their email address and in turn they get an email with an expiring link to view the data. We'll be adding our data inline to this report:

Here is our repo for the add-on for this plugin:
https://github.com/easydigitaldownloads/wp-gdpr-edd-addon

Working:

• Adding Customer data to the report.
• Adding Simple Shipping data to the report.
• Adding payments where the email address exists on the Billing Information.
• Adding payments attached to the customer record associated with the email.

To Do:

• Build out the CSV/JSON exports.
• Add inline editing where/if acceptable.
• Add deletion support where/if necessary.

This is actually my focus currently, so there will be more coming to this repository in the coming days.

[cklosowski]

As far as the concern for the 'privacy agreement' being decoupled from the purchase agreement (raised by @lalunecreative) we could easily add a way to detect either the build in WP Core privacy page or add a custom page the store owner can define much like the purchase agreement, and make a 2nd checkbox available.

That's a pretty small change on the EDD side of things for compliance there.

[katmoody]

Hey @cklosowski - great work - looks like a great start! Will sites need to allow access to customers or will this be handled only via that expiring link? We don't currently have access for purchasers available and I'm trying to figure out if we need to do that for easier access or not.

[Basilakis]

@cklosowski WPCore team should take a lesson, not to mention #WooCommerce team 🤣

[mindctrl]

Along with the numerous tickets and patches in progress in WP core, there's also this repo which is holding all the info gathered so far: https://github.com/gdpr-compliance/info

[lalunecreative]

@cklosowski Excellent work, EDD is definitely on the right track!

[cklosowski]

@katmoody with that solution above, users do not need to do anything more than submit their email address and use the expiring link. This way you do not need to produce access to the backend or even a user profile page. Since EDD supports guest checkout it's entirely possible that a customer of an EDD shop may not even have a user, which is why we'll try and stick to solutions that require the lowest barrier to entry.

I spent last night reading GDPR front to back and have some clearer direction personally. There is some open interpretation on the Privacy Policy agreement checkbox @lalunecreative that we're looking into and wether it needs to be a separate checkbox if the privacy and terms are separate documents. But we'll get more information on Article 7(2) of the regulation before moving forward with the solution in EDD for the Agreement checkboxes.

[katmoody]

I'm impressed with how much work you all have done already! Thanks for the update - I was pretty sure I understood but wanted to be crystal clear ;-)

[lalunecreative]

After talking with our Lawyer about everything we need, I just realized there's no current way to see if a user has agreed to the terms of conditions checkbox on checkout. This was apparently needed before we even started on GDPR since legally there's no record of someone checking the boxes to purchase (to my knowledge that I can see). There has to be a "record of consent" for them to be legally useable in court.

I looked around everywhere in user profiles, download data, etc but couldn't find anything that proves the user checked the box, there's no log to speak of or any indication that I could find that gives that information if I needed to give it to someone else for proof that they did it (like a lawyer). That's a definite legal issue there because there's no definitive way for us to confirm the user checked/agreed to anything, and they have to, to make a purchase through EDD on our site. Just because they were able to make the purchase isn't enough for it to be legal when they check it. There has to be some sort of proof available.

I think we need to be able to download some data that they actually checked the TOC and the new Privacy Policy checkbox somewhere that proves that they did it, and be able to see that somewhere in the backend, like the profile page of the user or something.

[cklosowski]

We have an open issue #6432 to get this in place.

[cklosowski]

@lalunecreative ^^

[lalunecreative]

@cklosowski Great, I couldn't find the ticket so I wasn't sure if there was one for it specifically! It's awesome that you guys are staying on top of it, do we have a release date thereabouts for the GDPR stuff? Core is pushing for the 15th with theirs.

[cklosowski]

@lalunecreative No hard date yet no. I've been following core's tickets so I know their dates. As much as I want to push on the 15th with them and integrate, it's likely we'll be shortly after that to allow for some further development. While their date is the 15th, it's very likely there will be continued changes in their work up until that point, so we just have to keep shifting with the moves they're making.

It is a focus of ours though, so movement is continuing to press forward.

[danieliser]

@lalunecreative I would argue any purchase is effectively consent.

To be fair, the mere fact they made a purchase that couldn't have been completed without checking that required field should constitute consent ;). IE They literally cannot complete the purchase without having done so (at least not without of the box options).

@cklosowski Not sure how much code you guys have dug into in terms of what core is doing, but I have been following closely and wrote up a quick implementation guide based on the functionality that core has introduced so far in beta, none of which has any documentation, so this may be of use to you guys.

https://danieliser.com/practical-guide-to-gdpr-compliance-for-wordpress-plugin-and-theme-developers/

[bobriley]

Hey guys, I sell a plugin and am using EDD Software Licensing - since Software Licensing records the sites whose licenses have been 'activated' it seems like we need to add something to our plugin itself, not just the website where we sell the plugin.

In our plugin we have a "activate license" page where it would seem like we'll need to add both a link to the privacy policy as well as a checkbox that ensures they've read the policy or they won't be able to activate the license.

For those of your selling plugins/themes using EDD SL, is this how you guys read things? If not, how you are handling it within your product?

[cklosowski]

@bobriley We are still working through all the issues we need for all our repositories. Software Licensing doesn't have all it's own issues created yet.

As always we cannot provide specific things we _read_ on the legislation because that would equate to us providing legal advice to you, and as you can see from this issue already, there are many interpretations of some of the language (like needing one checkbox or two, some argue 1, some say 2). EDD is building it in such a way that we're trying to make it so _you_ as a store owner can implement the solutions in a way that your legal representation advises you to.

As we get closer to fully merging and releasing some of our implementations we'll have them ready for store owners to complete. We just got the WP Core functions less than week ago to start implementing.

[codebard]

The thing with GPDR is that it requires an easy way for users to delete the data. So just a notice and confirmation like cookie law wont seem to cut it. Or 'you agreed to our terms of service' methodology.

To chime in the general discussion before this point and some of the approaches voiced : GDPR shouldnt be treated like VAT - VAT was, and is something that pertains to local tax authorities and their action: For there to be consequences, a local (national) tax authority must think that some site is not paying the taxes due to their government, and then act on it. There first needs to be probable cause for this to happen - just like any citizen in any country being investigated for suspected tax evasion. So the authority must be informed of valid purchases by their own residents, then must conclude that the tax for those valid purchases were not paid that quarter, then initiate the procedure for following up and so on. And the consequences would be according to how that country would handle that VAT avoidance - owed VAT plus a measure of interest and fines applied on top, which would be totally pointless to pursue for small amounts.

But GPDR is different - users not being able to delete data is something obvious and it doesnt require reqporting to an authority, or the authority trying to confirm non compliance through long legal procedures and follow up with another series of long legal procedures. An official tasked with investigating such issues can just register and confirm that s/he has no way to delete the data.

And the fine for non compliance is quite serious - nothing like what could potentially result from VAT avoidance.

For that, both WP and EDD and any major plugin must have their own way of handling GPDR by default, at least for the default features. Plugins may extend these, but such compliance must not be left to plugins alone.

[danieliser]

@codebard - read over my link above about practical implementation guide. WP core v4.9.6 includes the forms and all of the eraser and exporter functionality in such a way that plugins simply extend it with their own export and erase functions. Same for privacy policy etc.

Core will be handing 99% of the workload and plugins should only have to deal with their own internal data by hooking into those existing interfaces.

[Spreeuw]

Core will be handing 99% of the workload and plugins should only have to deal with their own internal data by hooking into those existing interfaces.

Exactly, but EDD & extensions should be providing that. You can't expect all shop owners to roll their own.

@cklosowski has already created something (WP GDPR - Easy Digital Downloads) that works with a third party extension (WP GDPR), but I think this should at least work with the core WP methods and then preferably be integrated into EDD itself. I can live with an add-on too, but if the add-on requires another add-on while this functionality is offered by WP Core I think that should be changed. (to be fair, this wasn't cristalized yet when chris created that add-on).

[Basilakis]

@Spreeuw I suppose that as long as EDD team gave us a solution, we have to leave with that.
if someone wants to go an other way ( like the core team did 1week before the GDPR update ), then they are free to go with that and develop on their own time ;-)

[Spreeuw]

Fair enough, I didn't want to come across as if I were demanding anything, but I think it would make most sense to work with what is offered in Core regardless. But fully agree on the timing on everything and grateful that there is a working solution for now.

[rubengc]

Then, what we should do? Wait to EDD update or as a temporal solution use WP GDPR + @cklosowski EDD add-on?

[pippinsplugins]

EDD will be providing the export and deletion of personal data. It's nearly complete and will be released as soon as able.

[codebard]

That's really great to hear Pippin. Looking forward to it.

[danieliser]

@Spreeuw - To be fair, the plugin you mentioned is a commercial one, the one that was the origination of the concepts being added to WP Core was free and worked on standardizing things.
That plugin is effectively dead now as those are merged into core.

I personally don't like the idea of a commercial option here like the one you linked. The reason being they get to decide what plugins & things they will support, what order, and when etc.

By putting the guts into the core, you will get to 100% coverage on your site much quicker. IE each plugin will do what EDD & Popup Maker and others have done and quickly extend the core functions with their own data.

This means that within days or weeks you can have thousands of plugins supporting GDPR rather than a handful that the team of that one plugin can get put together on their own.

That said I recently had a small quarrel with an EU user who blamed WP core for the sluggishness of developing these features. The facts though are that nobody from EU contributed early on with exception to those who developed commercial solutions. Only when non-EU devs took up the mission did core progress get made. To clarify only 1 issue about GDPR was submitted prior to Feb 28 2018, and 80% of those submitted since are from a Canadian and an American.

[Spreeuw]

@danieliser I don't need to be convinced that using the filters from core is preferable over a solution that uses a 3rd party plugin (see my other posts above), I'm just thankful for the work of Chris that gives us a solution to work with _today_. And from Pippins remark it sounds like EDD core will have the export functions which I am assuming will be using the WP core filters so lets just be patient.
And thank you for the great documentation on those new filters, hats off!

[tomusborne]

One thing I'm worried about is the Software Licensing extension.

When a user activates their license key, their IP address and website URL are logged in the EDD Dashboard. Any thoughts on this? How will this be handled within EDD itself for its own extensions?

[danieliser]

@tomusborne - based on my research their is no reason to worry about it. That is essential data to the contractual agreement to provide service you both entered into when they purchased.

Same as things like legal invoicing. They can’t expect you to delete all record they purchased. That would be illegal. Same concept here. You need that info to do your job reasonably well.

[cklosowski]

Ok, it's time for an update with actual code and issues so here's the short version of where we are at:

We have a few status:

• To Do
• In Progress
• Ready for Review (just needs review and testing)
• Approved (Means it has been tested and code approved)
• Done (Means it has been merged, but not yet deployed)
• Deployed (The code has been deployed to users)

Misc Issues:
EDD: Privacy Policy Checkbox for checkout: Deployed (#6484)
Free Downloads: Newsletter Opt-In Unchecked by default: Deployed
EDD: Helper functions for masking data types: Done (#6502)
Free Downloads: Privacy Policy Checkbox: Done
EDD: Record agreements and terms on customer record: In Progress (#6432)
EDD: Privacy Policy Example Template: Ready for Testing (#6530)

Data Export Requests:
EDD: Customer Record: Done (#6544)
EDD: Customer Payment Data: Done (#6543)
EDD: File download log improvements, in preparation for export/eraser (#6548)
Simple Shipping: Customer Shipping Addresses: Approved
EDD Message: Export logged messages: Approved
EDD: Include file download logs in Export: Ready for Testing (#6499)
Reviews: Include Customer Reviews in Export: Ready for Testing

Data Anonymizer/Eraser:
EDD: Anonymize Customer Record: Approved (#6498)
EDD: Anonymize/Delete Payments: Ready for Testing (#6497)

We have a list of To Do items that I'm working through still, but that should give you some idea of where we are at with all the issues we've currently worked on.

[lalunecreative]

Is it possible to switch the TOS agreement to allow a selection of a page like the privacy policy options instead of writing it directly in EDD? I get that it's using Core's new features, but why not just make them consistent with each other?

[danieliser]

@lalunecreative Assuming I correctly understood what you are asking (take a section from the middle of another page) your likely not going to see that. Standardizing that also means you likely have to insert something into that page manually around your section that another plugin could use to pull the right info. This means a shortcode start & stop, or manual html etc. Ugly solution really once you break it down.

That said there are plugins that allow inserting page content via shortcode, but not only partial content (unless you mean the excerpt).

Simply no clean way to do what your asking, again assuming I understood correctly.

[lalunecreative]

Sorry I wasn't clear, right now you can select a dropdown in EDD to choose a privacy policy page. Which shows up on in the checkbox when you go to checkout. Instead of writing the TOS in the box on the settings page, why not just offer that same dropdown and select a page? It wouldn't be doing anything that you aren't already doing with the privacy policy option.

[fuzzytake]

@cklosowski Downloaded and activated the wp-gdpr-edd-addon plugin

However, the wp-gdpr-core returns the following error on the Add-on Licensing section:

Fatal error: Class 'wp_gdpr_edd\lib\Gdpr_Form_License' not found in /web/htdocs/www.example.com/home/wp-content/plugins/wp-gdpr-edd-addon-master/view/admin/menu-page.php on line 12

11 12 $controller = new Gdpr_Form_License();
13 $controller->print_form();
14 ?>

Thanks

[Stiofan]

When is the GDRP compliant version intended for release and is there anything i can do to help (as a developer)?

[cklosowski]

@lalunecreative We were going for the least number of changes for our users for now. It's possible we may switch our Terms of Use to be a dropdown for a page, but for now we're keeping it as a setting as to get as much work done without having to run regression testing against all the other areas that aren't directly affected by this.

[cklosowski]

@fuzzytake For now we're focusing on the tools build within WP Core. Since that is bundled for free with WordPress and is likely to be the most used platform for GDPR compliance we'll start there and then continue work on the Integration plugin you're discussing once the Core work is done.

[cklosowski]

@Stiofan master currently has quite a few issues already merged (see https://github.com/easydigitaldownloads/easy-digital-downloads/issues/6216#issuecomment-390050827). I'm working through the rest of the core ones today to try and get them into master.

By the EOD today, I'm hoping that core will have the exporters and anonymizers for itself merged into master

[cklosowski]

EDD Core master branch now has all of the functionality for 2.9.2 in it. We have a few small tweaks to make to the way the settings or organized, but that will not affect the functionality.

I will keep this issue updated with any release information as we near that time and have documentation built.

[cklosowski]

EDD 2.9.2 (and subsequently 2.9.3) are released with our initial work for GDPR. Since we've pushed these out, i'm going to close this issue for comment, so we can raise any new points as new issues for easier milestoning and future releases.

Thank you all for your feedback and due diligence in the conversations regarding GDPR.