There are multiple places where a parameter is hinted as "object $regpath", but in fact it expects an array.
Example:
/**
* Sets page title for registration, login, and forgot password pages.
*
* @param object $regpath
* Object containing single row from profile2_regpath_get_profiles() database
* result.
*
* @param string $key
* Array key for 'misc' array. This will determine the title settings.
*/
function _profile2_regpath_set_title($regpath, $key) {
// Look for custom title in foremost profile, according to weight.
if (isset($regpath[0]->misc) && $misc = unserialize($regpath[0]->misc)) {
The parameter is hinted as an object, but further down it says $regpath[0]
.
Other examples are _profile2_regpath_user_register(), _profile2_regpath_user_password() etc.
The parameter is coming from hook_menu(), like this:
function profile2_regpath_menu() {
[..]
if ($profile_types = profile2_regpath_get_profiles($path)) {
[..]
$items[$registration_path] = array(
'title' => isset($misc['tab_text']) && trim($misc['tab_text']) != '' ? $misc['tab_text'] : t('Register as @profile_type', array('@profile_type' => $profile_types[0]->label)),
/* @see _profile2_regpath_user_register() */
'page callback' => '_profile2_regpath_user_register',
'page arguments' => array(
'profiles' => $profile_types,
),
where $profile_types is an array of profile2_regpath objects.
So the variable name is misleading, because one would expect profile2 objects, not profile2_regpath objects.
----------------
There are some other problems associated with this:
- profile2_regpath_get_profiles() gets the items directly from the database, bypassing ctools.
If I understand correctly how ctools works, if you export to feature and then deploy this elsewhere, the objects might not even be in the database, but defined in a hook instead. So the module would then fail to load them.
One example to look at correct (I think) ctools integration is the field_group module. - profile2_regpath_menu_alter() stores the complete objects in the menu_router table.
Instead, it should just store a string key in menu_router, and load the profiles when the form / page is being visited. - profile2_regpath uses a custom page callback to build the user registration form. In this page callback it already has all the $profile2_regpath objects. But later in hook_form_alter(), it tries to load the objects again, by examining $form['#action']. This is unnecessarily complex, and it is currently not supporting the "tabs" paths, as can be seen in #2505973: Profile2 fields only show up when Show on all user account forms is checked.
A lot of this could be fixed locally.
But it shows how complexity and misleading variable names can lead to errors. So, it is a strong argument to fix the variable naming and type hints.
Comments