Apparently, this is not the only privacy consent plugin. I'm going to provide an analogous implementation for the content plugin for contact forms tomorrow.
Thanks to @ChristineWk for pointing me there. ;-)

Updated with the according changes to Content - Confirm Consent. Testing instructions are now updated, too. It's ready to test now! ;-)

Stupid question here: Why do we have two plugins for almost the same thing, including two similar, but still different implementations for the form field that displays the modal?

@Harmageddon
Some test-results:

a) System - Privacy Consent (registration form) > there is no switch to "Menu Item".

b) Content - Confirm Consent (contact form) > successful. See screenshots

Now I got a) also. It wasn't there before.

I have tested this item ✅ successfully on ea4abe9

but not tested multilingual site

I have tested this item ✅ successfully on ea4abe9

I have tetsed this successfully:

1. Added German language to the site
2. Added German menu item for blog: "Das Blog" associated with "Blog" menu item
3. Enable plugin "privacy - consent" and changed to "Privacy Type -> menu item"
4. Set Privacy Menu Item to "Blog" (English menu item)
5. When checked the privacy consent link I see the menu item for English blog when in English language and the link for Das Blog when in German language

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/29024.}

RTC

Previous test results are still valid, because the change after the test was only in doc blocks. I've restored the test results in the tracker so the count there and here is correct again.

RTC status is also still valid, see my previous comment.

I have tested this item ✅ successfully on ae56966

Code Review

I have tested this item ? unsuccessfully on ae56966

I am using J4 Beta 2-Dev nightly build from last night. I installed the multi-lingual test data and created a Privacy Policy article in English, French and German. In the login form I see the Privacy box and Terms and Conditions box. However, with the patch applied with the Patch Tester the Privacy Plugin doe not have a switch and I can't find anything in the Contact configuration. So it does nothing. But it does not break anything either. How do I check whether the Patch Tester is actually working?

@ceford Can you post a screenshot of the plugin configuration? I just tested it with the current nightly and patchtester 4.0.0 RC2 and it works for me. Which plugin did you edit?

This is the only item I can find that matches the Test Instructions:

In the front end there is no modal box for the Privacy Policy. If I click the menu item I get the Article. I guess I must be doing something wrong. Is there a step missing from the instructions?

@ceford the plugin to configure is System - Privacy Consent. It's disabled by default.

I see. You have to check the Plugins "Content - Confirm Consent" for the contact form, and "System - Privacy Consent" for the registration form. It's a bit confusing, I had the same difficulties finding the differences.

I had the Content - Confirm Consent enabled but neglected to select the Article option. So now I have this:

But still nothing to select in the Privacy - Consents plugin and still no sign of a modal in the front end. Which has this at the foot of the Registration form:

I have the Privacy Policy article in English, French and German as Associations. Is the modal present in J4?

@ceford For the registration form, you have to look at "System - Privacy Consent" without an S at the end. As I mentioned above, "Content - Confirm Consent" is for the contact form (i.e. if you have a menu item of type Single Contact with a form).

Argh! I did not notice the Privacy Policy just above I agree and No is a link. Tired old eyes? Or poor accessibility design?

I'd say poor accessibility design ;-)

I can confirm that this patch works with two side effects:

The modal body needs some padding.

In a multilingual site, if the System - Privacy Consent is set to an Article in English and without associations in French and German, then in either of those two languages the modal box is a Search form:

I guess fixing that may be lilly guilding.

I can take care of the documentation update - right now!

Good spot! I'll try to look into the situation when there is no equivalent menu item for the language on the weekend. Please don't merge this PR before.
The padding thing is something I noticed, too, but needs to be fixed in another PR.

Good spot! I'll try to look into the situation when there is no equivalent menu item for the language on the weekend. Please don't merge this PR before.

Ok, will remove RTC to avoid the merge.

Removing RTC since the author wants to add some correction/enhancement, see his comment above: #29024 (comment)

If there is no associated menu item, the link should now fall back to the one selected in the plugin configuration, like it is for the article option.
@ceford Can you please test if it works for you? Thank you again for finding this error! :-)

I reloaded the Patch Tester Data and applied the patch. A wee box below the View buttons says Applied Commit SHA: 1c1c740. I see no change from the previous incarnation.

With all languages pointing to associated articles in different languages I noticed that the modal box does not contain the article content:

With the English article pointing to something not associated I get a Search form in the French and German modal boxes.

I reloaded the Patch Tester Data and applied the patch. A wee box below the View buttons says Applied Commit SHA: 1c1c740. I see no change from the previous incarnation.

That's a commit from a different PR (#29592). Is it possible that you mixed these up / re-installed that one instead of this here? For this PR here, it should give you "Applied Commit SHA: e56f475".

With all languages pointing to associated articles in different languages I noticed that the modal box does not contain the article content:

As far as I see, this is not a result of this PR, but was like this already before. So it should be fixed in a different PR as well, because it's another bug unrelated to this feature here.

I reloaded patch tester data again and I now seem to have the correct patch: Applied Commit SHA: e56f475. It works in all languages when an article or menu item are associated in all languages. The problem I see is when the privacy article or menu does not exist in all languages. I have experience of this with a custom component on a J3 site - there if a none-English item does not exist we display the English version because that is deemed the legal version.

Where I previously said the modal box does not contain the article content, as illustrated on my previous screen shot, I did not notice that the modal box has a vertical scroll - the content is all there. I think the modal box needs to be a tad longer. And where I previously said it contains a search from if the none-English version is missing, it actually contains page content, including left and right side bars:

I can think of instances where an article/menu item is created in several languages and another language is added later. Is there a technical solution? Or do we rely on Administrator education?

There should definitely be a solution for this. I'm just wondering because I intended to fix this with e56f475. So I don't understand why it's still the same like before on your site.

My approach is: I create three languages, en-GB, de-DE and fr-FR. Create a menu item in two of them (en-GB and de-DE), but not in fr-FR. In the plugin options, I select one of these two menu items. Now when I go to a registration or contact form, if I am in de-DE or en-GB, it shows me the respective page inside the modal. If I'm on fr-FR, the modal opens the menu item I selected in the plugin (which will be en-GB or de-DE, depending which one I selected there).

Is this at any point different to your setting? Can you maybe check if the patch has been applied correctly, i.e. if for example the file plugins/system/privacyconsent/src/Field/PrivacyField.php contains the following on lines 106f:

Or maybe revert the patch and apply it again?

And which form are you viewing there? Registration or Contact? And does it work on the other?

I followed your instructions and it worked as you described. Except - if the French menu item is unpublished rather than trashed and deleted. In which case - the French version displays a French Not Found page.

Ohhh... I only tested with the french item not existing. But I can imagine that trashed/unpublished might break this. Will look into it tomorrow. Thank you for your patience!

So it works if the item doesn't exist at all / has been properly deleted (also removed from trash)?

I reviewed this edge case now. So, to summarize, in this case, you have three menu items for three languages:

• de-DE (published)
• en-GB (published)
• fr-FR (unpublished or trashed)
  All of them are associated to each other.

I see no simple fix to this besides doing another query on the menu items just to avoid this situation. I'm not sure if this situation is wanted in any scenario. It will give you problems on several other levels. I just tested this situation and for example, in the language switcher module, all three flags appear, but the french one falls back to the home page instead of the unpublished menu item. So as far as I see, if you have associated menu items, they should all be published (or restricted on base of user groups, but this wouldn't make much sense either for a privacy policy).

So I'm not in big favor of adding a database query that will run without any effect for all pages besides very few that are oddly configured.

@ceford Could you clarify if I understood the situation correctly in my comment above or if I missed something?

I tried another test to remind myself of the issue. Right now, with the patch applied, and with a de/en/fr switcher, if I select a menu item that points to an Article in English for which no translations exist, the Privacy Policy link invokes the modal dialog with Page not Found content in French or German, as in my previous illustration. I think this is a new test.

In my previous test I had a Privacy Policy in English associated with one in German and French. But I only had menu items for the English and German versions. That caused the the French Privacy dialog to display the English privacy content, which is good.

If fixing this problem is not practicable we will need to rely on education / documentation.

Thank you for your response! To make sure, so I can reproduce your test case: Is the language for the menu item set to English, too? Or to all languages?

So:

• Menu item: English, not associated to anything
• Article: English, not associated to anything

Or how is the situation?

The language of the menu item is English and has de-DE as an association.

And where is the de-DE menu item pointing to? A german article?

The de-DE menu item is pointing the privacy article in German associated with the privacy article in English.

I'm not sure if I understand you correctly. You said:

if I select a menu item that points to an Article in English for which no translations exist, the Privacy Policy link invokes the modal dialog with Page not Found content in French or German, as in my previous illustration. I think this is a new test.

So only an article and a menu item in English? But now you have both in German as well? And does it work or not?

This is a concise summary of my tests. Hope it is clearer.

Set up - Associated Articles - Privacy Policy == Privacy Policy in French == Privacy Policy in German
Set up - Associated menu items - Privacy Policy == Privacy Policy in German
Set up - SomeOtherArticle and SomeOtherArticleMenuItem
Apply Patch
Test 1:
Set - Privacy Type - Menu Item - Privacy Policy
Select language and then Privacy Policy link:
English - Privacy Policy in English
German - Privacy Policy in German
French - Privacy Policy in English
Result - Good - what I want / expect
Test 2:
Set - Privacy Type - Menu Item - SomeOtherArticleMenuItem (no French or German Association)
Select language and then Privacy Policy link:
English - SomeOtherArticle content
French - Page not Found content in French (as illustrated previously)
German - Page not Found content in German
Result - Bad - Should be SomeOtherArticle content in English OR some simple error message.

Test 1 is exactly what I would expect and how I wanted this to work: If there is no entry in the according language, fall back to that one selected in the plugin.

For Test 2, I'm still struggling to replicate. I have:

• Article "SomeOtherArticle" (en), not associated to anything
• Menu Item "SomeOtherArticleMenuItem" (en), not associated to anything

This leads me to the English article in all three languages.

The only case when I get a 404 there is, when the menu item "SomeOtherArticleMenuItem" is set to all languages, not to English. But if I see it correctly, this is not a valid configuration, as I get a 404 then when clicking on the menu item in a normal menu as well.

@ceford Thank you for the clarification! So is this a successful test from your side or do you see any remaining issues with this PR?

Yes - Pass.

@ceford Does your previous mean you have tested this PR completely with success? If so, please mark the test result again at the issue tracker because your previous result has been reset with the last commit.

@zero-24 GH still shows changes requested by your review, but the review comments have been solved. Maybe you can just pass again a neutral review to reset this?

@zero-24 No, is still there in the box at the bottom.

I have tested this item ? unsuccessfully on e56f475

I selected a menu item for the Privacy Policy and that worked fine. I went back and selected Privacy Type: Article; Privacy Article: Select brought up a list to select from. But the links are dead and I see javascript:void() at the bottom left of the screen. I am now on Beta-3 Dev. Is there a Javascript issue?

#29897

The bug you mentioned has been fixed in #29860, merged a few minutes ago. As mentioned there, it was introduced in #29464, which has been merged into 4.0-dev just before the release of beta2. So the bug came with beta2 and was fixed after the release of beta2. I'd therefore ask you to test with beta1 or a current version (nightly starting from tomorrow, Fr 03 July or git from right now).

Thank you @ChristineWk for pointing this out!

If I pick an article in English that has no associations in French and German then I get that Article in English in the Privacy Policy dialog in all three languages. Good!

If I pick the menu item that points to that article, also without associations in French and German, then I only get that Article in English in the Privacy Policy dialog. In French and German I get the dialog with a 404 not found page. And it is a big page with all of the modules in left and right columns. I accept that that could be left as a User education problem but it would be better if there were a technical solution.

Otherwise the normal behaviour works fine.

Like I mentioned above, the menu item should be set to English in your second case as well. Is this the case?

Yes, it works properly with the menu item set to English.

One more question: why is this plugin in the System group instead of the Privacy group?

I have tested this item ✅ successfully on e56f475

With the small proviso I mentioned previously I think this is OK. I have documented the changes in the Help screen:

https://docs.joomla.org/Chunk4x:Extensions_Plugin_Manager_Edit_System_Group#System_-_Privacy_Consent

And there drawn attention to multilingual associations.

Thank you for your tests and the effort on the documentation! :-)

I have tested this item ✅ successfully on dc39f39

Version 4.0.0-beta3-dev Jul6th2020 new Installation

I have tested this item ✅ successfully on dc39f39

RTC

@wilsonge Anything which keeps this RTC PR from being merged? Does it count as "new feauture" and so has to go into 4.1?