GFCphotog

@jeremy, well it seems the behavior of how the summary text gets chosen has changed. It used to send out the whole post when that was selected, even if the “more” code was in place, that’s why we weren’t using it.

Well, it works now. The image along with the text above the “more” line in the post is going out – I’m fixed. How about everyone else?

Thanks!
Tim

@jeremy, yes, the summary notification is deliberate. That way there’s a desire to see the whole post with recipe on the blog.

If that might be considered an issue now, it used to work. A summary with a nice image (the top one in the post) used to be sent.

Thanks,
Tim

Yes. I deleted the cache, should have done that before…

Thanks,
Tim

It’s in the right column of most pages, or it was…

I must admit, it went away. I must have deleted it in the last shuffle. Thanks for pointing it out.

It’s back in the right hand column, under the social subscriptions.

Thanks,
Tim

https://glutenfreecanteen.com/

Active plugins (all current except Jetpack):
Askimet
AZIndex
Bibs Twitter Follow Button Reloaded
Easy Recipe Plus
Google Analytics for WordPress
Google XML Sitemaps
Gravatar Widget
Jetpack (v 2.0, stopped updating – too unstable)
Limit Login Attempts
LinkWithin
Pinterest “Pin It” Button Lite
PuSHPress
Quantcast Quantifier
WP Super Cache

Updated to 1.9.1, seems to be working fine so far (stats work).
Thanks for the quick fix!

Jeff, appreciated! I forgot the beta doesn’t use SSL…

I would have said the same thing, except I didn’t get that on my Beta site when I tested v1.9 (free as opposed to paid plugin versions, so some differences), and it doesn’t happen with Jetpack v1.7.

We also have been bit by the “stats not available now” issue post update:
https://glutenfreecanteen.com/

Found it, it was a plug-in after all. Had to build a duplicate site without some of the extras to localize the problem (had to leave the main site up).

The issue is with Easy Recipe, I’ll contact them directly and let them know.

Thanks, I might say the main issue regarding the site is resolved, but the root cause is still open. I used a pretty big hammer to fix the main site db. I would still like to understand to understand why it happened in the first place, and get it fixed as I’m sure I’ll have to do this again.

That was my first thought as well. However the new install created a different database from the first (main) one. The original db was named {id}_wrd1 and the new db that was created used {id}_wrd2. It looks like it was the WordPress Import function that trashed the pair of db’s and created the mixed set of tables across both.

Fortunately, the backup was current. After the backup was restored for the main site’s {id}_wrd1 db, both sites now seem to be behaving as expected.

So, I then did a full restore from backup, all the files and the db tables, the site is back to where it was. I can limp along like this for a bit, but still need to understand why the subdomain screwed things up.

More information:

The new install created db tables _wrd2, the original site’s data was in _wrd1 tables. After the import the tables are all messed up, most have been migrated to _wrd2, leaving the non-standard AZIndex and defunct (no longer in use, hadn’t deleted the tables yet) WPSentinal tables in _wrd1.

Any suggestions on how to untwist the mess?

Ok, all’s well. The blog is stable at WP 3.2.1 with no new errors.

Solution was pilot error on my part. When upgrading to 3.2 the WPTouch/SuperCache settings got lost. Reconfiguring SuperCache to play nice with WPTouch (the exceptions device list) fixed the problem.