Signup forms

Integrations with other form plugins

Wynko’s own signup form isn’t the only way to subscribe someone to a Laposta list. Wynko → Integrations lists optional bridges that let a form built in another plugin write to Laposta through Wynko — reusing your API key, your list and field definitions, and your activity log, without that other plugin needing to know anything about Laposta.

Every integration ships switched off. A site that doesn’t use one pays nothing for it. Turn one on from the Integrations screen; an integration can only be activated while the plugin it bridges to is also active.

The bundled integrations

Two come with Wynko:

• Contact Form 7 — reads a native Contact Form 7 checkbox tag, [checkbox wynko-optin-{list_id} …], that you paste into your form’s own template. A submission with that box ticked is subscribed to the list the tag names.
• HTML Forms — the same idea for the HTML Forms plugin, which has no typed tag system, so you paste a small block of HTML instead.

For both, any Laposta fields the list marks required are supplied by form fields you name wynko-{field_name} exactly. Each integration’s Settings screen shows you the precise tag or HTML to paste for each list, so you don’t have to work out the names yourself.

Because these bridges attach to another plugin’s own form, they don’t go through Wynko’s signup pipeline — there’s no Wynko honeypot, no post-submit redirect, and the per-form rate-limit cap doesn’t apply. The per-visitor cap still does, counted against the IP address that other plugin resolved. See Settings reference for the rate limits.

When the plugin it bridges to goes away

If you deactivate Contact Form 7 (or HTML Forms) while its Wynko integration is still switched on, Wynko notices on the next page load, switches the integration back off on its own — leaving it “on” would misrepresent what’s actually running — records an error in the activity log (so a critical email alert goes out if you have those enabled; a form may have just gone quiet), and shows a one-time admin notice naming the integration.

The Integrations screen’s Deactivate link also warns you, in the confirmation dialog, about the concrete thing that stops working — for the Contact Form 7 bridge, that any opt-in checkbox already pasted into a form stops subscribing anyone.

Integrations from other developers

The bridge list is open: any plugin or theme can register its own integration, and it then appears on the same screen with its own name, description, version, and documentation link. Integrations not provided by Wynko are developed and supported by their authors — for a problem with one, contact its developer.

Building your own integration

An integration is a PHP class that implements Wynko\Integrations\Integration and is added to the wynko_register_integrations filter (available since Wynko 1.2). Wynko then lists it on Wynko → Integrations, stores its on/off state, and calls its boot() method once — only when an admin has switched it on and its is_available() check passes.

The contract

Implement all of these:

Method	Returns	What it’s for
slug()	string	Stable identifier, e.g. my-form-plugin. It’s the key your enabled state is stored under, so never change it across releases.
name()	string	Display name in the Integrations list.
description()	string	One sentence shown under the name.
author()	string	Your name or plugin name for the “Provided by” column. '' marks it as bundled with Wynko.
author_uri()	string	Where author() links to. '' shows it as plain text.
documentation_uri()	string	Where “View documentation” links. '' shows no link.
version()	string	Your plugin or theme’s version — not Wynko’s.
is_available()	bool	Whether the thing you bridge to (another plugin, usually) is actually active right now.
boot()	void	Wire up your own hooks here. Called once, only when enabled and available.
render_settings()	void	Print your settings screen, or do nothing if you have none. Everything you echo here is yours to escape, and any action it submits is yours to protect with a capability check and a nonce.
deactivation_warning()	string	One sentence naming what stops working when an admin turns you off. '' falls back to a generic warning.

name(), description(), author(), version() and deactivation_warning() are always rendered escaped by Wynko, whatever they return.

Registering it

Your plugin depends on Wynko, never the other way round, so your registration has to do nothing — not fatal-error — on a site where Wynko isn’t active:

add_action( 'plugins_loaded', function () {
	if ( ! interface_exists( '\Wynko\Integrations\Integration' ) ) {
		return;
	}
	add_filter( 'wynko_register_integrations', function ( array $integrations ) {
		$integrations[] = new My_Form_Plugin_Wynko_Integration();
		return $integrations;
	} );
} );

Writing to Laposta

From your boot() hooks, send a subscriber with Wynko\Api\Subscribers::create( $list_id, $email, $ip, $source_url, $custom_fields, $skip_doi ) — it reuses Wynko’s API key resolution, transport, and error handling. The wynko_subscriber_data filter (see Hooks and filters) fires on every such call if you or others need to adjust the payload.

Two behaviours to plan for

• Availability and enabled state are separate. Wynko calls boot() only when both say yes. If your dependency disappears while an admin had you switched on, Wynko turns the stored setting back off on its own, logs it, and shows a one-time notice — so you never have an “enabled but unavailable” state to handle.
• Rate limiting. A bridge submission goes through the per-visitor IP cap (Wynko\Throttle::allows_ip()) but not the per-form cap, which is scoped to Wynko’s own forms.

The bundled ContactForm7Integration and HtmlFormsIntegration classes in the plugin source are complete, working examples.