Lately, this has especially been the case for "experiments" I've been building, whether they are micro-SaaS projects or pSEO sites. These sites are built to see if they can drive traffic (and potentially revenue) and I don't want to invest a whole lot into them because they could get nuked just as fast.

95% of these experiments are Laravel apps because it's the tool I know best, and I know I can squeeze a ton of functionality and performance for my site using the framework.

Also top of mind is SEO. SEO is vital for any project with hopes of organic growth. Blogs are an excellent way to build an SEO presence. So with that in mind I know that that blog needs to sit within the root domain, not a subdomain, or I'm just shooting myself in the foot (This is a big topic you can explore).

This article outlines how I set up Wordpress blogs alongside existing Laravel apps so that I can have a powerful content platform without affecting functionality.

Considerations

When considering my options a few come to mind:

• Write my own - This is fine, but it's also limited. There's so much domain knowledge that has gone into blogging systems and CMSs that I'd want to leverage, but I don't want to have to build.

• Use Statamic - Statamic is very awesome, I've used it on a handful of sites. Since it's a package that sits inside of a Laravel installation it's actually well suited for this case. Unfortunately, I'm not always in the position to fork up the money for a license for an experiment I'm running.

• Use Wordpress - Wordpress is free, it's easy to install, and it comes with all the bells and whistles I may or may not need. But it's got one major issue, which is that it is intended to be its own standalone app. Laravel's routing system makes it difficult to "ignore" a folder within the app and you'd need to fiddle with Apache or nginx settings.

Wordpress + Laravel = 🥰

Faced with these options, it's clear none are perfect for my "cheap experiments" scenario.

But for what I'm going for Wordpress comes closest, so I decided that it was time to figure out how to make Wordpress work with an existing Laravel app without adding additional complex overhead.

I'm not 100% sure what I outline in this article is the easiest or quickest way that a Laravel and Wordpress marriage can be done. But I do know this set up absolutely works, is pretty elegant, and has allowed me to seamlessly incorporate Wordpress into my existing apps.

And you'll be happy to know that this is all just as possible using PostgreSQL as it is MySQL (I'll show you how)!

Overview

Before we start I want to lay out the objective so you can decide now if you want to keep reading or not.

What we're going to do is to use Wordpress as a headless CMS for our blog. By "headless" I mean Wordpress will only serve as the CMS; we will separately pull that data into our app by other means.

Wordpress will be set up as a distinct app from your Laravel app but it will share the database. The Wordpress data and content can be pulled into our app just like you would with any other resource.

It's intended that the Wordpress install will live on a subdomain (which is completely fine from an SEO perspective because it's just acting as a CMS) and your blog content will be presented within blog pages you create within your app.

For the sake of this example:

• The Laravel app is mysite.test

• The CMS app is cms.mysite.test

• The blog will live at the /blog path of your Laravel app, mysite.test/blog

Implications

The implications of this setup is that your Laravel app and your Wordpress install are two distinct projects and will require independent deployments.

Fortunately, once Wordpress is deployed it can be managed entirely from production, including framework and plugin updates, so you shouldn't need to be running two deployment processes after it's first installed.

Hopefully you're still with me. Let's press on.

Requirements

There's a few things you'll need before getting started:

• An existing Laravel app that's up and running, with a database

• wp-cli

  • This is the official CLI for Wordpress. I refuse to download and unzip packages, so this is the nicer way to do it.

  • You can install wp-cli using curl or composer; I myself did it using brew (brew install wp-cli)

Getting Started

Install Wordpress as a new site using the CLI. Note the path argument is installing it into a new folder; just to remind you, this should be a distinct project.

wp core download --path=mysite-blog --skip-content

Ok, that was easy.

PostgreSQL

If you're not using PostgreSQL feel free to skip ahead to the next section. Wordpress is built for MySQL out of the box.

Otherwise, follow me...

Wordpress on PostgreSQL

I've been a PostgreSQL user for years. For most of that time I thought I had to spin up one-off MySQL DBs just to run Wordpress. But thanks to the PostgreSQL for Wordpress project, that's not the case!

1. Go to the wp-content folder

2. Install pg4wp

git clone https://github.com/kevinoid/postgresql-for-wordpress.git

1. Move the pg4wp folder to the wp-content directory:

mv postgresql-for-wordpress/pg4wp pg4wp

1. Move the db.php file to the wp-content directory

cp pg4wp/db.php db.php

That's it! Your Wordpress site will work in blissful harmony with your PostgreSQL database.

Configuring Wordpress

Return to root of your Wordpress project and finish preparing it for installation.

Environment Variables

As someone who has reached developer enlightenment I prefer not to hard-code environment variables into configuration files. So to handle env variables better, we're going to do some quick setup.

Eric Barnes's wrote a great post about this back in 2017, so we're going to follow his suggestions. There's been a few updates to the related packages since, but here's the steps:

1. In your Wordpress project run composer init to create a composer.json file. If you don't want to do that you can just use this snippet (replace the values in <>s):

{
    "name": "<repo name>",
    "authors": [
        {
            "name": "<your name>",
            "email": "<your email>"
        }
    ],
    "require": {
        "vlucas/phpdotenv": "^5.6"
    }
}

1. As you can see we're using the awesome vlucas/phpdotenv package. Pull it in using composer require vlucas/phpdotenv or composer install if you manually created your composer.json file.

2. Create a .env file inside the project folder

3. Add the .env file to a .gitignore file. We don't want that landing in our commit history.

4. Set the same database variables from your Laravel app into the .env:

DB_HOST=127.0.0.1
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=

Now your Wordpress site is leveraging environment variables, which will work both locally and in production.

Finishing Configuration

1. Create the config file:

cp -rp wp-config-sample.php wp-config.php

1. Run wp config shuffle-salts to set all your SALT values.

1. Update the new wp-config.php file with your DB settings.

   1. If you're using environment variables ensure you're including the autoload script at the top, and properly referring to the values using $_ENV.

   2. If you're not using environment variables just drop the necessary values right in there like a complete savage

<?php

require_once(__DIR__ . '/vendor/autoload.php');
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the installation.
 * You don't have to use the web site, you can copy this file to "wp-config.php"
 * and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * Database settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://wordpress.org/documentation/article/editing-wp-config-php/
 *
 * @package WordPress
 */

/** The name of the database for WordPress */
define( 'DB_NAME', $_SERVER['DB_DATABASE'] );

/** Database username */
define( 'DB_USER', $_SERVER['DB_USERNAME'] );

/** Database password */
define( 'DB_PASSWORD', $_SERVER['DB_PASSWORD'] );

/** Database hostname */
define( 'DB_HOST', $_SERVER['DB_HOST'] );

/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

Installation

We've made great progress and now it's time to install! First, let's review what we've done:

• ✅ We've created a standalone Wordpress install

• ✅ We've configured it to connect to our main Laravel app database

• ✅ We're leveraging environment variables to keep secrets where they belong

It may seem like it's a lot of work, but after you do it once it only takes a minute.

Now it's time to install Wordpress.

If you're working in Valet now is a good time to link this domain. I like to set up the Wordpress install on a subdomain of my Laravel site to emulate how it'll work in production, but you don't have to do that.

valet link cms.mysite

It should now be available at http://cms.mysite.test.

Visit the new URL to complete setup – it should redirect you to the installation path.

Once the installation flow is complete you should have your site setup and running now, whether you use MySQL or PostgreSQL. Congrats!

Viewing your Blog

Next is the part we've been waiting for: pulling in blog content into our Laravel site.

Staying Eloquent

One of the great parts of Laravel is having Eloquent models to easily interact with database records. Fortunately for us, the Corcel library has done the heavy lifting to bring Eloquent structure to Wordpress resources.

Corcel is a collection of PHP classes built on top of Eloquent ORM (from Laravel framework), that provides a fluent interface to connect and get data directly from a WordPress database.

1. Return to your Laravel project folder (not the WP app) and install Corcel:

composer require jgrossi/corcel

1. Publish the corcel.php config file:

php artisan vendor:publish --provider="Corcel\Laravel\CorcelServiceProvider

1. Open your database.php file and make a copy of your primary database connection configuration. We want Corcel to use our primary database but we need to tell it that the Wordpress resources are found in tables prefixed with wp_.

   1. Set the key to wordpress

   2. Change the prefix value to wp_

2. Edit the corcel.php config file and change the connection value to use your new configuration:

'connection' => 'wordpress'

Creating blog pages

Now you can create a controller and view that will serve up your blog index and posts, or however your app is set up to present views.

Out of the box Corcel comes with Post models, with all necessary relationships, but you can extend it to add your own functionality. Check out https://github.com/corcel/corcel for a deep dive on all the things you can do.

Here's a quick example of a BlogController to serve up your blog and blog posts:

<?php

namespace App\Http\Controllers;

use Corcel\Model\Post;

class BlogController extends Controller
{
    public function index()
    {
        return view('blog.index', [
            'posts' => Post::query()
                ->type('post')
                ->published()
                ->newest()
                ->paginate(10),
        ]);
    }

    public function show(string $slug)
    {
        return view('blog.show', [
            'post' => Post::slug($slug)->first(),
        ]);
    }
}

And of course you'll need some routes:

<?php

// routes/web.php

use Illuminate\Support\Facades\Route;

Route::get('/blog', [\App\Http\Controllers\BlogController::class, 'index'])->name('blog.index');
Route::get('/blog/{slug}', [\App\Http\Controllers\BlogController::class, 'show'])->name('blog.show');

Wrap Up

There you have it: a Wordpress blog deployed against your current infrastructure and ready for you to tap into within your primary app.

While I think there's definitely another path to this with having the Wordpress installation live inside your app in a /blog folder it means you'll need to configure server configs to get that path to resolve Wordpress's index.php file and related routing.

I am interested in this solution as an alternative though, so if you know how to do it please let me know!

And of course, questions and comments are most welcome, as well as suggestions for improving this post to include your particular scenarios.

Resources:

Here's some links to sites I referenced while pulling this article together:

• https://m.dotdev.co/secure-your-wordpress-config-with-dotenv-d939fcb06e24

• https://inovector.com/blog/wordpress-as-a-headless-cms-for-your-laravel-website

• https://www.enterprisedb.com/postgres-tutorials/how-deploy-wordpress-highly-available-postgresql

• https://www.codeable.io/blog/laravel-wordpress/ https://www.cloudways.com/blog/laravel-wordpress/

Next week I'm going to be re-launching it on Product Hunt. But before I get into that, let me tell a story...

A bit of StatusTicker history

The idea was simple: instead of managing subscriptions for the myriad different cloud services and APIs my team used I would aggregate status feeds into a single "ticker" and present them on a screen in our office.

Green boxes were good, red boxes said something was broken upstream, yellow boxes were forewarning of problems to come, and blue boxes indicated the provider was undergoing maintenance.

I also added the ability to notify about status changes via email, SMS, Slack, etc. The Slack integration in particular was nice because it just became a steady stream of awareness within our team Slack instance.

It was simple and it was effective. So I turned it into a SaaS product. I also had a lot of fun tackling all of the different feeds and formats. James Brooks recently told me that I was one of the first people to integrate with Cachet, which is pretty cool.

StatusTicker today

6+ years later and StatusTicker lives on. Over that time I've had 1000s of people sign up for the service, and many many more hitting any of the public status pages I make available. I've added many new features, improved SEO, and changed my pricing structure. I've chatted with other makers and have tried to connect with customers to learn about what would make the product better.

But candidly it's never been as successful (or profitable) as I'd like. At all.

There's probably a few good reasons for that (we'll save the app roast for another article).

But one in particular I've come to terms with lately is entirely about me, and it's that I have another strong developer tendency:

I focus on building and avoid marketing like the plague.

Leaving the Fort

From what I've seen this is a pretty common trait among our ilk, and I've been meditating on why that is...

• Maybe our own experiences being sold and marketed to has left us jaded

• Maybe we're lacking confidence and/or conviction that our solution has value, or at least more value than another solution

• Maybe we don't know where to go to tell people about it without being driven out of town (ie. Reddit or Hackernews)

• <insert your own reasons here>

I think for me it has been a bit of all of those.

But I also know that lately I've become very interested in pushing myself into places where I'm not comfortable.

The time I've spent watching others who are finding the types of success that I want for myself are doing it because they are exploring new places, pushing their own boundaries, discovering good things, and then telling (and selling) people on their experiences.

And I think I used to be a lot more like this, then I went all corporate and forgot how. Well, time for me to leave the fort again and blaze new trails.

Moving to 60/40

Look, I'm not aiming to become someone who is just trying to sell all the time.

What I do want is to become better at valuing the things I envision and create and expressing that value to others. I absolutely want to help people succeed in their own goals.

I now believe doubling-down on sharing my experiences and connecting with people is the best way to do that. It doesn't always come naturally... it's like hitting the gym after a long hiatus (yet another topic for another day).

So, In 2024 I'm going to be focusing on going 60/40:

• 60% sharing/selling/marketing (uncomfortable)

• 40% building (comfortable)

Ideally, that becomes 80/20 over time but I need to start realistically 😅

This blog is a big part of that 60% (so far)

So about that relaunch...

As I said, I'm doing another StatusTicker launch on Product Hunt next week (January 9th, 2024). If you support it, awesome, thanks in advance.

For me this is about learning and honing. I'll be thrilled if I gain new subscribers through this launch. But just as importantly it's an opportunity for me to improve content, messaging, and voice. To force myself to speak boldly and confidently about what I've built and be convicted that it will help other people too. And that if someone finds value in it that it's totally OK for me to ask for appropriate compensation in return (ya, I'm of the old $5/sub squad...)

Maybe none of this resonates with you, and to that I give you a hat tip.

But if you've ever found yourself wrestling with these thoughts as a creator then I encourage you to flip the script, push yourself to do some uncomfortable stuff, and see what comes out of it.

You might be surprised.

Livewire has been around for a long time too. Caleb Porzio released v1 around the same time and has been incrementally improving it through 3 major releases ever since.

I was on-site at Laracon Nashville when v3 was officially launched. The tech and features looked super impressive, and the crowd was pumped.

But I had never used Livewire myself, so the enthusiasm was a little lost on me.

That's about to change with this blog post.

I'm taking a new app I'm starting to build in my tried-and-true VILT (Vue/Inertia/Laravel/Tailwind) stack and I'm going to try to convert it and build it out in a TALL (Tailwind/Alpine/Laravel/Livewire) stack instead.

Like I said, I've never even touched Livewire before so this is a blind run. I'm also dividing this post into a few parts as I go through the process.

Time to get pumped 😎

Removing Inertia.js

I've already built out some of the functionality of this app, so this post is going to skip the parts about setting up a new Laravel project. In fact, I've also already got a bunch of Vue pages and Inertia controllers in place, which I'm going to need to convert over.

But, first things first... removing Inertia.

Admittedly, this feels strange and a disloyal, but I believe in my heart I'll be forgiven.

Let's go.

composer remove inertiajs/inertia-laravel

and

npm uninstall @inertiajs/vue3

And while I'm there, I might as well incur some collateral damage and remove Ziggy.

composer remove tightenco/ziggy

There, the Bandaid has been ripped off.

Updating Assets

Since my app is currently built as a Vue + Inertia.js SPA I need to perform some surgery on a few files to get it rebuilding.

Firstly, I need to remove all of the Inertia-related boilerplate from my app.js file:

Before:

import '../css/app.css'
import './bootstrap'

import { createInertiaApp } from '@inertiajs/vue3'
import { resolvePageComponent } from 'laravel-vite-plugin/inertia-helpers'
import { createApp, h } from 'vue'
import { ZiggyVue } from '../../vendor/tightenco/ziggy/dist/vue.m'

const appName = import.meta.env.VITE_APP_NAME
const appUrl = import.meta.env.VITE_APP_URL

createInertiaApp({
  title: (title) => `${title} - ${appName}`,
  resolve: (name) =>
    resolvePageComponent(`./Pages/${name}.vue`, import.meta.glob('./Pages/**/*.vue')),
  setup({ el, App, props, plugin }) {
    return createApp({ render: () => h(App, props) })
      .use(plugin)
      .use(ZiggyVue)
      .provide('appName', appName)
      .provide('appUrl', appUrl)
      .mount(el)
  },
  progress: false,
})

After:

import '../css/app.css'
import './bootstrap'

I deleted my ssr.js file too, and good riddance. SSR has always been the biggest pain with SPAs and maybe one of the biggest reasons I'm excited about trying Livewire.

Next I'm cleaning up my vite.config.js file to remove any references to Vue, Ziggy, and SSR.

Adding Livewire

Now, to add in Livewire.

Heading over to the Livewire docs, I see that installing it is pretty straightforward:

composer require livewire/livewire

OK. That's done.

I'm going to skip adding the livewire.php config file unless I discover I need it later on. I'm also going to assume the rest of the OOB settings will work for me.

It's cool that this single package provides both the Laravel services as well as the necessary "wiring" scripts for Livewire.

Views

OK, so far I've removed Inertia, added Livewire, and hacked up some of the build files for my app. Now that all of the assets have been changed I'm left with:

• An app that won't build

• A single Blade app.blade.php file that's kind of useless

• A bunch of vestigial Vue files

• Controller methods that are broken

This means the lion's share of the work that remains will be updating views, so let's get started with the layout files.

Layouts

I saw in the Quickstart section that a default layout could be created easily, so I'll do that:

php artisan livewire:layout

Et voila! 🤙

Before I continue I'm going to move some of the stuff from the head of my old app.blade.php file into this new layout file in /resources/views/components/layouts.app.blade.php.

And I deleted the old app.blade.php so I didn't confuse myself later.

Testing it all out

Before I go any further with the rest of my views I need to test this out to see if I'm close. I'm going to just add a landing page with some content, and we'll see if it loads.

Since I'm OCD about folder structure I'm going a little fancier with the component generation:

php artisan make:livewire Home\\Index

🎉🎉🎉

Ok, so, I guess I need to start the server so Tailwind can run:

npm run dev

And then I can visit my local site...

Oh ya, forgot about that. I've deleted that middleware and removed the reference from App\Http\Kernel.php. Let's try again...

Closer.

But I just realized I never did anything with my controller, so I need to do that first.

And this is the first time I'm hitting a real paradigm shift with Livewire, because it's not that I need to change my controller, it's that I need to delete it.

Instead I'm mapping this route right to the Livewire component.

This is going to take some getting used to. But I'm OK with it.

I discover these are called full-page components and they leverage my layout file I just created. I'm also pleased to see I can still use different layouts for different components. And Caleb has gone absolutely bananas offering 3(? 4?) different ways of doing this, as I assume will be the pattern all over Livewire.

It's alive!

I update the page with some memorable content for this landmark event, try out live reload with a Tailwind change, and even use a snazzy attribute to change the page title.

I'm feeling the pump start to swell...

Realizing my Limitations

I don't want to squash any excitement but I'm realizing there's a ton of Inertia scaffolding that I get from Jetstream that I've not loaded into this app for Livewire.

So, I'm going to do the opposite of what's typically recommended and I'm going to run a Jetstream install into an existing app.

First, make sure I have the latest Jetstream installed:

composer require laravel/jetstream

Second, Install Jetstream with Livewire:

php artisan jetstream:install livewire

There's a bunch of other steps you can take when installing this, so browse the Jetstream docs to see what you need for your project.

Conclusion

OK, that's it for Part 1. I successfully have my app re-wired for Livewire and it's ready to have the rest of the components reworked.

Here's what I know is ahead of me and what I'll be tackling in the next post(s):

• Rebuilding my two layouts, a "Public" layout for non-authed users and an "App" layout for the actual app

• Building a dynamic dashboard that displays multiple data points at the same time

• CRUD-style pages for some of the resources that users can manage

• Sortable, filterable tables that contain 1000s of rows of data

It feels a little daunting right now (part of the reason why I stopped at this point) but I think if I take it a bit at a time I'm going to learn a ton.

Thanks for reading.