IDF Woo Roomdesign

Changelog

v0.7.1

Behoben

• Die Erklärung zur Materialbeschreibung stand neben dem Eingabefeld statt darunter, als schmale Spalte am rechten Rand. Grund: WooCommerce setzt eine mitgegebene Beschreibung in dieselbe Zeile wie das Feld. Bei einzeiligen Eingaben geht das auf, neben einem vierzeiligen Textbereich nicht. Beide Erklärzeilen stehen jetzt als eigene Zeilen unter dem Feld.

v0.7.0

Hinzugefügt

• Materialbeschreibung je Produkt. Das Bildmodell sieht das Produkt nicht, es liest darüber, und der Produktname trägt diesen Text nicht: „Stucco Gesso 5 kg" nennt eine Gebindegröße und sagt nichts über Struktur, Glanzgrad oder Auftragsart. Ohne Beschreibung wurde aus jeder Zuordnung ein Anstrich, egal welches Material gewählt war. Der Text steht am Produkt im neuen Reiter „Raumplaner", englisch und knapp, etwa polished lime plaster with a soft cloudy texture, matte finish.
• Führt der Shop die Beschreibung schon in einem eigenen Feld, lässt sich dieses Feld unter Einstellungen eintragen. Mehrere Namen sind erlaubt, durch Komma getrennt, wie beim Farbwert.
• Abgleich zwischen dem übernommenen Feld und dem Feld am Produkt. Er läuft beim Speichern eines geänderten Feldnamens und über einen Knopf. Dabei geht nichts verloren: in ein leeres Feld wird übernommen, zwei unterschiedliche Texte werden untereinander zusammengeführt, überschrieben wird nie. Ein zweiter Durchlauf ändert nichts mehr.
• Prüfzeile auf der Einstellungsseite: wie viele Produkte eine Materialbeschreibung haben, und welche nicht. Am Produkt selbst steht unter dem Feld, was ohne Eintrag tatsächlich losgeschickt wird.

Geändert

• Der Produktname geht ohne Mengen- und Verpackungsangabe an das Bildmodell. Erkannt und entfernt werden Angaben wie „5 kg", „0,75 l Eimer", „(25 kg)" und „10 Liter". Gespeichert bleibt der volle Name, denn im Kundenkonto und in der Auftragsliste ist er der Beleg. Ein Name, der nur aus einer Mengenangabe besteht, bleibt unverändert: wenig zu sagen ist besser als nichts zu sagen.
• Die Materialbeschreibung wird als Momentaufnahme im Auftrag mitgeschrieben, wie der Produktname. Was das Modell zu sehen bekam, muss auch dann nachvollziehbar sein, wenn die Beschreibung am Produkt inzwischen eine andere ist.

Behoben

• Die Eingabetaste in einem Textfeld der Einstellungsseite löste den ersten Absende-Knopf des Formulars aus. Mit dem Abgleich-Knopf wäre das ein Durchlauf über das ganze Sortiment gewesen, ausgelöst von einem Enter im Feld für den Endpunkt-Slug.

v0.6.2

Behoben

• Die Farbfelder blieben farblos, obwohl das Sortiment Farbwerte führt. Grund: der Wert stand nicht als HEX, sondern als RGB in der Form 231 225 215, und das Plugin las nur #rrggbb. Erkannt werden jetzt #a1b2c3, a1b2c3, die Kurzform #abc, drei Zahlen mit Leerzeichen, Komma oder Semikolon dazwischen sowie rgb(...) und rgba(...).
• Im Feld für den Farbwert dürfen mehrere Feldnamen stehen, durch Komma getrennt. Genommen wird der erste, der einen brauchbaren Wert liefert. Das hilft, wenn ein Teil des Sortiments den HEX-Wert führt und der Rest nur RGB.
• Der ACF-Farbwähler wird auch dann gelesen, wenn er als Array statt als Zeichenkette zurückkommt.

Geändert

• Der erkannte Farbwert wird vereinheitlicht: Kleinschreibung, Kurzform ausgeschrieben. sanitize_hex_color() prüft nur, es vereinheitlicht nicht, und der Wert geht in eine CSS-Eigenschaft, in die Kontrastrechnung und als Momentaufnahme in den Auftrag.
• Das Feld heißt jetzt „Feld mit dem Farbwert" statt „Feld mit dem HEX-Wert", und die Prüfzeile spricht von Farbwerten. Es geht nicht mehr nur um HEX.

v0.6.1

Geändert

• Die Farbtöne stecken jetzt in einem Akkordeon und sind zugeklappt. Ein gepflegtes Sortiment hat mehrere hundert Farbtöne; aufgeklappt belegen die den halben Bildschirm, und die Fläche darunter findet niemand mehr. Bei bis zu zwölf Farbtönen öffnet es sich gleich, dann löst das Zuklappen ein Problem, das keines ist.
• Suchfeld über den Farbtönen. Bei mehreren hundert Feldern ist Scrollen keine Auswahl. Gesucht wird in der Bezeichnung, und die trägt bei gepflegten Sortimenten die Nummer.
• Die getroffene Wahl steht mit kleinem Farbfeld in der Kopfzeile des Akkordeons, das sich nach der Auswahl schließt. Sonst bliebe die Wahl irgendwo mitten in der Liste stehen.
• Die Farbfelder sind kleiner, und die Liste hat eine gedeckelte Höhe mit eigenem Scrollbereich.
• Ein Produktwechsel verwirft die Farbwahl. Die Farbtöne gehören zum Produkt, nicht zur Fläche.

Hinzugefügt

• Liefert kein einziger Farbton einen HEX-Wert, steht das jetzt im Protokoll, mit dem eingetragenen Feldnamen. Ohne HEX-Wert bleiben die Farbfelder farblos, und die Auswahl ist wieder das, was sie vorher war: eine Liste von Nummern. Das ist ein Konfigurationsfehler und gehört benannt, nicht erraten.

v0.6.0

Geändert

• Die Farbtöne stehen nicht mehr in einer Auswahlliste, sondern als Farbfelder. Die Bezeichnung liegt auf dem Ton selbst. Vorher war dort nur der Name mit der Nummer zu sehen, und eine Nummer sagt über einen Farbton nichts aus.
• Die Schriftfarbe auf jedem Feld richtet sich nach dem Ton: dunkle Schrift auf hellen Farben, helle auf dunklen. Gerechnet wird nach der Formel aus den Barrierefreiheits-Richtlinien, und zwar auf dem Server. Damit gilt dieselbe Regel überall, und sie ist prüfbar.
• Die Flächen sind Blöcke statt einer Tabelle. Eine Fläche trägt inzwischen mehr als zwei Werte, und eine Reihe umbrechender Farbfelder passt nicht in eine Tabellenzelle.
• Die gewählte Fläche ist an einem Ring und einem Haken zu erkennen, nicht nur an der Farbe. Auf einem Ton, der dem Rahmen ähnelt, wäre eine reine Farbmarkierung unsichtbar.

Barrierefreiheit

• Die Farbfelder sind eine Auswahlgruppe aus Optionsfeldern, mit der Tastatur bedienbar und mit Beschriftung für Screenreader. Das Feld selbst ist optisch ausgeblendet, aber vorhanden.
• Gemessen im Browser: der schlechteste Kontrast im Prüfsatz liegt bei 4,34 zu 1. Bei mittleren Tönen ist mehr nicht zu holen, ohne den Farbton mit einem Schleier zu verfälschen, und der Farbton ist hier die Information. Deshalb sind die Bezeichnungen etwas größer und halbfett.

Hinweis

Ein Farbton ohne hinterlegten HEX-Wert bekommt kein Feld mit erfundener Farbe, sondern einen gestrichelten Rahmen mit dem Namen. Was das Sortiment nicht hergibt, soll die Oberfläche nicht behaupten.

v0.5.4

Geändert

• Scheitert die Auslieferung eines Bildes, steht der Grund jetzt im Platzhalter selbst, sichtbar nur für Administratoren. Für die Kundschaft bleibt es beim neutralen Hinweis: „Signatur stimmt nicht" ist für sie kein Hinweis, sondern Rauschen. Für den Betreiber spart es den Weg ins Protokoll, und genau dieser Weg wird im Zweifel nicht gegangen.
• Fünf Fehlerklassen statt vier. Der Fall „der Merkposten zum Upload ist weg" war bisher unter „gehört einem anderen Konto" mitgezählt, obwohl er etwas völlig anderes bedeutet: nicht fehlende Berechtigung, sondern ein Zwischenspeicher, der nicht hält, was er soll.
• Die Protokolleinträge zur Auslieferung nennen jetzt Token-Anfang, angemeldetes Konto und erwartetes Konto. Ohne diese Werte lässt sich nicht unterscheiden, ob die Anfrage ohne Anmeldung ankam oder unter einem anderen Konto.

v0.5.3

Behoben

• Die Protokoll-Tabelle war unbrauchbar: die linken Spalten wurden dreizeilig zusammengequetscht, und die Werte-Spalte lief trotzdem über den rechten Seitenrand hinaus. Ursache waren feste Spaltenbreiten und eine Werte-Spalte, die nicht umbrechen durfte. Die beiden linken Spalten schrumpfen jetzt auf ihren Inhalt, alles Weitere steht in einer Spalte und bricht um. Geprüft von 375 bis 1280 Pixel Breite, ohne waagerechtes Scrollen.
• Datum und Uhrzeit stehen untereinander, jedes für sich ungebrochen. In einer Zeile zwang der Zeitstempel die Spalte breiter, als sie sein muss.

v0.5.2

Hinzugefügt

• Neue Seite Protokoll. Sie beantwortet die Frage, die im Fehlerfall als Erstes kommt: wann ist welche Anfrage rausgegangen und was kam zurück. Jede Anfrage an das Bildmodell wird jetzt vor dem Absenden protokolliert, nicht erst nach der Antwort. Bleibt die Antwort ganz aus, stand vorher nirgends, dass überhaupt etwas rausging, obwohl es da schon Geld gekostet hat.
• Neue Seite Aufträge. Wer hat wann was angefordert, mit welchem Modell, wie lange hat es gedauert und wie ist es ausgegangen. Filter nach Status, und je Auftrag ein Knopf „Erneut versuchen" für den Fall, dass ein Konfigurationsfehler behoben wurde und die Kundschaft nicht alles neu hochladen soll.

Behoben

• Ein fehlendes Modell und ein abgelehnter Zugang wurden dreimal wiederholt, obwohl beide beim zweiten Versuch dasselbe antworten. Die Kundschaft sah dadurch minutenlang „Die Vorschau wird erzeugt", ohne dass etwas passierte. Beide gelten jetzt als endgültig.
• Während einer Wiederholung stand der Auftrag wieder auf „wartet", und das Frontend meldete weiter „wird erzeugt". Jetzt steht dort, dass der Versuch gescheitert ist, woran es lag und wann der nächste läuft. Eine beruhigende Anzeige über einem gescheiterten Versuch ist eine Lüge.
• Die Meldung bei fehlendem Modell nennt jetzt den Weg dorthin: Einstellungen, Bildmodell, „Verfügbare Modelle abrufen".

Sicherheit

• Im Protokoll steht nur der Hostname des Anbieters, nie die vollständige Adresse. Im Schlüssel-Modus trägt die den Zugangsschlüssel als Parameter.

v0.5.1

Hinzugefügt

• Auffanglauf alle fünf Minuten. Der Einzeltermin eines Auftrags greift zuverlässig, solange jemand die Seite aufruft; auf einer ruhigen Seite konnte er liegenbleiben. In v0.5.0 hing der Auffanglauf am Tageslauf, und das war zu grob.
• Aufträge ohne Fortschritt gelten nach fünfzehn Minuten als abgelaufen. Vorher blieb ein Auftrag, dessen Hintergrundlauf nie anlief, dauerhaft auf „In Warteschlange" stehen. Das ist die unangenehmste Variante, weil es aussieht, als käme gleich etwas.

v0.5.0

Ab dieser Version entsteht tatsächlich ein Bild. Das ist der Punkt, ab dem jeder Auftrag beim Anbieter Geld kostet.

Hinzugefügt

• Der Raumplaner erzeugt jetzt eine Vorschau. Nach dem Absenden läuft der Auftrag im Hintergrund, das Frontend fragt den Stand ab und zeigt das fertige Bild an, sobald es vorliegt.
• Das Ergebnis liegt dauerhaft im Kundenkonto unter „Meine Designs", in der Liste als Kachel und in der Detailansicht in voller Größe.
• Der Aufruf des Bildmodells beherrscht beide Zugangsarten: API-Schlüssel über die Gemini-Schnittstelle, Dienstkonto über Vertex AI. Im Dienstkonto-Modus greift die eingestellte Region, wobei global und eu eigene Adressen haben.
• Neuer Knopf „Verfügbare Modelle abrufen" in den Einstellungen. Er fragt beim hinterlegten Zugang nach, welche Modelle es dort wirklich gibt, und übernimmt einen Namen per Klick ins Feld. Ein Modellname, den der Zugang nicht kennt, ließ bisher jeden Auftrag mit einer Meldung scheitern, die nach einem kaputten Schlüssel aussah.
• Das monatliche Kontingent je Kunde ist wirksam. Es ist die einzige Bremse zwischen einem neugierigen Kunden und einer dreistelligen Rechnung.
• Die Vorlage für die Anweisung an das Bildmodell lässt sich in den Einstellungen überschreiben, der fertige Text zusätzlich über den Filter idf/woo-roomdesign/prompt.

Geändert

• Einstellungen, die jetzt wirken, tragen nicht mehr den Hinweis auf eine spätere Version: Region, Hintergrundlauf, Kontingent, Uploadgrenze, Bildkante und Aufbewahrung der Raumfotos. Der Hinweis steht nur noch am Kostendeckel und an der Aufbewahrung der Ergebnisbilder.

Sicherheit

• Der Hintergrundlauf braucht keinen ungeschützten Endpunkt. Er läuft über einen WP-Cron-Einzeltermin, der bei Bedarf sofort angestoßen wird. Das Plugin hat weiterhin keinen einzigen ohne Anmeldung erreichbaren Endpunkt.
• Zwei gleichzeitig anlaufende Hintergrundläufe können nicht beide dasselbe Bild erzeugen: der Zustandswechsel steckt in der Bedingung des Datenbank-Updates, nicht in einer vorgelagerten Prüfung.
• Wiederholt wird nur, was plausibel vorübergehend ist, und höchstens dreimal. Ein abgelehnter Zugang, ein fehlendes Modell oder ein Sicherheitsfilter liefern beim zweiten Versuch dasselbe Ergebnis und kosten nur erneut Geld.
• Das Ergebnisbild liegt wie das Raumfoto im gesperrten Verzeichnis und wird über einen geprüften Stream ausgeliefert. Die Eigentümerprüfung steckt in der Abfrage.

Hinweis

Der Wortlaut der Anweisung ist die eigentliche Arbeit an diesem Plugin. Er sagt zuerst und ausführlich, was NICHT verändert werden darf, und erst danach, was sich ändern soll. Ohne diesen Vorspann rendert ein Bildmodell die ganze Szene neu: der Farbton stimmt dann, aber die Wohnung ist eine andere.

Ob das Bildmodell in der eingestellten Region überhaupt angeboten wird, beantwortet nur der Aufruf selbst. Für die Gemini-3-Familie ist ein Einzelregions-Endpunkt bislang nicht belegt.

v0.4.3

Hinzugefügt

• Unter Einstellungen lässt sich festlegen, aus welchen Produktkategorien der Raumplaner wählen lässt. Ohne Auswahl stehen weiterhin alle veröffentlichten Produkte zur Wahl, das meldet die Prüfung am Formular jetzt aber als Warnung: für einen echten Shop ist es selten richtig, Zubehör, Werkzeug und Musterkartons gehören nicht an eine Wand.
• Neue Auswahl „nur Farbton, ohne Produkt" je Fläche. Damit lässt sich ein Farbton ausprobieren, ohne vorher ein Material auszuwählen. Das Ergebnis ist dann ein schlichter Anstrich ohne Materialwirkung, und genau das steht auch im Frontend.

Sicherheit

• Die Kategorie-Einschränkung gilt auch beim Absenden, nicht nur in der Auswahlliste. Wer die Liste umgeht, kann sonst jedes Produkt des Shops zuordnen, auch eines aus einer bewusst ausgeschlossenen Kategorie.

v0.4.2

Hinzugefügt

• Das Raumfoto wird über eine Ablagefläche ausgewählt: anklicken oder das Foto hineinziehen. Vorher stand dort ein nacktes Dateifeld.
• Fortschrittsanzeige beim Hochladen. Bei einem 12-MB-Foto über Mobilfunk ist das der Unterschied zwischen „hängt" und „läuft". Technisch heißt das XMLHttpRequest statt fetch, denn fetch meldet keinen Upload-Fortschritt.
• Knopf „Anderes Foto wählen", sobald eine Vorschau steht.
• Ein zu großes Foto wird abgelehnt, bevor es hochgeht. Format und Inhalt prüft weiterhin der Server, der die besseren Meldungen hat.
• Die Ablagefläche zeigt ihren Zustand: leer, wird gezogen, lädt, Vorschau steht, Fehler.

Geändert

• Die Schrittnummern kommen jetzt aus einem CSS-Counter. Die Zählziffern der Liste standen ungestylt neben den Überschriften und ließen sich nicht gestalten. Die nummerierte Liste bleibt, weil die Reihenfolge inhaltlich bedeutsam ist und Screenreader sie so korrekt vorlesen.
• Erledigte Schritte tragen einen Haken statt der Ziffer, und Schritt 3 ist sichtbar gesperrt, solange kein Foto hochgeladen und keine Fläche belegt ist. Gesperrt war er vorher auch, nur sah man es nicht.
• Die Vorschau ist in der Höhe begrenzt. Ein Handyfoto im Hochformat schob vorher alles Weitere aus dem Bild.
• Die Höchstgröße im Formular ist jetzt der Wert, der auch wirklich durchgeht: der kleinere von Einstellung und Serverlimit. Stand dort eine höhere Zahl, lud die Kundschaft minutenlang hoch und bekam danach eine Absage.
• Die Überschriften-Ebene der Schritte lässt sich über den Filter idf/woo-roomdesign/heading_level setzen. h3 passt nur, wenn darüber ein h2 steht.

Barrierefreiheit

• Das Dateifeld ist optisch ausgeblendet, aber vorhanden: mit display: none wäre es weder mit der Tastatur erreichbar noch für einen Screenreader da. Der Tastaturfokus ist an der Ablagefläche zu sehen.
• Die Fortschrittsanzeige meldet ihren Wert als progressbar, der gesperrte Knopf verweist auf den Hinweis, was noch fehlt.
• Bedienbar auf dem Handy: das ist der Regelfall, nicht die Ausnahme. Die Kundschaft fotografiert den Raum mit dem Telefon und lädt direkt hoch.

Hinweis

Schrift, Schriftgröße und Grundfarben bleiben Sache des Themes. Fest gesetzt sind nur Struktur, Rahmen und Zustände, und wo eine Farbe nötig ist, steht die Textfarbe des Themes. Feste Werte gibt es an genau zwei Stellen, beide dokumentiert: die Farbfelder und das Fehlerrot.

v0.4.1

Behoben

• Auf Seiten mit Avada Layouts erschien der Raumplaner im Header statt im Inhalt. Avada rendert Header-, Titel- und Footer-Sections ebenfalls über den Inhaltsfilter, und während dieser Durchläufe blieben die bisherigen Prüfungen wahr. Der Planer wird jetzt nur noch am Inhalt der zugewiesenen Seite selbst angehängt, nicht in einer Layout-Section.
• Stand der Shortcode bereits im Seiteninhalt, wurde der Planer trotzdem ein zweites Mal angehängt. Die Prüfung lief zu spät, nämlich erst nachdem WordPress den Shortcode längst ersetzt hatte, und fand deshalb nie etwas. Sie läuft jetzt auf dem Rohinhalt.
• Das hochgeladene Raumfoto erschien nicht in der Vorschau. Der relative Pfad wurde bereits vor der Bildvorverarbeitung bestimmt, obwohl die Vorverarbeitung die Datei neu schreibt. Er wird jetzt danach gebildet.
• Liegt wp-content/uploads auf einem Symlink, ließ sich für abgelegte Dateien überhaupt kein relativer Pfad bilden. Der Auftrag zeigte dann auf ein Bild, das es unter seinem gespeicherten Pfad nie gab. Symlinks werden jetzt auf beiden Seiten des Vergleichs aufgelöst.

Geändert

• Scheitert die Auslieferung eines Bildes, kommt ein neutrales Platzhalterbild statt eines kaputten Bildes, und der Grund landet im Ereignisprotokoll. Bisher endeten alle vier Prüfstufen in einer HTML-Fehlerseite an einem Bild-Element: die Kundschaft sah nichts, und im Backend war nicht zu erkennen, woran es lag.
• Bilder laufen über admin-ajax.php statt über admin-post.php. Letzteres startet vor der Weitergabe an das Plugin die komplette Backend-Sequenz aller installierten Plugins, mitsamt deren Weiterleitungen und Ausgaben. Für eine Bildauslieferung ist das zu viel Angriffsfläche für Fremdeinflüsse.
• Vor dem Senden eines Bildes werden offene Ausgabepuffer verworfen, und die Längenangabe entfällt bei aktiver Ausgabekomprimierung. Beides sind die üblichen Gründe für ein halb geladenes Bild.
• Kann ein Upload nicht abgelegt werden, meldet das Plugin das jetzt sofort, statt einen leeren Pfad zu speichern und den Fehler erst in der Vorschau sichtbar werden zu lassen.

Hinweis

Avada hält gerenderte Layout-Sections im eigenen Zwischenspeicher. Wer den Planer schon im Header hatte, leert nach dem Update einmal den Avada-Cache, sonst bleibt die alte Fassung stehen.

v0.4.0

Hinzugefügt

• Der Raumplaner nimmt jetzt ein Raumfoto entgegen, zeigt eine Vorschau und lässt Flächen mit Produkt und Farbton belegen. Fünf Flächen stehen zur Auswahl: Wand gegenüber, linke Wand, rechte Wand, Decke, Fußboden. Nicht belegte Flächen bleiben unverändert.
• Die Farbliste lädt je gewähltem Produkt nach. Im Farbwähler-Modus erscheint stattdessen ein Farbfeld.
• Am Ende entsteht ein Design-Auftrag, der in der Warteschlange liegt. Die Bilderzeugung folgt in der nächsten Version, und genau das steht auch im Frontend. Eine erfundene Fortschrittsanzeige gibt es bewusst nicht.
• Tägliches Aufräumen: Raumfotos werden nach Ablauf der Aufbewahrungsfrist gelöscht, unabhängig davon, ob je ein Auftrag daraus wurde.

Sicherheit

• Kein einziger Endpunkt ist ohne Anmeldung erreichbar. Es gibt keinen wp_ajax_nopriv_-Hook.
• Jede Zuordnung wird serverseitig gegen den Katalog geprüft: Existiert das Produkt, ist es veröffentlicht, gehört der Farbton zu diesem Produkt. Ohne diese Prüfung ließen sich beliebige IDs unterschieben, auch aus unveröffentlichten Entwürfen.
• Der Dateityp wird gegen den echten Inhalt geprüft, nicht gegen die Endung. HEIC-Fotos vom iPhone werden erkannt und mit einer Anleitung abgelehnt, statt stumm zu scheitern.
• Das Foto landet unter einem Zufallsnamen im gesperrten Verzeichnis. Zurück an den Browser geht nur ein Token, nie ein Pfad. Die Vorschau läuft über einen geprüften Stream mit Nonce, Anmeldung, Eigentümerprüfung und Pfad-Containment.
• Rate-Limit pro Kunde, mit korrekt ablaufendem Zeitfenster: die Restlaufzeit wird aus dem Startzeitpunkt berechnet, nicht bei jedem Aufruf erneuert. Sonst bliebe gesperrt, wer einmal am Limit war.
• Der Auftrag trägt einen Idempotenz-Schlüssel mit eindeutigem Index. Doppelklick, Reload oder ein wiederholter Netzaufruf erzeugen keinen zweiten, kostenpflichtigen Auftrag.

v0.3.0

Hinzugefügt

• Farbquelle ist frei konfigurierbar. Der Inhaltstyp der Farbtöne wird aus einer Liste gewählt, das Feld mit dem HEX-Wert und das Verknüpfungsfeld zum Produkt werden als Feldnamen eingetragen. Damit läuft das Plugin auf Websites mit unterschiedlicher Feldbenennung, ohne dass Code angefasst werden muss.
• Die Verknüpfung darf auf beiden Seiten liegen: am Produkt mit Verweis auf Farbtöne oder am Farbton mit Verweis auf Produkte. Ohne Verknüpfungsfeld stehen bei jedem Produkt alle Farbtöne zur Auswahl.
• Ist kein Inhaltstyp gewählt, wählt die Kundschaft den Farbton frei über einen Farbwähler. Das braucht keine Pflege, bindet den Entwurf aber nicht ans Sortiment.
• Prüfung der Farbquelle direkt am Formular: sie meldet, wie viele Farbtöne gefunden wurden, wie viele davon einen gültigen HEX-Wert liefern, und nennt drei Beispiele. Ein Tippfehler im Feldnamen fällt damit beim Speichern auf und nicht erst, wenn die Farbliste im Frontend leer bleibt.
• Vorarbeit für den Upload: Bildvorverarbeitung und Ereignisprotokoll. Beide sind noch an keine Oberfläche angebunden und ohne Wirkung.

Hinweis

Die Bildvorverarbeitung schätzt den Speicherbedarf, bevor ein Foto geladen wird, wendet die EXIF-Drehung vor dem Skalieren an und prüft nach dem Entfernen der Metadaten, ob noch Standortdaten übrig sind. Findet sie welche, bricht sie ab, statt das Foto zu verschicken. Hintergrund: GD verliert EXIF beim Neuschreiben automatisch, Imagick behält Profile bei.

v0.2.2

Behoben

• Wer unter Einstellungen eine „Seite mit dem Raumplaner" auswählte, sah auf dieser Seite nichts. Die Einstellung diente bis dahin ausschließlich dem Zurück-Knopf aus „Meine Designs"; den Planer selbst musste man zusätzlich per Shortcode einfügen. Der Feldname versprach etwas anderes, und die Erklärung dazu stand nur auf der Hilfeseite.

Geändert

• Auf der zugewiesenen Seite erscheint der Raumplaner jetzt automatisch, ein Shortcode ist dafür nicht mehr nötig. Die Einstellung tut damit, was ihr Name sagt.
• Der Shortcode bleibt erhalten und hat Vorrang: steht er im Inhalt, bestimmt er die Position, und es wird nichts zusätzlich angehängt. Das ist der Weg für Seitenbaukästen, in denen der Planer zwischen zwei Abschnitten sitzen soll.
• Die Ausgabe hängt an the_content mit Priorität 20, also nach der Absatzformatierung und nach den meisten Baukasten-Filtern. Ein Wiederholungsschutz verhindert doppelte Ausgabe, wenn ein Seitenbaukasten den Filter mehrfach aufruft.
• Die Systemprüfung zeigt jetzt, welche Seite zugewiesen ist und ob sie veröffentlicht ist. Eine ausgewählte, aber noch nicht veröffentlichte Seite war bisher nicht von außen zu erkennen.
• Hilfeseite und Beschreibungstexte auf die neue Reihenfolge umgestellt: Seite anlegen, Seite auswählen, fertig.

v0.2.1

Behoben

• „Verbindung testen" meldete „Es ist kein Zugang hinterlegt", obwohl im Feld darüber ein gültiger Schlüssel stand. Der Knopf prüfte ausschließlich den bereits gespeicherten Zugang, und der Hinweis darauf stand als Kleingedrucktes unterhalb des Knopfes, also genau dort, wo er niemandem auffällt. Wer seinen Schlüssel einfügte und direkt darunter auf Testen klickte, bekam eine Fehlermeldung, die nach einem kaputten Schlüssel klang, obwohl schlicht noch nichts gespeichert war.

Geändert

• Der Verbindungstest prüft jetzt den Feldinhalt. Ist das Feld leer, prüft er weiterhin den gespeicherten Zugang. Damit lässt sich ein Schlüssel vor dem Speichern gegen Google prüfen. Der geprüfte Wert wird dabei nicht abgelegt, und ein so erzeugtes Vertex-Token landet bewusst nicht im Zwischenspeicher des tatsächlich hinterlegten Zugangs.
• Wurde ein ungespeicherter Feldinhalt geprüft, endet die Erfolgsmeldung mit dem Hinweis, die Änderungen noch zu speichern. Sonst klickt man auf grün und geht weiter, ohne dass etwas abgelegt wurde.
• Der Hinweis, was der Test genau prüft, steht jetzt über dem Knopf statt darunter.
• Ein unbrauchbarer Feldinhalt wird als solcher gemeldet und nicht mehr als „kein Zugang hinterlegt". Die beiden Fälle brauchen unterschiedliche Reaktionen.

v0.2.0

Hinzugefügt

• Zugangsverwaltung für das Bildmodell. Der Zugang wird unter Einstellungen hinterlegt, in zwei möglichen Formen, die das Plugin am Inhalt selbst erkennt: ein API-Schlüssel aus Google AI Studio oder das vollständige Service-Account-JSON eines Google-Cloud-Projekts. Der Anwender muss nichts auswählen, er fügt ein, was er hat.
• Im Service-Account-Modus signiert das Plugin selbst ein JWT und tauscht es beim Google-Token-Endpunkt gegen ein Access-Token, weil Google kein fertiges Token herausgibt. Das Ergebnis wird 55 Minuten zwischengespeichert.
• Knopf „Verbindung testen". Er prüft den gespeicherten Zugang gegen Google und kostet nichts: im Schlüssel-Modus über die Modellliste, im Service-Account-Modus reicht der erfolgreiche Token-Tausch als Nachweis. Ohne diesen Test fiele ein falsch eingefügtes JSON oder eine nicht aktivierte API erst auf, wenn der erste Kunde eine Vorschau anfordert.
• Systemprüfung zeigt zusätzlich, ob und in welcher Form ein Zugang hinterlegt ist.

Sicherheit

• Zugangsdaten liegen AES-256-CBC-verschlüsselt in einer eigenen Option, der Schlüssel wird aus AUTH_KEY abgeleitet. Sie laufen zwar durch das Einstellungsformular, landen aber bewusst nie im Settings-Array, sonst stünden sie im Klartext in wp_options.
• Die Konstante IDF_WOO_ROOMDESIGN_CREDENTIALS in der wp-config.php hat immer Vorrang. Ist sie gesetzt, ist das Feld in der Oberfläche gesperrt: was in der wp-config steht, soll nicht über das Backend überschreibbar sein.
• Das Eingabefeld wird immer leer gerendert. Der gespeicherte Wert wird nie wieder angezeigt, nur maskiert oder als Dienstkonto-Adresse.

Behoben

• Der Abschnitt „Bildmodell" in den Einstellungen enthielt Modell und Region, aber kein Feld für die Zugangsdaten. Wer seinen Schlüssel eintragen wollte, suchte vergeblich.

v0.1.0

Hinzugefügt

• Grundgerüst aus idf-plugin-template: Plugin-Header, Konstanten IDF_WOO_ROOMDESIGN_*, SPL-Autoloader, Text-Domain, Anbindung an IDF Home für Update-Registrierung und Plugin-Dashboard.
• Abhängigkeits-Prüfung mit zwei Härtegraden. WooCommerce ist Voraussetzung, ohne Shop bootet das Plugin gar nicht erst. Fehlendes IDF Home ist dagegen nur eine Notice, das Plugin läuft vollständig weiter und bekommt lediglich keine automatischen Updates.
• Eigene Tabelle {prefix}idf_woo_roomdesign_jobs für Design-Aufträge, angelegt per dbDelta. Bewusst keine Custom Post Types: Aufträge sind technische Datensätze, die nie redaktionell bearbeitet und nie über die Loop ausgegeben werden. Als CPT würden sie wp_posts und wp_postmeta aufblähen und aus der späteren Kontingent-Zählung eine WP_Query machen.
• Endpunkt „Meine Designs" unter „Mein Konto" mit Listen- und Detailansicht. Der Menüpunkt wird vor „Abmelden" einsortiert, sonst landet er darunter und wird übersehen.
• Shortcode [idf_woo_roomdesign] mit Zugangsprüfung. Nicht angemeldete Besucher bekommen einen Anmeldelink, der nach der Anmeldung auf dieselbe Seite zurückführt.
• Admin-Bereich mit den vier Pflichtseiten Übersicht, Einstellungen, Hilfe und Deinstallation.
• Systemprüfung auf der Übersichtsseite: WooCommerce-Version, verfügbare Bildbearbeitung, memory_limit, max_execution_time, Zustand des Ablageverzeichnisses und WP-Cron. Diese Werte entscheiden darüber, ob der spätere Bildaufruf auf dem Server überhaupt durchläuft, und gehören deshalb sichtbar ins Backend statt in ein Support-Ticket.
• Geschütztes Ablageverzeichnis unterhalb von uploads/ mit .htaccess-Sperre und Containment-Prüfung beim Auflösen relativer Pfade.
• uninstall.php mit ausdrücklicher Freigabe über die Deinstallations-Seite. Ohne gesetzte Freigabe bleiben Aufträge, Bilder und Einstellungen beim Löschen des Plugins erhalten.

Geändert

• Gegenüber dem Template drei Korrekturen: vendor/ in der .gitignore auf /vendor/ verankert, damit ein späteres assets/vendor/ nicht lautlos aus dem Release-ZIP fällt. Der Autoloader durchsucht zusätzlich admin/. Der Dependency-Checker heißt Idf_Woo_Roomdesign_Dependency_Checker statt IDF_Dependency_Checker, damit die Ladereihenfolge der Plugins keine Rolle spielt.

Hinweis

Diese Version ist ein lauffähiges Grundgerüst ohne Bilderzeugung. Upload, Flächenauswahl und der Aufruf des Bildmodells folgen in den nächsten Versionen. Einstellungen, die noch keine Wirkung haben, sind im Formular als solche gekennzeichnet.