[Jon Erik]

Hi, we are running a WP 3.4.2 site, with connections 0.7.6.6 and cMap 3.0.3
Our problem: the public / unlisted option does not work for addresses, phones, emails or dates.
Example 1: A contact is marked as public, having a phone marked as public, an email as public and a date as unlisted. In the frontend phone is not shown, email is not shown and date is shown
Example 2: A contact is marked as public, having a phone marked as public, an email as public and a date as unlisted. In the frontend phone is not shown, email is shown and date is shown

We have detected no pattern. The database is perfect, both in the independent tables and in the arrays in the contact registry (I think you referred to those arrays as cached).

Now comes the tricky part: you go to the backend, click update button in the contact detail form, and the frontend changes, showing perfectly all public and hiding all unlisted.

We have no cache plugins at all.

We tried upgrading to Connections 0.7.9 and the problem persists.

We are currently out of ideas. Any idea or clue, please?

[Steven Zahm]

@ Jon

I know you said the cached arrays are correct but the “fix” of simply updating the entry in the admin actually suggests that the cache of the source data are somehow out of sync.

Honestly the only way for me to even begin to make any suggestions on how to fix, I would need a temp access to both the WP admin and the database.

How many entries are we talking about total?

[Jon Erik]

264 entries

And yes, everything reeks of cache problem. But all data in database is correct, checked in three different contacts. And in everyone of them, when updating, the problem got solved.

Now trying possible plugin incompatibilities.

[Steven Zahm]

@ Jon

Not sure it could be a plugin conflict. Try this … open the class.output.php file. Do a search for Block(. In each instance that you see , $cached = TRUE ) { on the same line; change TRUE to FALSE. There should be only 8 instances. Save and upload. Now Connections will never use the cached data from the main table. Doing this will definitely cause much more db usage.

[Jon Erik]

Already tried that, and got every date shown…
We did some debugging with the dates:
card.php, line 51, getDateBlock
class.output.php, line 1670, getDates
class.entry.php, line 2606 (if cached):

				$dates = unserialize( $this->dates );
				if ( empty( $dates ) ) return $results;

Echos show that $this->dates has an array, e.g. :
a:1:{i:1038842957832;a:5:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-04-28";s:5:"order";i:0;s:9:"preferred";b:0;}}

But $dates is empty. Somehow the unserialize detects some saved elements as wrong and falls in the next if, returning the results.

Same problem with CACHED = TRUE:
In line: (around 2670)
$dates = $connections->retrieve->dates( $atts );
The $dates is an empty Array.

So we are thinking it could be a problem with the data when we upgraded. Did we miss something to be done?
Right now the backend understands all the data in the DB, as it shows it perfectly. The problem is the unserialize, as it does not understand the cached values. Any way (php code) that we could make a mass update for the 264 records?

[Jon Erik]

The data shown in the cached values clearly changes after the update, here are the previous and after values:

dates previous
a:1:{i:1058893055930;a:5:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-11-20";s:5:"order";i:0;s:9:"preferred";b:0;}}
dates after
a:1:{s:32:"d48e7b5f0495de9616c62604483ced99";a:6:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-10-31";s:2:"id";s:3:"434";s:5:"order";i:0;s:9:"preferred";b:0;}}

And pretty much the same with email, phone, addresses.

In the case of a contact that shows the dates correctly (not showing unlisted dates), the serials are:
date previous
a:1:{s:32:"4889aec3304e1d0fa03ecaea16960a1c";a:6:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-05-21";s:2:"id";s:3:"445";s:5:"order";i:0;s:9:"preferred";b:0;}}
date after
a:1:{s:32:"2c8e778e108d48c298c1157796ca44b9";a:6:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-05-21";s:2:"id";s:3:"445";s:5:"order";i:0;s:9:"preferred";b:0;}}

So it is quite obvious that the error comes from the way that the serialize has been made: some of the data has been storaged as integer ?!?!
That would explain why the update solves the problem.

We have confirmed that the new values stored (new contact) are done as string, but if we repeat the same process: make a new contact (public with one unlisted date), save it, we get this cached date:
a:1:{s:12:"439828048886";a:5:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-09-25";s:5:"order";i:0;s:9:"preferred";b:0;}}
It shows perfectly, but if we update again (no modifications) the cached value changes to:
a:1:{s:32:"74469e7a4f9b2c5ece4e79227cd68b72";a:6:{s:4:"type";s:8:"birthday";s:10:"visibility";s:8:"unlisted";s:4:"date";s:10:"2013-09-25";s:2:"id";s:3:"512";s:5:"order";i:0;s:9:"preferred";b:0;}}

If you put one line over the other you can see that a couple of new string datas are added in the update: the strings “id” and “512”, which is the id value in the wp_connections_date table. The frontend works perfectly both previously and afterwards the update, but that change appears. Should it be that way?

We still think that it is related somehow to the upgrade, but anyway this gives us a clear way to solve the problem: do you have any php code for mass updating?

[Steven Zahm]

@ Jon

It doesn’t make any sense that changing the flag for for cached doesn’t work. That’s the only difference between showing the data in the frontend and the admin/edit form. Question, after you changed the cache flag, did you check while logged out or in? If you didn’t then you’re viewing the data with the same permission you have as in the admin; which means you would see all listed. That would be expected.

Another quick question … which version where you running that worked and which version did you update to where it stopped working? If you have that info, I could pull a diff and see what might have caused the issue to begin with. If you don’t know, no worries.

Bulk updating should be simple. You need to be on 0.7.9+ for this to work:

add_action( 'cn-loaded', 'cnBulkUpdate' );

function cnBulkUpdate() {

	$results = $connections->retrieve->entries();

	foreach ( $results as $row ) {

		$entry = new cnEntry( $row );
		$entry->update();
	}
}

Dropping this in the theme’s functions.php file should do it.

A few words of caution…

I didn’t test the code, but there’s no reason it should not work.

IMPORTANT: Put your site in maint mode and sure no others are on the site before you add this code because it will run on every page load. That would be bad.

I would test with a single broken entry first to make sure it’s all good; like so:

add_action( 'cn-loaded', 'cnBulkUpdate' );

function cnBulkUpdate() {

	// X == the entry ID to update.
	$results = $connections->retrieve->entries( array( 'id' => X ) );

	foreach ( $results as $row ) {

		$entry = new cnEntry( $row );
		$entry->update();
	}
}

I would also suggest increasing the PHP memory and max exec time. What you have set now should be perfectly fine; but why chance it, right?

After you test on a couple and you’re satisfied that it worked. Go ahead and do them all. Don’t worry about excluding the ones you tested on.

Let me know how it goes.

[Jon Erik]

Ok, first your ideas:
– “after you changed the cache flag, did you check while logged out or in?” : Logged out, I usually try to work with Firefox in the backend, while opening the frontend in the damned IE. Even more, the Super Admin role has all the connectiosn permissions turned off, so he doesn’t see the unlisted ones.

– ” which version where you running that worked and which version did you update to where it stopped working?”: I am not sure that is the problem, it is the only thing that has changed that could access the connections tables in the DB, as the changes we have made are for the multilanguage support and how categories are shown. We went from cMap 2.0.10 in connections 0.7.3.1 to cMap 3.0.3 in connections 0.7.6.6 .

As for the bulk update: we are trying this in a local copy of the website, so we do not have the problems you foresaw. Another thing: we have returned to your code, just in case our changes are interfiring in some way that we cannot see.
As we have the 0.7.6.6 version, we changed the code to the following one (correct us if something is wrong):

function cnBulkUpdate() {
global $connections;
	// X == the entry ID to update.
	$results = $connections->retrieve->entries( array( 'id' => 44 ) );

	foreach ( $results as $row ) {
		$entry = new cnEntry();
		$entry->set( $row->id );
		$entry->update();
	}
}
add_action( 'graphene_before_page_content', 'cnBulkUpdate' );

The graphene action is part of the graphene theme, and it is loaded just before the content (obviously, as the name says).

Result after the update:
– in the Frontend: no change, disgracefully. Date is shown, public phones and emails are not shown.
– in the Backend: the unlisted date is duplicated, but with Public visibility. So now the contact has tow dates, exactly the same except for the visibility. And the public visibility is wrong, obviously. Interestingly this problem does not happen in the unlisted phones or emails.

Now, if I click the Update button in the backend everything is solved (except that now the new public date – the wrong duplicated date – appears).

I am trying to see possible differences between the update method and the action of the button, and I do not see any… any ideas?

[Jon Erik]

Still I do not understand why the cached = false option does not work, as the data in the child tables is correct… will look into that later.

[Jon Erik]

Trying that I realized that the date shown is the birthday field, not the birthday date (either cached or its own table). In the example of http://connections-pro.com/documentation/template/cmap/option/ you have show_birthday=’false’ , although it is not described below.
I tried both show_birthday=’false’ and show_birthday=false in the code, and doesn’t change.
I commented out the birthday lines (class.entry.php, lines 2570-2582) and dates are not shown anymore. So that’s why cached false does not work!

Anyway, my solution: comment the birthday block and cached FALSE. It finally works!. I must have done something wrong in the process, because I remember trying cached FALSE and phones did not show…

OK, Steven, thank you very much for your attention. You have helped us and sincerely your code is great, your layering is impressive! I hope we do not need to bother you anymore :)

[Author]

Posts