A CCK all releases oldalán ott a 3.x dev, abban benne van:

The 3.x dev release is currently an experimental branch for larger scale new features while the 2.x branch is now staying with only stable changes and minor new features.

For further information, please look at: #494100: State of the multigroup module

1. Létrehoz egy moderátor csoportot.
2. Telepíti a Workflow modult, bekapcsolja a Workflow Access komponenst is, felkínált linkre kattintva újraépíti a node access táblát.
3. Létrehoz egy workflow-t mondjuk munkamenet néven.
4. Hozzáad két state-et: szerkesztés alatt, közzétett.
5. Megadja, hogy létrehozás után a node szerkesztés alatt állapotba kerüljön.
6. Megadja, hogy a szerzők csak szerkesztés alatt állapotú node-okat szerkeszthessenek.
7. Megadja, hogy szerkesztés alatt állapotból csak a moderátorok tehetnek át node-ot közzétett állapotba (és 6. miatt csak ők vehetnek ki onnan).

Vagy nem erről van szó, nem ez a feladat? Az előbb végigcsináltam, kb. 3 perc volt teszt webhely létrehozásával együtt. Régen használtam a modult és ezért sokat bénáztam, szerintem másodjára már gyorsabban menne. :)

Szerk.: csatoltam a témaindítóhoz egy képernyőképet. A workflow-t tesztworkflow néven hoztam létre, a többi ahogy fent leírtam.

Örökzöld téma, nálam már a fejlesztés során elő szokott jönni. :) Minimális felületi javítások (és nem ritkán rontások) kedvéért kell formalterekkel, saját felülíró kóddal szétszedni a rendszert, amit aztán szinte lehetetlen karbantartani. Nagyon nehéz elmagyarázni, hogy annak a cuki kis izének ott a jobb sarokban komoly költsége lesz hosszú távon.

Nem tudok erre én sem megoldást, ezekkel próbálkozom, mérsékelt sikerrel:

1. Írásban rögzíteni, hogy ez vagy az a módosítás hosszú távon milyen karbantartási problémákat generálhat. (Általában csak írásban kommunikálok, meetingekről, Skype beszélgetésekről stb. mindig írok emlékeztetőt még aznap.)
2. Belekalkulálni az árba 1-2 komolyabb refaktorálást.
3. Mindig a tényleges munkaidő alapján számlázni. Ha egy látszólag kis módosítás fél munkanapot igényel, akkor az annyi. Ha emiatt az ügyfél elmegy, akkor ez van. (Előfordult már.) Ha valami 5-10 percnél tovább tart, az nem szívesség, hanem munka, és a munkát ki kell számlázni, hosszú távon mindkettőnk érdekében.
4. Ha hagy az ügyfél dolgozni, autonóm módon dönthetek, hogy a cuki kis izé megéri-e, stb. akkor azt az ügyfelet a tenyeremen hordozom és mindenféle extrákkal jutalmazom.

Ha be van kapcsolva a gyorstárazás a webhelyen, akkor innentől kezdve a tárhelyszolgáltatónál a labda. Neki kellene úgy beállítani a webszervert, hogy ki tudja szolgálni az oldalakat. Az azért elképzelhető, hogy egy sima osztott tárhelyen ezt nem fogja megtenni, inkább távozásra kér. Ha nem volt forgalmi korlát a szerződésben, akkor a pénzed visszajár.

Egyébként pedig saját gépen kell ezt a webhelyet futtatni, mert csak ott van komolyabb játéktered Apache, stb. optimalizálással. Sajnos van ilyen, hogy egy viszonlag kis webhely alá is saját szerver kell a spammerek miatt. Általában a webhely témája az, ami célponttá teszi. Én a napokban költöztettem egy drogpolitikával foglalkozó kisebb oldalt, amit gyógyszerreklámokkal spammelnek és az eddigi VPS tárhelyen sem volt elegendő eszköz a forgalom menedzselésére.