# Diagnostic — toulouse-les-orgues.org

> Serveur : Scaleway `scw-sleepy-Apache` (51.158.96.239) — Ubuntu 24.04
> Stack : Apache 2.4.58 + PHP 8.3.6 + MariaDB 10.11.14 + WordPress (préfixe `tlo_racine_`)
> Date du diag : 2026-06-23 — **lecture seule, aucune modification appliquée**

---

## TL;DR

| # | Problème | Gravité | Impact utilisateur | Statut |
|---|----------|---------|--------------------|--------|
| 1 | **PHP TypeError** dans `single-artiste.php:133` | 🔴 Critique | **Pages artistes en erreur 500** | ✅ **CORRIGÉ 2026-06-23** |
| 2 | **Auth root MariaDB cassée** (`debian.cnf` sans mot de passe) | 🟠 Élevée | Maintenance/upgrade/backup root KO au boot | À corriger |
| 3 | Variables PHP non définies (`$size`,`$icon`,`$attrib`…) | 🟡 Moyenne | Warnings, bruit dans les logs | À corriger |
| 4 | **DB obèse : 1.28 Go de logs WP Time Capsule** | 🟠 Élevée | DB lente/lourde, backups gonflés | Optim |

> ⚠️ **Contre-intuitif** : la connexion WordPress → base de données **fonctionne** (`WP_DB_OK`).
> L'« erreur d'accès à la base » ressentie = en réalité **(1)** le fatal PHP qui casse les pages artistes,
> et **(2)** l'auth `root` MariaDB cassée côté maintenance système. Ce ne sont **pas** des erreurs de connexion WP→DB.

---

## 1. 🔴 PHP Fatal — pages artistes cassées (cause racine du "site KO")

```
PHP Fatal error: Uncaught TypeError: in_array():
Argument #2 ($haystack) must be of type array, string given
in single-artiste.php:133
```

**Code fautif** (`wp-content/themes/toulouse-les-orgues/single-artiste.php`) :
```php
foreach( $posts as $post ) {
    $interpretes = get_field('interpretes', false, false);   // ACF
    if (in_array($artisteActuel, $interpretes)) {             // ← L133 : $interpretes peut être string|null
        $tabProgrammationEvent[] = get_the_ID();
    }
}
```

**Cause racine** : sous **PHP 8.x**, `in_array($needle, $haystack)` lève une `TypeError` si `$haystack`
n'est pas un tableau. Le champ ACF `interpretes` renvoie parfois une **chaîne** (ou `null`) au lieu d'un
tableau (champ non rempli, ou stocké comme valeur unique). Avant PHP 8 c'était un simple warning → d'où
l'apparition récente du bug après la montée en PHP 8.3.

**Fix proposé (minimal, sans risque)** :
```php
if ( is_array($interpretes) && in_array($artisteActuel, $interpretes) ) {
```

> ✅ **APPLIQUÉ le 2026-06-23.** Ligne 133 corrigée, `php -l` OK.
> Backup : `single-artiste.php.bak-20260623-inarray`.
> Vérif : `/artiste/silva-orendain/`, `/opstad/`, `/candau/` → **HTTP 200** (étaient 500).

---

## 2. 🟠 Auth root MariaDB cassée (le vrai problème "accès DB" côté infra)

Symptômes (logs systemd MariaDB, à chaque boot) :
```
Access denied for user 'root'@'localhost' (using password: NO)
/etc/mysql/debian-start: ERROR 1045 (28000): Access denied ... FATAL ERROR: Upgrade failed
```

**Tests effectués :**
- `mysql` (root via socket) → ❌ `Access denied (using password: NO)` → **root n'est PAS en `unix_socket`**, il attend un mot de passe.
- `mysql --defaults-file=/etc/mysql/debian.cnf` → ❌ `Access denied (using password: NO)` → le **champ `password` de `debian.cnf` est vide**.

**Cause racine** : le compte `root@localhost` a été basculé en authentification par **mot de passe**
(plugin `mysql_native_password`), mais `/etc/mysql/debian.cnf` ne contient **aucun mot de passe**.
Du coup, tous les scripts de maintenance Debian (`debian-start`, `mariadb-upgrade`) qui se connectent en
root échouent au démarrage → "Upgrade failed".

**Conséquence** : pas d'accès admin à MariaDB, pas d'upgrade auto des tables, maintenance/backup root KO.
Pas (encore) visible pour le visiteur, mais c'est une bombe à retardement (un upgrade MariaDB raté peut
corrompre des tables).

**Options de fix (À VALIDER — choix utilisateur)** :
- **A.** Repasser `root@localhost` en `unix_socket` (recommandé sur Debian/Ubuntu) → maintenance auto OK, pas de mot de passe à gérer.
- **B.** Renseigner le mot de passe root existant dans `/etc/mysql/debian.cnf` (si on le connaît).
- **C.** Créer un user de maintenance dédié avec les bons droits et pointer `debian.cnf` dessus.

> Toute option nécessite un accès admin MariaDB → si le mot de passe root est perdu, redémarrage en
> `--skip-grant-tables` requis (= action serveur, à valider explicitement).

---

## 3. 🟡 Variables PHP non définies (warnings)

```
PHP Warning: Undefined variable $size / $icon / $attrib
  → single-artiste.php:34  (wp_get_attachment_image($photo_artiste_1, $size, $icon, $attrib))
PHP Warning: Undefined variable $retour / $size / $icon
  → plugins/pepille_shortcode/includes/moteurArtistesTexte.php:12
  → plugins/pepille_shortcode/includes/resultatArtistes.php:73
```

**Cause** : variables jamais initialisées avant usage (toléré < PHP 8, bruyant en 8.3).
**Fix** : initialiser explicitement (`$size = 'full'; $icon = false; $attrib = '';`) ou retirer les
arguments inutiles de `wp_get_attachment_image()`.

---

## 4. 🟠 Obésité de la base de données (chantier optimisation)

Top tables (sur ~1.5 Go total) :

| Table | Taille | Lignes | Origine |
|-------|--------|--------|---------|
| `tlo_racine_wptc_activity_log` | **1276 Mo** | 1 387 985 | **WP Time Capsule** (log d'activité) |
| `tlo_racine_postmeta` | 151 Mo | 289 483 | WordPress (méta, potentiels orphelins) |
| `tlo_racine_posts` | 56 Mo | 15 652 | WordPress (révisions ?) |
| `tlo_racine_wptc_processed_files` | 41 Mo | 62 630 | WP Time Capsule |
| `tlo_racine_aiowps_audit_log` | 36 Mo | 6 236 | All In One WP Security |
| `tlo_racine_wptc_current_process` | 6 Mo | 20 214 | WP Time Capsule |

**Constat** : **~88 % de la base = logs du plugin WP Time Capsule**. C'est le levier d'optim n°1.

### ✅ Fait le 2026-06-23
- `wptc_activity_log` : **1276 Mo / 1.39M lignes → 0** (TRUNCATE). Disque 99% → 96%.
- Set sûr tronqué : `aiowps_audit_log`, `wptc_processed_files`, `wptc_current_process`,
  `wptc_processed_iterator`, `wptc_processed_restored_files`, `wptc_query_recorder`,
  `aiowps_debug_log`, `aiowps_events`.
- **Préservé** (config/référence) : `wptc_backups` (76 points de restauration), `wptc_options`,
  `wptc_inc_exc_contents`, `aiowps_login_lockdown`, `aiowps_permanent_block`, `aiowps_global_meta`.

### 🔎 Découverte : plugins orphelins
`active_plugins` ne contient **NI WP Time Capsule NI All-In-One WP Security**. Backup actif = **UpdraftPlus**.
→ Toutes les tables `wptc_*` et `aiowps_*` sont des **orphelines** → candidates à un `DROP` complet.

### 🐘 Vrai problème disque : `wp-content/uploads` = 9.9 Go (DB = 865 Mo)
Disque root 36 Go à **95%**. Priorité d'optim = les uploads (médias non optimisés, backups UpdraftPlus locaux ?).

### 🔥 Cause racine disque trouvée : UpdraftPlus
`wp-content/updraft` = **16 Go** : 47 archives `.zip` locales (15 Go) + 857 Mo de logs.
- Destination = Google Drive (uploads **OK**, copies offsite confirmées dans les logs).
- `updraft_delete_local=1` (déjà bon) MAIS **les 7 sets étaient flaggés "Always Keep"** → jamais purgés.
- Backup du jour en **échec / boucle de relance** (562× `No space left on device`) → log de 795 Mo.

### ✅ Fait le 2026-06-23 (validé utilisateur)
| Action | Résultat |
|--------|----------|
| Stop boucle backup (`updraft_backup_resume` + jobdata) | ✅ (backups récurrents préservés) |
| Suppression logs + temp UpdraftPlus | **859 Mo** libérés |
| Purge archives locales (garde set 16 juin) | **12.6 Go** libérés |
| Retrait flag "Always Keep" (7 sets) | ✅ rétention 6 sets réactivée |
| `DROP` 17 tables orphelines `wptc_*`/`aiowps_*` | ✅ 0 restante |
| **Disque `/`** | **95% → 58% (16 Go libres)** |
| Vérif site (`/`, `/artiste/…`) | **HTTP 200** ✅ |

> ⚠️ Le set local du 16 juin gardé est **incomplet** (uploads2-8 seulement, pas de DB) — restauration réelle = Google Drive.

### Reste à optimiser (non bloquant)
- `wp-content/uploads` = 9.9 Go (médias) → Imagify est actif, vérifier WebP/compression des vieux médias.
- Révisions de posts, postmeta orphelins, transients expirés.
- Tuning MariaDB (`innodb_buffer_pool_size`), slow query log.
- Surveiller que le prochain backup UpdraftPlus se termine et purge bien (disque OK maintenant).
- `autoload` = 0.85 Mo / 511 options → **OK**, pas prioritaire.
- Tuning MariaDB (`50-server.cnf` actuellement sans override innodb visible — à confirmer) :
  `innodb_buffer_pool_size`, slow query log. Serveur : 3 vCPU / 3.8 Go RAM.
- Front Apache : compression Brotli/Gzip + cache statique **déjà bien configurés** (`toulouse.conf`).

---

## Plan d'action proposé (ordre)

1. **[Fix #1]** Corriger le `in_array` (1 ligne) → débloque les pages artistes. ← *quick win, fort impact*
2. **[Fix #3]** Initialiser les variables PHP → logs propres.
3. **[Fix #2]** Réparer l'auth root MariaDB (choix A/B/C).
4. **[Optim #4]** Purge WP Time Capsule + nettoyage WP + tuning MariaDB.

> **Aucune de ces actions n'est appliquée tant que tu ne valides pas, étape par étape.**