Posted by theflightrs on Fri, Nov 08, 2024 - 4:40pm --- Updated: Nov 08 '24 - 4:51pm

Hi,

There is something erroneous going on between Rules and Entity Plus when a user registers:

- Log Message - Severity: Error


If the Register-button is clicked:

Frontend error

-------------------------------------------

The rule:

In written text, the actions are:

  • Assign role: User account: [site:current-user], Roles: Initiate
    - This doesn't actually set the role
  • Set data value to a field: [site:current-user:field-my-code] - [random:hash:crc32b]
    - The error disappears when removing this action (or anything that sets data).

In principle, the user gets through. The account appears in "Manage user accounts", but without any role.

Side notes:

I don't fully understand Entity Plus yet, I'm only focused on native account fields.

I don't know what could be cross-interacting. I have no other registration modules on. On another Backdrop site, this rule fires fine. Any ideas, suggestions, solutions?

Accepted answer

Hi Graham, 

Done. In a nutshell: The [account] selector is for the registering account instance, while [site:current-user] is for an already existing user. 

I think it's a pretty logical error that can happen when using a wrong data selector - It can't set something that doesn't exist.  :-) 

Cheers, and thanks.

Comments

Fri, Nov 08, 2024 - 5:59pm by Graham Leach

In:

entity_plus.wrapper.inc

The line of code that's breaking is (in bold):

  /**
  * Permanently save the wrapped entity.
  *
  * @throws EntityMetadataWrapperException
  *   If the entity type does not support saving.
  *
  * @return EntityBackdropWrapper
  *   The saved entity wrapper.
  */
 public function save() {
   if ($this->data) {
     if (!entity_plus_type_supports($this->type, 'save')) {
       throw new EntityMetadataWrapperException("There is no information about how to save entities of type " . check_plain($this->type) . '.');
     }
     $this->data->save();
     // On insert, update the identifier afterwards.
     if (!$this->id) {
       list($this->id, ,) = entity_extract_ids($this->type, $this->data);
     }
   }
   // If the entity hasn't been loaded yet, don't bother saving it.
   return $this;
 }

What's interesting is that there is actually a test to see if a 'save' method exists for this object, immediately preceding the call to save() it.  

Theoretically you should NOT be seeing this error, and yet...you are...

You need to inspect the contents of the $this object to see what's going on in there.

I would:

  1. Comment out the line in bold using the # character

    #     $this->data->save();

  2. Stick the following block in just below it to see what the contents of $this actually looks like:

$DEBUG = TRUE;

if ($DEBUG) {

  echo "<pre>";

  print_r($this);

  echo "</pre>";

}

Enhanced state inspection may help you to troubleshoot the $this object in terms of what it contains (data) and what it can do (methods).

  • There may simply be a misspelling somewhere, which would be an easy fix.
  • There may be a logical fallacy somewhere, which is more difficult.
  • There may be a missing dependency somewhere.

If you don't see a save method somehow intrinsic to the $this object, then you need to back-trace things to where it is attached to the $this object, and figure out why it didn't happen.

Hope I got the above right...I'm learning too!  

g.

-----

 

Fri, Nov 08, 2024 - 7:29pm by theflightrs

Hi and thanks, i tried this now. 

Both with and without the #,   i saw nothing printed anywhere. It only bypassed the actions and the user got registered.  

Where should this print debug be shown? I looked at the header, my hoster error logs and the log - nothing. 

In the meantime i'm really trying to think what could be. My suspicion is about some modules i turned on in the past briefly such as Registration and Membership, and my question is actually if any of those could have left a certain setting remaining? Usually i revert all settings before disabling modules, but maybe less detailed when rushing tests. Otherwise, i will try to drill down on field permissions and such. 

Meanwhile, i'll leave my currently enabled modules from the Debug Information here if that makes sense:

Enabled modules
===============

Contrib
-------
actions_permissions              1.x-3.0.6
addressfield                     1.x-1.3.2
antibot                          1.x-1.2.1
antiscan                         1.x-1.0.12
barcodes                         1.x-1.0.1
blockify                         1.x-1.0.1
colorbox                         1.x-2.17.2
commentsblock                    1.x-3.0.0
conditional_fields               1.x-3.0.0
css_editor                       1.x-1.1.1
custom_header_block              1.x-1.0.0
editablefields                   1.x-1.0.1
editableviews                    1.x-1.0.3
encrypt                          1.x-2.0.2
entity_plus                      1.x-1.0.21
entity_token                     1.x-2.0.4
entity_ui                        1.x-1.0.2
entityreference_view_widget      1.x-2.1.0-alpha1
faqfield                         1.x-1.0.3
featherlight                     1.x-1.0.4
field_default_token              1.x-1.0.0
field_encrypt                    1.x-1.0.3
field_group                      1.x-1.2.1
field_permissions                1.x-1.0.6
field_readonly                   1.x-1.0.0-alpha
field_visibility_condition       1.x-1.0.0
filefield_paths                  1.x-1.0.4
filefield_sources                1.x-1.12.0
filehash                         1.x-1.9.0
flag                             1.x-3.6.0
flag_actions                     1.x-3.6.0
forum_ng                         1.x-1.0.0-alpha1
honeypot                         1.x-1.26.1
html5_upload                     1.x-1.1.3
ip_blocking                      1.x-1.0.18
key                              1.x-3.4.0
key_encrypt                      1.x-3.4.0
libraries                        1.x-2.2.3
linkchecker                      1.x-1.5.2
linked_field                     1.x-1.10.1
menu_views                       1.x-2.5.1
nicemessages                     1.x-1.0.4
plugin_manager                   1.x-1.0.0
protected_forms                  1.x-1.1.2
realname                         1.x-1.0.6
references                       1.x-1.0.3
restrict_abusive_words           1.x-2.1.0
rules                            1.x-2.14.2
rules_admin                      1.x-2.14.2
seckit                           1.x-1.13.0
security_review                  1.x-1.3.2
serial                           1.x-1.8.0
statistics                       1.x-1.0.2
token_block                      1.x-1.0.3
token_custom                     1.x-1.3.0
token_filter                     1.x-1.0.3
unique_field                     1.x-1.0.1
user_reference                   1.x-1.0.3
utility_css                      1.x-0.2
viewfield                        1.x-1.0.0
views_bootstrap                  1.x-3.5.1
views_bulk_operations            1.x-3.0.6
views_conditional                1.x-1.3.1
views_field_view                 1.x-1.2.0
views_random_seed                1.x-1.2.2
views_term_hierarchy             1.x-1.0.0
webform                          1.x-4.26.3
webform_calculator               1.x-2.1.1 

What i also think is weird is that the role doesn't even get set for the user. It's a pretty straightforward Rule though.

EDIT: Interesting side encounter when uninstalling the Registration module:

I remember setting new users to go to a "Wait List" there. I unchecked things before uninstalling.

Fri, Nov 08, 2024 - 7:43pm by Graham Leach

Hello @flighrs,

If a save() method is failing you're lucky for anything regarding this object to be persisted at all.

Q:  Do you get the same error with authenticated users?

Other measures:

  1.  Try looking at page source - the information you are seeking might be appearing there.  It has for me at times.
  2. Are you using the devel module?  It offers rich set of troubleshooting tools, including many object/array inspection tools

Again, I'm no expert - I'm just describing what I woudl be doing in your position.

g.

-----

Fri, Nov 08, 2024 - 9:23pm by theflightrs

Hi,

Oh goodness,  i was pondering that until i pulled a surprise solution:  

I changed the data selectors from site:current-user to account. 
The desired registration works now - including the assignment of roles. 

Been sitting on this for some days, so it was a long day lol. 

Thanks for the suggestions and input, g. 
I'll leave this here as solved. :-)

Sat, Nov 09, 2024 - 3:21pm by Graham Leach

Hello @flightrs,

You might want to take 5 minutes and go over to GitHub and flag this issue on the module, now that you know where it is, what it is and how to reproduce it.

This particular error is liable to return, zombie-like, to plague someone else.

There's obviously a design flaw in that module when it comes to saving role settings for Anonymous users when your original configuration was used.

g.

----

Sat, Nov 09, 2024 - 4:15pm by theflightrs

Hi Graham, 

Done. In a nutshell: The [account] selector is for the registering account instance, while [site:current-user] is for an already existing user. 

I think it's a pretty logical error that can happen when using a wrong data selector - It can't set something that doesn't exist.  :-) 

Cheers, and thanks.

Sat, Nov 09, 2024 - 4:31pm by Graham Leach

Thank you for taking the time to report.