OpenCFP: a PHP call for papers system in maintenance mode

What OpenCFP does, and the maintenance notice

OpenCFP is a PHP-based conference talk submission system, and the feature list is short enough to state in full.

There is a speaker registration system that gathers contact information. There is a dashboard that allows speakers to submit talk proposals and manage their profile. There is an administrative dashboard for reviewing submitted talks and making selections. And there are command-line utilities for administering the system.

Those four things are the whole product, and they map onto the two sides of a call for papers: the speaker side and the reviewer side, with a third component, the command line, for the organiser who has to create accounts and groups rather than submit proposals.

Then there is the notice, and it appears immediately under the title in italics. OpenCFP is now in maintenance mode with only security fixes being accepted.

That line changes what the project is, and it is worth being blunt about it. This is a system that worked, that has a settled feature set, and that is no longer being extended. The last three tagged releases are v1.8.0 from 2020-01-03, v1.7.0 from 2019-04-11 and v1.6.1 from 2018-11-06, and the last push was on 2026-05-20, which tells you the security maintenance is real rather than a sign of abandonment.

So the reasonable way to evaluate it is as a finished artefact. If you need a call for papers system today and you want one you can read, install and extend yourself, a system in maintenance mode is arguably an advantage, because nothing is going to change under you. If you need one that will grow with your conference over the next few years, this is not that.

The licence is MIT, the primary language is PHP, and the repository topics are call-for-papers, conferences and php. Screenshots live in the project wiki rather than in the repository.

The privacy section, which is unusually direct

Before the installation instructions there is a privacy section, and it is the part of the readme that deserves the most attention if you intend to run this for real.

The request is that anyone who installs OpenCFP should not share any of the personal information collected from users with any third parties without explicit permission from users, and should be aware of the existence of the European Union's General Data Protection Regulation as it could potentially impact your ability to accept submissions from anyone residing within the European Union.

Then the recommendation, which is concrete: delete any data stored in a database associated with an OpenCFP instance within 15 months of accepting submissions from users.

A fifteen month retention limit is a short window, and it is worth thinking about why that length. A conference cycle is typically a year, so retaining data for a year after the acceptance decision covers the period in which speakers might need to be contacted about their talk and the scheduling of the event itself. After that, the data has no ongoing purpose, which is exactly the argument the GDPR makes about keeping personal data no longer than necessary.

The readme also says tools to make it easier to comply with the GDPR are in the process of being created. That phrasing dates the section to a period when the regulation was new, and it is a small indicator that the guidance here reflects the project's moment rather than being continuously reviewed legal advice.

There is also a data deletion angle in the command line utilities. The readme's table of contents lists admin group management, reviewer group management, user management and clear caches, and user management in a system that collects names, email addresses and talk proposals is a natural place to look for a way to remove a person's data on request.

For an organiser, the practical reading is that this system puts you in the position of being the data controller for your speakers' personal information, with an obligation to delete it on a schedule. That is a responsibility the system supports but does not discharge for you.

Installing it, and the environment variable that runs the show

The installation section is a numbered sequence, and it is written for someone setting the system up by hand.

You are advised to always install the latest marked release, downloading it from the releases page, or clone the repository. The readme says to always run the master branch as it was frequent contributions:

$ git clone [email protected]:opencfp/opencfp.git
Cloning into 'opencfp'...
remote: Counting objects: 4794, done.
remote: Total 4794 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4794/4794), 1.59 MiB | 10.37 MiB/s, done.
Resolving deltas: 100% (2314/2314), done.
Checking connectivity... done.

The next step is the one that catches people. OpenCFP can be configured to run in multiple environments, and the application environment must be specified as an environment variable called CFP_ENV, with the default being development if it is not set.

The configuration is done through the web server's rewrite rules rather than a file, and the readme points at a distributed Apache configuration at /web/htaccess.dist that you copy to /web/.htaccess or otherwise reproduce. The environment is set with a directive like:

SetEnv CFP_ENV production

And it also has to be set in the shell doing the install, with the readme giving the three common shells: bash uses export CFP_ENV=production, zsh uses export CFP_ENV = production, and fish uses set -x CFP_ENV production.

That duplication is deliberate and worth understanding. The web server needs it to know which configuration to load when serving requests, and the shell needs it so that the install commands and the command line utilities run against the same environment. Setting it in only one place produces the classic failure where the installer writes to one database and the site reads from another.

The minimum requirements are PHP 7.4, Apache 2+ with mod_rewrite enabled and an AllowOverride all directive in the Directory block recommended, the Composer requirements listed in composer.json, a possible need for the php7.0-intl extension for PHP, and either the GD image library or the Imagick PHP extension for the Intervention image library.

Dependencies are installed with Composer, and the readme gives three equivalent ways to do it:

$ php composer.phar run setup-env

$ composer run setup-env

$ ./script/setup

The third is the script/ directory in the repository, and the script/ prefix in the third command matches the script/ entry at the top level.

Web server configuration and the front end build

The web server section gives an Apache virtual host and an nginx server block, and the nginx one is worth reading closely because it shows how the environment variable reaches PHP under nginx, which does not use the same mechanism as Apache.

The Apache example simply points the DocumentRoot at the /path/to/web directory. The nginx block sets the server name, the root at /var/www/opencfp/web, an index list of index.php index.html index.htm, separate access and error logs, and a location block that uses try_files to fall back to /index.php with the query string, which is the front controller pattern.

The PHP location block then does the work that Apache does with SetEnv. It sets fastcgi_param CFP_ENV production, splits the path info with a regular expression, passes to the PHP-FPM socket over a unix socket, sets a read timeout of 150, and includes the standard fastcgi_params.

So the difference between the two servers is exactly where the environment variable goes, and the readme covers both because OpenCFP has to be deployable on either.

The front end is a separate build with its own toolchain, and the package.json shows what it uses. Laravel Mix drives Webpack for the development, watch and production scripts, with cross-env setting NODE_ENV, and the asset pipeline includes Tailwind, Sass with a sass-loader, Font Awesome, normalize.css and suitcss-base, plus a purgecss webpack plugin for stripping unused CSS.

That combination is a slightly dated but coherent setup. Laravel Mix was the standard way to get a Webpack build with a Laravel-style config file, and the Makefile has an asset target that runs yarn install and then yarn run production.

The stylesheets are built with the Tailwind configuration in a tailwind.js file at the top level, and the mix manifest is checked in as mix-manifest.json, which is how the built asset names are tracked. The webpack configuration itself lives in webpack.mix.js.

The Docker setup, the command line utilities and the test suite

The Docker route is the other way to run OpenCFP, and the compose file is a reasonable place to see the whole shape of the application at once.

There are three services. The php service builds from the Dockerfile with the php target and takes a CFP_ENV build argument set to development, with the environment variables for the database connection, mail settings and the initial administrator account. The nginx service builds from the nginx target, depends on php, and publishes port 80 on host port 8080. The database service is a mysql:5.7 image with a named volume for the data and ports published on 3306.

The php service mounts the working directory at /srv/app with rw and cached, and the nginx service mounts it read-only and additionally mounts the log directory into the nginx log path. That asymmetry is the point: the application writes into the mounted tree while the web server only reads it, and the log directory is shared so both sides can see the same files.

The environment variables are all overridable, and the defaults are placeholders. The database password, the mail settings marked with a tilde for unset, and the administrator name, last name, password and email all default to changeMe or similar, which is a reminder that the compose file is a development setup rather than something to deploy as is.

The Dockerfile builds from a php image with the FPM Alpine variant, and it pins the PHP version as a build argument along with an OpenResty version for the nginx side. It installs the intl, pdo_mysql and zip extensions, enables apcu and opcache, and copies the composer binary in from the official composer image so the dependency install does not need a separate download step.

The command line utilities listed in the readme table of contents are the other operational half. Admin group management, reviewer group management, user management and clear caches. The Makefile shows how those are wired into the testing workflow: the cache target runs bin/console cache:clear with the testing environment, and the doctrine target runs schema update, schema validate and mapping info against the test database.

Those bin/console commands are Symfony console commands, and their presence tells you the underlying framework. A conference talk submission system that inherits a Symfony application, with Doctrine migrations, a Twig front end and a Mailer for notifications, is a system built on well-worn parts rather than assembled from scratch.

The Makefile is where the engineering discipline shows. It has phony targets for asset, auto-review, cache, coverage, cs, database, infection, integration, it, stan, test, test-env and unit, and the it target is cs, stan and test in sequence, which is the static analysis and test gate in one command.

The individual tools are worth naming. cs runs php-cs-fixer with verbose output and a diff. static runs psalm, and there is a phpstan.neon.dist as well, so two static analysers. infection runs the mutation testing tool with the xdebug extension loaded, which is the most rigorous of the checks and the slowest. The test targets run phpunit with a testsuite argument, and the suites are auto-review, integration and unit.

Two details recur across the targets. The environment is set to testing in each test run, and SYMFONY_DEPRECATIONS_HELPER=disabled appears in front of several commands, which suppresses a deprecation helper that would otherwise fail a suite on old dependencies. The vendor target depends on composer.json and composer.lock and runs composer validate before composer install, so a malformed manifest fails before anything is installed.

The database target drops and recreates the test database and runs the migrations, and the test-env target copies config/testing.yml.dist to config/testing.yml if it does not already exist. That pattern of shipping a dist file and copying it into place is how the project handles environment-specific configuration without putting secrets in the repository.

Editorial conclusion

Adopt OpenCFP if you are running a small conference and want a talk submission system you can read, audit and run without handing your reviewer data to a third party. Do not adopt it as a system that will still gain features, because the readme says it is in maintenance mode with only security fixes being accepted, and the last tagged release is v1.8.0 from January 2020. Before you commit, read the privacy section, because the project asks installers to delete collected data within fifteen months of accepting submissions and the GDPR text is unusually direct about what that implies.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. opencfp/opencfp on GitHub
4. README
5. Releases