Warum diese Kombination?

Access ist bei vielen KMU das Herzstück.
Rechnungen, Stammdaten, Kalkulation, alles lokal.
Aber Kunden wollen online zugreifen – auf Dokumente, Aufträge, Daten.

WordPress ist schnell aufgesetzt.
Benutzerverwaltung, Login, Rollen – alles da.
Und: mobil nutzbar.

Ich nutze WordPress als Frontend.
Und Access bleibt das Backoffice.

Architektur im Überblick

Komponente	Aufgabe
WordPress	Kundenportal mit Login
MySQL	Web-Datenhaltung (Kopie)
Access	Datenpflege, Businesslogik
ODBC / REST	Brücke zwischen beiden Welten

Du pflegst alles in Access.
Der Kunde sieht nur das, was Du ihm freigibst – in WordPress.

Datenfluss: Von Access nach WordPress

Ziel: Access schiebt selektive Daten in die WordPress-MySQL.

Beispiel in VBA:

Sub KundeExportieren(kundeID As Long)
    Dim dbWeb As DAO.Database
    Set dbWeb = OpenDatabase("", False, False, _
        "ODBC;Driver={MySQL ODBC 8.0 Driver};Server=wp-db;Database=wordpress;UID=apiuser;PWD=geheim;")

    dbWeb.Execute "DELETE FROM wp_kundendaten WHERE kunde_id = " & kundeID

    dbWeb.Execute "INSERT INTO wp_kundendaten (kunde_id, name, status) " & _
        "SELECT ID, Firma, Status FROM tblKunde WHERE ID = " & kundeID

    dbWeb.Close
End Sub

Wichtig: Nur Freigabe-Felder schreiben. Kein Wildwuchs.
Und: Nur lesend übergeben, nicht bidirektional.

WordPress: Daten anzeigen ohne Admin-Zugang

Custom Post Types brauchst Du nicht.
Ich arbeite mit Shortcodes und wpdb.

Beispiel in functions.php:

add_shortcode('kundendaten', 'zeige_kundendaten');

function zeige_kundendaten() {
    global $wpdb;
    $user_id = get_current_user_id();
    $kunde_id = get_user_meta($user_id, 'access_kunde_id', true);

    $daten = $wpdb->get_results("SELECT * FROM wp_kundendaten WHERE kunde_id = $kunde_id");

    foreach ($daten as $zeile) {
        echo "<p><strong>Firma:</strong> " . esc_html($zeile->name) . "</p>";
        echo "<p><strong>Status:</strong> " . esc_html($zeile->status) . "</p>";
    }
}

Der Kunde sieht nur seine Daten.
Kein wp-admin nötig.

Authentifizierung und Rechte

Ich weise jedem WordPress-User eine access_kunde_id zu.
Das ist der Schlüssel in beide Richtungen.

In Access steht:

SELECT * FROM tblKunde WHERE ID = [Formulare]![frmBenutzer]![KundeID]

In WordPress prüfe ich:
Darf dieser Nutzer diese kunde_id sehen?

Synchronisierung und Automatisierung

Ich arbeite mit Aufgabenplanung.
Beispiel: nächtlicher Export über Access:

Sub Nachtsync()
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT ID FROM tblKunde WHERE SichtbarWeb = TRUE")

    Do While Not rs.EOF
        Call KundeExportieren(rs!ID)
        rs.MoveNext
    Loop
    rs.Close
End Sub

Der Taskplaner startet Access:

msaccess.exe "C:\DeineDB.accdb" /x Nachtsync

Keine manuelle Pflege.
Keine Zwischenhändler.

Zugriff vom Kunden: Einfach, responsiv, rollenbasiert

Ich nutze das Plugin MemberPress oder User Role Editor.
Damit steuere ich, wer was sieht.
Und welche Seiten für wen sichtbar sind.

Wenn der Kunde neue Daten braucht:
In Access markieren, exportieren, WordPress zeigt’s an.

Alternative: REST-API statt MySQL-ODBC

Du kannst auch direkt die WordPress-REST-API nutzen.
Ich mache das bei kleinen Datenmengen:

Function HoleWPToken()
    Dim http As Object
    Set http = CreateObject("MSXML2.XMLHTTP")

    http.Open "POST", "https://portal.de/wp-json/jwt-auth/v1/token", False
    http.setRequestHeader "Content-Type", "application/json"
    http.Send "{""username"":""apiuser"",""password"":""geheim""}"

    Debug.Print http.responseText
End Function

Oder Daten als JSON übergeben.
Mehr Aufwand, aber flexibler.

Was ich nicht mache

• Kein Schreiben direkt von WordPress in Access
• Kein Vollzugriff auf Access von außen
• Keine direkten MySQL-Verbindungen aus Access über Internet ohne VPN

Klare Trennung, saubere Übergabe.

Access bleibt Herr der Daten.
WordPress zeigt, was gesehen werden soll.
Die Technik dazwischen hält sich raus.
Und der Kunde merkt davon nichts.