WPFAevent: putting an Eventyay conference inside a WordPress site

The event data stays in Eventyay, the presentation stays in WordPress

WPFAevent is a WordPress plugin for sites whose event content is managed on Eventyay. The split it enforces is simple and useful: Eventyay holds the data, WordPress holds the pages. The plugin fetches speakers, sessions, events, past events, schedules and code of conduct content from Eventyay or other compatible APIs and renders them inside a WordPress site.

The audience is the volunteer or small team behind a conference site. FOSSASIA maintains the plugin and it is compatible with the Eventyay platform, including the unified Eventyay architecture described as Django plus Vue 3. The problem it solves is concrete: an event that runs on Eventyay still needs pages on the WordPress site that are editable by the site's own editors, with the theme applied, rather than pages pasted from the event platform.

The rendering strategy is the part worth understanding. Shortcodes and blocks use embedded template rendering, so WPFA content can live inside existing theme pages without the standalone template header and footer that a full page template would impose. The documentation states that this is what makes the templates work in both classic themes and block themes, which is the reason the same six pieces of content can be dropped into a shortcode in a classic theme and a block in the block editor.

The plugin describes itself as built with modern WordPress development practices, with a class-based structure, hooks and actions, and internationalization that is translation ready. There is also a base translation template at `languages/event-plugin.pot`.

Six shortcodes and six blocks covering the same templates

The shortcode set covers the full event surface: landing page, speaker directory, upcoming events hub, past events archive, schedule, and code of conduct. There is also a generic `wpfaevent_template` shortcode that takes a `template` attribute, with supported values including landing, speakers, events, past_events, schedule and code_of_conduct.

All shortcodes accept an optional `align` attribute, with values `wide` or `full`. When it is provided the output is wrapped in a matching alignment container, and when it is omitted the shortcode renders the raw embed without altering the surrounding layout. That is a small detail with a practical consequence: a wide section inside a constrained page column can be widened without the editor having to wrap it in an extra container element by hand.

The block editor gets the same six pieces of content as blocks, named `wpfaevent/landing`, `wpfaevent/speakers`, `wpfaevent/events`, `wpfaevent/past-events`, `wpfaevent/schedule` and `wpfaevent/code-of-conduct`. The documentation notes that WPFA blocks render dynamically, so the content follows the API rather than being frozen into the post at save time.

The organisation of the code mirrors this. The `includes/` directory holds the classes that do the work: a loader that initializes hooks and shortcodes, an API class that handles remote fetching with caching, an admin class for the settings page, and separate classes for speakers, sessions and schedule logic. Presentation templates live in `public/partials/`, one per content type, with `public/css/` and `public/js/` for the front end.

Installing it and pointing it at your endpoints

Installation is a clone into the plugins directory. The repository is cloned into `wp-content/plugins/` under a directory name of your choosing:

git clone https://github.com/fossasia/WPFAevent.git event-plugin

Contributors also need the JavaScript toolchain, which is not needed to use the plugin:

# If you use nvm:
nvm install 24 && nvm use 24
npm install

After that, activate Event Plugin in the WordPress admin under Plugins, then configure the API endpoints in Settings, where you enter the URLs for the Eventyay API endpoints for Speakers, Sessions and Schedule, and optionally adjust the cache time in seconds.

Then add the shortcodes to a page or post:

[wpfaevent_landing]
[wpfaevent_speakers]
[wpfaevent_events]
[wpfaevent_past_events]
[wpfaevent_schedule]
[wpfaevent_code_of_conduct]

The matching WPFA blocks can be added in the block editor instead.

The runtime requirements are modest and worth checking before you start: WordPress 5.8 or higher, PHP 7.4 or newer, an HTTPS-enabled server for the API calls, and the WordPress REST API plus `wp_remote_get()` available. That last pair is the one that bites in unusual hosting setups, where outbound HTTP is restricted by a firewall or the REST API is disabled by a plugin.

Caching is a settings field, not an implementation detail

The admin settings page configures two things, the JSON API endpoints and the cache duration, which the documentation calls the cache time in seconds and the plugin surfaces as a TTL setting. The API class in `includes/` is the one that handles remote API fetching with caching, so the cache lives in the layer that makes the requests rather than in the templates.

That placement has a consequence for how you think about the content. Because the render path is cached, the cache duration effectively sets how quickly an edit on Eventyay appears on the WordPress site. For a conference site, a schedule that changes between sessions is the kind of content where a long TTL becomes visibly wrong, and where the sensible setting is short enough to keep up but long enough to spare the API.

The admin JavaScript in `public/js/event-admin.js` exists for Test Connection buttons, which suggests the settings page can verify that a configured endpoint is reachable before you rely on it. That matters in practice, because an endpoint URL typed slightly wrong fails silently at render time, leaving an empty section on a public page rather than an error anyone notices.

The plugin also ships placeholder data for local development and testing, including a placeholder image in `assets/img/speaker-placeholder.jpg` that contains no real data. For a contributor working offline, that means the templates can be rendered without a live Eventyay instance.

One command runs the whole quality gate

The plugin runs two separate toolchains, one for JavaScript and one for PHP, and the scripts table is worth reading because it shows what the maintainers consider a passing contribution.

The JavaScript side uses ESLint with the WordPress configuration and Prettier with the WordPress Prettier config. The PHP side runs PHP_CodeSniffer through Composer, and PHPStan for static analysis with a bootstrap file and a `phpstan.neon.dist` configuration. The combined command runs all three:

npm run check

which the package.json expands to lint, then phpcs, then phpstan. The individual scripts are `npm run lint`, `npm run lint:fix`, `npm run format`, `npm run phpcs`, `npm run phpcbf` and `npm run phpstan`.

Two details are worth flagging for a contributor. First, Node.js 24 or newer is required for the npm toolchain, and the package.json engines field pins that with `node: >=24`. The documentation is explicit that this is for contributors only and is not needed to install or use the plugin, which is a sensible separation. Second, the plugin runs on PHP 7.4 or newer while the tooling assumes a very recent Node, so the contributor's machine and the production server are on quite different generations of their respective runtimes.

The repository layout also shows the WordPress packaging conventions being followed: `wpfaevent.php` as the plugin entry point, `index.php` and `uninstall.php` as silence-is-golden files, `readme.txt` for the WordPress.org style plugin readme, `composer.json` and `composer.lock` for PHP dependencies, `phpcs.xml`, `phpunit.xml.dist` and a `tests/` directory for PHP tests.

Where this plugin stops

The boundary of the plugin is worth stating plainly, because a name like WPFAevent suggests more than a rendering layer.

It does not manage your event. There is no ticket selling, no registration, no CFP handling and no attendee accounts in this repository. Registration and submission live with the Eventyay platform; the plugin's job is to display what Eventyay already knows. If you were hoping for a WordPress site that runs the conference, this is the wrong tool, and the split is by design rather than by omission.

It is also tied to one data shape. The plugin fetches from configured Eventyay JSON API endpoints for speakers, sessions and schedule specifically. A site whose content comes from a different platform, or from WordPress itself, gets nothing from it. The documentation mentions other compatible APIs, which is a wider claim than Eventyay alone, but the endpoint configuration in the settings page is where that compatibility is exercised.

There is a versioning gap to know about. The repository has no GitHub releases, and the top level contains no plugin version constant visible in the listing, so tracking which build you deployed means tracking your own checkout. The repository is not archived and the last push was on 2026-10-13, so the code is moving, but there is no published version to pin against and no upgrade path documented.

The licence is Apache-2.0, declared in package.json and with the text in the LICENSE file, which is a permissive licence that does not require you to open source the theme or the pages built around the plugin.

Editorial conclusion

Adopt WPFAevent if your event data already lives in Eventyay and you want a WordPress site to present it without hand copying schedules into pages. Do not adopt it if your event data lives elsewhere, since the plugin fetches from configured Eventyay JSON API endpoints, and do not expect it to manage submissions or registration, which stay with the Eventyay platform. Verify first that your Eventyay deployment exposes the speakers, sessions and schedule endpoints you intend to point it at, and that your server can make outbound HTTPS requests, because the plugin relies on wp_remote_get() to reach them.

Frequently asked questions

Official sources

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