WordPress website lifecycle

How to work with WordPress. 💡 #active-development #self-hosted #long-term #monitoring

We run WordPress on Debian GNU/Linux operating system which runs on an UpCloud cloud instance.

Division of labour

Who does what.

1. Editor manages the content and related settings.
2. Developer commits plugin and theme source code to GitHub and initiates deployment (CI/CD).
3. Viktor manages the operating system, webserver software, WordPress core, plugins, the theme, privileged users, system settings, security, backup and migrations.

There is no web-based administration. WordPress installation is managed with git, Composer and WP-CLI on the command-line.

More than the famous 5-minute installation

Our WordPress installation includes preparations for the next few error-free years.

These preparations are implemented in MU plugins.

Support my work

Please consider sponsoring me monthly if you use my packages in an agency.

They are already sponsoring me.

           

Working in a git repository

Our WordPress installation is stored in a git repository and managed with Composer.

This is the starter template. szepeviktor/composer-managed-wordpress

Custom plugins and themes live in separate git repositories.

Purchased themes should have an active child theme.

wp plugin install child-theme-configurator --activate

Keep the child theme in a git repository also.

Onboarding for developers

Let's prevent working against each other!

• Don't write code changing WordPress core behavior anywhere else than MU plugins,
  • removing admin menus, admin bar elements
  • disabling emojis
  • disabling comments
  • disabling feeds
  • disabling embeds
  • mail settings and logging
  • WAF: authentication/login, HTTP and REST API security
  • comment form and contact form spam traps
  • media management
  • nav menu, translation and content caching
  • HTTP and HTML optimization
  • CDN support
• Plugin update check HTTP requests and updates itself are disabled because the whole WordPress installation is managed with Composer
• Plugin and theme update and WordPress management-related admin pages are removed (updated with Composer, administered with WP-CLI)
• WP-Cron is ran by a Linux cron job (the default pseudo cron/web callback is disabled)
• Only things necessary for generating custom admin pages and generating HTML go into the theme
• Business logic (e.g. processing input from visitors) goes into plugins
• Please adhere to a coding standard of your choice
• Please avoid discouraged functions
• We run static analysis on all source code
• PSR-4 autoloading is suggested (no need for require and custom class autoloading)
• WordPress core is installed in a separate subdirectory
• Please also see hosting information for developers

High level overview

💡

• Hosting
• Software stack
• Performance
• Security
• Production environment

Installation materials

• WordPress installation: szepeviktor/composer-managed-wordpress
• wp-config
• Alternative WP-CLI installation
• MU plugins for core, theme and plugins: /mu-plugins/ and how to install Default plugins
• Starter plugin: szepeviktor/starter-plugin
• Starter theme: timber/starter-theme
• Starter child theme: /divi-child/
• Feature plugins: szepeviktor/wordpress-plugin-construction

Theme review

• Theme Check plugin
• unofficial fork of Theme Check plugin
• WPThemeReview Standard for PHP_CodeSniffer
• PHP Insights

Development stuff

• Leaving legacy technologies behind
• Hooks in WordPress
• OOP for WordPress
• Tools for development: SentencePress
• wp_mail emails https://github.com/johnbillion/wp_mail

Testing

• Query monitor
• Unit tests without a database https://github.com/Automattic/wordbless
• WP_Mock
• Codeception (BDD)