bilmel

I removed all of the :: followed by number fields, and found a couple of places where the data describing the dropdown field was either incomplete, unused, or shown as lower case while the database text field was upper case. After doing this, I found one record that displayed “0” for its value, and changed it to a valid status.

Now everything seems to be working!

I tried removing the ::1 from the fields, and it didn’t make a difference with this problem.

I just re-read the documentation, and perhaps I shouldn’t have a “::1” listed in the database fields, since that seems to be the method for creating Option Labels, while what I want is just the specific fields offered by the dropdown.

I just looked at the database via phpmyadmin, and in each record the dropdown value appears to have the string, for example “Alaweo St” that belongs in the record.

Likewise, the database fields table has all of the strings for each dropdown, with the same index values that were entered into the database fields portion of the plugin, ie Alaweo St::1

The change I made previously to the database fields, at your suggestion, was from 1::Alaweo St to Alaweo St::1, etc for each field.

If the value was stored in the record, and then mapped to the field name in the database field, I’d understand the confusion, but since the record contains the string corresponding to the chosen dropdown, I don’t understand why it displays correctly when viewing the record, but does not in the dropdown when editing the record.

I can set you up with access to the database if you need it.

Mahalo.

I wasn’t clear; when you select a record for editing, with either the front or backend, instead of displaying the value already present in the drop down, it displays a blank field, and if you subsequently save the record, the blank selection overwrites the original value. Once you actually select the correct dropdown value and save it, it works normally.

Mahalo

OK, I read the blog on this topic; for me, changing the WP timezone to “Honolulu” versus “UTC-10” seems to have fixed PDB’s issue.It seems very strange that this would make a difference.

My current server uses UTC as its base time. Setting the WordPress timezone to UTC-10 seems to work fine for other plug ins, such as The Events Calendar. Whether I set the “Sync PHP Timezone” or not, I still see the date recorded in PDB as being off by ~10 hours.

• This reply was modified 4 years, 11 months ago by bilmel.
• This reply was modified 4 years, 11 months ago by bilmel.
• This reply was modified 4 years, 11 months ago by bilmel.
• This reply was modified 4 years, 11 months ago by bilmel.
• This reply was modified 4 years, 11 months ago by bilmel.