I'm comfortable running my own Linux server, but I'm the only one on my team that is so. Running PHP on Windows is best avoided if possible, and wasn't cost-effective when compared to running as App Services. We had tested running one of the sites on a Linux-based App Service versus a Windows-based App Service, and found the Linux-based service had a significant performance advantage, as measured by response time to the browser.

While we're on the subject of performance, I did not find the performance of Concrete5 to be satisfactory. Both sites are pretty basic brochureware. Some text, images, navigation; a single "contact us" form. Yet, reviewing the database query log for a single page showed 762 database queries. Seven-hundred-sixty-two. Individual queries. One page requested, one time. The action to take here, proposed on the Concrete5 forums and elsewhere by developers building sites with C5, is to enable caching. This does produce a snappy site, as pages are simply served from an on-disk cache instead of constructed from data, but this means you've got to tussle with reconstructing the cache as part of your publishing workflow. I've not had similar problems using WordPress, and maybe either the sites I was given (from two different developers) were poorly implemented, or they're two different use-cases, but either way I'd recommend WP over C5 in cases like this.

In the end though, the fault did not lie solely with Concrete5, Microsoft's Azure cloud service was also to blame.

What was happening, is that when a request came in, C5 was checking to see if the site was being served over HTTPS; and it was. Sort of. The requests were being made to the server and responses back to the client over HTTPS. However, behind the scenes, Azure accepted our request and then via its Application Request Routing scheme, routes the request to our code. As part of that proxying, it changes to HTTP.

An HTTPS header is not set
An HTTP_X_ARR_SSL header is set to the SSL info
An HTTP_X_FORWARDED_PROTO is set to the value "https"
A REQUEST_SCHEME header is set to "http"
A SERVER_PORT header is set to "80"

If your application is checking for a header other than HTTP_X_FORWARDED_PROTO, then it will not correctly detect the URL scheme the request was made via. This is not clearly documented by Microsoft; I happened upon it in a Stack Overflow answer: (https://stackoverflow.com/a/38726543/248917).

Concrete5 builds page content URLs using the scheme and domain info from the incoming request. It checks for an HTTPS header, only checks the HTTP_X_FORWARDED_PROTO in the event a "trusted proxy" is set, and uses that to write the scheme for URLs on the page (see /concrete/vendor/symfony/http-foundation/Request.php). Personally, I'd prefer if URLs were written to the page scheme-less; forcing https-everywhere at the site level would enforce security.

Setting up a C5 site on an Azure Web Service resource with an SSL binding causes pages to be served back to the client over HTTPS, but URLs on the page, including form actions, are written with an HTTP scheme; with an SSL-rewrite rule on the server, C5 forms will not be processed correctly - you won't be able to log in to the admin section, for example.

My solution, while probably not the best, was to add the following code to index.php in the site root:

if(isset($_SERVER['HTTP_X_ARR_SSL'])) {
    $_SERVER['HTTPS'] = 'on';
}

I've done this before, a bit differently, with the files living on the Mac, and utilizing PHPStorm to SCP files to the VM on save for testing/hosting, but this time I'm going to utilize a samba share with inspiration from https://gist.github.com/fideloper/2879466.

I'll enumerate out the steps, and maybe I'll come back and add more detail, but this page is (at least not currently) a complete guide to setup.

Steps

I'm not going to go into everything done to set up a virtual machine; I'm using VMWare Fusion 10 and the gues OS is CentOS 7. I'll enumerate some of the steps taken as well as anything unique to this process.

• Create virtual machine via installation media
• Configure VM (standard housekeeping)
  • set static IP address (192.168.180.112)
    • set gateway, DNS
  • install wget
  • install nano
  • install EPEL
  • install cron
  • install at
  • install screen
  • install NTP
    • synchronize clock
    • start ntpd, run at startup
  • create a user to replace root login
    • enable sudo add user to wheel
  • change default SSH port
  • disable root SSH login
  • add user to SSH
  • install firewalld
    • allow ssh on new port
    • allow localhost
    • alllow http, https, smtp
• Create directory
• Install nginx

That will get us a machine we can develop against. Now to be able to utilize it.

On dev server

• install samba
• set up a share pointing at our directory created previously (/var/www/eid)
• allow samba via firewall-cmd
• add our user to samba users

On Mac

Finder -> Go -> Connect To Server
Add in our server address 192.168.180.112
Connect

Now that we've spent a day searching for solutions for all of the above steps, we're ready to start development.

So, let's go through the choices I've made for this project, and some of the thought behind those choices.

Node.js

The storesdowntown.com site is already on Node. I really like it as a platform for hosting web sites and services; I enjoy working with JavaScript; and there's already more than enough that's new and changing as part of this project, no need to pick something else here.

Express

The site we're replacing uses https://sailsjs.com/ , which is based off Express. I really like Sails, and would use it in the future, but I feel it obscures some of the lower-level aspects of using Node and Express. I so very briefly considered a switch to Koa or Hapi, but there's not enough of a reason for it not to wait for another project.

MongoDB

The first version of the site is running on MySQL, and it's worked quite well. The data model for the site is for now, and the foreseeable future, simple enough that any modern data storage solution would suffice. I'm picking Mongo as I've had little opportunity to work with it in the past. Also, picking the most popular NoSQL database is likely not a bad choice.

React

I definitely wanted to use this project as a springboard into single page applications with a focus on SEO. We've adopted Angular as the SPA framework of choice at my day job and while this was pretty much a coin-toss between Angular and React, I'm going to try and expand my horizons even further with this project and see on which side of the coin I'd prefer to be on.

Amazon AWS

storesdowntown.com was initially published on an instance of CentOS running Nginx. Hosting was procured from https://openvirtuals.com/ and has been a good experience. I'm going to continue running other sites and services there, but in the interest of staying up-to-date (the whole purpose of this exercise), we're moving to a cloud hosting provider.

I'll continue to do development on a Mac with the actual development server as a VMWare Fusion-hosted CentOS instance. I find developing full stack natively that eventually you run into a conflict.

Docker

We probably won't be utilizing Docker to its potential on a simple project like this, but I'm trying to define a set of best practices for myself as part of this and containerization definitely falls into that.

Jenkins

For CI/CD, I only considered three options: Jenkins, Circle CI, and Strider. I'm using Jenkins and Circle CI on other projects, and between those two I'd choose Jenkins, mostly based on cost and popularity. Of the CI/CD tools out there, the only one that caught my attention was Strider, as it's based on Node. I think I'll stick with Jenkins for the time being though.

Github

Source control is not even up for debate, even though I'm the only one working on this project. Of all the source control sytems I've used, I actually like Mercurial the best, but Git is a close second and the clear frontrunner in the space.

I've been using http://repositoryhosting.com/ for my personal repos up until now, but I'm using Github everywhere else, so let's use this opportunity to transition to that.

SCSS and BEM

Like Mercurial and Git, I actually prefer Stylus over SCSS (or, at least I did last time I used both concurrently), but the other (SCSS in this case) is wildly more popular, and I use it on other projects.

The only reason I mention this here, and haven't explicitly called out other tech choices, like Webpack, et. al, is that I want to bring attention to using BEM. BEM stands for Block, Element, Modifier, and is a stylistic choice when writing CSS. The best explanation I've found is in [https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/](MindBEMding – getting your head ’round BEM syntax). I've used it on another project, and definitely appreciate it.

Whew! There's a lot in this post, but I wanted to get my stack choices and rationale written down - this is more important than you think. How many times have you worked on a project long after decisions were made and can't remember why those choices were made in the first place? I'm sure there's lots to disagree with here, but I'm not trying to say these are the best, only the best for me on this project. Whether that means they're the best overall, really is up to the individual. Let's move on to some hands-on work.

In order to stay current, and relevant, there's got to be time you spend on projects that take you out of your daily work's stack. To try and achieve this, I'm going to take an existing application I've got in production storesdowntown.com . Often the most difficult hurdle to jump in a project like this, which is done mostly for educational purposes, is the idea of what application to build. Using something that already exists makes things easier and has the added benefit that I'll end up with an upgraded site.

I'll also document the whole thing here; it's primarily for my notes, but if making them public helps someone else, or brings a valuable opinion from a peer, then that's great.

In javascript, all objects are associative arrays. That is to say, each method or property an object contains can be thought of as a key-value pair. So window.location.href can be expressed as window[location][href], where location is the key name of an object inside the window object and href is the key name of an object inside the location object. In the third party libraries I was using, both tried to create an object named "tabs" inside the jQuery.fn object.

Each plugin tried this:

$.fn.tabs = function(some, parameters) {/* plugin code goes here */}

Where "$" is shorthand for jQuery.

What happens is that the included javascript is parsed in order and the last statement to define "tabs" via "$.fn.tabs = X" sets the value of "tabs." If we understand this, we can leverage it to solve our problem. What I did was to create a new jQuery function and assign the value of one of the conflicting functions to this new object.

Create a js file (I named mine fixTabs.js), and include the following:

$.fn.uitabs = $.fn.tabs;
delete $.fn.tabs;

What this does is takes the tabs() function already defined by the first library included and renames it. When the second library defines the tabs() function the first is kept under it's new name (in this case "uitabs", but it can be named whatever you like).

You must include the fix js file between the script tags of the two libraries and remember that the first will be renamed. In this example I am first including the jQuery.ui library, then the fix script, then the jQuery.tools library.

You can then call:

$("#tabs").uitabs(); 
$(".tabs").tabs(); 

I spend most of my free time with family or developing personal projects.

After the update, the mouse was moving extremely slowly. The fix was removing the Smoothmouse driver, using an uninstaller provided by Smoothmouse.

In javascript, all objects are associative arrays. That is to say, each method or property an object contains can be thought of as a key-value pair. So window.location.href can be expressed as window[location][href], where location is the key name of an object inside the window object and href is the key name of an object inside the location object. In the third party libraries I was using, both tried to create an object named "tabs" inside the jQuery.fn object.

Each plugin tried this:

$.fn.tabs = function(some, parameters) {/* plugin code goes here */}

Where "$" is shorthand for jQuery.

What happens is that the included javascript is parsed in order and the last statement to define "tabs" via "$.fn.tabs = X" sets the value of "tabs." If we understand this, we can leverage it to solve our problem. What I did was to create a new jQuery function and assign the value of one of the conflicting functions to this new object.

Create a js file (I named mine fixTabs.js), and include the following:

$.fn.uitabs = $.fn.tabs;
delete $.fn.tabs;

What this does is takes the tabs() function already defined by the first library included and renames it. When the second library defines the tabs() function the first is kept under it's new name (in this case "uitabs", but it can be named whatever you like).

You must include the fix js file between the script tags of the two libraries and remember that the first will be renamed. In this example I am first including the jQuery.ui library, then the fix script, then the jQuery.tools library.

You can then call:

$("#tabs").uitabs(); 
$(".tabs").tabs();