Page MenuHomeDevCentral

Provide WordPress SaaS
Open, NormalPublic

Description

We've a SaaS entry point for MediaWiki in rSAASMW.

We can port this code to build a service also based on rSAASSVC to provide WordPress as a SaaS.

Provide two deployments flavours:

  • a free-form deployment as WordPress regular site managing the settings to handle the multisite, for transition and sites willing to attach or detach themselves to our SaaS
  • a canonical WordPress multisite installation (formerly WordPress Mu) for new sites starting from scratch

Documentation: https://agora.nasqueron.org/Operations_grimoire/WordPress

Event Timeline

dereckson triaged this task as Normal priority.Feb 21 2022, 20:18
dereckson created this task.

Some ideas for a WordPress SaaS to consolidate and maintain our different WordPress installations:

Plan could be to:

  • Security
    • each site uses its OWN wordpress user
    • each site uses its OWN database credentials
    • the WordPress multisite installation will so share ONE user, that means it should be restricted to common plugins and themes, e.g. Akismet and the twenty-something
  • Flavours
    • independant deployment: it should be easy to request its own WordPress (not easy like "web panel" but easy like "deploy that Salt state with just this new pillar change")
    • WordPress multisite: a deployment like the others, but shared for several sites
  • WordPress core
    • deploy WordPress source code to /srv/wordpress: every WordPress site upgrades at the same time
    • disable auto-update at site level (will be automatically done by .git presence)
    • provide a custom update mechanism
      • it should first upgrade Git code, then run database migrations, then reload php-fpm (opcache!)
      • if we update a lot, could be nice to have our own specific php-fpm instance for the WordPress pools
      • also use a warmup script to load WordPress classes
  • WordPress wp-content (plugins, themes, uploads)
    • each site has its own wp-content folder, this is mandatory to avoid
    • a wp-content folder = a ZFS filesystem
    • to store in /var/dataroot, like we do for MediaWiki (note MediaWiki don't use ZFS)
    • explore if we need a separate volume for content (for example if could allow easy snapshots in wp-content/ to upgrade and rollback, without rollbacking media uploaded)
    • explore if we can through ZFS provide a base volume for wp-content/ to clone, that would avoid several copies of the same base content
    • explore upgrade strategies: if we only auto update the core that creates an issue for non compatible plugins, and that still create a maintenance burden for other sites => a solution could be to encourage the use of the WordPress multisite

PHP configuration to improve:

  • PHP extensions to add
    • exif
    • imagick
    • zip
  • Post limit to raise, so we can have correct uploads
    • Max size of post data allowed: 8M (should be at least 64M)
    • Max size of an uploaded file: 2M (should be at least 64M)
    • Max effective file size: 2 MB (should be at least 64M)