Building a conference registration app step-by-step using Bolt CMS

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?

User Stories

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:

1. Members can register on site with email and password
2. Members can fill-in their personal details (firstname, lastname, foodPreference, roomSize) when registering or after registration in a different form
3. Members can change their personal details after submission
4. Members who are logged in can access a page with tickets (for demonstration purposes a static site with a general ticket image)
5. Members should get informed about registration and changes of details via e-mail
6. * Admins can export the user data to Excel
7. * 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.

Setup

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.)

Installing Bolt

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?

Find 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 Public Name, 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 firstname, lastname, foodPreferences and roomSize. For a first iteration, however, public name , email and password is fine.

Let's create a first member: Captain Future (captain@martinbetz.eu, 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 captain@martinbetz.eu ()
Editing profile for account captain@martinbetz.eu (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.

(Cover Image: https://farm9.staticflickr.com/8631/16087236662_567a61b9ae_o.jpg)