Доработка магазина на Prestashop

Skonfudowany serwis na CMS Joomla. Należy przywrócić dostęp do strony głównej, możliwa pomoc w przejściu na najnowszą wersję systemu zarządzania.

Dzień dobry. Szukam dewelopera do projektu TehnoVek / T-VEK. Potrzebuję stworzyć nie tylko ładną stronę lądowania, ale pierwszy techniczny etap przyszłego sklepu internetowego. Projekt: TehnoVek / T-VEK Domena: tehnovek.com.ua Format: sklep stacjonarny + strona + mini-katalog + przyszły sklep internetowy. Główna tematyka: elekroskutery, elektryczne trójkołowce, elektryczne rowery, motocykle, quady, części zamienne, akcesoria, serwis, dostawa, kredyt/rata. Potrzebne: WordPress + WooCommerce. Strona główna jako landing page. Katalog produktów. Kategorie produktów. Pierwsze produkty muszą być wprowadzone jako produkty WooCommerce, a nie jako proste bloki. Formularze zgłoszeniowe: dobór sprzętu; zapytanie o produkt; kredyt / rata; dostawa. Przyciski Telegram / Viber / WhatsApp. Linia wsparcia 0 800 108 100 w nagłówku, stopce i kluczowych blokach strony. Strony: elekroskutery; elektryczne trójkołowce; elektryczne rowery; motocykle i quady; części zamienne i akcesoria; serwis i wsparcie; kredyt i rata; dostawa w regionie; dostawa w Polsce; sklep stacjonarny; gwarancja; kontakty; blog. Podstawowe SEO. Adaptacja mobilna. Szybkie ładowanie. Podłączenie Google Analytics 4, Google Tag Manager, Meta Pixel, TikTok Pixel. Możliwość przyszłej integracji z CRM. Możliwość przyszłego podłączenia Google Merchant Center. Możliwość przyszłego AI-konsultanta. Możliwość skalowania do pełnoprawnego sklepu internetowego bez całkowitej przeróbki. Ważne: obecnie strona może wystartować jako landing page + mini-katalog, ale technicznie musi być zrobiona tak, aby po 3–6 miesiącach można było ją rozszerzyć do pełnego sklepu internetowego. Proszę odpowiedzieć konkretnie na punkty: Czy pracujecie z WordPress + WooCommerce? Czy możecie zrobić landing page, ale na bazie WooCommerce? Czy produkty będą wprowadzone jako produkty WooCommerce? Czy będzie można później dodać koszyk, płatność online i pełny katalog? Czy macie doświadczenie z sklepami internetowymi, a nie tylko z wizytówkami? Czy robiliście integrację formularzy z Telegramem, e-mailem lub CRM? Czy możecie przechowywać UTM-etykiety w zgłoszeniach? Czy możecie podłączyć GA4, Google Tag Manager, Meta Pixel i TikTok Pixel? Czy możecie zrobić podstawową strukturę SEO? Czy strona będzie szybka i dobrze działała na telefonie? Czy będzie można później podłączyć Google Merchant Center? Czy będzie można później podłączyć CRM, na przykład KeyCRM lub SalesDrive? Czy będę mógł sam dodawać produkty po uruchomieniu? Czy dacie krótką instrukcję, jak dodawać produkty i edytować strony? Czy będzie wsparcie techniczne po uruchomieniu? Jakie przykłady podobnych prac możecie pokazać? Jaki orientacyjny czas realizacji pierwszego etapu? Jaka orientacyjna cena pierwszego etapu? Co dokładnie wchodzi w tę cenę? Jak proponujecie podzielić pracę na etapy i płatność? Pytanie kontrolne: Jak technicznie zrobicie stronę teraz jako landing page + mini-katalog, aby później nie przerabiać jej od zera, a rozszerzyć do pełnoprawnego sklepu internetowego? Dla mnie ważne jest nie tylko „ładnie”, ale poprawnie zbudować fundament przyszłej platformy TehnoVek Commerce: strona, produkty, zgłoszenia, CRM, reklama, dostawa, kredyt/rata, analityka i dalsze skalowanie.

Potrzebne jest wdrożenie na stronach OpenCart (3 szt.) pełnoprawnego mechanizmu zarządzania zgodą na użycie plików cookie (Cookie Consent) oraz skonfigurowanie Google Consent Mode v2. Wymagane: zainstalowanie i skonfigurowanie CMP (Cookie Management Platform) lub innego rozwiązania do zarządzania zgodami użytkowników; wdrożenie pełnoprawnego banera Cookie Consent z możliwością akceptacji, odrzucenia oraz konfiguracji kategorii cookie; skonfigurowanie Google Consent Mode v2 za pośrednictwem Google Tag Manager; zapewnienie poprawnego przesyłania statusów zgody do Google Analytics 4, Google Ads, a także innych usług marketingowych; skonfigurowanie działania tagów analitycznych i reklamowych w taki sposób, aby uruchamiały się tylko zgodnie z uzyskanymi zgodami użytkownika. Obecnie baner cookie jest jedynie informacyjny i nie zarządza zgodami, a także nie przesyła ich statusu do usług Google. Potrzebne jest pełne skonfigurowanie zgodnie z aktualnymi wymaganiami GDPR oraz Google Consent Mode v2.

Potrzebny doświadczony programista OpenCart do przejęcia projektu i dalszego wsparcia Szukam doświadczonego programisty OpenCart (nie agencji), który profesjonalnie przejmie sklep internetowy od obecnego dewelopera i zajmie się jego wsparciem, rozwojem i optymalizacją SEO. O projekcie Sklep internetowy na OpenCart. Projekt gotowy w około 99% i sprawdzony zgodnie z wymaganiami technicznymi. Potrzebne jest przeprowadzenie niezależnego audytu technicznego przed ostatecznym przekazaniem strony. Po zakończeniu przekazania planowana jest długoterminowa współpraca przy rozwoju projektu. Podstawowe zadania Przeprowadzenie audytu kodu i struktury projektu. Sprawdzenie jakości realizacji funkcjonalności. Sprawdzenie zainstalowanych modułów, ich kompatybilności i poprawności działania. Ocena bezpieczeństwa i stabilności działania strony. Sprawdzenie wydajności i zaproponowanie rekomendacji dotyczących jej poprawy. Sprawdzenie zrealizowanej części SEO i zaproponowanie dalszego planu optymalizacji. Upewnienie się, że projekt jest w pełni gotowy do samodzielnego wsparcia bez zależności od poprzedniego dewelopera. Sprawdzenie poprawności przekazania wszystkich dostępów: kod źródłowy; baza danych; FTP; hosting; domena; e-mail; panel administracyjny; zainstalowane moduły i ich licencje. W razie potrzeby udział w komunikacji z obecnym deweloperem podczas przekazywania projektu. Przedstawić listę rekomendacji i uwag przed ostatecznym przyjęciem. Dalsza współpraca Po przyjęciu strony planowana jest regularna praca nad projektem: rozwój nowych funkcjonalności; optymalizacja SEO; poprawa wydajności; integracje z zewnętrznymi usługami; wsparcie techniczne. Wymagania dla kandydata Potrzebny specjalista, który: ma znaczące doświadczenie w pracy z OpenCart; dobrze zna architekturę OpenCart i popularne moduły; ma doświadczenie w audycie i wsparciu istniejących projektów; może argumentować jakość wykonanych prac; odpowiedzialnie podchodzi do ustaleń i przestrzega uzgodnionych terminów realizacji prac; jest zainteresowany długoterminową współpracą. W odpowiedzi proszę podać doświadczenie w pracy z OpenCart; przykłady zrealizowanych sklepów internetowych; czy przeprowadzałeś audyt lub przyjęcie cudzych projektów; orientacyjną cenę: audytu technicznego; udziału w przyjęciu projektu; wsparcia godzinowego lub projektowego po przekazaniu. Preferencje będą miały osoby, które mają wieloletnie doświadczenie w pracy z OpenCart, odpowiedzialnie podchodzą do swojej pracy, przestrzegają uzgodnionych terminów i są gotowe stać się technicznym partnerem projektu na długi czas.

Opracowanie architektury jednolitej platformy zarządzania flotą stron WordPressKontekst projektu Istnieje flota kilku dziesiątek stron WordPress, umieszczonych na jednym serwerze i obsługiwanych przez jeden zespół. Strony są stopniowo przekształcane w jednolity standard rozwoju i wsparcia — wspólny system projektowania z jednolitą biblioteką bloków (ACF + Gutenberg) oraz jednolitym standardem bezpieczeństwa. Wymagana jest architektura platformy do centralnego zarządzania tą flotą.Zadanie Potrzebne jest opracowanie technicznej architektury jednolitej platformy zarządzania flotą stron WordPress. Platforma to nie dashboard metryk, ale pełnoprawny system centralnego zarządzania i dostępu.Wymagania dotyczące platformy Jednolity dostęp dla super-administratora — jeden punkt dostępu do zarządzania wszystkimi stronami floty: przegląd stanu, wersji, statusu zgodności ze standardem. Dostęp jednym kliknięciem do panelu administracyjnego każdej strony — możliwość wejścia do wp-admin dowolnej strony floty z jednego interfejsu, bez przechowywania/wprowadzania haseł dla każdej strony osobno. Wymagana jest przemyślana mechanika uwierzytelniania (tokeny z ograniczonym czasem życia, powiązanie z konkretnym użytkownikiem, pełne logowanie dostępu). Rozgraniczenie ról: super-admin widzi i zarządza całą flotą; administratorzy poszczególnych stron mają dostęp tylko do swoich stron. Jednolity system projektowania z personalizacją na poziomie strony — wspólna biblioteka bloków (ACF + Gutenberg), dystrybuowana na wszystkie strony przez centralny mechanizm aktualizacji, ale z możliwością lokalnej personalizacji bloków pod konkretną stronę bez utraty kompatybilności z przyszłymi aktualizacjami biblioteki. Wspólny dashboard monitorowania i powiadomień — stan stron i serwera, alerty o awariach/problemach, status aktualizacji i zgodności każdej strony względem jednolitego standardu. Łatwe dodawanie nowych stron do sieci — platforma powinna wspierać szybkie klonowanie/rozszerzanie nowej strony na podstawie jednolitego standardu (plugin Core, system projektowania) i podłączenie jej do Hub z minimalną liczbą ręcznych kroków.Ograniczenia architektoniczne (ważne) WordPress Multisite nie jest brany pod uwagę i nie nadaje się do tego zadania. Powód nie leży w wygodzie interfejsu, ale w fundamentalnych właściwościach architektonicznych Multisite: Wspólna baza danych i wspólne jądro dla wszystkich stron sieci oznaczają jedną punkt awarii: nieprawidłowa aktualizacja pluginu lub jądra może jednocześnie wyłączyć wszystkie strony sieci, a nie tylko jedną. Wspólny zbiór zasobów serwerowych (pracownicy PHP, połączenia z bazą danych) oznacza, że anormalne obciążenie jednej strony (akcja, wzrost ruchu, atak) degraduje wydajność wszystkich pozostałych stron sieci, w tym tych, które nie są w żaden sposób związane z tym obciążeniem. To systemowe właściwości Multisite, które nie mogą być wyeliminowane przez proces lub dyscyplinę — dlatego wymagana jest architektura, w której każda strona pozostaje niezależną instalacją (własna baza danych), a unifikacja i centralne zarządzanie osiągane są innymi środkami.Wstępny kierunek architektoniczny Na chwilę obecną najbardziej obiecującym wydaje się podejście architektoniczne Hub & Spoke, w którym niezależne instalacje WordPress ("Spokes"), każda ze swoją bazą danych, są łączone: wspólnym dystrybuowanym pluginem Core (biblioteka bloków, podstawy bezpieczeństwa, moduł mostu do połączenia z Hub); centralną aplikacją zarządzającą ("Hub") — rejestr stron, logowanie jednym kliknięciem, monitorowanie, powiadomienia. Jednak ta architektura nie jest z góry wybranym rozwiązaniem. Jeśli wykonawca uważa, że istnieje bardziej odpowiednie podejście architektoniczne, może zaproponować alternatywę pod warunkiem jej uzasadnienia technicznego i ekonomicznego. Osobne zadanie w ramach specyfikacji — uzasadniona analiza i rekomendacja: budować Hub od podstaw customowo, czy wziąć za podstawę gotowe rozwiązanie self-hosted (MainWP, InfiniteWP, ManageWP lub analogiczne) i rozszerzać je pod specyficzne wymagania (integracja z pluginem Core, śledzenie zgodności wersji bloków, przyszła warstwa marketingowa). Potrzebna jest porównawcza ocena pod względem czasu, kosztów wsparcia, elastyczności i ograniczeń każdego wariantu, z wyraźną rekomendacją.Wymagania architektoniczne Podczas projektowania rozwiązania należy uwzględnić następujące wymagania niefunkcjonalne: odporność na awarie i brak jednego punktu awarii dla floty stron; możliwość niezależnej aktualizacji, przywracania i konserwacji każdej strony; minimalizacja blast radius przy awariach i błędach aktualizacji; możliwość poziomego skalowania przy wzroście liczby stron; bezpieczeństwo centralnego zarządzania i delegowanego dostępu; możliwość późniejszego wydzielenia Hub w osobną infrastrukturę bez zmiany zasad architektonicznych; rozszerzalność platformy do dodawania nowych centralnych usług. Ponadto architektura powinna pozostawać żywotna przy zwiększeniu liczby stron z kilku dziesiątek do 100+ bez konieczności zasadniczej rewizji wybranego podejścia.Długoterminowy rozwój platformy Platforma jest postrzegana jako długoterminowa podstawa cyfrowego ekosystemu firmy, a nie jako narzędzie wyłącznie do administracji stronami WordPress. Podczas projektowania należy przewidzieć możliwość późniejszego dodawania centralnych usług (np. zarządzanie aktywnościami marketingowymi, analityka, biblioteka komponentów, integracje i inne moduły) bez konieczności przerabiania podstawowej architektury.Technologie Konkretny stos technologiczny nie jest ustalany z góry — wykonawca samodzielnie proponuje i uzasadnia technologie w dokumencie architektonicznym (język/framework dla Hub, model hostingu/deployu, mechanizm uwierzytelniania itd.), w oparciu o wymagania zadania. Uzasadniona propozycja technologii jest obowiązkową częścią wyniku pracy, na równi z porównaniem custom vs gotowe rozwiązanie dla Hub.Co potrzebne od wykonawcy Doświadczenie w projektowaniu architektur multi-site/multi-tenant na WordPress (zasadniczo — NIE na bazie Multisite) Praktyczne doświadczenie w pracy z MainWP/InfiniteWP/ManageWP lub podobnymi systemami zarządzania flotą stron WP — zrozumienie ich możliwości i ograniczeń na poziomie API/rozszerzalności Doświadczenie w tworzeniu pluginów WordPress na poziomie produkcyjnym (ACF, rozwój bloków Gutenberg, REST API) Zrozumienie kwestii bezpieczeństwa przy budowie systemów centralnego/delegowanego dostępu (uwierzytelnianie oparte na tokenach, audyt dostępu, minimalizacja blast radius) Umiejętność przygotowania dokumentacji architektonicznej: diagramy, kontrakty API między Hub a stronami, schemat danychFormat pracy Pierwszy etap — dokument architektoniczny z uzasadnionym rozwiązaniem (custom vs gotowe rozwiązanie), schemat interakcji komponentów, kontrakt API Hub ↔ plugin Core, plan etapowej realizacji. Dokument powinien zawierać schemat wireframe interfejsu platformy (kluczowe ekrany: rejestr stron, dostęp do panelu administracyjnego, dashboard monitorowania). Po zatwierdzeniu architektury — możliwe jest kontynuowanie współpracy. Ważna uwaga Oczekuje się samodzielnego opracowania architektury, opartego na praktycznym doświadczeniu projektowania i eksploatacji podobnych systemów. Nie wystarczy dostarczyć kompilacji ogólnych rekomendacji lub typowych odpowiedzi, wygenerowanych przez AI. Każde kluczowe rozwiązanie architektoniczne powinno być poparte uzasadnieniem technicznym: dlaczego wybrano właśnie to podejście, jakie alternatywy były rozważane, jakie są jego zalety, ograniczenia i potencjalne ryzyka w kontekście tego projektu. W razie potrzeby wykonawca powinien odwoływać się do praktycznego doświadczenia, istniejących rozwiązań, dokumentacji, projektów open-source lub innych źródeł, które potwierdzają żywotność proponowanych rozwiązań architektonicznych.