Upgrading

To 7.1.412

• Nothing to change. The release frees the PHP-FPM pool between requests again: on 7.1.4-6 to 7.1.411 every PHP request bound its worker to NGINX for a minute after the response, so a few requests per minute left a site slow, its readiness probe timing out and NGINX answering 502. Upgrade every installation on those versions. An installation that pins the image by image.digest keeps the image of that digest whatever the chart version says: set the digest of the 7.1.412 image, or clear the value so that the chart's tag applies. Until then, a script in customPostInitScripts helps a site, since the image runs it before NGINX starts: sed -i 's/fastcgi_keep_conn on;/fastcgi_keep_conn off;/' /etc/nginx/custom.d/01-common.conf.

To 7.1.411

• The pod has no HTTPS port any more. The image listens on port 80 only and the chart renders no port https: not on the container, not on the Service, not in the NetworkPolicy. TLS ends at the Ingress, as before; an installation that reaches the site through the Ingress or the Service's port http needs nothing.
  • Whatever used the Service's port https (443), which answered with a placeholder certificate, has to use the port http, or the Ingress: a Service of type LoadBalancer or NodePort addressed on 443, an Ingress or a route of your own that names the Service's port https, a rule that forwards to 443.
  • containerPorts.https, service.ports.https, service.httpsTargetPort and service.nodePorts.https are gone from values.yaml. A values file that still sets them renders as before, apart from the missing port, and the notes after helm upgrade name the ones that are set. Take them out.
• The readiness and the startup probe ask over HTTP. Their defaults followed wordpressScheme, so a site with wordpressScheme: https was asked on the port https. They now ask /healthz.php on the port http with the scheme HTTP, whatever wordpressScheme is; a release that leaves the probes at their defaults needs nothing. One that sets readinessProbe.httpGet, startupProbe.httpGet or a custom probe with the port https or 443, or the scheme HTTPS, has to change it to http and HTTP: the chart refuses to render such a probe, because its pods would never become ready. helm template with the release's values shows it before the upgrade.
• Responses no longer carry an Alt-Svc header that announces HTTP/3 on port 443. An Ingress controller that serves HTTP/3 announces it itself.
• The reindex endpoint of the search sidecar has a key from this version. With idx.enabled and neither idx.reindexApiKey nor idx.existingReindexApiKeySecret, POST /api/reindex was switched off. The chart now generates a key at the upgrade, keeps it in the Secret <fullname>-idx, and hands it to the search plugin, so "Rebuild index" in wp-admin works. Nothing has to be done. A tool that renders the chart without access to the cluster (helm template, Argo CD) would generate a new key with every render: set idx.reindexApiKey or name a Secret there.
• The pod is ready a little later after the upgrade, and the index build needs room on the volume. With idx.enabled, the sidecar builds its index anew once, at its first start with this version, and needs the database for that start. The pod is not ready before the index is written: with the chart's default update strategy the earlier pod serves the site until then, with Recreate the site is away for that time.
  • The index is on the WordPress volume, under idx/. The build needs room there for three to four times the new index file while it runs, next to the file of the earlier version, which is removed once the new index is written. On a site of 15,600 posts and pages the new file has 143 MB and the earlier one 415 MB. Check the free space on the volume before the upgrade of a large site: without room the build fails and is tried again every 5 seconds, and the pod does not get ready.

To 7.1.410

• Back the database up before the upgrade. With mariadb.enabled and the chart's default mariadb.image, the bundled MariaDB moves from 12.2 to 12.3 and starts on the existing data directory. It updates its system tables at that first start, and MariaDB does not support going back to the earlier series. An installation that sets mariadb.image itself keeps its image, and an external database is not affected.
• The search is ready a little later after the upgrade. With idx.enabled, the sidecar builds its index anew once, at its first start with this version. Nothing has to be done by hand.

To 7.1.409

• The search sidecar's image carries the chart version as its tag. It is built by this project's release from now on: with idx.enabled, the chart runs ghcr.io/ioanalytica/wordpress-idx:7.1.409, where it ran a 1.x.y tag before. An installation that takes the image from its default repository needs nothing. One that points idx.image.registry or idx.image.repository at a mirror copies the image there under the chart version before it upgrades; idx.image.digest still wins over the tag.
• Helm checks every value against the schema. values.schema.json now covers every value and refuses a value of a kind the chart cannot use, such as a list where the chart reads a single value. helm template with the release's values shows before the upgrade whether one of them is refused.
• wordpressExtraConfigContent takes effect. A release that has set it, so far without effect, gets its PHP statements evaluated in wp-config.php. Check the content first: a statement PHP cannot parse stops every request.
• customHTAccessCM and metrics.prometheusRule are gone from values.yaml. Neither had an effect, and a values file that still sets them renders as before.
• The defaults under containerSecurityContext changed. They apply only with containerSecurityContext.enabled: true, which stays off by default. With the earlier defaults (user 1001, a read-only root filesystem, all capabilities dropped) neither container started; the defaults are now what the image runs with: runAsUser: 0, runAsGroup: 0, runAsNonRoot: false, readOnlyRootFilesystem: false, capabilities.drop: []. A release that enables the context and sets these values itself renders as before.
• With metrics.enabled, the NetworkPolicy admits the exporter's port, like the HTTP port: from every source with networkPolicy.allowExternal: true, the default. A rule in networkPolicy.extraIngress that admitted the scrape is no longer needed; a release whose rule admitted it from selected sources only has the port open to every source now, and networkPolicy.allowExternal: false narrows all of the pod's ports.
• metrics.serviceMonitor.metricRelabelings and metrics.serviceMonitor.selector take effect: rules and labels set there, so far without effect, reach the ServiceMonitor with this version.
• Both images and the chart are signed; Verify a release has the commands.

To 7.1.408

The chart version scheme changed: 7.1.408 follows 7.1.4-7. The build number moved from a -N suffix into the patch component (see Chart versions), so releases are stable SemVer versions and no longer pre-releases. Chart and image are otherwise the same as in 7.1.4-7; no values changes are required.

• A deployment that pins an exact version (--version, a Flux HelmRelease, an Argo CD targetRevision) changes the pin to the new form with its next upgrade.
• --devel is no longer needed to install or upgrade without --version.
• A range that named a pre-release to match the earlier versions needs a look at its upper bound:
  • Without one, it keeps matching. >=7.1.0-0 selects the new versions too, and its pre-release part is no longer needed (>=7.1.0).
  • Bounded to one WordPress patch release, it matches nothing new and upgrades stop without an error: >=7.1.4-0 <7.1.5-0 accepts 7.1.4-7 but not 7.1.408. The builds on WordPress 7.1.4 are now >=7.1.400 <7.1.500.
• Earlier versions and their image tags stay published unchanged.

To 7.0.0-2

• First-class Traefik support: ingress.ingressClassName: traefik is now a fully supported steady-state value alongside nginx and nginx-traefik. See "Supported ingressClassName values" in the Ingress section for the per-class behaviour matrix (which provider serves the Ingress, whether nginx-style annotations are translated, silently ignored, or interpreted natively).

• New: redirect: values block (see Ingress → Redirects section above). Backwards-compatible — opt-in, defaults to disabled. Renders a kind:Ingress on nginx and a kind:Middleware + kind:IngressRoute (+ optional kind:Certificate) on nginx-traefik / traefik. Note: the nginx-path redirect drops the request path (annotation limitation); the Traefik-path redirect preserves it (redirectRegex with capture group).

• Breaking: the bitnami-compatible nginx.ingress.kubernetes.io/from-to-www-redirect: "true" annotation is no longer honoured. If you relied on it for cert expansion only, set ingress.tlsWwwPrefix: true (or secondaryIngress.tlsWwwPrefix: true). If you relied on it for the actual www-magic redirect, declare the redirect explicitly via the new redirect: block.

To 7.0.0-1

Updates WordPress to 7.0.0. Review the WordPress 7.0 release notes for breaking changes before upgrading. No chart values changes required.

To 6.9.4-13

Two nginx behavior fixes:

• Removes an overly restrictive method allow-list in the image's nginx config that returned 444 (TCP RST) for any method outside GET / HEAD / POST. This silently broke the WordPress REST API for OPTIONS (capability discovery + CORS preflights), PUT, DELETE, and PATCH — methods the Gutenberg block editor and most REST clients rely on. After upgrading, all HTTP methods reach PHP-FPM, and WordPress handles unsupported methods itself with proper 405 Method Not Allowed responses.
• Fixes a dead volumeMount so that nginxCustomServerBlockAddition / existingCustomServerBlockAdditionConfigMap actually take effect. Previously the ConfigMap volume was declared in the Deployment but never mounted, so user-supplied server-block additions were ignored.

No values changes are required. If you use existingCustomServerBlockAdditionConfigMap, ensure the ConfigMap exposes its content under the key 01_userconfig.conf.

To 6.9.4-9

Version 6.9.4-9 removes all Bitnami chart dependencies. Key changes:

• MariaDB: Now uses a native internal deployment (image: mariadb:12.2.2-noble) instead of the Bitnami MariaDB subchart. The mariadb.image parameter is new. The mariadb.architecture parameter (replication mode) is no longer supported for internal deployments.
• Cache: The memcached.enabled key is preserved for backward compatibility. When enabled, it now deploys Dragonfly (serving both Redis and Memcached protocols) instead of the Bitnami Memcached subchart. New parameters: memcached.image, memcached.password, memcached.persistence.*.
• Resource presets: Still available via resourcesPreset but now provided by the ioanalytica/common library chart.
• Volume permissions: The volumePermissions section has been removed.
• Default credentials: Database defaults changed from bitnami_wordpress/bn_wordpress to wordpress/wp_user.
• Common chart: Switched from bitnami/common to ioanalytica/common.