Closed (won't fix)
Project:
Hierarchical Select
Version:
6.x-3.7
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
29 Sep 2011 at 20:50 UTC
Updated:
19 Mar 2015 at 11:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
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 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 1312Comment #3
sunCan you let me know what version of PHP you're on? admin/reports/status should tell.
Comment #4
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 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 commentedSorry, I didn't see what you did there in the issue status. Setting it back.
Comment #7
seaneffel commentedAaaand botched the version number. Now it should be correct.
Comment #8
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 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 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 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 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 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 commentedComment #16
seaneffel commentedFine, changing queues to the Hierarchical Select module. See if it gets any love over there.
Comment #17
js commentedI have this problem as well. @seaneffel, thank you for all your investigative time.
Comment #18
stefan.r commented6.x issue without activity for over 3 years, closing.
Feel free to reopen if this is still an issue.