WPFA Mail Connect is a scaffold, and it says so in the first line

What exists today in the repository

The README is unusually direct about the state of the project. It calls wpfa-mailconnect a WordPress plugin scaffold by FOSSASIA to integrate email connectivity into sites and other WPFA plugins, and then states the current repository status as a minimal plugin skeleton prepared for adding mail connectivity features.

That sentence is the whole adoption decision. If you were hoping to install a plugin and have your WordPress site send transactional mail through a provider API, this is not that. What you get is the frame: a plugin bootstrap file, the four standard directories, a translation domain, an uninstall stub, and a documented plan for the features that should be implemented inside that structure.

The included items are listed plainly. There is a WordPress-compatible plugin bootstrap called wpfa-mailconnect.php, standard directories for admin UI, public hooks and shared includes, a translation domain with a language folder, and an uninstall.php stub whose purpose is to keep data cleanup explicit. A note repeats the point: provider integrations for SMTP and APIs, settings pages and email helpers can be implemented inside the existing structure.

The version story is small but worth knowing. The README names 1.0.0 as the current stable release, and the project publishes no GitHub releases, so there is no tag history to consult and no changelog beyond the README itself.

The four directories that decide where your code goes

The structure is the main asset of the repository, and it is the standard WordPress plugin layout, which is what makes it predictable to anybody who has written a plugin before.

wpfa-mailconnect/
├─ admin/        # Admin screens, settings, assets
├─ includes/     # Core classes, loaders, helpers
├─ languages/    # .po/.mo translation files
├─ public/       # Public-facing hooks/assets
├─ index.php
├─ uninstall.php # Cleanup stub
└─ wpfa-mailconnect.php # Main plugin bootstrap

The README ties that layout to a development order, which is the clearest instruction for anyone picking this up.

1. Create feature classes in `includes/` (e.g., loaders, mail adapters).
2. Register admin screens in `admin/` (settings API, capability checks).
3. Add public hooks/assets in `public/` (should you expose shortcodes or public forms).
4. Wire everything from `wpfa-mailconnect.php` (activation/deactivation, loaders).

Two details of that list matter. The admin step explicitly pairs the settings API with capability checks, and the bootstrap file is where activation and deactivation hooks go, which is where a mail plugin has to be careful about what happens to queued mail when a site deactivates a plugin.

The repository root also shows a composer.json and a phpcs.xml, plus a templates/ directory, so dependency management and the coding standard checker are part of the setup even though the README does not walk through either. The phpcs.xml is the machine readable half of the coding standards section, and the composer file is there for you to extend rather than to install from a lock file that the project does not publish.

Installing it as a contributor, and what activation gets you

The README gives two install paths and marks the Git one as recommended for contributors, since the point of this repository is that you will change it.

cd wp-content/plugins
git clone https://github.com/fossasia/wpfa-mailconnect.git

The manual path is to download the repository as a ZIP and upload it in the WordPress admin under Plugins, then Add New, then Upload Plugin. Activation is then a matter of going to Plugins in the admin and activating WPFA MailConnect.

The runtime requirements are stated up front.

* WordPress 6.0+ (recommended)
* PHP 7.4+ (PHP 8.x compatible recommended)

What you get after activation is nothing user visible, and the README says so. There is no settings page yet, no outbound mail behaviour and no admin screen with content. The configure section is written in the conditional: once features are implemented, a settings page under Settings and WPFA MailConnect can expose a connection method of SMTP or a provider API, host, port and encryption, authentication by username and password or by token, a from address and name, and a test email utility. The repository already contains admin/ as an options page scaffold, and the instruction is to hook your settings there.

That is a useful distinction to hold on to when you evaluate this project. The scaffolding for a settings screen exists; the settings screen does not.

The coding standards are the part worth copying

Most of what a reviewer would want from a WordPress project is in the coding standards section, and it is short enough to read in a minute.

The rules are: follow the WordPress PHP coding standards, escape output with esc_html, esc_attr and wp_kses, sanitize input with functions such as sanitize_text_field, use nonces and capability checks for all admin actions, and prefix everything with wpfa_mailconnect_ or WPFA_MailConnect_ so that nothing collides with another plugin on the same site.

That last rule is the one that matters most in a scaffold intended for reuse across several FOSSASIA plugins, and the escaping and capability rules are the ones that decide whether the finished plugin is safe to install on a site with other plugins and untrusted content. The repository has phpcs.xml at the root, so the standard can be checked rather than argued about in review.

The contributing guidance is equally concrete: fork the repository and create a feature branch, keep commits focused and add tests where possible, and open a pull request with a clear description and screenshots of admin UI changes. The screenshots request tells you something about the intended shape of the work, since the admin side is where the visible part of this plugin will live.

Uninstall cleanup and translation are the two details most skeletons skip

Two small pieces of the scaffold are worth singling out, because they are the parts a hand-rolled plugin usually omits and then regrets.

The first is uninstall.php. The README says the repository includes it as a stub, and the reason is stated: extend it to remove plugin options and custom data on uninstall to keep sites clean. WordPress deletes a plugin's files when you delete it, but it does not delete the rows it wrote to the options table or to custom tables. For a mail plugin that has stored provider API keys and logs, that difference matters, and a scaffold that hands you the file and says what belongs in it is doing you a real favour.

The second is internationalisation. The plugin declares the text domain wpfa-mailconnect, and the translation files live in the languages/ folder as .po and .mo files, added and updated in the usual way. Declaring the text domain in the bootstrap file from the start, rather than retrofitting it after a dozen strings have been hardcoded, is the kind of decision that is invisible in a demo and expensive to reverse later.

Together with the prefixing rule, these three things, the cleanup stub, the text domain and the naming prefix, are what distinguish a scaffold that is meant to be built on from a folder of example code.

The work still ahead, and the alternative to writing it

The README suggests the next tasks, and they are a good specification for what a finished plugin needs.

* Add a settings page with the WordPress Settings API
* Write unit tests for adapters (mock transport)

The full list goes further: implement a MailAdapterInterface with concrete adapters for SMTP and provider APIs, provide a Send Test Email action to verify connectivity, and optionally add a logging mechanism, either a logging library such as WP_Logging or a custom table, guarded by capability checks. The interface plus the adapters is the interesting piece, because it is what lets a site owner switch between a plain SMTP relay and a hosted provider API without the rest of the plugin caring.

The alternative to writing all of that is to use an existing mail plugin for SMTP delivery and, if a provider API is required, to write a small plugin of your own that hooks the sending path rather than shipping a general framework. The difference in approach is real: a dedicated mail plugin gives you a maintained settings screen and provider list, while a bespoke hook gives you exactly the behaviour you need and nothing else, at the cost of the settings UI, the test email utility and the cleanup routine that this scaffold already provides the slots for.

The limits of the scaffold are the limits of any starting point. It is a single maintained repository with a narrow scope, its last push was on 2026-05-15, it publishes no GitHub releases, and it has no changelog, so a fork carries the burden of its own release discipline. It is licensed under Apache-2.0, with the terms in LICENSE.txt, which is a permissive licence and a good fit for a plugin meant to be extended and redistributed; read the file for the notice and patent terms rather than treating the name as the whole of it.

Editorial conclusion

WPFA Mail Connect fits a contributor who wants to build a FOSSASIA compatible email provider plugin and needs a reviewed structure to start from, and it does not fit a site owner expecting a working mail integration, because the settings page, the adapters and the test email action are all still to be written. Before you build on it, read wpfa-mailconnect.php and admin/ to see how much bootstrap exists, and check that composer.json is wired the way your project expects, because the README does not document it. The last push was on 2026-05-15, the project publishes no GitHub releases, and the licence is Apache-2.0.

Frequently asked questions

Official sources

1. fossasia/wpfa-mailconnect on GitHub
2. Issues
3. License: Apache-2.0
4. README