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)
dereckson removed dereckson as the assignee of this task.Mon, Mar 23, 09:23

Unassigning this task to make it available for others.

As I'm not currently working actively on this issue, reset the assignee.

Contributions opportunity. If you’re interested, go ahead and assign yourself. I’m available to share context, review early approaches, or pair if helpful—just tag me.