laravel-forum adds a forum to a Laravel app that already has users

A forum as a package, not a separate application

Team-Tea-Time's laravel-forum is described as a slim, lean forum package designed for quick and easy integration in Laravel projects, and the full documentation lives at teamteatime.net.

The word integration is the whole design decision. This is not a forum application you deploy on its own with its own user table and its own admin. It is a package that goes into an application that already has users, and the forum is one of the features of that application. The evidence is in the details: there is a configuration option called forum.integration.user_name that specifies which attribute on your user model should be used as a display name in the forum views, and you may need to modify it to match your model. A forum that has its own accounts would not need such a setting.

That makes the package a good fit for a product with a community attached to it, where a user who signed up for the main product can also ask a question, and where the identities stay the same. It also means the package inherits the host application's strengths and weaknesses, including its authentication system, its email delivery and its queueing.

The stack is current. The primary language is PHP, the topic list includes both php7 and php8, and the repository topics name laravel, livewire and laravel-package. The default branch is 8.x, and the homepage is laravel-forum.teamteatime.net.

The licence is MIT, and the repository is not archived, with the last push on 2026-09-20 and releases 8.0.5, 8.0.4 and 8.0.3 in the weeks before that.

The version table decides which package line you take

The README leads with a compatibility table, and for a package like this the table is more important than the feature list, because the package version, the framework version and the PHP version move together.

The current rows are Laravel 13 with Livewire 4 and package version 8.0 on PHP 8.3, and Laravel 12 with Livewire 3 and package version 7.0 on PHP 8.2. The Livewire column is marked as only applicable if you intend to use a Livewire based UI preset, which is the key detail in the footnote.

The README also states plainly that older package versions not listed in the table are no longer maintained or supported. That is a short list of things you should check before pinning, because a project that installed the 5.x or 6.x line last year is now on an unsupported package.

The reason for the coupling is the framework's own release policy. The README points at the support policy in the Laravel documentation for the release versions, the PHP versions they support, and how long they receive bug and security fixes. That is the right reference for a team doing this exercise, because the question covers both which package version to install and how long the framework underneath it will be patched.

One naming detail catches people out when they search for the package. The repository is Team-Tea-Time/laravel-forum, but the Packagist package name is riari/laravel-forum, which is what goes into the Composer command.

Four installation steps, and the one that is easy to miss

Installation is presented as four steps, and the first three are the familiar Laravel package routine.

The package is installed with Composer:

composer require riari/laravel-forum:^8.0

Package Discovery should register the service provider automatically, and the README explains the manual fallback for when it does not, which is to add the provider class to bootstrap/providers.php:

TeamTeaTime\Forum\ForumServiceProvider::class,

Then the package files are published, which writes the configuration, the translations and the migrations into the application:

`php artisan vendor:publish`

And then the database is brought up to date:

`php artisan migrate`

The fourth step is the one that trips people up, because it has no default behaviour you can rely on. A `forum:preset-install {name}` command installs a UI preset, and `forum:preset-list` shows what is available. You must install one of them, because that is what publishes the corresponding views into your application. The example given is:

`php artisan forum:preset-install livewire-tailwind`

By default the livewire-tailwind preset is the active one in the forum.frontend.preset configuration value, and the README notes that this preset requires Livewire and a few other dependencies. So a project that installs the package and never runs the preset command has the backend and no views, which is exactly the failure mode the note is warning about.

Configuration, the display name option, and fifteen languages

Several configuration files are published to config/forum, and the README directs you there for the options that change the behaviour of the forum and how it integrates with the rest of the application code. Publishing rather than hard-coding is the right call for a package like this, since the same package has to serve applications with different auth models, different pagination expectations and different URL schemes.

One option is called out specifically. The forum.integration.user_name config option specifies which attribute on the user model should be used as a display name in the forum views, and you may need to modify it according to your own model. If your users have a name attribute, it works out of the box; if your display name is computed or lives in a profile table, this is the setting to point at it.

Translations are a strong point. The package currently supports 15 languages: German, English, Spanish, French, Italian, Dutch, Romanian, Russian, Thai, Turkish, Serbian, Portuguese (Brazil), Swedish, Chinese, and Indonesian. The files are published to resources/lang/vendor/forum/{locale}, the conventional path for a package's translations inside a Laravel application.

The README is honest about a gap. Some new language strings were introduced in version 6 and are not yet translated, and pull requests to translate them would be appreciated. That is worth knowing if you are deploying in one of the fifteen listed languages, because a missing string in a shipped interface is a visible defect rather than a cosmetic one.

For local development, the README points at Team-Tea-Time/laravel-studio, which is set up to load a local working copy of the package, and the usage details are in that project's own readme.

Running the test suite in containers

The development section describes a Docker-based workflow with three services, and the compose file in the repository confirms the shape of it.

MySQL is built from a Dockerfile in the docker/mysql directory, runs in a container named lf-tests-mysql, and stores its data on a tmpfs mount at /var/lib/mysql, which means the test database is discarded when the container stops rather than persisting between runs.

The composer service is built from docker/composer/Dockerfile, mounts the repository at /app as its working directory, sets COMPOSER_CACHE_DIR to a path inside the mounted volume so the package cache survives between runs, and overrides the entrypoint with /usr/bin/composer.

The phpunit service is built from docker/phpunit/Dockerfile, mounts the same way, is set to restart with no, and its entrypoint is vendor/bin/phpunit.

The three commands the README gives are correspondingly simple. The database comes up with:

docker-compose up -d mysql

Composer dependencies are installed with:

docker-compose run --rm composer install

And the tests run with:

docker-compose run --rm phpunit

Seeding is a separate step, and the package ships a seeder for it, with sample categories, threads, posts and a user:

docker-compose exec php-fpm php artisan forum:seed

That last command runs inside the running application container rather than a one-off container, which is a reasonable difference in practice: seeding touches the application environment, so it has to run where the application and its configuration live.

What the repository holds and what the package does not

The top-level entries describe a package rather than an application. There is a composer.json and composer.lock, a config directory, a database directory for the migrations, a routes directory, the src directory with the PHP code, a translations directory, and a ui-presets directory holding the preset the package installs. The docker directory holds the three service Dockerfiles, and docker-compose.yml defines the services, while phpcs.xml and phpunit.xml handle the coding standard and the test configuration.

That last pair is worth a sentence. A package with a phpcs configuration and a PHPUnit configuration, and a GitHub Actions workflow for each, is set up to be read by other developers and reviewed on a pull request, which is the difference between a package and a script somebody committed.

Two limits are worth stating. First, this is a forum, and the README's feature surface is a forum's feature surface: categories, threads, posts and a user. It is not a full community platform with reputation, badges, moderation workflows or private messaging, and the documentation does not describe any of those. Second, the package's release line is tied to the framework's, so a Laravel application that needs a long support horizon should be planned around the framework's own policy rather than around the forum's version numbers.

The documentation is split across the site, with the main documentation at teamteatime.net and the UI presets page linked from the installation step, so the presets deserve a read before installation rather than after.

Editorial conclusion

laravel-forum fits a Laravel product that already has users, a mail setup and an admin area, and that needs discussion threads as a feature rather than as a separate community to run, since it installs into the host application and reuses its user model. It is the wrong choice if you want a standalone forum with its own accounts, moderation workflow and reputation system, and it is the wrong choice if your project is still on an older Laravel or PHP version, since the current package line requires Laravel 12 or 13 with PHP 8.2 or 8.3. Before adopting it, read the version table and pick the package line that matches your Laravel major, decide which UI preset you will ship, and check the forum.integration.user_name setting against your own user model.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Team-Tea-Time/laravel-forum on GitHub