Jer Clarke

Thank you. That’s what I needed to hear. Looking forward to a new version and appreciate having a response from one of the developers.

More: It’s specifically merge variables (in my case groups on one site and HTML/Text radio on another) that cause the problems. Sites without merge variables wouldn’t exhibit the problem.

Please add “test plugin update on site with active group options in the form” to your QA list ??

Also: After resaving my form, my “groups” option became unticked and wasn’t visible on the form. IMHO this shouldn’t happen when I use “Update list”. It should remember the “Show” checkbox for any merge variables shouldn’t it?

Okay, after even more debugging I’ve finally identified the real problem, which is that the recent update dramatically changed the format of the ‘mc_merge_vars` option in the database, but nothing was done to prevent the old format from triggering neverending errors.

So the notices I mention above were caused by my list being saved in the old format but run by the new code. When I resaved my list the result was all my “fixes” became notices since the new code didn’t have the old fields (‘req’ etc.).

Can a developer from MC comment on this? What was your plan? Did you test existing sites for compatibility with the new code?

If refreshing the list was necessary after update, why wasn’t it at least mentioned in the changelog?!?

Really a change like this should come with something that automatically updates the settings that will cause errors. If not it should automatically warn users with out-of-date settings that they need to reload their MC options. BARE MINIMUM would be a warning in the Changelog.

So in the end only a couple of my bugs mentioned above are still relevant (specifically the one about $merge->$var['tag'] = $opt_val which I think is PHP7 related).

Mostly I need you to think about backwards compatibility more!

Seems like this is a pretty big problem. Several other posts about ReCaptcha integration breaking forms here on the forum.

I wish I could just use Really Simple Captcha. It always worked for me.

Same here. Subscribing in case of follow-up.

Related: https://www.ads-software.com/support/topic/error-when-submitting-form-2?replies=6#post-8665351 (also several others, may be a temporary problem with ReCaptcha IDK just tried setting it up today and find forum full of other people having problems.)

+1 sad that at WP 4.5.3 this still isn’t fixed.

Added to the list of things I need to patch in my copy of the plugin.

Look in /wp-content/mu-plugins/ and see if the plugin is there.

Also try installing Limit Login Attempts normally and see what happens. Maybe enabling the real thing will make the menus show.

#missionaccomplished

FWIW I support them doing this overall. I bet your site, like the others that share the server, is faster and more reliable because they handled the login spam for you.

That said it should have been obvious what was going on, so you have a right to be confused/dismayed. It sucks that “gd-system-plugin” didn’t show in the admin and/or didn’t have a description that clarified what it did (i.e. which plugins/features it auto-enabled that deviate your site from a clean WP install).

Wow okay this sounds like it might be something specific about your setup.

Do any of you see the plugin in /mu-plugins/?

That would explain why it’s autoloaded and can’t be removed.

It’s also possible that your hosting provider is enforcing the use of LLA (I know Dreamhost has auto-enabled WP-Supercache in the past). This would be a logical move or hosts since login spam can bring a server to it’s knees and has little to do with whether a site is actually popular or not (so cheap hosting is even more susceptible to small amounts of login spam).

FWIW this is a great plugin, so having it enabled is a good thing 99% of the time. If you are stuck with it just deal with it and remember your passwords!

If you can’t remember your passwords you are probably not using one of the now-mandatory password management applications (1password, lastpass, keepassx) and need to start doing so ASAP.

This is not a problem for me right now. Running WP 4.4.2 and LLA: 1.7.1

Are you two still experiencing the issue? Maybe it was fixed by WP 4.4.1/4.4.2?

If so please mark this ticket as resolved.

ATM I’m having the opposite problem: Plugin is working, shows in plugins list but SETTINGS > LIMIT LOGIN ATTEMPTS is nowhere to be found.

The settings page should be at:

Settings > Limit Login Attempts

in wp-admin.

I personally am having a problem where the menu item isn’t appearing on my VPS, but it IS appearing on my local install. Trying to debug the problem (similar PHP version) but it’s possible that there is an edge-case where the menu isn’t visible.

Here’s the answer: https://github.com/WP-API/WP-API/issues/1526

It’s (IMHO) a bug that ONLY affects posts where the featured image ISNT attached to the post being fetched. So if you re-use uploads as featured images the second/third post to use it will have issues.

Re-uploading predictably fixes it because the new upload is attached to the right post.

Thanks, done! https://github.com/lesterchan/wp-print/pull/7

Thanks! Love how quickly you replied!

Thanks John for your response and for getting back so quickly!

It works great as far as I can tell. Definitely showing in the menu and the list of queries is working. Now I can know that my use of wp_cache_get is indeed relieving strain on that second DB ??

My main request would be that you put the instructions above into the plugin’s Notes or FAQ sections, where they’d be a lot easier for people to find.

Another would be to add some kind of marker between the two results in the menu. Right now it’s like:

3.79S 62.59MB 0.3245S 138Q 0.5809S 19Q

which works but isn’t clear at all, you have to know/remember that you have two objects going and that’s why you have the extra “S” and “Q” items. Something simple like adding a pipe could go a long way:

3.79S 62.59MB 0.3245S 138Q | 0.5809S 19Q

Alternately something like a database icon before each DB listing could be cool, but also take up more space which isn’t ideal.

Oh yeah last thing is that in the “Queries” listing for the second wpdb instance I see this message:

Extended query information such as the component and affected rows is not available. Query Monitor was unable to symlink its db.php file into place. See this wiki page for more information.

I don’t get that on the first one and it seems like it’s probably related to using the second db feature more than anything.

Thanks! Here’s my filter code for anyone else who finds this and wants an example to work from:

/**
 * Hook into Query Monitor plugin to register gv_lingua->db for tracking
 *
 * @see QM_Collector_DB_Queries::process where the filter is run
 * @uses $gv_lingua->db where the lingua wpdb object is stored
 * @global object $gv_lingua GV Lingua object which contains the class
 * @param array $globals_wpdb Array of db objects that Query Monitor tracks
 * @return type
 */
function gv_query_monitor_track_lingua_db($globals_wpdb) {
	global $gv_lingua;

	/**
	 * If the lingua db object exists insert it with (meaningless) lingua_db slug
	 */
	if (is_object($gv_lingua) AND isset($gv_lingua->db) AND is_object($gv_lingua->db))
		$globals_wpdb['lingua_db'] = $gv_lingua->db;

	return $globals_wpdb;
}
add_filter('qm/collect/db_objects', 'gv_query_monitor_track_lingua_db');