General

AILinux Devlog: WordPress, Login-System, MCP und Infrastruktur weitergehärtet

By zombie Loading...

Kurzfassung: In den letzten 24 Stunden ging es bei AILinux weniger um sichtbaren Glanz und mehr um das, was ein System produktionsreif macht: Login-Flows, Account-Weiterleitungen, MCP-Anbindung, WordPress-Integration, Traffic-Auswertung und saubere Infrastruktur.

Nicht spektakulär im Marketing-Sinn — aber genau die Art Arbeit, die später verhindert, dass Nutzer an kaputten Passwort-Reset-Seiten, falschen API-Calls oder halbgaren Plugin-Flows hängen bleiben.

WordPress-Login und Account-System aufgeräumt

Ein wichtiger Fix war das Verhalten rund um Passwort-Reset und Login im Frontend.

Vorher gab es noch Stellen, an denen WordPress eigene Standard-Mechanismen sichtbar waren oder Nutzer über falsche Wege zum Passwort-Reset geführt werden konnten. Das passt nicht zum Ziel von AILinux, weil der Account-Flow zentral über das eigene Login-System laufen soll.

  • WordPress-Standard-Passwort-Reset aus dem Frontend entfernt
  • Login- und Reset-Flows stärker auf login.ailinux.me ausgerichtet
  • Weiterleitungen und Hooks im WordPress-Plugin angepasst
  • Account-Verhalten konsistenter gemacht
  • unnötige WordPress-Standardpfade reduziert

Damit ist klarer: AILinux/TriForce ist Master für Account-Login und Passwort-Verwaltung, WordPress ist nicht mehr der wilde Neben-Eingang.

AILinux User Plugin erweitert

Am WordPress-Plugin wurde weitergebaut, besonders an den Bereichen Registrierung, Login-Verhalten und Nutzerverwaltung.

  • sauberere Hook-Struktur
  • bessere Kontrolle über Login- und Reset-URLs
  • Vorbereitung auf ein einheitliches Nutzerkonto-System
  • weniger WordPress-Standardverhalten, mehr AILinux-eigene Logik

Das ist ein wichtiger Schritt, weil AILinux langfristig nicht nur eine Website ist, sondern ein zusammenhängendes Ökosystem aus Website, Login, API, Client, Repo und KI-Infrastruktur.

MCP-API Calls geprüft und korrigiert

Auch an der MCP-Seite wurde gearbeitet. Beim Testen der lokalen TriForce/MCP-API wurde sichtbar, dass ein Call noch im falschen Format abgesetzt wurde.

Der alte Request nutzte sinngemäß:

{
  "name": "tools_index",
  "arguments": {}
}

Die API erwartete aber Felder wie:

{
  "client_id": "...",
  "tool": "...",
  "arguments": {}
}

Das ist genau die Sorte Fehler, die in der Entwicklung wichtig ist: nicht „kaputt“, sondern ein klarer Schema-Mismatch. Der Endpoint funktioniert nach Vertrag, der Client muss nur korrekt sprechen.

LM Studio und OpenClaw MCP-Anbindung untersucht

Zusätzlich wurde die MCP-Anbindung über externe Clients geprüft, unter anderem LM Studio und OpenClaw.

  • SSE-Endpunkt getestet
  • Bearer-Token-Verhalten geprüft
  • 401-Fehler eingegrenzt
  • Unterschied zwischen lokalem MCP-Call und externer Client-Anbindung analysiert
  • OpenClaw-Konfiguration getestet
  • LM-Studio-MCP-Bridge-Verhalten nachvollzogen

Der wichtigste Punkt: Die Infrastruktur antwortet kontrolliert. Wenn der Zugriff fehlschlägt, dann nicht chaotisch, sondern wegen Authentifizierung oder falsch gesetztem Token/Client-Kontext.

Ein 401 ist nervig, aber ein sauberer 401 ist besser als ein offenes Scheunentor.

Traffic und Apache Logs ausgewertet

Neben dem Bauen wurde auch geprüft, was auf der Website tatsächlich passiert.

Apache-Logs wurden gefiltert nach echten Requests, Bots, WordPress-Pfaden, API-Endpunkten und typischen Crawlern. Ziel war, echte Besucher und relevante Zugriffe besser von Hintergrundrauschen zu trennen.

  • Zeitraum der Apache-Logs geprüft
  • echte GET, POST, HEAD und PATCH Requests gefiltert
  • wp-admin, wp-json, Assets, Favicons, Bots und Crawler ausgenommen
  • bessere Einschätzung realer Seitenzugriffe vorbereitet

WordPress bleibt Website — TriForce bleibt Gehirn

Ein zentrales Ergebnis der letzten Arbeit: Die Rollen werden klarer.

WordPress ist die öffentliche Oberfläche: Website, News, Shop, Produktseiten, Blog und Einstiegspunkt für Nutzer.

TriForce ist das Backend-Gehirn: KI-Provider, Modelle, MCP-Tools, API-Logik, Authentifizierung, Automatisierung und Client-Anbindung.

AILinux wird damit nicht einfach ein WordPress-Projekt mit ein bisschen KI. Es wird ein echtes, verbundenes System: Website, Linux-Distribution, Client, Repository, Login und KI-Orchestrierung greifen zunehmend ineinander.

Fazit

Die letzten 24 Stunden waren kein einzelner großer Launch-Moment, sondern ein produktiver Infrastruktur-Tag.

  • sauberere WordPress-Login-Flows
  • entfernte und umgeleitete Passwort-Reset-Wege
  • bessere AILinux-User-Plugin-Logik
  • geprüfte MCP-API-Requests
  • Debugging von LM Studio und OpenClaw
  • Authentifizierungsverhalten am MCP-SSE-Endpunkt
  • Traffic-Auswertung über Apache-Logs
  • klarere Trennung zwischen WordPress-Frontend und TriForce-Backend

Das ist genau die Art Fundament, auf der später stabile Produkte stehen.

AILinux wächst weiter — nicht als Demo, sondern als echtes System.

Und ja: Es ist weiterhin ein One-Man-Projekt. Aber langsam sieht es verdächtig nach Infrastruktur aus, für die andere normalerweise ein kleines Team, drei Meetings und einen Jira-Kult brauchen würden.

AI Assistant
Context loaded: AILinux Devlog: WordPress, Login-System, MCP und Infrastrukt