gazouteast

mellis – I can confirm the wp_options table bloat with nggallery transients is the cause of your login issues – as soon as I cleaned those and reduced the table by 270,000 entries, our site came back up and I was able to login to admin.

I’ve not yet identified why that bloat occurred – transients should not be retained in that table after they’ve expired.

Why NGG’s transients are not expiring is something for them to sort out.

Cheers
Gaz

Apologies – I thought I was posting to that sub-forum as I was logged into it and clicked “add new” at the top of the topics list.

Please could you move this topic to there?

Supporting what I said above – of the 330,000+ lines that had appeared in the wp-options table, 270,000 of them were transients created by ng-gallery. Once those were removed, the site came back up perfectly with no other changes.

Of the remaining 60,000-ish entries in the table, 57,000 were created by WordFence transients (another plugin).

I’ve seen this issue before – back when WP used Magpie caching, but this is the first time I’ve seen it since Magpie was replaced. Could something have been re-introduced in WP3.6 that is causing this?

Hi mellis

One of my sites just collapsed with a very similar error. Refreshing the error page reveals that the file name and line number at the end of the error will change … however /wp_includes/plugins.php turns up regularly.

On a hunch I looked in the database and found the wp-options table had exploded. Instead of being about 50k it was over 232MB – 99% of that being transient data for nggallery gallery views.

I’m racking my brain for the SQL code to clean them out safely, but cannot remember how to structure it.

Because of the NG Gallery sticky support thread about not deleting the plugin or you will lose all data, I’m loathe to just rename the plugins folder to regain access to wp-admin as I would normally do, so I can’t offer any advice, and I hope the NextGen team hurry up and answer this topic.

Issuing a plugin update will not work NextGen – we cannot get into admin to run the updater – we need a hack to clear the bug, and a sql script to clear the trash – and we need it urgently please.

Richard – many thanks for the spotting of that WP_IMPORTING line.

I’ve now disabled that and set revisions=0 in the wp-config.php and it all works fine now. I waited a while before posting this to make sure no side issues kicked up.

Problem solved ??

Mark
I posted way up there in the thread (2nd post) that I was having similar issues to the OP

In fact, on that same site, I’ve just wiped the entire site, installed WP3.5.1 fresh, added WordFence 3.6.9 as the only plugin, using the default twentytwelve theme … and WordFence still will not save the Options page nor start a scan.

The only post/comment on the site are the defaults ones when you first install WP. Six months now I’ve been waiting for you to comment on my problem, and you haven’t yet.

As I said above, this is on a VPS, and the other domains on that VPS all run WordFence perfectly. I love WordFence, but getting frustrated my one “problem” is being ignored – I’ve lost 6 months of site live time waiting for an answer.

I’m stumped on this – any clues you can point at?

Gaz

Richard

I think I know why that WP_IMPORTING setting is there – it’s to prevent database bloat explosions.

The Zamango feed updates around 20 posts per day after importing the (currently) approx 3600 posts in the game feed. Over the course of just one year that would auto-generate 7500-ish post revisions (365×20) on top of the actual posts. Any manual re-imports would also create 3600 revisions each time.

If I’m correct and based on your comment about it then it would seem that posts from feeds, when revisions are turned off to prevent database bloat, cannot be posted to facebook?

Does the same restriction apply if
[code] define ('WP_POST_REVISIONS', 0); [/code]
is used in wp_config.php ?

OK Richard – just seen your reply above at post #8

I’ll ping the developers on this now – probably take them 24 hours or so to get back to me.

Thanks

Ah-ha … interesting

Had another wild thought and looked in the database to see if there was anything odd in there.

Noticed the guid column was strange –
Zamango posts are saving a guid such as “https://trivia-machine-reloaded”
whereas direct-typed posts are saving the guid as “https://www.freechoicegames.com/?p=1”

The permalinks option is set as “https://www.freechoicegames.com/2013/04/sample-post/” – I re-saved that to see if it makes a difference.

edit to remove some nonsense here

Checking the main php file of the plugin, they use the guid column to set an index for each post, so they can check if the post content has been updated since the last fetch for that post.

Even more stumped now.

Just a random thought – is it possible to build a delay into Publicize (an itchy finger mode) to delay passing the post to facebook for say 60-120 seconds after the publish action of the post?

That way, posts introduced from feeds would have the chance to save in the database and show on site before Publicize triggered the upload to facebook.

Hi Richard – tried it with WordFence de-activated and Zamango still didn’t post to facebook.

Checking the facebook page (facebook.com/freechoicegames) I remembered that a directly typed post did go to facebook a few days ago.

Perhaps there’s something in Publicize blocking posts from feeds, and only allowing direct entries through?

On the site at work (which I manage) we have wordfence and jetpack, and there’s never a problem with Publicize – all manually-entered posts are on facebook and twitter within seconds.

Hi Richard – it’s in the first line of the OP

Gaz

Just noticed this thread is marked resolved – it is NOT !

The issue reported in the OP still manifests, however it has stabilised around Add Media works in Posts, but not in Pages. The WYSIWYG insert link button does not work at all.

Hi Jeremy – if you re-search for information about iFeature Pro on WordPress 3.5.x and widen the search to all CyberChimps themes, you’ll see they’re all having major problems since WP3.5 and the early January release of JetPack.

In fact, it’s got so bad that CyberChimp have withdrawn all support for non-current versions of their themes, effective last month, which is really bad customer service for those of us who only bought our themes at the end of last year. They’ve even stopped issuing the latest version of iFeature Pro 4.x and it’s not possible to easily migrate to the 5.x version because the codebase and database tables are completely different.

I still remain convinced, because of the nature of the assorted issues, that JetPack is the central cause of the conflicts and issues.

Hi Ipstenu

Returning to this topic after a couple of months bug hunting.

Still getting the Add Media issue on most sites, including ones which have zero plugins (not even Akismet or JetPack) other than Total Privacy, because only the demo data is being input before the build starts.

Strangely, there seems to be a correlation between how many things have been clicked in admin and whether or not the Add Media button works – – On some sites, if I go straight to add or edit a post, the button works for a few uses then bombs out and stops. If I do a few things such as plugin upgrades of settings/options changes before I go to add/edit a post, then the Add Media button doesn’t work at all.

In Pages, forget it – it never works at all, no matter what I do.

These are all standalone sites (not multisite) if that helps.

Still haven’t been able to figure it out, but am currently wondering about wp_enqueue() since 3.5 and the new media manager.

Gaz

Grant, thanks for the input.

It’s turning into a bit of a wierd issue this as it’s rolled from a permanent problem to an intermittent one.

It’s intermittent in a strange way too. The Add Media button works for the first media-addition when a computer has been restarted for whatever reason. Sometimes it works for the second addition too, then it just stops responding again.

This is still with the iMedia Pro theme. Although a couple of plugins have been upgraded since the first report, the only one using javascript that’s been upgraded is WordFence, which I doubt was the cause of the issue.

Right now, I’m just monitoring it and waiting to see if it works itself out over time as I suspect that might happen (seen this type of glitch do that before). In the meanwhile, the content creators are having to go back to the old fashioned way of uploading media outside of a post or page, then including it via the html tab. They’re not happy with this as it’s slow and inconvenient, but apart from ripping the site apart or rebuilding on a new theme to the current styling, I can’t see any other way to get the project finished on time … especially with JetPack Support saying that there’s nothing wrong with Jetpack and it’s the hundreds of other themes and plugins that are coded improperly.

Perhaps (shock, horror) it’s actually WP 3.5 that’s coded incorrectly? Wouldn’t be the first time for that either. I keep getting drawn back to the trac ticket that Nacin raised (mentioned above) about problems with Add Media in a post or page during 3.5’s beta testing … hmmm? I do also wonder about the hosting too (1&1 UK), but that might be a red herring.