Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Got lots of users reporting a fatal error with the message:
"Fatal error: Cannot create references to/from string offsets nor overloaded
objects in /home/mysite/public_html/**sites/all/modules/mollom/**mollom.module
on line 1312"
They are prevented from submitting the node they have created. Any idea why this is happening? I bet I can reproduce the problem for you, if you open up an account on our site and tell me your user name I can approve an account to show you. http://www.cctvcambridge.org/user/register
I've set this to critical since the error prevents nodes from submitting.
Comment | File | Size | Author |
---|---|---|---|
#14 | Picture 4.png | 26.22 KB | seaneffel |
#10 | Picture 2.png | 68.68 KB | seaneffel |
Comments
Comment #1
seaneffel CreditAttribution: seaneffel commentedI notice there is a 6.x-1.9 tag on this issue queue, but the most recent release on the project page is 6.x-1.6. Have I missed something?
Comment #2
seaneffel CreditAttribution: seaneffel commentedMore information. Running tests I can see that the error turns up after the CAPTCHA is passed by the user.
Immediately, this following error message turns up.
Fatal error: Cannot create references to/from string offsets nor overloaded objects in /home/mysite/public_html/sites/all/modules/mollom/mollom.module on line 1312
Comment #3
sunCan you let me know what version of PHP you're on? admin/reports/status should tell.
Comment #4
seaneffel CreditAttribution: seaneffel commentedMore conditional stuff.
I see that this is a problem with one content type. The content type is pretty sophisticated. It has several custom text fields, a date field, a location field, an image filefield, a CCK Link field, and several taxonomy fields. I'm going to try to isolate the field that is causing us the pains.
I notice also that the preview step during node creation brings up this error with no check against Mollom for the correct CAPTCHA.
Comment #5
seaneffel CreditAttribution: seaneffel commentedHere are all the details about my webserver config: Apache/1.3.42 (Unix) PHP/5.2.9 mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Comment #6
seaneffel CreditAttribution: seaneffel commentedSorry, I didn't see what you did there in the issue status. Setting it back.
Comment #7
seaneffel CreditAttribution: seaneffel commentedAaaand botched the version number. Now it should be correct.
Comment #8
seaneffel CreditAttribution: seaneffel commentedI've run these operations that generate errors on a test server and found that the error doesn't present itself. Maybe this is an environmental thing, maybe not. I'm still following another hunch that its a conflict with another module being used on a content type.
Webserver config : Apache/2.0.59 (Unix) PHP/5.2.6 DAV/2
This is the passed captcha session if that is helpful to you (or me).
Comment #9
sunIn that case, there must indeed be something wrong or odd with that specific content type form.
The code that is triggering the error in the Mollom module is searching the form structure for submit buttons in order to remove their values from the submitted form values (only internally to further process the form submission data within mollom.module).
The error message basically means that the submitted form values contain a string or object in a location where an array is expected; i.e., within the path from the top-level array to one of the deeper/nested button value keys in the submitted form values.
This should normally not happen. Some module must be altering the submitted form values in an odd/invalid way.
You could try to put the following line at the beginning of _mollom_form_state_values_clean() in mollom.module:
and afterwards try to submit the form again. That should show all of the actual submitted form values.
Comment #10
seaneffel CreditAttribution: seaneffel commentedI stripped out all of the fields from that content type, one by one, and resubmitted the form each time. I got down to core-only fields and found that I still got the errors. Screenshot to prove it.
Comment #11
seaneffel CreditAttribution: seaneffel commentedI pasted that snippet at line 1281 in the mollom.module and got the following results. I don't know how to interperet them:
Comment #12
seaneffel CreditAttribution: seaneffel commentedNot like this PHP message could be related, could it? Noticed it in the log entries near the time of my last Mollom submission. I do have date fields contained in this suspicious content type.
Comment #13
seaneffel CreditAttribution: seaneffel commentedMore information.
I've created a second content type with the same structure and fields as the content type with the issue. As far as I can tell, the only difference is machine-readable name of the content type. It works as intended. I can't narrow down the problem to a specific field, but I think this may indicate that this is an issue with this specific content type. In the long term, this is probably an issue that someone else will have and it would be nice to single out the issue. Does what I have shared here make it any easier to pinpoint the problem?
In the short term, I am likely to change the workflow of my users to author nodes of this new content type instead of the old. I'll need to update views and blocks.
Comment #14
seaneffel CreditAttribution: seaneffel commentedFound. What a super annoying problem to diagnose.
The fatal error pops up because of the Hierarchical Select 6.x-3.7 module. I have two taxonomy vocabularies on this content type, both configured with HS but only one difference. The "save lineage" setting breaks the Mollom module when it is set to "Save only the deepest term". See attached screenie.
Changing the setting to "Save term lineage" allows the node to submit properly. I have done so for my site in order to get the users happy.
Now how can we fix this for everyone? Does this issue still belong in the Mollom queue?
Comment #15
seaneffel CreditAttribution: seaneffel commentedComment #16
seaneffel CreditAttribution: seaneffel commentedFine, changing queues to the Hierarchical Select module. See if it gets any love over there.
Comment #17
js CreditAttribution: js commentedI have this problem as well. @seaneffel, thank you for all your investigative time.
Comment #18
stefan.r CreditAttribution: stefan.r commented6.x issue without activity for over 3 years, closing.
Feel free to reopen if this is still an issue.