Ви взяли замовлення на доробку. Замовник прийняв пропозицію, гроші зайшли в escrow — і в кабінеті зʼявився форк. Що це насправді, куди можна писати код і як зміни доїдуть до реального магазину.
Одразу знімемо питання, яке виникає в кожного, хто робить це вперше: доступу до сайту клієнта ви не отримуєте. Ні до адмінки, ні до бази, ні до файлів на його хостингу. Ви отримуєте окремий git-репозиторій — копію його CMS. Усе, що туди запушите, платформа перетворить на оновлення й доставить клієнту тим самим каналом, яким приходять звичайні апдейти.
Що таке форк і чого він не дає
Форк — персональна гілкаclient/{uuid}у репозиторії замовника — тобто магазину, який замовник уже підключив до свого акаунта. Uuid непрозорий: ні домену, ні бази, ні чужих форків через нього не видно.
Три речі варто зрозуміти до першого коміту.
Форк створюється не за брифом, а за прийнятою пропозицією. Доки замовлення не в роботі, робочої копії не існує. Це і є авторизація: замовник не «дає доступ» окремою кнопкою — доступ виникає в момент, коли він приймає вашу ціну й резервує кошти. Наосліп доступ не видається нікому.
Форк живий, доки живе замовлення. Закрили замовлення — форк закривається автоматично. Заморожене чи закрите замовлення push не приймає.
Ваш кастом і оновлення платформи — різні файли. Це не обіцянка, а технічне обмеження: зони, у яких вам дозволено писати, не перетинаються з тими, які замінює апдейт.
Тепер чесно про межі, щоб не витрачати час на очікування, яке не справдиться. Це не доступ до бази — дані магазину лишаються поза досяжністю. Це не доступ до адмінки — ви змінюєте її код, але не заходите в неї. Це не спільна робота в реальному часі: ви пушите, платформа збирає, замовник ставить оновлення, і момент застосування вирішує він. І це не канал для секретів — ключі й токени клієнта у форк не потрапляють.
Крок 1. Отримати git-доступ
Кабінет розробника → CMS-форки. У картці форку — блок «Git-доступ (push кастому)» і кнопка «Згенерувати токен».
Токен варто розуміти правильно, бо тут легко помилитись:
| Властивість | Що це означає на практиці |
|---|---|
| Один токен — один магазин | Токен форку А не відкриє форк Б. Витік одного не відкриває решту ваших проєктів |
| Обмежений строк життя | Токен не вічний. Протермінований git відкине, і ви побачите запит креденшелів — це сигнал перевидати, а не «щось зламалось» |
| Показується один раз | Зберігайте одразу: платформа тримає лише хеш і показати повторно не може |
| Перевидача відкликає попередній | Натиснули «Згенерувати» вдруге — старий токен цієї ж пари мертвий. Навмисно: «один токен — один форк» має бути буквальним |
Email для git-логіну не потрібен: токен самоідентифікуючий. Якщо натрапите на старі інструкції зemail:токен@…— вони застаріли, і символ@у логіні лише ламав URL.
Крок 2. Клон, гілка й локальна копія
У картці є готовий сценарій — копіюйте його, а не збирайте команду руками:
# <PAT> = ваш токен. Клон у ПОТОЧНУ теку (крапка!) — тека має бути порожня.
git clone https://oauth2:<PAT>@forge.commercentr.com/git/<uuid> .Дві деталі, на яких спотикаються.
oauth2:перед токеном обовʼязковий. Токен має бути в полі пароля. Форма<PAT>@hostлишає пароль порожнім, і git зупиняється з проханням його ввести — у скрипті це просто фатал.
Гілку перемикати не треба.client/{uuid}виписується одразу при клоні (що таке гілка в Git). Якщо за звичкою створите свою — push у неї не пройде: приймається лише гілка вашого форку.
Локальна копія: архів і домен розробки
Клон дає код, але не робочий магазин: бази й налаштувань у ньому немає. Щоб підняти сайт локально, у картці форку є «Завантажити архів» — і поле домену розробки поруч.
Домен вкажіть до завантаження, наприкладlab.example.comабоlab.loc:8080. Він вшивається вAPP_URLархіву, і це не формальність: із порожнім значенням магазин після інсталяції згенерує всі абсолютні адреси — ассети, редіректи, OAuth-callback, листи — на неіснуючий хост, і ви витратите вечір на діагностику там, де проблема в одному полі.
Архів збирається тим самим пакувальником, що й покупецький: чужі секрети й рантайм вирізані,.envсвіжий. Одна відмінність — усередині лежитьFORK.mdіз готовими git-командами.
Живого.gitв архіві навмисно немає. Причина технічна: тягнути в zip багатомегабайтне bare-репо гірше, ніж три команди в інструкції. Тому послідовність така: архів для запуску локально, клон — для роботи з кодом.
Крок 3. Де можна писати код
Головне обмеження, і воно не декларативне: збірка перевіряє кожен шлях у вашому коміті.
Дозволено:
| Зона | Що сюди кладемо | Приклад |
|---|---|---|
config/ | нові файли налаштувань | config/custom_shop.php |
www/ | фронтенд, статика, ассети | www/assets/custom.css |
/Templates/ | шаблони-вʼюхи, override вигляду | admin/Templates/desktop/pages/dashboard.tpl |
/Custom/ | ваш PHP-код і класи (теку створюєте самі) | client/Custom/PriceHook.php |
/Languages/ | переклади, override текстів | admin/Languages/uk/Shop.php |
Заборонено:core/,bin/,data/,install/,modules/,vendor/,tools/,.git/, а такожwww/index.php,config/routing.phpіconfig/events/.
Логіка проста: усе, що замінює оновлення CMS, вам не належить. Якби форк писав у ядро, апдейт затер би ваш кастом — або конфліктував із ним на кожному релізі.
Зверніть увагу на зірочку в/Templates/,/Custom/і/Languages/: вона означає будь-який модуль, включно зadmin/. Перекрити вигляд адмінки чи її переклади можна без окремого дозволу. Окремий дозвіл потрібен лише для логіки — контролерів, моделей, сервісів.
Крок 4. Push, доставка і відмови
git commit -am "опис змін"
git push origin client/<uuid>Далі автоматично: платформа перевіряє токен і те, що замовлення активне; перевіряє кожен змінений шлях проти зон; збирає з різниці патч і публікує його для магазину. Замовник бачить оновлення у своїй адмінці — так само, як звичайний апдейт CMS.
У картці форку є лічильник «Стан апдейтів» — скільки патчів у ланцюзі. Це індикатор, що push доїхав і став доставним оновленням, а не просто ліг у гілку.
Найчастіша відмова — файл поза зоною. Ви отримаєте сповіщення з конкретним переліком шляхів. Збірка не «підчищає зайве», вона відхиляє коміт цілком: часткове застосування дало б магазину напівстан, у якому незрозуміло, що саме поїхало.
Що робити: перенесіть зміну в дозволену зону. Майже завжди це можливо — правку ядра замінює шаблон-override, власний клас уCustom/або перевизначений переклад. Якщо задача справді вимагає логіки вadmin/, просіть розширений доступ, а не обхідний шлях.
Розширений доступ, етапи та re-baseline
Розширений доступ. Замовник може дозволити ширшу зону — наприкладadmin/цілком, разом із контролерами й сервісами. Це його рішення, і ризики оновлень він бере на себе: логіка вadmin/може конфліктувати з майбутніми релізами. Просіть її тоді, коли шаблонів і хуків справді не вистачає, — не «про всяк випадок».
Етапи. Роботу можна розбити на частини, і кожну замовник приймає окремо: етап проходить стани «очікує → подано → зараховано». Для вас це означає, що гроші розблоковуються поетапно, а не все наприкінці. Для великої задачі це помітно знижує ризик обом сторонам.
Re-baseline. Якщо форк відстав від community-бази й кастом почав конфліктувати з оновленнями, у картці два виходи. «Перенести на свіжу базу» — форк переїжджає на актуальний знімок CMS, кастом лишається. «Відчепити від community» — форк переходить на власну базу: кастом лишається весь, але community-оновлення більше не надходять. Крок незворотний, і саме тому він окремою кнопкою. Друге має сенс, коли магазин так далеко пішов від стандартної CMS, що оновлення дають більше конфліктів, ніж користі. Це усвідомлений компроміс, а не аварійна кнопка.
Якщо замовник відкрив спір
Спір — не аварія й не звинувачення особисто вам. Це стан замовлення, у якому escrow лишається замороженим до розбору: гроші не йдуть ні вам, ні назад замовнику, доки платформа не вирішить.
Ви побачите це двома шляхами: системним записом у листуванні замовлення й дзвіночком у кабінеті. Окремої «дії у спорі» у вас немає — і це навмисно: вирішує арбітр платформи, а ви сторона, яка пояснює. Ваш інструмент тут один, і він потужніший, ніж здається — те саме листування.
Що варто зробити одразу:
- Відповісти по суті претензії, а не загалом. Арбітр бачить усю нитку: бриф, вашу пропозицію, кожне повідомлення обох сторін і системні події — коли етап подано, коли зараховано.
- Показати, що вже прийнято. Якщо етапи здавались частинами й замовник їх зараховував, це видно в історії з датами. Зарахований етап — сильний аргумент, і його не треба доводити словами.
- Прикріпити артефакти. Листування приймає вкладення; скріншот, лог або посилання на коміт переконують краще за опис.
Звідси й практична порада на майбутнє: тримайте комунікацію в замовленні, а не в месенджерах. Домовленість, якої немає в нитці, для арбітра не існує. Розбивати роботу на етапи варто з тієї ж причини — кожен зарахований етап це зафіксоване приймання, а не памʼять обох сторін.
Що це дає вам як виконавцю
Три речі, яких зазвичай немає у фрилансі «дайте FTP».
Ви не можете зламати клієнту сайт правкою ядра — зони цього не дозволять. Це знімає найбільший страх замовника, а разом із ним половину переговорів про доступи.
Ваш кастом переживає оновленняcommunity-CMS. Не тому, що ви акуратні, а тому, що він фізично в інших файлах.
І гроші вже зарезервовані в escrow до того, як ви взялися за роботу. Ви бачите резерв на сторінці замовлення й не залежите від того, чи згадає замовник про оплату.
Якщо ви ще не брали замовлень на платформі, подивіться, як замовник складає бриф і приймає роботу: у нього свій набір кроків і своя відповідальність.
CTA: відкрийте кабінет розробника → CMS-форки й перегляньте картку наявного замовлення, перш ніж генерувати токен. Половина питань знімається самим інтерфейсом.
Якщо домовитись у листуванні не вдалось — механіка розгляду окремо: суперечка за замовленням.