[5.x] Add user profile form tabs and sections

[AtmoFX]

This PR follows a discussion on Discord.

It adds/changes the following to {{ user:profile_form }}:

• Main purpose: added loops over sections, using the {{ sections }} inner tag.
  This aligns the profile form to other forms where it was possible to loop over sections.
• Additionally: added loops over tabs, using the {{ tabs }} inner tag.
  Tabs do not exist in forms' blueprints.

Technically, the tags work by:

1. The getProfileTabs() method:
   1. Generates the array of tabs that can be looped through
   2. Excludes the fields password, password_confirmation, roles, groups as well as assets fields, on the same principle as the existing getProfileFields method.
   3. Adds values and preprocess the fields, again on the same principle as the existing getProfileFields method.
2. The result of getProfileTab() is then used to create the new {{ tabs }}` inner tag.
3. It is then flattened into another array used to create the new {{ sections }} inner tag.
4. This new array is flattened again into an array used to create the existing {{ fields }} inner tag (i.e. instead of using getProfileFields() to create {{ fields }}).
   This removes duplicate code (getProfileFields() is not called anymore, though I have not removed it) and is expected to have better performance.

Note: flattening the Array from tabs to sections and then to profile is done on the same way as it is done for regular forms:

$data['tabs'] = $this->getProfileTabs();
$data['sections'] = collect($data['tabs'])->flatMap->sections->all();
$data['fields'] = collect($data['sections'])->flatMap->fields->all();

But it could have been done using:

$array_tabs = $this->getProfileTabs();
$array_sections = array_reduce(array_column($array_tabs, 'sections'), 'array_merge', []);
$array_fields = array_reduce(array_column($array_sections, 'fields'), 'array_merge', []);

One method might be superior in terms of performance.

[duncanmcclean]

Can you add tests to cover your changes? You can add to UserTagsTest.

[AtmoFX]

@duncanmcclean

Test added, not in the file you mentioned but in ProfileFormTest instead (though your link was useful to locate the correct file to add the tests to).

To me, tests seemed relevant only for custom blueprints, since the default blueprint only has 1 tab, 1 section, therefore, I changed the custom blueprint to make it work with {{ tabs }}, {{ sections }} and the existing {{ fields }} loop.

While I am here, quick reminder: getProfileFields() (src\Auth\UserTags, line 753 in my version) has NOT been removed.
As per our Discord discussion, if I am right in the belief that it is not called anywhere anymore, it is dead code now. I leave to you the decision about whether it should be removed now or later, or be kept in the code for future use.

[AtmoFX]

@duncanmcclean : to follow up, will this PR ever be passed into 5.x? Or only 6.x?

[duncanmcclean]

I'm not sure, sorry! It really depends when we get around to reviewing this PR.

If you need to use this in your project, you could potentially use a composer patch.

[AtmoFX]

Going to be honest: your answer, or lack thereof, rubs me the wrong way.

You are spending all of your time on Statamic v6; good for you and I understand the challenge.
I'm sure v6 is going to be very neat and all but:

• People make their own contributions on things they need.
  Sorry to say but my website already works well with Statamic 5; I can make use of it, but Statamic 6 is not something I need.
  If they go out of their way to develop something themselves (alternative would be to submit an idea and leave it to your schedule), it is safe to say they need it somewhat short term.
• The team seems to want to spend 100% of their time on v6, ideally not 1% less. The result is that we receive scarce updates now, with very few functions that add value to our sites.

It is not like I was pushing to have the PR merged urgently (though I'd very much like to see the thing be merged after 2 months), I was only asking for the plan. How is it possible nobody in the core team has discussed what to do with the growing backlog?

Ultimately, it is unreasonable to ask people who go out of their way to develop themselves something they need short term (instead of submitting an idea and leaving its delivery to your schedule) to wait months without so much as a heads up and by happy with a makeshift solution.

---

As to "use a composer patch", nah, I won't be using that sh*t and I feel you should not require your users, who are making contributions on their own time (and paid a Statamic license BTW), to use it.

First of all, Statatamic can be used with just the commands provided in /cp/updater/; judging by the 316 contributors to the repo vs 4.5k stars it has collected, I think it is safe to say >75% will not have to edit composer.json manually, ever.

Your users are likely not, for the most part, expert in composer or git, let alone both. I for one made my first, and so far only, contribution ever on a PHP application with this very PR.

Regarding the package, I've spent a few hours on it and all I have figured out is:

• It is straight up abandoned.
  Last release was in 2022, v1.7.3 and:

  • The documentation clearly states: [quote]: Nothing here applies to 1.x: All documentation for the current, production-ready version of the plugin is in the 1.x README.md in the project repository. [/endquote]
  • And of course, said README clearly states [quote]: Note that the 1.x versions of Composer Patches are supported on a best-effort basis due to the imminent release of 2.0.0. [/endquote]

  3 years without releasing a so called "imminent" update, or any update at all, and without bothering aligning the official website for the package on that goes beyond calling the package just "unmaintained".

• Like many other utilities in the PHP/webdev world, documentation is abysmal.

  • There is no introduction at all about what the package does.
    Immediate red flag: failing to explain something as basic as what command to run once the configuration is done is a total red flag. If you argue "said command is just composer, it is obvious and you can use it normally", my answer to that is: this is not obvious to me and any decent maintainer would have spent 10secs to write it.

  • It only provides snippets with no explanation as to what it does.
    What I mean here is that I do not consider wording such as (those are all quotes:) There may be situations in which [...], Some situations require to force the [...] to provide any information.
    I do not even know what keys (in composer.json) are interpreted by the vanilla composer and subsequentely, what keys are added by the package. Am I expected to know what to do with it being my first experience editing composer.json manually?
    A good example of where snippets are limited is the Allowing to force the patch level (-pX) section. I don't know jack about drupal/core and I don't know what a patch level. So, how am I supposed to know what to put, or if I need that at all?

  • And to all of the above, I was interested in at least another PR. There is no explanation whatsoever about how I put 2 patches in the single patches-file property of a json.

You seriously overestimate your users if you think they all can configure it without hours of trial and errors.... or at all really.