Hi SebCorbin,
oops, updating to the latest module version breaks polls that were created before.
Instead of previous added answers, we get "no answer" as values in all fields.

Newly created polls work fine.

Not sure yet, why.
It could have something to do with how values get stored in db.

CommentFileSizeAuthor
#7 screenshot-makemeeting-node.png24.24 KBindigoxela
#5 makemeeting-2821092-existing-polls.patch474 bytesindigoxela

Comments

indigoxela created an issue. See original summary.

SebCorbin’s picture

SebCorbin commented

Have you tried to flush your caches ?
I've split up the code into more files and those need to be detected by Drupal

indigoxela’s picture

indigoxela commented

Yes, I've been flushing cache several times.

What I found out so far: $key is false for answers added in the previous version.

indigoxela’s picture

indigoxela commented

Some more details:
Drupal 7.50
no other contrib module enabled

Steps to reproduce:

Install makemeeting-7.x-2.0 (previous version) create content type, add field, create some nodes, add several answers.

Update to makemeeting-7.x-2.1, flush cache as usual.
Visit the formerly created polls.
"No answer" everywhere.

Edit such a broken answer.
difference in $answer:
old:
array(2) { ["1477094400:sugg:0"]=> int(1) ["1477180800:sugg:0"]=> int(1) }
new:
array(2) { ["1477087200:sugg:0"]=> int(1) ["1477173600:sugg:0"]=> int(1) }

Hey, did you change something in date/timezone handling?

indigoxela’s picture

indigoxela commented
StatusFileSize
new makemeeting-2821092-existing-polls.patch474 bytes

Actually you did change something with timezone:
http://cgit.drupalcode.org/makemeeting/commit/?id=d7c7fd8441a69c1624952f...

This patch brings back preivous behaviour.
But I'm not sure.
In case it is important *not* to use date_default_timezone_set('UTC') in function _makemeeting_date_timestamp() anymore, updating could be a bit more complex.

SebCorbin’s picture

SebCorbin commented
Status: Active » Fixed

I've worked on timezone handling, normally fixing this.

This is what I did:

  • migrated timestamps to real dates in data (as UTC), that was your problem
  • add timezone data from the user that submitted the poll
  • display date with timezone handling for user answering poll
  • always save as UTC, always display depending on user's timezone

Please test it with a backup as you may lose/corrupt data

indigoxela’s picture

indigoxela commented
StatusFileSize
new screenshot-makemeeting-node.png24.24 KB

Some more testing here with updates. What I did:

Fresh Drupal install (7.51).
Installed makemeeting 7.x-2.0
Added node type, added field, created nodes, added several answers.

Updated to 7.x-2.1
drush cc all
As expected: formerly added answers are broken. But I didn't edit any of these.
Added some more nodes, added several answers.

Updated to 7.x-2.x (git clone)
drush updb, drush cc all
Cool, all answers added in 7.x-2.0 are back! Timezone was set correctly.
Weird: not all answers added in 7.x-2.1 are there.
Every last answer in set is "no answer". It doesn't seem to matter, how many dates or how many suggestions are used.

Screenshot is attached.

SebCorbin’s picture

SebCorbin commented
Status: Fixed » Needs work

Thanks a lot for this thorough testing (+screenshot), that will help me find the bug and I'll add an automatic test to it.

I'll try to reproduce and fix ad soon as I can.

indigoxela’s picture

indigoxela commented

Little update after some more research.

Not only the last answer per set is wrong. The whole answer set is off by one.
Just coincidentally the dates I used for testing were serial (tomorrow, day after tomorrow,...)

Dates added in 7.x-2.1 are alltogether off by one here (timezone).
Your approach works fine with data added in 7.x-2.0, because it was reliably UTC.

Data added in 7.x-2.1 do use a timezone (in my case Europe/Berlin), but I see no chance to distinguish, which existing entries were UTC and which were in default (php/Drupal) timezone.

indigoxela’s picture

indigoxela commented

Any update on this issue?

The longer you wait, the worse it gets...
But I don't want to stress you out.

drupal-son’s picture

drupal-son commented

I can confirm this issue.

When the poll answer is edited from the UI and then hit the Submit button, it raises the following AJAX error:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /system/ajax
StatusText: Internal Server Error
ResponseText: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AS revision_id, AS bundle
FROM
og_membership ogm
INNER JOIN ON . = ogm.etid
' at line 1: SELECT DISTINCT ogm.entity_type AS entity_type, ogm.etid AS entity_id, AS revision_id, AS bundle
FROM
{og_membership} ogm
INNER JOIN {} ON . = ogm.etid
WHERE (ogm.gid = :db_condition_placeholder_0) ; Array
(
[:db_condition_placeholder_0] => 2139
)
in field_sql_storage_field_storage_query() (line 652 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/modules/field/modules/field_sql_storage/field_sql_storage.module).

But after refresh the node, the updated answers are properly rendered.

If I try to delete the poll answer and confirm the action, I get the following critical error:

Notice: Undefined index: entity_type in og_query_og_membership_alter() (line 1418 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/sites/all/modules/og/og.module).
Notice: Undefined index: entity keys in og_query_og_membership_alter() (line 1421 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/sites/all/modules/og/og.module).
Notice: Undefined index: base table in og_query_og_membership_alter() (line 1427 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/sites/all/modules/og/og.module).
Notice: Undefined index: entity keys in _og_query_og_membership_alter_conditions() (line 1549 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/sites/all/modules/og/og.module).
Notice: Undefined index: entity keys in _og_query_og_membership_alter_conditions() (line 1549 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/sites/all/modules/og/og.module).
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AS revision_id, AS bundle FROM og_membership ogm INNER JOIN ON . = ogm.etid ' at line 1: SELECT DISTINCT ogm.entity_type AS entity_type, ogm.etid AS entity_id, AS revision_id, AS bundle FROM {og_membership} ogm INNER JOIN {} ON . = ogm.etid WHERE (ogm.gid = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 2139 ) in field_sql_storage_field_storage_query() (line 652 of /srv/bindings/92f04c7dda1e48fd8780733eb40c39b6/code/modules/field/modules/field_sql_storage/field_sql_storage.module).

Regards,
Ariel