[Mitch]

Hey,

So this is weird, and I have no idea when it started. But if I go in and edit any record, once I save and exit, the Address fields are multiplied and places each of the components (eg. Address, City, State) on its own line. Hard to explain, but see that attached screencaps.

I have deactivated all other plugins on that page, but the issues remains.

Have you seen anything like this? Any ideas?

Thanks.

• WordPress 4.4.1
• Kleo 3.1.3
• Connections 8.5.8
• CMap 5.1 (also tried with default template)

Attachments:

You must be logged in to view attached files.

[Steven Zahm]

@ Mitch

Nope, never seen this before. I don’t have any idea what could cause that. I would need a temp admin account so I could take a closer look at this.

[Mitch]

Always happy to provide the ‘never-seen-before.’ :)

So another strange related issue is that in the Manage record area, when you click REMOVE on any item, for example the 5th section of the social links, it removes the TOP section, NOT the one that was clicked. Weird.

I’ll set up an admin account on the dev site for you.

Thanks for the timely reply.

[Mitch]

By the way, I figure you got hit pretty good with the snow. Hope all is well.

So this gets even more curiouser and curiouser. Now, when I go into a record, ALL of the address data is GONE.

Of course then when I save any edit, the address info is gone on the site.

EXCEPT, if you go back in a record that had already been updated (and had all those extra fields). That data is still there, and if you open and save that record, it duplicates all of those fields. Good times.

Fortunately, all of this is happening on the Dev site, but now I’m terrified to try anything on the Live site. :) Adding a login and info in a private post next.

Thanks.

[Mitch]

This reply has been marked as private.

[Steven Zahm]

@ Mitch

Well, it seems the PHP function openssl_random_pseudo_bytes() on your server is broken as it returns FALSE. It’s rare for this to be FALSE, but some systems may be broken or old.

What I did was add a check for FALSE and then used backup function in its place which was already being used if the server didn’t support openssl_random_pseudo_bytes() at all. I made this change to my development files so it’ll be included in the next update so you should not experience this interesting issue again. This one issue was the originating issue causing the other issues you were experiencing.

For debugging I had enabled Query Monitor and set it as a global plugin. I did deactivate it. I also installed and activate the WP Editor plugin so I could easily make this edit. This too is deactivated.

[Mitch]

First, thanks for taking a look. Excellent support as always.

Interesting, as I had not noticed this issue previously. We use a managed WordPress host, so the ‘broken or old’ part is a little disconcerting. I will be passing this along to them for comment.

Could it have anything to do with any changes in WP 4.4? as again, I don’t recall this issue previously.

Two bigger questions.

1) I am experiencing this issue on other sites on the same server. Do I need to make changes there also? or can I just wait for your next release? (or is that a ways out? if so, I’ll need to address).

2) It still seems as though existing records that HAVE data (address, phone, etc…) when I open these records to make any edits, ALL of that address data is gone. So if I save (without reentering the address data from scratch), it saves the record with blank data.

This ONLY happens with records that have NOT been (recently) edited. Meaning if I edit a record that had already been messed up, the new edit does retain the data and works properly. (That sounds weird, does that make any sense?)

Thoughts?

Thanks.

[Steven Zahm]

@ Mitch

re: Interesting, as I had not noticed this issue previously. We use a managed WordPress host, so the ‘broken or old’ part is a little disconcerting. I will be passing this along to them for comment.

That statement comes straight from the PHP doc page explaining why a FALSE would be returned.

re: I am experiencing this issue on other sites on the same server. Do I need to make changes there also? or can I just wait for your next release? (or is that a ways out? if so, I’ll need to address).

I’ll very likely push out an update, very minor, this week. If you wish, all you need to do is copy the class.utility.php file from your sandbox to the live sites.

re: It still seems as though existing records that HAVE data (address, phone, etc…) when I open these records to make any edits, ALL of that address data is gone. So if I save (without reentering the address data from scratch), it saves the record with blank data.

This ONLY happens with records that have NOT been (recently) edited. Meaning if I edit a record that had already been messed up, the new edit does retain the data and works properly. (That sounds weird, does that make any sense?)

Connections stores record data in two locations in the db for performance reasons. The first is a cache and the second is the actual db tables. The actual db table will only ever be access when editing and searching, never for display. The display comes from the cache.

Now, that said… three years ago, maybe longer, all the entry data was read/written to from what is now the cache as the tables did not exist. So, one of those updates, along the way included a routine which added the tables and migrated the data from what is now the cache. It seems that update never migrated the data for some reasons for you. The only solution would be to manually trigger that update. Doing that though, the good entries will now have duplicates of the data when editing an entry.

So… yes, what you described make perfect sense.

[Mitch]

RE: That statement comes straight from the PHP doc page explaining why a FALSE would be returned.

Upon passing along your comments, I received the following from the host:
We recently discovered a bug that may have created this issue. A fix has been applied to the server and hopefully the issue has been resolved.
If you run into further issues regarding this, let us know and our Engineers can take a closer look.

RE: I’ll very likely push out an update, very minor, this week. If you wish, all you need to do is copy the class.utility.php file from your sandbox to the live sites.

Easy enough, I’ll do that.

RE: the other…

ahhh, yeah, some of that data in the sandbox is 2011 (!). So that makes sense. I’ll update the files on a Live site, see what happens and let you know.

Thanks!

[Steven Zahm]

@ Mitch

Sounds like its fix from both ends so you’re good to go.

[Author]

Posts