Hefty Sites on WIMPy Servers

Launching a new website for the

Cherokee County School District

cherokeek12.net

The way we were...

  • SharePoint 2007 public website and intranet all-in-one
  • Very little content on pages - primarily PDF document libraries
  • Many users with design rights
  • Permissions all over the place - permissions down to the library and list level
  • Site overly-customized - no upgrade path, even to SharePoint 2010

Decisions, decisions...

But we love SharePoint!

  • Make SharePoint not look like SharePoint
  • Spent 2 months theming SharePoint
  • Developed a theme, but each change broke something.
  • Drank copious amounts of alcohol.

Decisions, decisions...

Going Rogue

  • Set up Windows 2012r2 VM with WordPress
  • Developed child-theme prototype based on the Enigma theme.
  • Chose Enigma because...
    • Based on the Bootstrap responsive framework
    • Drastically different look-and-feel from SharePoint
    • Shiny features which could be modified through WYSIWIG options

Decisions, decisions...

Going Rogue

  • Presented to Assistant Superintendent of Technology - approval to proceed with WordPress as the new public website CMS!
  • January - February: revised design, presented to Administration
  • Administration is on board! Final design approval on March 1st.

Resistance is futile, you will be assimilated.

  • Main school district site "completed" in April; presented to principals
  • Subsequently implemented WP Multisite and created 43 subsites:
    • One site per school - each school uses the child theme, but has its own stylesheet
    • Chose Multisite specifically to keep sites separate - content separate, logins separate

Resistance is futile, you will be assimilated.

School Webmasters

  • No centralized website department or content team. Public Information has oversight, but content is the responsibility of each school.
  • Each school has its own webmaster - usually a teacher or media specialist, that receives a stipend to be the school webmaster.

Resistance is futile, you will be assimilated.

School Webmasters

  • Webmaster training conducted May 9th - basic logging in, creating/editing pages and posts, and how to post slideshow photos.
  • More resistance from webmasters than from administrators. We moved their cheese.
  • The webmasters can now login...

Life in the Thunderdome

  • Severe lack-of-understanding on responsive design.
    • Failure to think mobile!

Life in the Thunderdome

  • "Avoid PDFs" translated to...
    • Use Word documents instead
  • Enough tables we needed a maître d'
    • "But we thought we were encouraged to use tables for layout."

Life in the Thunderdome

  • Overall lack of understanding on links.
    • Links do not automagically appear.
    • Using the preview page as a link.
    • Linking to the old website.
  • Difficulty understanding editing calendar within the Events menu instead of on the calendar page.
  • And the worst of all...
    • "But I already know a little something about HTML."

Surviving the Thunderdome...

  • Created the CCSD Webmasters Group in Office 365
    • Regular threads/discussions
    • Lots of "How to..." documents
    • One-on-one training

Surviving the Thunderdome...

  • Lock down visible Dashboard menu options.
    • Webmasters need edit_theme_options capability to edit the slideshow
    • Created ccsd_customizer_filter() function to hide additional theme options
    • Created ccsd_hide_menus() function to hide additional dashboard options

Surviving the Thunderdome...

  • Teachers make the worst students...
    • Despite hiding the menu options, some webmasters derived the URL to access hidden options.
    • Created the redirect_naughty_children() function, which redirects the webmaster to the Dashboard if they attempt to access hidden locations.
  • Using Siteimprove (paid service) for analytics.

The Tech Specs

The Tech Specs: System Goals

  • Multiple WordPress front-ends, fronted by a load balancer
  • Shared wp-content directory
    • Avoid sync issues with media uploads
    • Plugins and themes stay in sync, as well
  • Separate, shared MySQL server
    • Separate, to spread load
    • Shared, to keep configuration consistent
  • Responsive, mobile-friendly theme

The Tech Specs: Social Goals

  • Limit capabilities of individual site Webmasters
  • Allow extra capabilities for "trusted" Webmasters

The Tech Specs: Configuration

4 Servers Total:

  • 2 front-end servers
  • 1 database server - centralized database and wp-content directory
  • 1 development server
  • WIMP stack: Windows, IIS, MySQL, PHP

Tech Specs: Production Servers

WP-Web1  |   WP-Web2  |   WP-Database

There could be additional front-end WordPress servers. Their setup would be identical to WP-Web1 and WP-Web2.

About the WP-Database Server:

  • WP-Database server also runs WordPress, but it is not in the load balancing rotation -- it is only accessible from the internal network.
  • The wp-content folder on this server is the "master" copy which is shared to the other servers.

Server Setup

Warning: Tech Ahead!

Web Platform Installer

Microsoft's WPI is probably the easiest way to get WordPress up and running with IIS.

https://www.microsoft.com/web/downloads/platform.aspx

It will install MySQL, PHP (as a FastCGI process), and WordPress. It will also create the IIS site configuration, the MySQL user and database for WordPress to use, and the initial settings for your wp-config.php file.

We used WPI to install WordPress to all three of the servers.

Domain User

Because we want to use a shared content directory, we need to create a domain user which IIS/PHP will use for shared filesystem permissions. Let's call it MYDOMAIN\IISPHP.

Keep in mind the security principal of Least Privilege. This account should only have the access it absolutely needs.

WP-Database

This server is not in the load-balancing rotation, and is only accessible to the front-end servers and the internal network. However, we still want WordPress running here, because it is going to hold the master copy of the wp-content folder which will be shared on the network to the front-end servers.

We give our MYDOMAIN\IISPHP account ownership and control of wp-content.

WP-Database

After installing WordPress, we configured Multisite in the usual way, by setting the appropriate define() statements in the wp-config.php file. 


/* Multisite */
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'cherokeek12.net' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

WP-Database

By default, the DB_USER account can only connect to MySQL from its own server. We have to tell MySQL to allow the user to connect from our other front-end servers. Run mysql from the command line, and grant permissions to the user: 

C:\> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 86197

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> GRANT ALL PRIVILEGES ON wpdbname.* TO 'wpdbuser'@'server.ip.number';

WP-Database

C:\> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 86197

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> GRANT ALL PRIVILEGES ON wpdbname.* TO 'wpdbuser'@'server.ip.number';

Do this for each front-end server (WP-Web1 & WP-Web2), substituting the appropriate values for the database name, user name, and server IP address.

If you aren't comfortable with the command line, you can also do this with the MySQL Workbench app, under Users and Privileges.

WP-Web1 & WP-Web2

These are our load-balanced front-ends. We can disable the MySQL service on these servers, and modify wp-config.php to point to the WP-Database server. They should use the same database settings as WP-DATABASE. For example: 

define('DB_NAME', 'wordpress999');
define('DB_USER', 'wordpressuser999');
define('DB_PASSWORD', 'mydbpassword');
define('DB_HOST', '10.1.2.3');

WP-Web1 & WP-Web2

We also delete (or rename, or move) the wp-content folder on these servers, and replace it with a link to the network share from WP-Database: 

mklink /d C:\InetPub\wwwroot\wp-content \\WP-Web1\wwwroot\wp-content

This lets WordPress map URLs <==> filenames without additional trickery.

WP-Web1 & WP-Web2

At this point, the front-end servers are mostly configured, and serving up web pages; however, Media Uploads were not working.

Over time, we discovered that there were several pieces to this puzzle, and you have to get all of them into place before uploads will work on the shared content directory configuration.

For detailed information, please see Dougal Campbell's presentation:
Get Off My Lawn! ...and out of my Dashboard!
http://dougal.us/presentations/getoffmylawn/

More Cowbell!

Features through functions...

  • Automagically queue a site style based on a stylesheet naming convention
  • Adjust Footer Menu layout for 3 auto-flow columns
  • Hide some Dashboard menu options
  • Remove unwanted customizer options
  • Redirect naughty children
  • These functions were added to the functions.php file of the child theme

What now?

  • Continuing education for webmasters
  • Utilizing Siteimprove data to fix sites - primarily broken links and misspelled words
  • Still adding sites... School Nutrition, Athletics
  • Working through "To do" list

In the future...

  • Tables - appropriate use, responsive
  • Gravity Forms - move away from PDFs to true online forms
  • Custom Post Types for specific pages, like Board Agenda Meetings
  • Multisite menu replication - lock root-level items, allow webmasters to edit portions

Thanks for coming!

@suzecampbell  |  @dougal

cherokeek12.net

For more information...

Get Off My Lawn! ...and out of my Dashboard!
by Dougal Campbell
http://dougal.us/presentations/getoffmylawn/

Teachers Make the Worst Students!
by Susan Campbell
http://www.digitaldivas.net/presentations/TeachersWorstStudents/