Fairfax Media have 40+ sites on WordPress, with more added every month.
As part of his new gig with Fairfax Media Jeremy has taken on the task of making this manageable, secure and cost effective, and he will share with you some ideas on approaches to the problem he has used in the past and new approaches that are just being rolled out now.
4. Why WordPress, anyway ?
Ease of training for authors - most used CMS in the world.
Lots of build partners available.
Fast and convenient for journalists - for example WordPress app for
authors.
Fast to stand up, quick to skin, compared to “business” CMSes.
But …
Currently less supportable after go live and needs active dev support if it is
not to “rot”.
4
5. WordPress site types and different
challenges
Seasonal - eg once per year events like
http://www.100womenofinfluence.com.au/
Actively developed eg clique -
http://www.smh.com.au/national/clique/news-and-competitions
Actively used but not actively developed eg
http://www.adcentre.com.au/
Agency
5
Keep WordPress Up to date,
changing development partners
Code review, small isolated dev
teams
Keep WordPress Up to date,
occasional small updates
Sales teams, charging for
customer, keep up to date
7. Key questions any large user must ask
● When should I use WordPress ? When Not ?
● What will it cost to host at the traffic levels I expect?
● How do I make my site secure ?
● Can updates be automated or at least made simple ?
● Is my internal dev/ops team motivated to really run lots of WordPress?
● Dev pipeline from test to prod.
● How will my code get quality reviewed ?
● What plugins are safe ?
● Are core hacks allowed ?
● CDN costs
● Membership integration
7
8. What you need to do
8
● All your code and assets in (one) GIT and have a release automation strategy
(eg bamboo)
● Train your devs on hosting deployment and local dev methods and make sure
doco exists for partner devs
● Core comes from main repo (SVN/GIT) or hosting partner(s)
● Maintain list of acceptable plugins and have process to vet new ones
● Choose hosts, reexamine annually
● Choose dev partners, use “panel” for all internal jobs staff can’t do
● If possible get staff who are active community members or want to be
● Develop one or more parent themes
● Encapsulate any corporate special requirements (eg APIs, paywall, analytics) in
plugins if off the shelf plugins not suitable.
● Contribute to the community
9. The WordPress Flow
9
Prototype
Gated by:
● Business case
● Revenue
● Traffic “Weaponize”
Deploy to
Enterprise
Hosting
Pre-
existi
ng
sites
Innovate
Fix Legacy Issues
10. Choosing a dev Partner
10
● Blended Development model - works to empower your internal dev/ops team
(fishing rods, not fish)
● Do core committers work for the company ? Well known Plugins ?
● Active community members ?
● Do they have great local tech/PM “front men” AND well vetted offshore for
scalability
● What do the top Hosting companies say ?
● Sites like yours
● Lead times
11. What you need to do to host it yourself
11
● So you have internal dev/ops, and are going to cloud self host (eg AWS)
○ Consider using a framework that is “like” the ones the better hosts use
■ Eg Bedrock from roots.io https://roots.io/bedrock-vs-regular-wordpress-install/
○ Get WordPress into your git and automate the update of core - all sites use that
■ https://github.com/WordPress/WordPress
○ Get your authorised plugins into your git, ditto the updates
○ All internal customisations = plugins or themes, in git.
○ code quality checks
■ VIP rules
https://vip.wordpress.com/documentation/vip/code-review-what-we-look-for/ and
vip_scanner
■ Lint, eg https://en-au.wordpress.org/plugins/php-compatibility-checker/ from
wp-engine
■ Check for use of deprecated functions
https://codex.wordpress.org/Category:Deprecated_Functions
■ Even internal themes should follow theme review team guidelines
https://make.wordpress.org/themes/
○ Plugins and tools to capture db from prod and pull to staging on every release candidate
○ Security eg https://sucuri.net/
12. Choosing a hosting Partner
12
● What do the dev partners recommend ?
● Integration with GIT easy (hint - (S)FTP is banned)
● Ticketing system for problems and requests
● Dev/staging/prod - included ?
● Multisite vs many site
● Geography (USA OK, Singapore not so much)
● CDN included ?
● How to core updates work (fully automatic, facilitated)
● Code Quality control included ?
● Plugin limitation acceptable (hint - probably should be)
● Cost model for scaling steps (number of sites, traffic)
● Security Model (hint - they should have one!)
● Authentication for company users (eg against Microsoft AD)
13. Example - WordPress Hosting Tradeoffs
13
Option/
ability
Auto
Patch
WP core
Dev
Staging
?
Front End
Scalability
Database
Scalability
Level 1 Ops
Support
Frontline
Security
Plugin
Vetting
Code
Vetting
Core
Hacks ?
Corporate
Authenticat
ion ?
CDN HTTP(S)
AWS DIY Dependent
on internal
skills
At cost YES,
Dependent on
internal skills
YES,
Dependent on
internal skills
Internal Internal Dependent on
internal skills
Dependent on
internal skills YES YES At own cost
(cloudfront
possible)
either
Pantheon No YES,
included
YES, some
WP
configuration
skill needed
YES, some
WP
configuration
skill needed
Outsourced CDN and
Outsourced
Review on
initial
deployment of
each site
Dependent on
internal skills YES,
though will
impact
easy
updates
YES At own
cost
either
WPEngine Yes Extra
cost
Yes, some
account
management
needed
Yes, some
account
management
needed
Outsourced https://s
ucuri.ne
t/
Yes
Dependent on
internal skills No YES At own
cost
either
Automattic
VIP
YES Staging
at extra
cost
YES YES
Outsourced
YES YES YES NO,
Never
No Included HTTPS
only
14. WordPress can be
used well at scale
it just takes the right
people
and the right
ingredients
14