Building a conference registration app step-by-step using Bolt CMS
Martin Betz Jan 11, 2017
This is a step-by-step tutorial on how to create a conference registration app using Bolt CMS and the Members ) extension. I will work with iterations and go from easy to more advanced. I will break down the tutorial in several parts.
Part 1: What is the goal of our application? What are the features that users will expect from a conference registration app? And how can you set up Bolt CMS which is the framework that helps us to build the app faster?
Imagine that you are responsible for organising a big conference on The future. You rent the place, secured sponsors and booked some keynote speakers. Also, you sent invitations to thousands of readers in your Future mailing list. You expect that a few hundred of them want to come to your conference. But how will you manage the registrations? Should your attendants (or members as I will call them here) just reply via email and you save the submissions in a big Excel file. Well, this is a good starting point. But what if someone who signed up wants to change details or if the caterer needs all food preferences in real-time? Of course, placing the Excel sheet in a shared Dropbox folder could be enough. But: If you ever worked with several people on one shared Excel sheet you know that it can become messy pretty quickly.
So, a app for managing conference registrations might be helpful. And these are the requirements:
- Members can register on site with
- Members can fill-in their personal details (
roomSize) when registering or after registration in a different form
- Members can change their personal details after submission
- Members who are logged in can access a page with tickets (for demonstration purposes a static site with a general ticket image)
- Members should get informed about registration and changes of details via e-mail
*Admins can export the user data to Excel
*Members who register for a second conference can reuse their old data
The last two items (
*) are nice-to-haves but not necessary for the app to work. I might just describe easy and quick workarounds if it turns out to be beyond what Bolt and its extensions can do.
You need a local development environment using a command-line and running PHP 5.6/7, Composer.
I am using a Mac for my development and I use the very handy development tool Laravel Valet. Please use whatever you and your machine works best with, be it MAMP, DesktopServer or even Docker. If you are not on a Mac and have no preferences, I can highly recommend Laravel Homestead to you.
You are ready to go if
php -v in terminal spits out
PHP 7.1.0 or any other version number above 5.6,
composer shows you a list of commands.
Shall we begin?
(Note: I always add line numbers for my edits. Those derive from vanilla settings, so if you added extra lines in your files, the numbers would not be correct. But even in these situations, they will guide you to the approximate location.)
We will use Composer to install the CMS itself.
composer create-project bolt/composer-install:^3.2 conference --prefer-dist
conference is the name of the app – you can name it however you want, just note this name, you might need it later. Be patient, the installer downloads quite a few libraries (~ 100 MB). The installer will ask you a few questions about locations that I will just confirm with
enter. Of course, you can change the details to your liking here.
Bolt is ready for setup now. You just need to tell your local web server to serve the
public folder. The easiest way is to fire up PHP’s internal dev server with
php -S localhost:8888 while within the
public folder. I prefer using Valet which uses Nginx under the hood. The command is
valet link conference while within the
public folder. You can now open
conference.dev in your browser and enter an admin user.
There is a note below the form which informs you that you’re using SQLite. SQLite is a „database in a file“, which makes it a lot more mobile than a MySQL database. It is production-ready for sites where you have few editors (= people editing the database) and as many visitors (= requesting data from the database and cache) as you like. Our conference app may become a case where many users access and alter the database via their entries, so probably for a production site, I would go for a full-blown MySQL database. For development SQLite is fine, and you can migrate from SQLite to MySQL or MariaDB rather simply later if you want.
Setting up Bolt and the Members extension
Did you create your admin user already? I gave him the username
ticketmaster-262s (the name is not so easy to get, which is good to prevent brute-force login attempts). Click save, and you’ll be redirected to
conference.dev/bolt and see the backend.
Let’s install the Members extension right away. We need the extension for advanced user management. With a vanilla instance of Bolt we could add users, but these users would be backend users who could access all data of all visitors. Not good. That is why we need the extension. But how to install?
Extend in the left sidebar. In the search form, type in
Members. As you type, a dropdown appears where you can select
Members (Gawain Lynch - bolt/members). Hit
Browse Versions. Oops, no stable versions. From the Github repo I know that
dev-master is the most recent one. So let’s install it with
Install This Version. And the next oops: A Composer Error along the lines of „No package for your minimum-stability (stable)“. Let’s fix this.
Open a text editor in Conference’s root folder and edit
app/config/config.yml . Starting in line
399 change the lines like this:
extensions: # site: 'https://extensions.bolt.cm/' # enabled: true composer: minimum-stability: stable
Note that this is a YAML file where indentation matters. It should be four characters, no tabs. YAML fails if you have an inconsistent indentation, so if you have problems with this step, check your spaces.
Save the config file and head back to conference.dev/bolt/extend. There is a big warning sign. Follow the instructions, check the database and update it with a single click.
Open a new tab in your browser and go to conference.dev/membership/profile/register. There is now a form where your website visitors can sign up for your conference and become members.
The details an aspiring member has to fill in in this vanilla version of our app are
Email address and
Password. We need email and password (= User Story #1), do not need a public name (although a CaptainFuture name badge for a renowned scientist would be fantastic) and miss fields for
roomSize. For a first iteration, however,
public name ,
password is fine.
Let’s create a first member:
Captain Future (
thefuture). I will talk about email settings in a future part, but for now all we need is a valid URL (conference.dev will not work). Click
Save and you should see a debug message that looks like this one:
Registered account firstname.lastname@example.org () Editing profile for account email@example.com (a6d3c4ce-c9ed-436a-9faa-0e4e4e57d1c2)
Not only did you create your first member, but you also are locked in as Captain Future and can change your details from the frontend. Try this by opening a new tab and open your profile page. Change your public name to Doctor Future, hit save and open the profile page on another tab. You’re still Doctor Future.
You cannot log in and out; custom fields are missing and we haven’t seen how you the admin can see all members who signed up.
But: We have a first working version of our app. That was easy, wasn’t it?
Stay tuned for part 2: creating custom fields and customising the template, setting up email and managing your members from Bolt’s backend.