Site Contractok és oldal-Blueprintek konfigurálása

A Composer verziózott Config Setként tárolja a futásidejű szabályzatát. A látható hierarchia:

Config Set -> Site Contract -> Blueprints

A konfigurációt a legáltalánosabb szabályoktól a legkonkrétabbak felé haladva építse fel. Az aktív Config Set maradjon változatlan; klónozza, ha az éles működést módosítani szeretné.

1. Munkaként használt Config Set létrehozása​

Nyissa meg a WP Admin -> SmartCloud -> Agent Composer -> Config sets oldalt, majd hozzon létre új készletet vagy klónozz egy meglévőt.

• A Universal Gutenberg lehetőséget használja stabil alapblokkokból álló, minimális és témafüggetlen oldalszerződéshez.
• A SmartCloud Recommended lehetőséget válassza egy gazdagabb, hordozható oldalhoz, amely kiemelt részt, funkciókat, lépéseket, opcionális GYIK-et és záró cselekvésre ösztönzést tartalmaz.
• A Detected Theme Starter lehetőséggel az aktív témában regisztrált megfelelő mintából biztonságos, helyi kezdőkészletet hozhatsz létre. A Composer rögzíti a forrásmintát, valamint az aktuális téma és a képességek ujjlenyomatát.
• A New lehetőséggel tiszta konfigurációt készíthetsz.
• A Clone lehetőséget akkor használja, ha az aktív konfiguráció megfelelő kiindulópont.
• Az Import lehetőséget csak megbízható, ellenőrző összeggel védett Composer-csomaghoz használja.

Az előbeállításból, újonnan, klónozással vagy importálással készült készletek inaktívak. Az előbeállítás egyedi azonosítójú, munkaként használt Config Setbe másolódik; soha nem ír felül és nem aktivál konfigurációt. Minden készletnek olyan tartós, leíró címkét adjon, amely a célját ismerteti, nem pedig környezeti jelszót, ügyfélnevet vagy belső jegyazonosítót tartalmaz.

2. A Site Contract meghatározása​

A Site Contract a Config Set minden Blueprintje által használt közös szabályzat. Itt adja meg azokat a korlátozásokat, amelyeknek minden oldaltípusnál egységesnek kell maradniuk, például:

• az engedélyezett WordPress-bejegyzéstípusokat;
• a szerkesztők és üzemeltetők nyelvét;
• a tipográfiai és vizuális rendszerre vonatkozó útmutatást;
• a médiaelhelyezési és képaláírási szabályokat;
• a sablonokra vonatkozó közös elvárásokat;
• a tervezési korlátozásokat, például a kizárólag témaelőbeállításokat használó stílusokat;
• a biztonsági kijelentéseket és a szolgáltatófüggetlen szabályzatokat.

A szerződés nem végrehajtható témakód. Ne helyezz el benne hitelesítő adatokat, API-kulcsokat, távoli callbackeket, JavaScriptet, PHP-t vagy szolgáltatói titkokat. A hordozható csomag ellenőrzése elutasítja a titoknak látszó mezőket.

3. Blueprint hozzáadása minden oldaltípushoz​

A Blueprint egy szemantikus oldaltípust kikényszeríthető WordPress-célponttá alakít. Minden lényegesen eltérő tartalmi felépítéshez külön Blueprintet készítsen, például szabványos oldalhoz, cikkhez, megoldáshoz, architektúradokumentumhoz vagy termékoldalhoz.

Ezeket a mezőket tudatosan konfigurálja:

• Page type: az MCP-műveletek által használt stabil gépi azonosító.
• Target post type: az oldal, bejegyzés vagy jóváhagyott egyéni bejegyzéstípus, amelyet a Composer létrehozhat.
• Target template: az aktív téma által regisztrált sablon. Ha a jóváhagyott minta már tartalmazza az egyetlen H1-et, használjon cím nélküli sablont.
• Allowed patterns: azok a minták, amelyekből az ügynök összeállíthatja ezt az oldaltípust.
• Required sequence: az a legkisebb rendezett mintasorozat, amelyet minden érvényes vázlatnak tartalmaznia kell.
• Allowed blocks: a blokkok teljes engedélyezési listája, beleértve minden jóváhagyott minta egymásba ágyazott blokkjait.
• Constraints: a H1-re, szószámra, beágyazásra, shortcode-ra, egyéni HTML-re és témaelőbeállításokra vonatkozó szabályok.
• Excerpt policy: ennél az oldaltípusnál required, optional vagy disabled.
• SEO contract: a kötelező WordPress-kivonat és metaleírás működése.
• Content mode: Gutenberg-blokktartalomhoz document, regisztrált strukturált rekordokhoz fields.
• Approved fields: csak a cél bejegyzéstípushoz regisztrált, REST-en látható mezőket válassza ki, és adja meg az olvasási/írási szabályzatukat.
• Relation fields: adja meg a számosságot, a sorrendet, az engedélyezett cél-bejegyzéstípusokat és -állapotokat, valamint az elemek legnagyobb számát.
• Taxonomy access: kizárólag a Blueprint cél-bejegyzéstípusához kapcsolt, felderített taxonómiáknál engedélyezze a keresést, a hozzárendelést vagy a megerősített létrehozást.

Használja a regisztrált blokkok választóját, ne emlékezetből írja be a blokkneveket. Másik bővítmény által biztosított blokk vagy minta csak addig érvényes, amíg a szolgáltató telepítve és aktiválva van, valamint regisztrálva van ezen a webhelyen.

Kapcsolati mező esetén a webhely vagy a szolgáltatói bővítmény regisztrálja az alapul szolgáló bejegyzéstípust, metamezőt és kapcsolati szerződést. Az általános végrehajtási útvonal a Composer tulajdona: a smartcloud-agent-composer/get-content-field-contract meghirdeti a munkafolyamatot, a smartcloud-agent-composer/search-relation-targets a címeket vagy slugokat matches[].id értékekké oldja fel, a smartcloud-agent-composer/update-content-fields ezeket az azonosítókat egy hozzárendelt, Composer-tulajdonú vázlatba írja, a smartcloud-agent-composer/inspect-content-fields pedig ellenőrzi a tárolt értéket. A smartcloud-agent-composer/list-content-drafts a szerkeszthető vagy átvehető tartalmakat sorolja fel, és nem használható kapcsolati célpontok feloldására.

A taxonómiakifejezések külön szabályozása​

Az egyes taxonómiákat továbbra is a felelős bővítmény vagy a WordPress magja regisztrálja és kapcsolja a cél-bejegyzéstípushoz. A Composer taxonomy access területén a Site Contract minden felderített taxonómiánál egymástól függetlenül engedélyezheti a keresést, a vázlathoz rendelést és a megerősített kifejezéslétrehozást. Emellett meghatározza az elemek legnagyobb számát, a hozzárendelés működését pedig append vagy replace értékre rögzíti. A hierarchikus létrehozás alapértelmezés szerint csak gyökérszinten engedélyezett; egy opcionális engedélyezési lista webhelyspecifikus azonosítók helyett tartós szülőslugokat használ.

A szabályozott ügynöki sorrend: get-taxonomy-contract -> search-taxonomy-terms -> pontos találat esetén a meglévő matches[].term_id újrafelhasználása -> create-taxonomy-term kizárólag indokoltan hiányzó nyilvános kifejezéshez, kifejezett megerősítéssel -> assign-taxonomy-terms -> inspect-taxonomy-terms. Az új kifejezésekhez természetes név, tartós slug, önálló archívumleírás és a Blueprint tartalmi nyelve szükséges. A Composer nem teszi lehetővé a kifejezések szerkesztését vagy törlését, és minden hozzárendelés egy aktuális konkurenciavezérlési tokenekkel rendelkező, hozzárendelt Composer-vázlatra korlátozódik.

4. Az aktív webhely újbóli vizsgálata​

Téma vagy szolgáltatói bővítmény telepítése, aktiválása vagy frissítése után nyissa meg a Theme & providers oldalt, és válassza a Rescan site lehetőséget.

Ellenőrizze:

• az aktív téma azonosítóját és verzióját;
• a regisztrált sablonokat és mintákat;
• az összes regisztrált Gutenberg-blokkot;
• a kiválasztott Config Set által hivatkozott mintákat;
• az opcionális szolgáltatók metaadatait és futásidejű készenlétét;
• minden hiányzó szerződésfüggőséget.

A felderítés a képességeket jelenti, a konfigurációt nem írja át. Ha megváltozott a téma, klónozza az aktív készletet, és a munkapéldányt módosítsd.

5. Módosítások előkészítése és alkalmazása​

Az entitások módosításai a böngészőben várakoznak. Egy entitás párbeszédablakának mentése nem hoz létre azonnal új adatbázis-revíziót. A műveletsáv megjeleníti a kiválasztott Config Set függőben lévő hozzáadásait, módosításait és megerősített törléseit.

• Az Apply modifications a teljes előkészített módosításkészletet egyetlen, optimista konkurenciavezérléssel védett tranzakcióként írja ki.
• A Discard eltávolítja az előkészített módosításokat anélkül, hogy a WordPressbe írna.

A módosításkészlet alkalmazása újraszámítja a Config Set kivonatát és módosítási idejét. Ha egy másik adminisztrátor ugyanazt az entitást módosította, a Composer ütközést jelez, és egyik verziót sem írja felül.

6. Ellenőrzés és aktiválás​

Minden lényeges szerződés-, téma-, minta-, blokk-, sablon- vagy szolgáltatómódosítás után válassza a Validate lehetőséget. Az aktiválás előtt oldja meg a hibákat, a figyelmeztetéseket pedig a környezetükben vizsgálja meg.

Az aktiváláshoz friss ellenőrzési bizonylat szükséges, amely a következőkhöz kötődik:

• a Config Set pontos ellenőrző összegéhez;
• az aktuális WordPress-webhelyhez;
• az aktuális adminisztrátorhoz;
• egy korlátozott érvényességi időhöz.

Csak a teljes munkakészlet felülvizsgálata után válassza az Activate lehetőséget. A korábban aktív készlet archiválódik, és összehasonlításhoz, illetve megerősített visszaállításhoz elérhető marad.

Összehasonlítás, visszaállítás, exportálás és biztonsági mentés​

• A Compare to active megmutatja, hogyan tér el a kiválasztott készlet a futásidejű konfigurációtól.
• A Restore archived as active újra ellenőrizze az archivált készletet, és kifejezett megerősítést kér; a böngészőben még nem mentett módosítást nem vonja vissza.
• Az Export egyetlen, ellenőrző összeggel védett Config Set-csomagot hoz létre.
• Az Audit & portability -> Export all configuration minden Config Set teljes biztonsági mentését létrehozza.

A hordozható exportok szándékosan kihagyják a hitelesítő adatokat és a webhelyspecifikus auditláncot. A visszaállított készletek inaktívak maradnak, amíg nem ellenőrizzék és kifejezetten nem aktiválják őket.

Ügynökségi átadási példa: meglévő esettanulmány-munkafolyamat​

Tegyük fel, hogy egy ügynökség már megtervezte a case_study egyéni bejegyzéstípust, a nyilvános felület sablonjait és a jóváhagyott vizuális megjelenését. A megjelenítés továbbra is a téma felelőssége; a Composer nem vezet be általános WP Suite esettanulmány-elrendezést.

Az ügynökség létrehozhat egy Config Setet, amely csak a szükséges munkafolyamatot teszi elérhetővé, és hozzáadhat egy case_study Blueprintet, amely megköveteli:

• a címet és az ügyfélkörnyezetet;
• a kihívás, a megvalósítás és az eredmények szakaszait;
• egy jóváhagyott cselekvésre ösztönzést;
• a Médiatár meglévő képmetaadatait;
• az engedélyezett kategóriákat, címkéket és SEO-metaadatokat;
• a webhelyen már használt témasablont, mintákat, blokkokat és sorrendet.

Amikor az ügyfél új esettanulmányt kér a kompatibilis ügynökétől, az ügynök betölti ezt a Blueprintet és az aktív tervezési környezetet, elkészíti a tartalmat, ellenőrizze a teljes struktúrát, majd vázlatot hoz létre. A jóváhagyás előtt egy ember ellenőrzi a tényeket, a médiát és a megjelenést. A WordPressen vagy egy opcionális Static Publisher-kiadáson keresztüli közzététel külön művelet marad.

Ez az átadás az ügynökség meglévő döntéseit megismételhető tartalmi műveletté alakítja. Nem kéri a Composert vagy az ügyfél ügynökét a webhely újratervezésére.

Ügynök csatlakoztatása előtt​

Ellenőrizze, hogy:

1. pontosan egy Config Set aktív;
2. minden kért oldaltípushoz tartozik érvényes Blueprint;
3. minden kötelező minta, sablon és blokk létezik;
4. az opcionális szolgáltatók kész állapotot jeleznek, vagy nem szerepelnek a Blueprintben;
5. a külön ügynökfelhasználó rendelkezik a smartcloud_agent szerepkörrel;
6. a Composer MCP-állapota a várt végpontot jelzi.