Fatal error: Class 'WPCF7_TagGenerator' not found

I guess the problem is caused in embedly/dialog.php that loads wp-admin/admin.php. The wp-admin/admin.php is for WordPress core to load admin functions on admin pages, plugins should not load. When the plugin loads wp-admin/admin.php, is_admin() still returns false, so WordPress and other plugins (including Contact Form 7) recognize it’s in non-admin page, this contradiction is probably the direct cause of your issue.

I am having the same problem as zsedelyp.

However, when I deactivate Contact Form 7, I no longer receive the error message.

The above explanation seems to indicate the problem lies within the Embedly code. Embedly is working as expected when Contact Form 7 is deactivated.

Any further insight in this issue would be appreciated.

Hi Takayuki Miyoshi,

Thanks for the feedback. But as jcecilb writes above the Embedly plugin is working as expected when Contact Form 7 is deactivated. Error messages start coming when the Contact Form 7 is active.
And in this previous ticket some other users reported more plugins which conflict with the latest version of the Contact Form 7.
So the problem might lie within the Contact Form 7 code?

Any further insight in this issue would be much appreciated.

Thanks!

zsedelyp, those plugins make the same mistake: they load wp-admin/admin.php or call do_action('admin_init') in the plugin code. Plugins shouldn’t and don’t need to do so at all. Only WordPress core should do.

Normal flow

1. WordPress core loads wp-admin/admin.php.
2. Because it is in an admin page (is_admin() => true), Contact Form 7 loads its admin/includes/tag-generator.php to declare WPCF7_TagGenerator class.
3. WordPress core calls do_action('admin_init').
4. Contact Form 7’s function wpcf7_add_tag_generator_text() is called because it is hooked to the admin_init action.
5. wpcf7_add_tag_generator_text() creates a WPCF7_TagGenerator instance.

Erroneous flow

1. A plugin (such as Embedly) loads wp-admin/admin.php.
2. Because it is not really in an admin page (is_admin() => false), Contact Form 7 doesn’t load its admin/includes/tag-generator.php.
3. The erroneous plugin calls do_action('admin_init').
4. Contact Form 7’s function wpcf7_add_tag_generator_text() is called because it is hooked to the admin_init action.
5. wpcf7_add_tag_generator_text() tries to create a WPCF7_TagGenerator instance and, of course, it fails.

Not only Contact Form 7 is affected by this issue.

@takayuki You could register the admin callbacks on is_admin() only to limit the damage. This is faster in all cases too, because there is no need to pollute the global variable $wp_filters with unused callbacks.

is_admin() && add_action(
    'admin_init',
    'admin_specific_callback'
);

Besides that, the other plugin authors should be informed. The plugin review team should be made aware of this issue too, so they can reject these plugins before the users run into problems.

toscho, thanks for the advice. That makes sense.

@takayuki: thanks for the deeper insight. I forwarded it to the Embedly plugin support. They will consider it in their next update.

@toscho: thanks for the advice. I hope it will work.

@takayuki, do you think you may use @toscho code in the next release? Would seem to resolve the problem for many plugins.

Toscho’s idea will be included in the next release. Regardless, the authors have to address the problem in their plugins. Toscho’s code only hides the problem, not resolves it.

@takayuki: thanks for including Tocho’s idea in the last update! The Embedly stopped conflicting with Contact Form. I know that this is a quick solution and not resolving the problem itself but I really appreciate it. I hope the other plugin authors will clean up their codes.

I have notified the plugin review team. Maybe they can detect occurrences of such includes automatically eventually.

This resolved the issue with dsIDXPress Plugin also, good fix guys! I agree @toscho, it would be nice for the plugin team to look out for these kinds of includes as the plugin authors I contacted regarding the issue completely denied that it was really an issue on their part. By reviewing this when a plugin is submitted it’s a chance to educate the author on why.

@toscho thank you.