Кога првично го создадов моето портфолио, целта беше едноставна: да изработам современ, професионален веб-сајт на кој ќе можам да ги претставам моите проекти, услуги и искуство во веб-развојот.
Дизајнот започна во Figma, а потоа целиот веб-сајт беше изработен во Webflow.
Во таа фаза Webflow беше одлично решение. Ми овозможи релативно брзо да го претворам дизајнот во целосно респонзивен веб-сајт, да додадам интеракции и анимации и да објавам портфолио подготвено за продукција, без да градам цел систем од почеток.
Но, како што портфолиото растеше, барањата се менуваа.
Повеќе не ми беше доволно само визуелно доработено статичко портфолио. Сакав сам да управувам со хостингот и изворниот код, да објавувам детални студии на случај преку CMS, повторно да користам шаблони, содржината да ја чувам под контрола на верзии и секоја промена автоматски да ја поставувам во продукција.
Така, едно релативно едноставно Webflow портфолио постепено се разви во мала, самостојно хостирана платформа за содржини.
Фаза 1 — Дизајн и развој во Webflow
Првата верзија на портфолиото беше класичен проект од дизајн до изработка во Webflow.
Најпрво во Figma целосно ги дефинирав корисничкиот интерфејс и корисничкото искуство, вклучувајќи ги визуелната насока, типографијата, боите, растојанијата, структурата на страниците и начинот на претставување на проектите.
Потоа го имплементирав дизајнот во Webflow.
Респонзивното однесување беше важен дел од развојниот процес. Дизајнот за десктоп не беше само намален за помали уреди. Распоредите, типографијата, растојанијата и одделните компоненти беа приспособени за точките на прекршување на таблет и мобилни уреди.
Webflow овозможи и додавање интеракции и анимации без непотребно усложнување на frontend кодот.
Резултатот беше целосно функционално портфолио со јасен визуелен идентитет.
Тоа подоцна стана важно.
Кога конечно решив да го мигрирам веб-сајтот, немаше причина повторно да изработувам frontend што веќе добро функционираше.
Целта не беше редизајн на портфолиото.
Целта беше да го зачувам она што веќе функционираше и да ја променам инфраструктурата зад него.
Фаза 2 — Од Webflow хостинг до сопствен хостинг
Со текот на времето стана јасно дека продукциското портфолио повеќе нема потреба да остане врзано за хостингот на Webflow.
Го извезов Webflow проектот и го префрлив целиот frontend во локална развојна околина.
Со тоа беа зачувани:
- HTML структура
- CSS
- JavaScript
- слики и други ресурси
- анимации
- респонзивно однесување
- frontend функционалности
Наместо сè да изработувам одново, извезениот Webflow веб-сајт стана основа на новиот проект со сопствен хостинг.
Потоа веб-сајтот беше поставен на Hostinger.
Тоа ми овозможи нешто важно: директна контрола врз продукциските датотеки, хостинг-околината и идниот развој на веб-сајтот.
Замена на Webflow backend-от за формуларот
Преминувањето од Webflow хостинг значеше и дека контактниот формулар повеќе не можеше да зависи од обработката на формулари на Webflow.
Таа функционалност ја заменив со сопствена PHP крајна точка.
Frontend делот го презема испраќањето на формуларот и ги испраќа податоците до серверот. PHP крајната точка го обработува барањето и враќа JSON одговор, а интерфејсот потоа ја прикажува соодветната состојба за успешно испраќање или грешка.
За заштита од ботови и спам го интегрирав Cloudflare Turnstile.
Така, контактниот формулар работи независно од инфраструктурата на Webflow, а ги задржува првичното корисничко искуство и дизајнот.
Фаза 3 — Од статички веб-сајт до платформа управувана преку CMS
Сопствениот хостинг го реши инфраструктурниот проблем, но остана уште едно прашање:
Како да се додаваат нови студии на случај?
Наједноставното решение ќе беше да направам копија од постојна HTML страница секогаш кога сакам да објавам нов проект.
Технички, тоа ќе функционираше.
Меѓутоа, долгорочно тоа би довело до повторување на HTML-кодот, повторлива работа за одржување и можност одделните страници со студии на случај постепено да станат недоследни.
Сакав содржината да биде независна од начинот на кој се прикажува.
Тоа доведе до воведување генератор на статички страници.
Eleventy како генератор на статички страници
Во проектот го воведов Eleventy (11ty).
Eleventy овозможува содржината да остане одделена од HTML шаблоните, а конечните статички страници да се генерираат во процесот на изработка.
За проектните студии на случај создадов повеќекратно употреблив Nunjucks шаблон.
Наместо да одржувам целосна HTML страница за секој проект, секоја студија на случај содржи сопствени структурирани податоци и содржина.
Тие опфаќаат информации како:
- наслов и категорија на проектот
- статус на проектот
- краток опис
- содржина во главната секција
- информации за проектот
- предизвик и цели
- улоги и одговорности
- развоен процес
- технолошки стек
- интеграции
- клучни функционалности
- испорачани решенија
- резултати
- научени лекции
- галерија на проектот
- врски до проектот
- SEO метаподатоци
Еден повеќекратно употреблив шаблон ја претвора таа структурирана содржина во целосна страница со студија на случај.
Ова носи важна предност при одржувањето.
Ако во иднина треба да се промени дизајнот на студиите на случај, не мора да го уредувам секој проект одделно.
Шаблонот го ажурирам само еднаш.
Markdown како слој за содржина
Секој проект се чува како Markdown датотека.
Така портфолиото добива едноставен слој за содржина без потреба од традиционална база на податоци.
За ваков веб-сајт тоа е намерен архитектонски избор.
На портфолиото не му се потребни кориснички сметки, сложени релациски податоци или содржина што се менува илјадници пати дневно.
Воведувањето база на податоци и целосен backend само за управување со содржините на портфолиото би додало сложеност без да реши вистински проблем.
Markdown е доволен.
Но, рачното уредување на Markdown и front matter не е идеален процес за објавување.
Тука во архитектурата влегува Pages CMS.
Pages CMS — Визуелно управување со содржините
GitHub складиштето е поврзано со Pages CMS.
Наместо рачно да отворам Markdown датотеки и да го уредувам front matter, можам да управувам со содржините преку структуриран CMS интерфејс.
За проектните студии на случај, CMS нуди полиња за насловот на проектот, категоријата, насловната слика, услугите, технологиите, информациите за проектот, целите, одговорностите, технолошкиот стек, галеријата, SEO податоците и другите секции што ги користи шаблонот за студии на случај.
Проектите може да се означат и за прикажување на почетната страница.
Кога содржината ќе се зачува, Pages CMS ја создава или ажурира соодветната Markdown датотека директно во GitHub складиштето.
Со други зборови:
CMS не е одделна база на податоци. Git складиштето останува меродавен извор.
Тоа значи и дека промените на содржината автоматски добиваат историја на верзии.
Секое ажурирање преку CMS станува Git commit.
GitHub како средиште на процесот за објавување
Во оваа фаза архитектурата приближно изгледаше вака:
Pages CMS → Markdown → GitHub → Eleventy → статички HTML
Сè уште недостигаше еден чекор.
Поставувањето.
Можев локално да ја извршам изработката, да ги земам генерираните датотеки и рачно да ги прикачам на Hostinger.
За повремени промени, тоа би било прифатливо.
Но, кај веб-сајт управуван преку CMS, таквиот пристап создава непотребни пречки.
Ако содржината може да се ажурира преку прелистувач, нема потреба да го отворам локалниот проект само за да ја објавам таа промена.
Затоа го автоматизирав процесот за поставување.
Автоматизирано поставување со GitHub Actions и Hostinger
Процес во GitHub Actions сега реагира на промените во гранката main.
Секогаш кога ќе се создаде нов commit, процесот автоматски:
- ја презема работната копија од складиштето
- ја подготвува Node.js околината
- ги инсталира потребните зависности
- ја извршува продукциската изработка со Eleventy
- го генерира конечниот излез во
_dist - ги поставува продукциските датотеки на Hostinger
За поставувањето се користи посебна FTP сметка со пристап ограничен на продукцискиот директориум на веб-сајтот за портфолио.
Податоците за најава не се чуваат во складиштето. Тие се безбедно зачувани како GitHub Actions Secrets.
Целосниот процес за објавување сега е:
Pages CMS → GitHub commit → GitHub Actions → изработка со Eleventy → FTP → Hostinger → активен веб-сајт
За објавување нова содржина повеќе не е потребно рачно прикачување во продукција.
Ја ажурирам содржината во CMS.
Кликнувам на Save.
Останатото се случува автоматски.
Зошто FTP наместо SSH?
Првичниот план беше поставувањето да се врши преку SSH.
Теоретски, процесот во GitHub Actions би можел да го генерира веб-сајтот и да ги пренесе генерираните датотеки директно на серверот преку SSH врска.
Меѓутоа, во оваа конкретна околина со споделен хостинг, директното SSH поставување од GitHub Actions runner не се покажа како најсигурно решение.
Наместо да додадам инфраструктурна сложеност само за да го задржам првичниот технички план, го приспособив начинот на поставување кон околината.
Создадов посебна FTP сметка со пристап ограничен на соодветниот продукциски директориум и го префрлив процесот на поставување преку FTP.
Ова е корисен потсетник дека најдоброто техничко решение не е секогаш она што изгледа најсовремено на архитектонски дијаграм.
Подобро е решението што сигурно го решава вистинскиот проблем.
Одвојување на проектите од блогот
Со развојот на архитектурата на содржините, стана корисно уште едно структурно подобрување.
Првично, списокот со студии на случај ја користеше патеката /blog/. Тоа функционираше додека на веб-сајтот му требаше само место за објавување детални проектни содржини, но ја замаглуваше разликата меѓу проектите во портфолиото и редакциските статии.
Архитектурата сега ги третира како два независни системи за содржини.
Проектните студии на случај се наоѓаат под:
/projects/
Секој проект има сопствена URL-адреса:
/projects/<project-slug>/
Проектите користат сопствена колекција во Pages CMS, структурирана проектна шема, колекција во Eleventy и повеќекратно употреблив шаблон за студии на случај.
Самиот блог сега се наоѓа под:
/blog/
Блог-статиите користат одделна колекција во Pages CMS, сопствен директориум со Markdown содржини, посебна колекција во Eleventy и повеќекратно употреблив шаблон за долги статии.
Ова одвојување го прави моделот на содржини многу појасен:
Проектите се доказ за сработеното. Блог-статиите ги објаснуваат идеите, одлуките, процесите и лекциите зад таа работа.
Двата система можат меѓусебно да се поврзуваат без да зависат еден од друг.
На пример, оваа статија ги објаснува архитектурата и процесот на миграција, додека соодветната проектна страница може да се фокусира на самото портфолио како студија на случај.
Автоматски генерирани списоци со проекти
Структурираната содржина е корисна и надвор од одделните страници со студии на случај.
Eleventy ги користи проектните податоци и за автоматско генерирање на списокот со проекти.
Кога преку CMS ќе се додаде нов проект, веб-сајтот може да ги генерира неговата картичка, URL-адреса и страница со студија на случај без рачно создавање уште една HTML страница.
Нема потреба рачно да се копира картичка, да се копира наслов или да се поврзува уште една URL-адреса.
Истите изворни податоци повторно се користат секаде каде што се потребни.
Тоа може да изгледа како мало подобрување кога портфолиото содржи само неколку проекти.
Но, станува сè повредно како што портфолиото расте.
Избрани проекти на почетната страница
Сличен принцип се користи и за почетната страница.
Преку CMS може да се одреди дали проектите треба да се појават меѓу избраните проекти на почетната страница.
Тоа значи дека изборот на почетната страница се управува преку содржината, наместо рачно да се одржува на неколку различни места.
CMS управува со содржината, а шаблоните со нејзиниот приказ.
Посебен систем за објавување блог-статии
Новиот блог ја следи истата општа филозофија, без да ја копира многу пообемната проектна шема.
Блог-статиите имаат намерно поедноставен модел на содржини, осмислен за долги статии.
CMS системот за блогот содржи полиња за:
- наслов и slug
- датум на објавување и статус
- означување како истакната статија
- категорија и ознаки
- краток опис
- насловна слика
- автор
- содржина на статијата во Markdown
- изборно поврзан проект
- SEO наслов и опис
- Open Graph слика
Објавените статии се генерираат при изработката и автоматски се појавуваат во списокот на /blog/.
Нацртите може да останат во CMS без да бидат вклучени во продукцискиот блог.
Така веб-сајтот добива два наменски процеса за објавување, а двата система остануваат во истата архитектура заснована на Git.
Анализа и разбирање на однесувањето на корисниците
Портфолиото користи и Microsoft Clarity.
Clarity обезбедува топлински мапи и снимки од сесии што ми помагаат да разберам како посетителите навистина комуницираат со веб-сајтот.
На пример, можам да следам:
- до каде посетителите се движат надолу по страницата
- со кои елементи комуницираат
- каде корисниците застануваат
- дали одредени повици за дејство се игнорираат
- каде може да се подобри корисничкото искуство
Тоа значи дека идните подобрувања не мора целосно да се засноваат на претпоставки.
Дали ова е поевтино од Webflow хостингот?
За овој конкретен проект — да.
Но, намалувањето на трошоците не беше единствената причина за миграцијата, ниту најважната.
Webflow останува корисна алатка за развој. Прашањето беше само дали на овој конкретен веб-сајт, откако му се променија барањата, сè уште му е потребен хостинг-моделот на Webflow.
Портфолиото сега работи на хостинг што веќе го користам, додека Pages CMS, GitHub и GitHub Actions го обезбедуваат процесот за управување со содржините и нивно објавување без потреба од уште еден традиционален платен CMS.
Со тоа се намалуваат повторливите трошоци поврзани конкретно со портфолиото.
Истовремено добив:
- директна контрола врз изворниот код
- контрола врз хостингот
- историја на верзии во Git
- визуелен CMS интерфејс
- повеќекратно употребливи шаблони
- генерирање статички страници
- автоматизирано поставување
- одделни системи за објавување проекти и блог-статии
- можност архитектурата да ја развивам според идните барања
Значи, поентата не е едноставно:
„Поевтино е од Webflow.“
Попрецизен опис е:
За барањата на овој проект добив поголема контрола и флексибилност, а истовремено ги намалив долгорочните трошоци за хостинг.
Што остана од Webflow?
Многу нешта.
И тоа е намерно.
Миграцијата никогаш не беше обид да го отстранам Webflow од проектот, како користењето на Webflow уште од почетокот да било погрешна одлука.
Првичниот Webflow frontend останува визуелната основа на веб-сајтот.
HTML, CSS, респонзивната структура, интеракциите и дизајнерските одлуки создадени во таа фаза не беа отфрлени само затоа што се промени инфраструктурата.
Наместо тоа, проектот се разви околу постоечки frontend што веќе добро функционираше.
Развојниот пат го гледам вака:
Figma → Webflow → извоз → сопствен хостинг → Eleventy → Pages CMS → GitHub → GitHub Actions → автоматизирано поставување
Секој слој беше воведен кога за него постоеше конкретна причина.
Тековна архитектура
Денес портфолиото комбинира неколку релативно едноставни технологии.
Frontend
HTML5, CSS3, JavaScript, jQuery и GSAP.
Генерирање статички страници
Eleventy и Nunjucks.
Содржина
Markdown.
CMS
Pages CMS.
Контрола на верзии
Git и GitHub.
Backend функционалност
PHP за обработка на контактниот формулар.
Безбедност
Cloudflare Turnstile.
Поставување
GitHub Actions и FTP.
Хостинг
Hostinger.
UX аналитика
Microsoft Clarity.
Ниту една од овие технологии не е особено сложена сама по себе.
Вредноста произлегува од начинот на кој се поврзани.
Што научив од проектот
Една од најважните лекции беше дека миграцијата не мора автоматски да значи повторна изработка на сè.
Ако постоечкиот frontend добро функционира, може да биде поразумно да се зачува и да се заменат само слоевите што станале ограничувачки.
Друга лекција беше дека CMS не мора автоматски да бара база на податоци, API и сложен backend.
За портфолио или сличен веб-сајт заснован на содржини:
Markdown + Git + генератор на статички страници + CMS интерфејс
може да биде многу ефикасна архитектура.
Третата лекција се однесуваше на поставувањето.
Автоматизацијата може да изгледа непотребна кога веб-сајтот се менува само еднаш на неколку месеци. Но, откако ќе се воведе CMS и содржините ќе почнат редовно да се објавуваат, рачното поставување станува непотребна пречка.
А можеби најважната лекција е:
Изберете ја технологијата според проблемот. Не приспособувајте го проблемот според технологијата.
SSH поставувањето не функционираше како што сакав во оваа конкретна околина со споделен хостинг. Наместо да го усложнувам системот, го приспособив механизмот за поставување и употребив FTP сметка со ограничен пристап.
Резултатот е поедноставен систем што работи сигурно.
Резултатот
Она што започна како лично Webflow портфолио сега е повеќе од збирка статички страници.
Стана мала платформа за содржини што можам самостојно да ја развивам и одржувам.
Нов проект може да помине низ целиот процес:
Pages CMS → GitHub → изработка → поставување → продукција
Нова блог-статија може да го следи истиот процес преку сопствениот наменски модел на содржини.
Нема потреба рачно да го уредувам продукцискиот HTML или да прикачувам генерирани датотеки по секое ажурирање на содржината.
Истовремено, првичниот дизајн останува непроменет.
Веб-сајтот е активен, но проектот нема традиционална „завршена“ состојба. Тој се одржува и постојано се развива.
Како што се создаваат нови проекти, статии, услуги и алатки, истата платформа може да продолжи да се развива заедно со портфолиото.
Погледнете го проектот
Ако сакате да ја видите имплементацијата од проектна перспектива, можете да ја прочитате целосната студија на случај за личното портфолио:
Погледнете ја студијата на случај за личното портфолио
Можете да го разгледате и активниот веб-сајт:
Посетете го портфолиото на Igor Mihajlovski
Заклучок
Овој проект ми е особено интересен затоа што поврзува две различни страни на веб-развојот.
Првата е визуелна: Figma, Webflow, респонзивен дизајн, интеракции и корисничко искуство.
Втората е структурна: архитектура на содржините, шаблони, CMS, Git, CI/CD, хостинг и автоматизација.
Немаше потреба да избирам меѓу нив.
Webflow обезбеди силна основа за frontend делот, а подоцнежната миграција ми овозможи околу таа основа да изградам сопствен систем за развој и објавување.
Резултатот не е само портфолио што изгледа поинаку.
Тоа е портфолио што се одржува, развива и објавува поинаку.
