This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I'll release the Meeting Planner code as open-source examples you can learn from. I'll also address startup-related business issues as they arise.
Launching a Second Web Domain
Expanding awareness and usage of Meeting Planner is my greatest challenge right now. Without lots of input, it's hard to make the product better, and without fast growth, it's hard to attract investors.
I've had concerns that the brand Meeting Planner might lead to people misunderstanding the app's social usefulness, such as planning friendly get-togethers, dates, and parties.
Obviously, choosing names is limited by domain availability and/or the budget you have to invest in buying alternatives. Meeting Planner seemed best at the time.
Recently, I noticed SimplePlanner.io was available, so I registered it and began to integrate the domain alongside the existing Meeting Planner service.
There are a couple of different approaches to adding domains to a Yii2-based application. In today's tutorial, I'll cover the simplest, running domains on the same codebase.
If you haven't tried out Meeting Planner yet, go ahead and schedule your first meeting at Simple Planner. I do participate in the comment threads below, so tell me what you think! You can also reach me on Twitter @reifman. I'm especially interested if you want to suggest new features or topics for future tutorials.
As a reminder, all of the code for Meeting Planner and Simple Planner is written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out our parallel series Programming With Yii2.
Before I get a started, I'd like to touch on one aspect of the challenge of building a startup.
A Peek at Startup Life
I've been working on this episode over the weekend, a "perk" of #StartupLife. I wanted to share a couple of fun things about this.
First, #StartupLife often means not having the time to finish putting together IKEA Furniture, just the biggest drawer:
Second, it also means working at coffee shops in fun places... Five Point Roasters in Portland, Oregon happens to have a neighboring bubble machine (or people breathe bubbles there):
Now, back to the focus of today's tutorial...
Implementing Multiple Domains in Yii
The Yii2 advanced template allows you to run a number of sites in one code tree. I used its front-end tree to build Meeting Planner and its back-end tree to build the administrative suite of tools for the service. Today, however, I'll focus on launching another domain on top of the existing front-end tree—and all the small and large complexities that go along with this.
In a future episode, I'll cover building sites on a third or fourth tree, for example a REST API or a related startup to Meeting Planner (yes, there's an exciting idea ahead).
I presumed it would be fairly simple (no pun intended) to launch Simple Planner, but it ended up taking a few days of work.
The simple work was the basic server configuration and some code handling with the Yii tree. However, since Meeting Planner is an email-intensive service (meeting invitations, confirmations, announcements, updates, etc.), it was important to send these emails with the domain from which meetings were created, either SimplePlanner.io or MeetingPlanner.io.
I also wanted there to be some initial visual differentiation between the two sites.
Let's get started, and I'll gradually reveal some of the complexities I encountered.
Configuration Based on the Domain Address
When people arrive at our site via browser requests, we need a central way in Yii to instruct all executed code which service should be shown: Meeting Planner or Simple Planner?
In /frontend/config/main.php, there is an unfortunately named bootstrap configuration (because it overlaps with Bootstrap) which will run code at the beginning of the framework invocation:
<?php
$config = parse_ini_file('/var/secure/mp.ini', true);
$params = array_merge(
require(__DIR__ . '/../../common/config/params.php'),
require(__DIR__ . '/../../common/config/params-local.php'),
require(__DIR__ . '/params.php'),
require(__DIR__ . '/params-local.php')
);
return [
'id' => 'mp-frontend',
'name' => 'Meeting Planner',
'basePath' => dirname(__DIR__),
'bootstrap' => ['log','\common\components\SiteHelper'],
'controllerNamespace' => 'frontend\controllers',
In addition to calling logging above, I created a component for it to call named SiteHelper:
So SiteHelper has all the code to customize the service based on which site is running. For example:
private function commonMeetingPlanner() {
Yii::$app->params['site']['id'] = SiteHelper::SITE_MP;
Yii::$app->params['site']['domain'] = 'meetingplanner.io';
Yii::$app->params['site']['url'] = 'https://meetingplanner.io';
Yii::$app->params['site']['title'] = Yii::t('frontend', 'Meeting Planner');
Yii::$app->params['site']['mtg'] = Yii::t('frontend', 'Meetings');
Yii::$app->params['site']['img'] = rand(2,3);
Yii::$app->params['site']['navbar'] = 'navbar-inverse';
Yii::$app->params['site']['email_logo'] = 'https://meetingplanner.io/img/email-logo-mp.gif';
Yii::$app->params['site']['ga'] = 'UA-37244292-18';
}
private function commonSimplePlanner() {
Yii::$app->params['site']['id'] = SiteHelper::SITE_SP;
Yii::$app->params['site']['domain'] = 'simpleplanner.io';
Yii::$app->params['site']['url'] = 'https://simpleplanner.io';
Yii::$app->params['site']['title'] = Yii::t('frontend', 'Simple Planner');
Yii::$app->params['site']['mtg'] = Yii::t('frontend', 'Meetups');
Yii::$app->params['site']['img'] = rand(0,1);
Yii::$app->params['site']['navbar'] = 'navbar-default';
Yii::$app->params['site']['email_logo'] = 'https://simpleplanner.io/img/email-logo-sp.gif';
Yii::$app->params['site']['ga'] = 'UA-37244292-21';
}
Those functions change variables, URLs and strings based on the requested service. These are called by the SiteHelper::init() function:
<?php
namespace common\components;
use yii;
use yii\helpers\Url;
class SiteHelper extends \yii\base\Component{
const SITE_MP = 0;
const SITE_SP = 1;
const SITE_FD = 2;
public function init() {
$baseUrl = Url::home(true);
if (stristr($baseUrl,'/mp/')!==false) {
// local mp
$this->commonMeetingPlanner();
Yii::$app->params['site']['url'] = 'http://localhost:8888/mp/';
Yii::$app->params['site']['ga'] = '';
} else if (stristr($baseUrl,'/sp/')!==false) {
// local sp
$this->commonSimplePlanner();
Yii::$app->params['site']['url'] = 'http://localhost:8888/sp/';
Yii::$app->params['site']['ga'] = '';
} else if (stristr($baseUrl,'simple')!==false) {
// simpleplanner.io
$this->commonSimplePlanner();
} else {
// default meetingplanner.io
$this->commonMeetingPlanner();
}
parent::init();
}
The above functions also override settings when calling from localhost:8888 development sites.
Meeting Planner is SITE_MP, Simple Planner is SITE_SP, and SITE_FD is my secret from you (for now).
Unique Home Page Appearance
For now, I decided to quickly vary the appearance of Simple Planner (SP) and Meeting Planner (MP) by using Bootstrap 3.0's two default navigation bars.
You'll notice above MP uses Yii::$app->params['site']['navbar'] = 'navbar-default'; and SP uses 'navbar-inverse';.
In /frontend/views/layouts/home.php and main.php, they are applied this way:
<?php
NavBar::begin([
'brandLabel' => Yii::$app->params['site']['title'].' <span class="badge">preview</span>', //
'brandUrl' => Yii::$app->homeUrl,
'options' => [
'class' => Yii::$app->params['site']['navbar'].' navbar-fixed-top',
],
This creates the two different navbar color schemes:
But what about the cover images? I licensed two playful social images for SP and two more serious professional images for MP.
The images are rotated randomly depending on the active service, with image filenames ending numerically as 0, 1, 2, or 3, e.g. /img/home/home-#.jpg.
Yii::$app->params['site']['img'] = rand(2,3);
Here's the home.php layout code that applies this to the chosen image:
<body>
<?php $this->beginBody() ?>
<div class="row">
<div class="col-md-12 bgimage"
style="background-image:
url('<?= $urlPrefix ?>/img/home/home-<?= Yii::$app->params['site']['img'] ?>.jpg');">
<div class="bgimage-inside"></div>
If you refresh the home pages for SimplePlanner.io or MeetingPlanner.io, you'll see the images oscillate.
Updating Text, Images, and Links
Variables from SiteHelper above help customize textual labels throughout the site. And in the future, I can do this more extensively:
Yii::$app->params['site']['title'] = Yii::t('frontend', 'Meeting Planner');
Yii::$app->params['site']['mtg'] = Yii::t('frontend', 'Meetings');
While MP calls things Meetings, I could globally change SP to use the more social phrase Meetups:
Yii::$app->params['site']['title'] = Yii::t('frontend', 'Simple Planner');
Yii::$app->params['site']['mtg'] = Yii::t('frontend', 'Meetups');
Configuring Services
Meeting Planner uses a lot of different services to deliver scheduling. Initializing these took the most time.
Google Analytics and Search Console
Google makes it a bit difficult to use multiple domains with Analytics, so I just divided them into different accounts. The SiteHelper sets up the GA code:
Yii::$app->params['site']['ga'] = 'UA-37244292-18';
Then, these are set in the Home.php and Main.php layout views:
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create', '<?php echo Yii::$app->params['site']['ga']; ?>', 'auto');
ga('send', 'pageview');
</script>
There's also a domain setting for Google's Search Console which I configured at my registrar (shown further below):
OAuth Login
And, since I added social login via OAuth for Facebook, Google, and LinkedIn, I had to tell all of these services about the SimplerPlanner.io domain. Google and LinkedIn are the most confusing because each and every query argument variation must be registered with those geniuses:
Here's Google:
Here's the simple LinkedIn:
But Facebook is the simplest and least picky (just keep the breastfeeding pics to a minimum):
Mailgun Email
Since I use Mailgun to deliver emails, I created a domain account for Simple Planner with them:
This required careful changes over at my domain registrar:
SSL
I use Let's Encrypt for the https (SSL) with Meeting Planner and its back-end administrative service. Setting those up went pretty smoothly for me. But adding SimplePlanner.io didn't work, and I ultimately had to create separate Apache (.conf) configuration files for SP and customize the files myself.
Here's the http sp.conf file which redirects to https:
<VirtualHost *:80>
ServerName simpleplanner.io
ServerAlias www.simpleplanner.io
DocumentRoot "/var/www/mp/frontend/web"
<Directory "/var/www/mp/frontend/web">
AllowOverride All
</Directory>
RewriteEngine on
RewriteCond %{SERVER_NAME} =simpleplanner.io [OR]
RewriteCond %{SERVER_NAME} =www.simpleplanner.io
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>
The redirections just weren't working with two server names and two server aliases. Here's the sp-ssl.conf file:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName simpleplanner.io
ServerAlias www.simpleplanner.io
DocumentRoot "/var/www/mp/frontend/web"
<Directory "/var/www/mp/frontend/web">
AllowOverride All
</Directory>
RewriteEngine On
RewriteCond %{SERVER_NAME} =www.simpleplanner.io
RewriteRule ^ https://simpleplanner.io%{REQUEST_URI} [END,QSA,R=permanent]
SSLCertificateFile /etc/letsencrypt/live/simpleplanner.io/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/simpleplanner.io/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/simpleplanner.io/chain.pem
</VirtualHost>
</IfModule>
Here's how I ultimately created the SSL certificates with Let's Encrypt:
cd /opt/letsencrypt/ sudo ./letsencrypt-auto --apache -d simpleplanner.io -d www.simpleplanner.io -d
Let's Encrypt is awesome, but they are still young, and while their scripts continue to get more robust, there are still issues occasionally like this one.
Background Email Differentiation
The biggest challenge for me in launching Simple Planner was processing background emails so that they came from the proper service, i.e. MP or SP, and all of their links did as well.
Since I kept the database unified for SP and MP, I also left the background processing to be done on the MP domain. So I had to extend the database so the User and Meeting table saved a site_id column to indicate which service created each entry.
Here's the Yii database migration:
<?php
use yii\db\Schema;
use yii\db\Migration;
use frontend\models\Meeting;
class m161016_204028_extend_user_and_meeting_for_simple extends Migration
{
public function up()
{
$tableOptions = null;
if ($this->db->driverName === 'mysql') {
$tableOptions = 'CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE=InnoDB';
}
$this->addColumn('{{%meeting}}','site_id',Schema::TYPE_SMALLINT.' NOT NULL DEFAULT 0');
$this->addColumn('{{%user}}','site_id',Schema::TYPE_SMALLINT.' NOT NULL DEFAULT 0');
}
public function down()
{
$this->dropColumn('{{%meeting}}','site_id');
$this->dropColumn('{{%user}}','site_id');
}
}
I used the beforeSave() method in the Meeting model to always configure a site_id based on the current service—you may remember I created this method to always generate a secure unique identifier for every meeting:
public function beforeSave($insert)
{
if (parent::beforeSave($insert)) {
if ($insert) {
$this->identifier = Yii::$app->security->generateRandomString(8);
$this->site_id = Yii::$app->params['site']['id'];
}
}
return true;
}
I created a similar one for the User model:
public function beforeSave($insert)
{
if (parent::beforeSave($insert)) {
if ($insert) {
$this->site_id = Yii::$app->params['site']['id'];
}
}
return true;
}
Throughout the service I use the MiscHelpers::buildCommand() method to construct secure links that don't require users to log in each time they respond to an email.
I thought it would be easy to customize this command in one place to link to the appropriate site domain. However, that would require that this frequently used method query the Meeting table for the site_id repeatedly. For example, the buildCommand() is called a number of times for every participant for every meeting.
For performance reasons, I decided to change all the calls to this function to include the site_id. For example, all of these calls had to be amended as shown below:
foreach ($this->participants as $p) {
if ($p->status !=Participant::STATUS_DEFAULT) {
continue;
}
// Build the absolute links to the meeting and commands
$auth_key=\common\models\User::find()->where(['id'=>$p->participant_id])->one()->auth_key;
$links=[
'home'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_HOME,0,$p->participant_id,$auth_key,$this->site_id),
'view'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_VIEW,0,$p->participant_id,$auth_key,$this->site_id),
'finalize'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_FINALIZE,0,$p->participant_id,$auth_key,$this->site_id),
'cancel'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_CANCEL,0,$p->participant_id,$auth_key,$this->site_id),
'decline'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_DECLINE,0,$p->participant_id,$auth_key,$this->site_id),
'acceptall'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ACCEPT_ALL,0,$p->participant_id,$auth_key,$this->site_id),
'acceptplaces'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ACCEPT_ALL_PLACES,0,$p->participant_id,$auth_key,$this->site_id),
'accepttimes'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ACCEPT_ALL_TIMES,0,$p->participant_id,$auth_key,$this->site_id),
'addplace'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ADD_PLACE,0,$p->participant_id,$auth_key,$this->site_id),
'addtime'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ADD_TIME,0,$p->participant_id,$auth_key,$this->site_id),
'addnote'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_ADD_NOTE,0,$p->participant_id,$auth_key,$this->site_id),
'footer_email'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_FOOTER_EMAIL,0,$p->participant_id,$auth_key,$this->site_id),
'footer_block'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_FOOTER_BLOCK,$this->owner_id,$p->participant_id,$auth_key,$this->site_id),
'footer_block_all'=>MiscHelpers::buildCommand($this->id,Meeting::COMMAND_FOOTER_BLOCK_ALL,0,$p->participant_id,$auth_key,$this->site_id),
];
The Meeting model is always loaded prior to these calls, so accessing the site_id is fastest from here.
What's Next?
While all the configurations and small variable changes of this site got a bit annoying to build after a while, it shows off some pretty cool features of the Yii Framework. If you haven't yet, please try scheduling at the new site, Simple Planner.
Share Meeting Planner with your business associates and Simple Planner with your friends and family.
Have your own thoughts? Ideas? Feedback? You can always reach me on Twitter @reifman directly. Watch for upcoming tutorials here in the Building Your Startup With PHP series.
I'm also getting closer to launching the experiment with WeFunder based on the implementation of the SEC's new crowdfunding rules. You can follow our profile there if you'd like. I will also write more about this in a future tutorial.
Comments