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

donquixote created an issue.