📱 Utiliser QuickEdit+, Google Drive et des chemins relatifs pour un site Markdown

🎯 1. Le principe général

L'objectif est de disposer d'un environnement de travail pratique sur Android, tout en conservant un site Web portable, utilisable ensuite sur un serveur OVH.

La solution repose sur trois éléments :

L'idée essentielle est de conserver les mêmes chemins relatifs dans les pages Markdown, sans devoir modifier les adresses des ressources selon l'appareil ou le serveur.

📂 2. Organisation des fichiers

Les pages Markdown sont conservées dans Google Drive. Les ressources sont placées dans le stockage interne Android, dans un répertoire commun assets.

Par exemple :

Google Drive/
└── pages-md/
    ├── index.md
    ├── presentation.md
    └── documentation.md

Stockage interne Android/
└── @/
    └── @Files/
        └── markdown/
            ├── pages/
            │   ├── index.md
            │   ├── presentation.md
            │   └── documentation.md
            └── assets/
                ├── css/
                │   └── base.css
                ├── js/
                │   └── script.js
                └── images/
                    ├── logo.png
                    └── photo.jpg

Cette représentation illustre l'organisation logique recherchée. Les fichiers Markdown peuvent être ouverts directement depuis Google Drive avec QuickEdit+, tandis que les ressources sont accessibles dans le stockage interne Android.

Le répertoire assets rassemble toutes les ressources communes :

Cette organisation facilite la maintenance : une seule feuille de style peut être utilisée par toutes les pages.

🔗 3. Le problème rencontré avec les chemins relatifs

Dans une page Markdown, on souhaite utiliser des références simples et portables.

Par exemple, pour charger une feuille de style :

<link rel="stylesheet" href="assets/css/base.css">

Pour charger un script JavaScript :

<script src="assets/js/script.js"></script>

Pour afficher une image :

![Logo du site](assets/images/logo.png)

Ces références sont relatives : elles ne contiennent ni le nom d'un serveur ni le chemin absolu du stockage Android.

C'est précisément ce qui les rend intéressantes pour un site destiné à être transféré sur OVH.

Pourquoi cela ne fonctionnait-il pas initialement dans QuickEdit+ ?

Lorsque l'on ouvre un fichier Markdown depuis Google Drive à l'aide du gestionnaire de fichiers Android, QuickEdit+ affiche son contenu dans un aperçu servi par une adresse locale, par exemple :

http://localhost:2435/storage/emulated/0/Android/data/
com.alphainventor.filemanager/cache/localcache/
googledrive/1/636647997/test.html

Le document est donc affiché à partir d'un chemin de cache temporaire.

Le navigateur interprète les chemins relatifs à partir de l'adresse du document. Il cherche alors les ressources dans le cache de Google Drive, au lieu de les chercher dans le répertoire assets du stockage interne.

Le test réalisé a confirmé ce problème :

JavaScript actif : Oui
CSS ../css/style.css : ERREUR HTTP 404
Image ../images/logo.png : ERREUR HTTP 404

L'erreur 404 indique que la ressource n'a pas été trouvée à l'adresse demandée.

💡 4. La solution : utiliser la balise HTML ``

La balise HTML `` permet de définir l'adresse de référence utilisée pour résoudre les URL relatives d'un document.

Dans notre cas, il suffit d'ajouter cette instruction au début de la partie <head> du document HTML :

Cette instruction indique au navigateur que les chemins relatifs doivent être interprétés à partir du répertoire :

/storage/emulated/0/@/@Files/markdown/pages/

C'est le répertoire local utilisé comme base pour les pages Markdown.

Exemple avec la feuille de style

La page contient :



<link rel="stylesheet" href="assets/css/base.css">

Le navigateur combine la base et le chemin relatif.

L'adresse résultante est :

file:///storage/emulated/0/@/@Files/markdown/assets/css/base.css

La feuille de style est ainsi retrouvée dans le stockage interne Android.

Exemple avec une image

Le même principe s'applique aux images :

![Logo du site](assets/images/logo.png)

Avec la base définie ci-dessus, le navigateur recherche :

file:///storage/emulated/0/@/@Files/markdown/assets/images/logo.png

Exemple avec un script JavaScript

Pour un script, on peut utiliser :

<script src="assets/js/script.js"></script>

Le navigateur recherche alors :

file:///storage/emulated/0/@/@Files/markdown/assets/js/script.js

Une propriété importante de ``

La balise `` concerne toutes les URL relatives du document, pas seulement les feuilles de style.

Elle peut donc influencer :

C'est pourquoi elle doit être placée dans la partie <head> et avant les éléments dont les URL relatives doivent être interprétées à partir de cette base.

Résultat : les pages Markdown restent dans Google Drive, les ressources restent dans le stockage interne Android et QuickEdit+ peut afficher le rendu en utilisant les chemins relatifs habituels.

🏗️ 5. Pourquoi cette balise ne doit pas être conservée sur OVH

La balise suivante est spécifique à notre environnement Android :

Sur OVH, ce chemin n'existe pas : il appartient au stockage interne de la tablette Android.

Il ne faut donc pas conserver cette instruction dans les pages HTML publiées.

En revanche, les références relatives doivent être conservées :

<link rel="stylesheet" href="assets/css/base.css">
<script src="assets/js/script.js"></script>
![Logo du site](assets/images/logo.png)

Sur le serveur Web, ces références seront résolues à partir de l'emplacement de la page HTML, selon l'arborescence du site.

La structure du site publié doit donc respecter les chemins relatifs utilisés dans les pages.

⚙️ 6. Supprimer automatiquement la balise dans build.php

Le plus simple consiste à conserver la balise `` dans les sources Markdown et à la supprimer automatiquement lors de la génération des pages HTML destinées à OVH.

Le fichier build.php transforme les pages Markdown en HTML. Une fois le HTML produit, il peut effectuer un nettoyage avant d'enregistrer chaque fichier final.

Voici l'instruction PHP proposée :

$html = preg_replace(
    '~~i',
    '',
    $html
);

Comment fonctionne cette instruction ?

La fonction PHP preg_replace() recherche les éléments correspondant à une expression régulière et les remplace par une chaîne vide.

Dans notre cas, elle supprime uniquement la balise `` correspondant à l'adresse locale définie pour QuickEdit+.

Décomposition de l'expression :

Élément Signification
`` Termine la balise.
i Rend la recherche insensible à la casse.

Le remplacement par '' supprime la balise sans toucher aux autres éléments du document.

Où placer ce code dans build.php ?

Il faut le placer après la conversion Markdown en HTML et avant l'écriture du fichier HTML final.

Le processus est donc le suivant :

  1. Lire le fichier Markdown.
  2. Convertir le Markdown en HTML.
  3. Supprimer la balise `` locale.
  4. Enregistrer le HTML final dans le répertoire de publication.

Exemple schématique :

// 1. Lire la page Markdown.
$markdown = file_get_contents($sourceFile);

// 2. Convertir le Markdown en HTML.
$html = $parsedown->text($markdown);

// 3. Supprimer la balise base propre à Android.
$html = preg_replace(
    '~~i',
    '',
    $html
);

// 4. Enregistrer la page HTML générée.
file_put_contents($destinationFile, $html);

Cet exemple illustre l'emplacement du nettoyage. Dans le véritable build.php, il faut conserver le mécanisme de conversion, les variables et les traitements déjà présents, et ajouter uniquement l'étape de suppression.

Attention : l'exemple suppose que $markdown, $parsedown, $sourceFile et $destinationFile correspondent aux variables réellement utilisées par le générateur. Il ne faut pas remplacer le programme existant par cet extrait sans vérifier ces noms.

🔄 7. Le processus complet, du travail sur Android à la publication sur OVH

┌─────────────────────────────────┐
│ Google Drive                    │
│                                 │
│ Pages Markdown (.md)            │
│ contenant les références        │
│ relatives et la balise    │
└────────────────┬────────────────┘
                 │
                 │ Ouverture depuis Android
                 ▼
┌─────────────────────────────────┐
│ QuickEdit+                      │
│                                 │
│ Édition du Markdown             │
│ Affichage du rendu              │
│ Chargement des ressources       │
│ depuis le stockage interne      │
└────────────────┬────────────────┘
                 │
                 │ Génération du site
                 ▼
┌─────────────────────────────────┐
│ build.php                       │
│                                 │
│ Conversion Markdown → HTML      │
│ Suppression de la balise base   │
│ Enregistrement des fichiers     │
│ HTML définitifs                 │
└────────────────┬────────────────┘
                 │
                 │ Transfert
                 ▼
┌─────────────────────────────────┐
│ Serveur OVH                     │
│                                 │
│ Pages HTML                      │
│ CSS, JavaScript et images       │
│ Chemins relatifs conservés      │
└─────────────────────────────────┘

✅ 8. Les avantages de cette méthode

Un seul jeu de sources Markdown

Il n'est pas nécessaire de maintenir une version Android et une version OVH de chaque page.

Des chemins relatifs portables

Les références aux ressources restent identiques dans les sources :

<link rel="stylesheet" href="assets/css/base.css">

Elles ne dépendent pas d'un nom de domaine ni d'un chemin absolu propre à un appareil.

Une organisation centralisée

Les ressources communes restent regroupées dans assets :

assets/
├── css/
├── js/
└── images/

Cela facilite les mises à jour et la maintenance.

Une génération automatique

La suppression de la balise spécifique à Android est intégrée au processus de construction. Il n'est donc pas nécessaire de modifier manuellement les pages avant leur transfert sur OVH.

⚠️ 9. Deux précautions importantes

Vérifier l'arborescence publiée

La suppression de `` ne modifie pas les chemins relatifs. Les fichiers HTML générés doivent donc se trouver à des emplacements compatibles avec les références des ressources.

Si les pages HTML sont déplacées dans un répertoire différent de celui attendu par les chemins relatifs, les adresses devront être adaptées à l'arborescence du site.

Vérifier le HTML final

Après la génération, il est utile de vérifier que :

Le nettoyage proposé ne supprime que la balise correspondant à l'adresse locale exacte. Il ne doit pas supprimer les autres éléments HTML.

🏁 Conclusion

La méthode permet de concilier deux environnements différents sans dupliquer les sources :

L'intérêt essentiel est de séparer les besoins de l'environnement de travail des contraintes de l'environnement de publication, tout en conservant une seule version des sources Markdown.