Настройка готового сайта Dizzy.kz

Istnieje działająca strona produkcyjna z katalogiem produktów, kartami modeli i stronami informacyjnymi. Stos technologiczny frontend: — Next.js; — React; — TypeScript; — istniejący system komponentów; — środowiska staging i produkcyjne. Jest zatwierdzony kierunek wizualny i projekt nowej strony głównej. Należy go wdrożyć w istniejącym projekcie, dostosować do desktop/tablet/mobile i doprowadzić wszystkie główne typy stron do jednolitej, zaktualizowanej stylistyki. Pełny redesign produktu i zmiana logiki biznesowej nie są wymagane. OBOWIĄZKOWY ZAKRES 1. Nowa strona główna — zrealizować stronę główną według dostarczonego projektu; — zachować istniejącą funkcjonalność, linki i routingu; — poprawnie podłączyć zatwierdzone sekcje i CTA; — wykorzystać istniejące dane i API; — przewidzieć poprawne wyświetlanie dynamicznej treści. Główne typy sekcji: — nagłówek/nawigacja; — hero; — bloki informacyjne; — karty modeli/ofert; — bloki analityczne lub market insight; — sekcje CTA; — stopka. Dokładny skład sekcji zostanie dostarczony wybranemu wykonawcy wraz z makietą. 2. Responsywność Należy zrealizować: — desktop; — tablet; — mobile; — pośrednie rozdzielczości; — poprawne zachowanie siatek, kart, menu, przycisków i typografii; — brak poziomego scrolla i konfliktów wizualnych. 3. Typografia i ogólne style — wdrożyć nowe zatwierdzone czcionki; — doprowadzić rozmiary, wagi, line-height i odstępy do jednolitego systemu; — zaktualizować style przycisków, kart, pól, badge'ów i nagłówków; — w miarę możliwości wykorzystać wspólne design tokens lub zmienne CSS; — nie dublować stylów osobno dla każdej strony bez potrzeby. 4. Ujednolicenie istniejących stron Sprawdzić i doprowadzić do nowej stylistyki główne typy stron: — katalog; — karta modelu / PDP; — strony informacyjne; — nagłówek; — stopka; — formularze; — okna modalne; — istniejące CTA; — stany loading / empty / error, jeśli już występują w projekcie. Chodzi o wizualne ujednolicenie istniejących komponentów, a nie o pełny indywidualny redesign każdej strony. 5. Katalog Sprawdzić: — siatkę kart; — obrazy; — nazwę, referencję i cenę; — filtry i sortowania; — przyciski i linki; — wyświetlanie desktop/mobile; — stany loading i empty; — brak wizualnych przesunięć podczas ładowania. 6. PDP Sprawdzić: — galerię; — główny blok informacyjny; — cenę i CTA; — sekcje analityczne; — tabele i metryki; — About Watch; — układ desktop/mobile; — długie nazwy, referencje i brakujące dane. Należy zachować obecną funkcjonalność i istniejące kontrakty API. 7. Nagłówek i Stopka — jednolita stylistyka na wszystkich stronach; — responsywna nawigacja; — mobilne menu; — poprawne stany active/hover/focus; — brak rozbieżności między stroną główną, katalogiem i PDP. 8. Stany interfejsu Dla dynamicznych bloków sprawdzić: — loading; — puste dane; — błąd API; — niewystarczające dane; — brakujący obraz; — brakująca cena; — długi tekst; — mobilne wyświetlenie. Nie jest wymagane opracowywanie nowej skomplikowanej logiki biznesowej. Należy poprawnie wizualizować już istniejące stany. 9. Jakość i wydajność — nie pogorszyć SEO i bieżącej indeksacji; — zachować poprawne metadane i semantyczne HTML; — nie tworzyć krytycznych przesunięć układu; — optymalizować obrazy i czcionki; — uwzględnić reduced motion dla animacji; — sprawdzić podstawową dostępność: stany focus, kontrast, nawigacja klawiaturą; — nie podłączać ciężkich bibliotek bez uzasadnionej potrzeby. 10. Staging i QA — wdrożyć zmiany na staging; — sprawdzić główne typy stron; — sprawdzić desktop, tablet i mobile; — usunąć wizualne i responsywne błędy; — po akceptacji wykonać wdrożenie produkcyjne; — zapewnić poprawę błędów w zrealizowanym zakresie nie mniej niż 7 dni kalendarzowych po publikacji. WYNIK PRACY — Pull Request z kodem frontendowym; — zrealizowana nowa strona główna; — responsywne desktop/tablet/mobile; — jednolite czcionki, karty i podstawowe komponenty UI; — wizualnie zatwierdzone katalog, PDP i strony informacyjne; — wdrożenie staging; — poprawa znalezionych błędów wizualnych; — wdrożenie produkcyjne; — krótki opis zmienionych komponentów; — 7-dniowy okres naprawy błędów po akceptacji. KRYTERIA AKCEPTACJI 1. Strona główna odpowiada dostarczonemu projektowi. 2. Wszystkie sekcje poprawnie działają na desktop, tablet i mobile. 3. Nagłówek i stopka są jednolite na wszystkich stronach. 4. Katalog i PDP wizualnie odpowiadają nowemu systemowi. 5. Obecna funkcjonalność strony nie jest naruszona. 6. Kontrakty API i logika backendowa nie zostały zmienione bez uzgodnienia. 7. Brak poziomego scrolla i krytycznych przesunięć układu. 8. Czcionki i obrazy ładują się poprawnie. 9. Stany loading, empty i error są wyświetlane bez uszkodzenia układu. 10. Zmiany zostały sprawdzone na staging i wdrożone w produkcji. 11. Poprawiono błędy wizualne wykryte podczas akceptacji w ramach uzgodnionego zakresu. CO NIE JEST WYMAGANE — opracowanie backendu; — zmiana logiki biznesowej; — stworzenie nowego katalogu lub CMS; — opracowanie nowego API; — pełny redesign każdej strony informacyjnej; — nowe funkcje użytkownika, które nie są zawarte w makietach; — opracowanie skomplikowanego systemu designu od podstaw; — stworzenie nowego projektu zamiast dopracowania istniejącego; — zmiana struktury SEO bez osobnego uzgodnienia. WYMAGANIA WOBEC WYKONAWCY — pewna znajomość Next.js / React / TypeScript; — doświadczenie w pracy z istniejącymi projektami produkcyjnymi; — jakościowe responsywne cięcie; — doświadczenie w wdrażaniu projektów z Figma; — podejście komponentowe; — pewna praca z CSS / CSS Modules / Tailwind lub istniejącym systemem projektu; — zrozumienie Core Web Vitals; — Git / Pull Request workflow; — umiejętność pracy przez staging. W ODPOWIEDZI NALEŻY KONIECZNIE PODAĆ 1. Stała cena za pełny obowiązkowy zakres. 2. Czas realizacji w dniach roboczych. 3. Ocena w godzinach. 4. Kiedy można zacząć. 5. Linki do 2–3 odpowiednich projektów na Next.js/React. 6. Czy jest doświadczenie w pracy z katalogami, kartami produktów lub interfejsami analitycznymi. 7. Co będzie potrzebne do dokładnej oceny przed rozpoczęciem pracy. 8. Czy w cenę wchodzą: — staging; — responsywne QA; — wdrożenie produkcyjne; — poprawa błędów; — 7-dniowy okres naprawy błędów. Szablonowe odpowiedzi bez przeglądania wymagań i bez konkretnej oceny nie będą rozpatrywane. Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca rozpoczyna się po ograniczonym przeglądzie kodu i wdrażana jest przez staging.

TECHNICZNE ZADANIE Aktualizacja sklepu internetowego bp.ua O projekcie Funkcjonujący sklep internetowy z perfumami na OpenCart 2.x. Należy przenieść na OpenCart 4.x, zaktualizować design i funkcjonalność, zachować wszystkie dane, integracje i SEO. Strona jest dwujęzyczna (ukraiński + rosyjski). Szukamy wykonawcy (lub zespołu) do backendu i frontendu. Można zgłaszać się do jednej części lub do obu.Część 1. Backend (OpenCart 4)Migracja Rozwój czystego OpenCart 4.x (najbardziej stabilna gałąź), PHP 8.1+. Przeniesienie danych: produkty, kategorie, atrybuty, opcje, marki, klienci, zamówienia, opinie, strony treści. Zachowanie SEO-URL (przyjazne URL) jeden-do-jednego; mapa 301-przekierowań ze starych adresów. Nie ma bezpośredniej aktualizacji 2.x → 4.x: tylko czysty rozwój + kontrolowane przeniesienie.Integracja API z dostawcą (priorytet) Portowanie istniejącej niestandardowej modyfikacji wymiany z serwerem dostawcy (ceny + stany magazynowe). Automatyczna synchronizacja według harmonogramu (cron), log błędów, ręczne uruchamianie. Ukrywanie/status dla pozycji, których nie ma w magazynie. Wsparcie katalogu 2000+ pozycji.Moduły Nowa Poczta: wybór oddziałów/paczkomatów, automatyczne generowanie TTN z panelu administracyjnego. Płatność: podłączenie systemu płatności (LiqPay / Fondy / WayForPay — do uzgodnienia), płatność przy odbiorze. Checkout: logika serwerowa, zamówienie gościa, statusy, powiadomienia dla klienta. Masowy import/aktualizacja produktów z cennika (xlsx/csv), powiązanie zdjęć z artykułem/kodem kreskowym.Dwujęzyczność (uk / ru) Dwujęzyczny sklep: uk-UA (główny) i ru-RU. Dwujęzyczne pola produktów, kategorii, stron treści, meta-tagów. Osobne SEO-URL dla każdego języka, tagi hreflang, kanoniczne URL. 301-przekierowania ze starych URL obu języków (sprawdzić aktualny schemat: /ru/, subdomena czy parametr). Listy do kupującego — w języku sesji klienta.Blog Zachować istniejącą sekcję artykułów https://blog.bp.ua/. Przenieść istniejące artykuły (uk/ru) z zachowaniem URL i 301-przekierowaniami tam, gdzie to konieczne. Dwujęzyczność, poprawna SEO-znakowanie artykułów. Sekcja bloga ma pozostać edytowalna z panelu administracyjnego.SEO (serwerowe) Wymiana zewnętrznego modułu SEO na natywny mechanizm OC4. Generacja sitemap.xml (osobne gałęzie językowe), poprawny robots.txt. Mikroznakowanie Schema.org (Produkt, Oferta, BreadcrumbList, Artykuł dla bloga).Wydajność i bezpieczeństwo Cache (OPcache + wbudowany OC4), optymalizacja zapytań, gzip/brotli, HTTP/2. Obrazy: WebP, zmiana rozmiaru z cache. HTTPS, 2FA w panelu administracyjnym, aktualne poprawki, codzienne kopie zapasowe. Core Web Vitals w „zielonej” strefie na urządzeniach mobilnych.Porządek prac Wszystkie prace prowadzone są na staging. Stara strona działa do pełnego przetestowania nowej. Przełączenie na produkcję — z możliwością cofnięcia przez 30 dni. Część 2. Frontend (design + kodowanie)Design Styl: minimalistyczny, premium, dużo „powietrza”, akcent na zdjęcia produktu. Podejście mobile-first (większość ruchu — mobilny). System designu w Figma: paleta, typografia, komponenty, stany. Makiety kluczowych ekranów (desktop + mobilny): strona główna, katalog, karta produktu, strona marki, koszyk, checkout, wyszukiwanie, blog i strona artykułu.Kodowanie Semantyczny HTML5, czysty CSS, responsywny (mobile-first). Integracja w szablonach twig OpenCart 4 (nie statyczne), praca z danymi na żywo. Obrazy: WebP, lazy-load, srcset. Czcionka z pełną cyrylicą (uk/ru). Cross-browser: Chrome, Safari, Firefox, Edge + iOS/Android. Core Web Vitals: LCP < 2.5 s, CLS < 0.1, INP < 200 ms (mobilny).Funkcjonalność interfejsu Filtry fasetowe katalogu: marka, typ, objętość, nuta, płeć, cena. Karta produktu: zdjęcie, opis, nuty, format/objętość, opinie, „kupują z tym”. Szybki podgląd, lista życzeń, porównanie, etykiety (nowość, hit, limitowana ilość). Responsywny checkout z minimalną liczbą kroków, automatyczne uzupełnianie dla Nowej Poczty. Sekcja bloga: lista artykułów i strona artykułu w stylu strony.Dwujęzyczność (uk / ru) Przełącznik języków w nagłówku, poprawny na urządzeniach mobilnych. Kodowanie uwzględnia różną długość linii w dwóch językach. Cały tekst tematu — przez zmienne językowe OC4 (bez „wbudowanego” tekstu). Przyjęcie i współpracaCo przekazać na zakończenie Backend: dostępy (serwer, Baza Danych, panel administracyjny, repozytorium), krótka dokumentacja dotycząca modyfikacji i cron, instrukcja dotycząca wdrożenia/rollbacku, lista zewnętrznych modułów. Frontend: plik Figma z systemem designu i ekranami, kod tematu (twig + CSS/JS), instrukcja zmiany banerów/treści.Kryteria przyjęcia (krótko)

https://www.figma.com/design/bSzGOmDb3scdsBgjR3hHLb/Robo?node-id=0-1&p=f https://robo.org.ua/index.php?route=product/product&path=145802278&product_id=237 Zadanie: redesign strony produktu i recenzji na stronie głównej Strona została już opracowana i działa w pełni. Projektant przygotował nowy projekt w Figma, który należy wdrożyć na istniejącej stronie. Wymagane: zrealizować nowy projekt zgodnie z makietą; zintegrować go z aktualną stroną; zaadaptować strony do urządzeń mobilnych, tabletów i komputerów; sprawdzić poprawne działanie przycisków, formularzy, menu i innych elementów; zapewnić maksymalną zgodność z makietą. Nie ma potrzeby tworzenia strony od zera — należy jedynie wykonać redesign i zastąpić aktualny wygląd nowym.

Wirus obecnie infiltrował stronę internetową. Strona nie działa prawidłowo. W szczególności główna strona nie działa poprawnie. Potrzebujemy dewelopera, który może naprawić ten błąd tak szybko, jak to możliwe.

Jest lejek sprzedażowy dla sklepu internetowego, który chcemy powtórzyć u siebie Wygląda on tak Główna strona (produkt, który jest główny w sprzedaży, na przykład koszula) Potem strona checkout (gdzie osoba wprowadza swoje dane i wybiera, ile na przykład koszul chce kupić) Następnie przechodzi dalej w lejek i oferowane są dodatkowe sprzedaże 1 (skarpetki) + potem dodatkowa sprzedaż 2 (majtki) i na końcu strona dziękuję Jak to powinno działać w kwestii przejść między stronami i logiki, możesz zobaczyć tutaj (trzeba dojść do końca do strony dziękuję) https://3plus3.heroman.com.ua/standard/ Mamy przykłady stron, które chcemy zrobić u siebie To znaczy, dla nas w zasadzie skopiujemy design - zrealizujemy - wypełnimy pod nasz produkt Strony z dodatkowymi sprzedażami będą takie same pod względem designu i struktury jak na stronie, którą wysłałem powyżej (majtki) Nie musisz wypełniać stron informacjami, tylko zebrać szkielet - aby zgłoszenie przychodziło poprawnie Nie trzeba też wymyślać struktury stron Od Ciebie w zasadzie Skopiować i zrealizować Ustawić, aby technicznie działało poprawnie Pokazać, jak z tym pracować, abyśmy mogli to robić sami Są 2 konstruktorzy stron, które mamy na myśli, z jednym intensywnie pracujemy teraz i trzeba zrozumieć, czy można na nim coś takiego rozwinąć (ale czytałem w GPT, że można)