Trying to get property of non-object in webform_results_submissions()

I experienced the same thing on 7.x-3.9. There were two broken submissions showing up under the results tab along with the errors you posted. I cloned the form using http://drupal.org/project/node_clone to resolve the issue.

Hi @the_phi! The two "broken submissions" would display errors (something similar to *Notice: Trying to get property of non-object in webform_results_submissions()...) when I would try to delete them. I am not sure what specifically caused these submissions to break, it happened while I was adding form components. My best guess is that I clicked the submit button more then once while waiting for the post to be saved and/or an unfortunately timed page reload.

I have the same too in a production situation from the 'Results/submissions' tab. I haven't double clicked anything although I can't speak for the clients:

Notice: Trying to get property of non-object in webform_results_submissions() (line 47 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Notice: Trying to get property of non-object in webform_results_submissions() (line 48 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1905 of /home/cardinal/public_html/includes/common.inc).
Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1915 of /home/cardinal/public_html/includes/common.inc).
Notice: Trying to get property of non-object in webform_results_submissions() (line 52 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Notice: Trying to get property of non-object in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Trying to get property of non-object in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Trying to get property of non-object in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Trying to get property of non-object in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Undefined property: stdClass::$is_draft in webform_results_submissions() (line 47 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Notice: Undefined property: stdClass::$submitted in webform_results_submissions() (line 48 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1905 of /home/cardinal/public_html/includes/common.inc).
Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1915 of /home/cardinal/public_html/includes/common.inc).
Notice: Undefined property: stdClass::$remote_addr in webform_results_submissions() (line 52 of /home/cardinal/public_html/sites/all/modules/webform/includes/webform.report.inc).
Notice: Undefined property: stdClass::$uid in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Undefined property: stdClass::$sid in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Undefined property: stdClass::$uid in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).
Notice: Undefined property: stdClass::$sid in webform_submission_access() (line 421 of /home/cardinal/public_html/sites/all/modules/webform/webform.module).

Hi guys, I can't confirm these problems. Is there any way to reproduce them on a clean install? I've been doing serious cleanup on the queue for the past week or so, these notices may have already been cleaned up, but it's hard to tell without a way to reproduce the problem.

Please reopen if you can provide steps to reproduce.

I'm just now running into this issue (worked fine with no errors on the site and for 2 other webforms on this site, it's still fine). It's been a while, but any thoughts on what could cause it? It's a brand new form on this site (2 others with results have no issues) and there's only 1 result -- that I can't view, edit or delete (I don't remember even testing this form, so not sure when this "result" got created). Is there a quick/clean way to remove just the result (from the mysql db?) to see if that's the cause and the fix?

****UPDATE****

Since there was only one entry, I did pop into the database and find the table (webform_submissions) and then just deleted that one entry (left all the others that were created by the other webforms on the site). So far, it seems to be working without error and the subsequent test worked fine with no issues. So, maybe this all boils down to a corrupted entry (or a partial since it got created before I completed the form and then it wouldn't let me edit it?).

Steps to reproduce:

1. Create a Webform.
2. Make a submission to that Webform.
3. Delete all the components of the Webform.
4. Visit the results tab.

If you make more components after you submit, you may have a usable Webform. The problem happens when there is at least one submission in the database that does not have any data submitted against it because all the components that existed at the time of the submission have been deleted.

This patch changes the SQL query in webform_get_submissions() to ensure that every submission gets returned, even if all of its components have been removed. Moving from a left join to a right join should be fine because every row in webform_submitted_data needs a match in webform_submissions anyway.

Reroll against 7.x-4.x-dev (last was against 7.x-3.18).

Ran into the same issue.

#14 worked thanks !

Thanks Liam for the patch. This query is specifically crafted to avoid sorting on multiple tables. However I found while running EXPLAIN on the queries, we're actually not quite as optimized as we should be.

Current query:

mysql> EXPLAIN SELECT s.*, sd.cid, sd.no, sd.data, u.name FROM webform_submitted_data sd LEFT JOIN webform_submissions s ON s.sid = sd.sid LEFT JOIN users u ON u.uid = s.uid WHERE sd.sid IN (10, 11, 12, 13, 14, 15, 16, 17 , 18, 19, 20) ORDER BY sd.sid ASC, sd.cid ASC, sd.no ASC;
+----+-------------+-------+--------+-----------------+---------+---------+----------------+------+-----------------------------+
| id | select_type | table | type   | possible_keys   | key     | key_len | ref            | rows | Extra                       |
+----+-------------+-------+--------+-----------------+---------+---------+----------------+------+-----------------------------+
|  1 | SIMPLE      | sd    | range  | sid_nid         | sid_nid | 4       | NULL           |  121 | Using where; Using filesort |
|  1 | SIMPLE      | s     | eq_ref | PRIMARY,sid_nid | PRIMARY | 4       | drupal7.sd.sid |    1 |                             |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY         | PRIMARY | 4       | drupal7.s.uid  |    1 |                             |
+----+-------------+-------+--------+-----------------+---------+---------+----------------+------+-----------------------------+
3 rows in set (0.00 sec)

Proposed modification:

mysql> EXPLAIN SELECT s.*, sd.cid, sd.no, sd.data, u.name FROM webform_submitted_data sd RIGHT JOIN webform_submissions s ON s.sid = sd.sid LEFT JOIN users u ON u.uid = s.uid WHERE s.sid IN (10, 11, 12, 13, 14, 15, 16, 17 , 18, 19, 20) ORDER BY sd.sid ASC, sd.cid ASC, sd.no ASC;
+----+-------------+-------+--------+-----------------+---------+---------+---------------+------+----------------------------------------------+
| id | select_type | table | type   | possible_keys   | key     | key_len | ref           | rows | Extra                                        |
+----+-------------+-------+--------+-----------------+---------+---------+---------------+------+----------------------------------------------+
|  1 | SIMPLE      | s     | range  | PRIMARY,sid_nid | PRIMARY | 4       | NULL          |   11 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | sd    | ref    | sid_nid         | sid_nid | 4       | drupal7.s.sid |    1 |                                              |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY         | PRIMARY | 4       | drupal7.s.uid |    1 |                                              |
+----+-------------+-------+--------+-----------------+---------+---------+---------------+------+----------------------------------------------+
3 rows in set (0.00 sec)

So after making the proposed change, we're introducing a potentially devastating performance killer: the dreaded "Using temporary" flag, meaning MySQL has to write a file to disk in order to generate the results of this query. Temporary tables are the devil of performance. That's why this query was specifically written to sort and filter on the webform_submitted_data table alone, so that the indexes could be used to optimize the result (MySQL can only use one index per query when doing a sort).

However after investigating this, it turns out that we're not doing the best we can. If the original query is maintained but we add an additional index on sid, cid, and no, then we can get an even better result where the entire result is pre-sorted for us by the index:

Original query with "webform_get_submissions" key: (sid, cid, no)

mysql> EXPLAIN SELECT s.*, sd.cid, sd.no, sd.data, u.name FROM webform_submitted_data sd LEFT JOIN webform_submissions s ON s.sid = sd.sid LEFT JOIN users u ON u.uid = s.uid WHERE sd.sid IN (10, 11, 12, 13, 14, 15, 16, 17 , 18, 19, 20) ORDER BY sd.sid ASC, sd.cid ASC, sd.no ASC;
+----+-------------+-------+--------+-------------------------+-------------------------+---------+----------------+------+-------------+
| id | select_type | table | type   | possible_keys           | key                     | key_len | ref            | rows | Extra       |
+----+-------------+-------+--------+-------------------------+-------------------------+---------+----------------+------+-------------+
|  1 | SIMPLE      | sd    | range  | webform_get_submissions | webform_get_submissions | 4       | NULL           |  121 | Using where |
|  1 | SIMPLE      | s     | eq_ref | PRIMARY,sid_nid         | PRIMARY                 | 4       | drupal7.sd.sid |    1 |             |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY                 | PRIMARY                 | 4       | drupal7.s.uid  |    1 |             |
+----+-------------+-------+--------+-------------------------+-------------------------+---------+----------------+------+-------------+

So in summary: I don't think we should change the query because it may cause performance issues. Instead I think we should prevent the query from being run if a user has deleted all the available components and just show an empty row on the Results tab. I'll open a new issue to add the new index for additional performance gains.

Over in #2019359: Add additional index to optimize webform_get_submissions(), some further analysis found that the additional index really isn't necessary, because we already add NID to all our queries so the primary key in the webform_submitted_data table can be used directly. However the justification still stands for not switching this query to sort/filter across multiple tables, because it would impact the performance of the query negatively.

The attached patch take a different approach: It gets the submission data with the earlier query to webform_submission. The query to webform_submitted_data has no joins at all.

Thanks this looks good! This moves more data into the submission query and skips the data being redundantly included in the submission_data query. And as is the goal, it prevents the undefined properties on the submission object. I'll give this a full review when I get the chance. Overall it looks great.

Rerolled after some conflicts in the 7.x-4.x branch. Unfortunately after trying this out I found that Webform no longer properly loads individual submissions. Because the "webform_get_submissions_sids" query isn't executed if a list of SIDs were passed in, so all the basics of the submission aren't loaded.

To reproduce this problem easily, just view an individual submission directly and see the stream of undefined property errors. Patch here is a straight reroll. Still needs work.

Removing dvm() line.

Thanks. I see the problem now. The first patch is based on the patch in #22 and fixes the problem. It now does the webform_get_submissions_sids query for all requests, so the submission information is always loaded. The second patch fixes the indentation.

Thanks Liam. The second patch didn't apply to the 4.x branch for some reason, but the first one worked fine and was easier to diff anyway. I just manually fixed the indentation after applying it and everything looks good. I like that this reduces the amount of duplicate data in every row of the data query. Previously we were pulling in the submission information in every row of data. Now we're only pulling in the exact information we need in the data query.

Committed to 7.x-4.x. Thanks again for all your contributions!

Thanks. I should have been more clear: The second patch had to be applied after the first. It only makes the needed indentation corrections.

Can we back port it to 3.x as well. As I came across this issue in 3.x.

Sure, we could probably do that. The patches don't apply cleanly to 3.x though, so yeah, porting necessary. Shouldn't be difficult though.

Here is an attempt.

...

Updated patch #29 as it was missing a close bracket { when applying to 7.x-3.20.

The patch worked well after that.

My #32 patch wasn't formatted correctly, my first attempt at a patch :)
#33 should be formatted and fixed up correctly.

Edit: Again I didn't setup my patch properly. Hopefully this one will work correctly

Are we worried about 108 fails?

I don't think so. 7.x-3.x is receiving only critical bug fixes, which this isn't.