If there is a required custom field that the user can fill by editing
their profile, and that field is missing, the user should be considered
as not fully set up. Instead, we want to redirect them to edit their
profile first.
There are some exceptions when we want to fall back to the previous
behaviour and check just the name and email fields. These exceptional
cases include checking remote user data in incoming MNet request (no
user id, no custom fields supported) and calls to require_login() with
redirecting disabled (typically ajax filepicker requests on profile
editing page itself).
Additional plugins that call the function user_not_fully_set_up()
themselves, should perform the strict check in most/typical cases. So
the strict mode is enabled by default even if it changes the behaviour
slightly. In improbable case of additional plugins relying on the
previous behaviour of the function, they can use the $strict parameter
and keep performing the lax check. However, I am sure the correct fix in
that case will likely be to stop abusing this function.
Note that custom fields are not currently transferred during the MNet
roaming. So having custom fields configured as required on MNet service
provider site (where users can't edit their profiles) is expected to
display an error (as the site is considered as misconfigured).
PHP7 doesn't have any default XHProf support and all other
investigated forks don't have stable PHP7. Tideways is under
active development and is easy to install. The data format
is compatible with XHProf so it is a drop-in replacement in that way.
Existing language strings for the host component suggest that the host can
be provided in the format hostname:port, but we previously did not support
this.
This patch explodes the string based on the colon character and assumes
that if there are two parts, that they are in the format hostname:port.
Note: This does not attempt to deal with full host specifications (e.g.
protocol://hostname:port), as this is beyond the scope of this change.
Changes made in this patch include:
* Reverting to the original look of having the percentage label of the
progress bar inside it.
* Setting a minimum width for the progress bar so the percentage label
will still be visible even at 0%.
* Replaced the blank space between the percent text and the percent
sign with a non-breaking space.
* Added relevant aria attributes for the progress bars.
* I think that this is a good opportunity to use a single template for the
progress bars so I created one that is basically based from the core
template columns-1to2. Column 1 contains the progress text, while column2
contains the progress bar itself.
Dan Poltawski