Интерфейс за управление на Zope ноу-хау за по-добро развитие на Plone

Има няколко места в ZMI, към които се връщам за диагностична информация:

• /Control_Panel/Database: Изберете точка на монтиране на ZODB. Разделът „Параметри на кеша“ показва каква част от определения ви размер на ZODB кеша е използван. Разделът „Активност“ показва колко обекта се зареждат в кеша и се записват с течение на времето.

• /Control_Panel/DebugInfo/manage: Много информация, включително показване каква заявка обслужва всяка нишка в текущия момент. Връзките „Подробности за кеша“ и „Изключителни подробности за кеша“ дават информация за това какви класове обекти са в момента в кеша на ZODB.

• Раздел Компоненти на корена на сайта на Plone: ​​Бърз начин да видите какви локални адаптери и помощни програми са регистрирани. НЕ НАТИСКАЙТЕ БУТОНА ЗА КАНДИДАТСТВАНЕ!

• Раздел Отмяна на повечето обекти: Вижте кой напоследък е извършил транзакции, засягащи обекта.

• Раздел Защита: Вижте какви разрешения действително са в сила за даден обект. Наистина не искате да променяте разрешенията тук в 90% от времето; твърде трудно е да се следи къде са зададени разрешенията и те могат да бъдат нулирани от работния процес. Вместо това използвайте раздела Споделяне в потребителския интерфейс на Plone, за да зададете локални роли. (Единственото изключение е, че често намирам за удобно да активирам разрешението за добавяне за определен тип в специфични контексти.) В Zope 2.12 има нова функция в този раздел за въвеждане на потребителско име и виждане какви разрешения и роли ще бъдат в ефект за този потребител, което е удобно.

• Раздел Catalog на portal_catalog: Вижте какви индексни данни и метаданни се съхраняват за определен път. (Може също да премахва фалшиви записи от индекса.)

• Раздел Index на portal_catalog: Изберете индекс, след което щракнете върху неговия раздел Browse, за да получите общ преглед на това кои ключове са индексирани и кои елементи са свързани с всеки ключ.

Ключовото нещо, което трябва да знаете е, че въпреки че много инструменти на ZMI осигуряват бърза персонализация в мрежата, персонализациите, които правите по този начин, трудно се експортират извън базата данни. Така че те не преминават лесно от среди за разработка към производствени среди или от едно внедряване към друго.

В идеалния случай нов разработчик трябва да използва ZMI, за да проучи и намери точки за намеса. След това научете как да прилагате същите промени в добавките на правилата (продукти), които се преместват от едно внедряване в друго много по-възпроизводимо.

Ако искате да пишете код за Plone, най-добре е да избягвате ZMI. Концепцията за правене на неща чрез ZMI е много ограничена и обезсърчена - все повече и повече неща не са налични там и това ще изчезне в един момент.

Действителните контролни панели на Plone ви предлагат повечето от опциите за конфигурация, които можете да използвате. За всичко друго файловата система е най-доброто място за търсене.

Съгласен съм с другите плакати, че не трябва да конфигурирате твърде много чрез ZMI, тъй като не е в контрола на версиите и лесно можете да загубите представа за промените.

Но ZMI все още е много полезен за отстраняване на грешки и за разглеждане на конкретни конфигурации на сайта.

Ето някои инструменти в ZMI, които редовно консултирам:

• portal_javascripts: За да изключите отстраняването на грешки. Проверява се какви скриптове има, какви са условията им за изобразяване и намират ли се?
• portal_css: По принцип същото като portal_javascripts, но за таблици със стилове.
• portal_types: За да видите какви са свойствата на даден тип. Може ли да се създаде глобално? Какви типове можете да създадете в него? Какъв е неговият изглед по подразбиране? и т.н.
• portal_catalog: Какви индекси има? Какви метаданни има в каталога? Можете да изчистите и възстановите каталога и дори да преглеждате каталога.
• portal_workflow: Какви състояния/преходи/разрешения има в определен работен процес? Какъв работен процес е активен за определен тип?
• portal_properties/site_properties: Вижте и задайте свойства за целия сайт. Много от тези настройки са в plone_control_panel (т.е. извън ZMI), но тук те са на една страница и ZMI е по-бърза за навигация.
• portal_skins: Вижте кои папки с скинове са инсталирани. Вижте подреждането на слоевете на кожата (чрез раздела свойства). Можете също така да редактирате шаблоните, таблиците със стилове и javascript в директориите на кожите. Не се препоръчва! Но полезно за отстраняване на грешки.
• portal_setup: Някои много големи и сложни уебсайтове на Plone могат да се повредят, ако просто ще добавите/премахнете/преинсталирате добавки. Често е по-безопасно просто да стартирате конкретна актуализация на GenericSetup. Например, ако сте добавили нов портлет, по-скоро импортирайте конкретната (portlets.xml) стъпка чрез portal_setup (раздела за импортиране), след което преинсталирайте целия продукт.
• portal_actions: Конфигурирайте кои действия са видими/присъстващи.
• portal_quickinstaller: Бързо преинсталиране, деинсталиране на добавки. Често по-бързо и по-леко от зареждането на еквивалента на контролния панел на Plone.
• acl_users: Понякога, когато използвате добавка като LDAPUserFolder, ще трябва да се разровите в acl_users, за да я конфигурирате и тествате. Можете също така да създавате потребители тук, въпреки че е по-добре да направите това чрез контролния панел на Plone (т.е. не в ZMI)

В ZMI има много повече инструменти и неща за настройване (и счупване на вашия сайт), но горните са това, което използвам 90% от времето.

Инструментът portal_historiesstorage може да изяде много дисково пространство. Всеки тип съдържание, настроен да записва ревизии, ги записва тук и по подразбиране Plone запазва всички ревизии (вижте инструмента portal_purgepolicy).

Искам всички ревизии на производствения Data.fs, но след като взема копие за разработка, първото нещо, което правя, е да изчистя portal_historiesstorage. Процедурата е:

• Отидете на вашия Plone сайт в ZMI
• Изтрийте инструмента portal_historiesstorage
• Отидете на portal_setup, раздел Импортиране
• Под „Избор на профил или моментна снимка“ изберете „CMFEditions“
• Изберете стъпката с манипулатора Products.GenericSetup.tool.importToolset
• Премахнете отметката от „Включване на зависимости?“
• Натиснете „Импортиране на избрани стъпки“, за да добавите отново portal_historiesstorage
• Опаковайте Data.fs и изтрийте получения Data.fs.old от файловата система

На моя 3G Data.fs тази малка последователност премахва 2.5G!

Правил съм това само на Data.fs за разработка. Без съвет от някой, който наистина знае, не препоръчвам да правите това на вашия производствен обект.

Обикновено няма причина интегратор или разработчик да се докосва до ZMI за възможни задачи по поддръжката. Почти всяко персонализиране може да се извърши с помощта на Python или GenericSetup профил. Предимствата на профилите са: повторяемост - възможност за поддържане във файловата система - възможност за поставяне на файлове под контрол на ревизиите.

Да можеш да работиш и конфигурираш неща чрез ZMI отчасти работи срещу Plone - особено когато Plone прави допълнителни неща под капака. Така че единствената препоръка може да бъде: останете в ZMI, ако можете. ZMI не е подходящ заместител за използване на Plone UI и трябва да се докосва само ако наистина знаете какво правите.

Да, ZMI е за случайна задача по поддръжка или, когато се натисне, бърза и мръсна настройка на CSS или шаблон. Не е предназначен за истинска работа по „кодиране“ и в контекста на Plone е най-добре да се смята за странен и минимално полезен остатък от историята на Zope.

portal_actions също е полезно за по-гъвкава навигация от най-високо ниво. но отново най-добре конфигуриран чрез gnericsetup.