Budżet: 500 USD Termin: 4 dni
Witam! Twoje zadanie to klasyczny przypadek dla dewelopera Shopify, który pracuje z Custom Product Builders. Doskonale rozumiem problem: Shopify domyślnie próbuje wyświetlić wszystkie właściwości i atrybuty systemowe, co zamienia koszyk w „techniczny dziennik” zamiast schludnego rachunku. Specjalizuję się w niestandardowych rozwiązaniach dla Shopify i głębokiej konfiguracji Liquid/JS (30+ udanych przypadków). Realizuję „czysty” przepływ w stylu Photowall, zachowując jednocześnie Twoją logikę obliczania ceny. 🛠 Mój plan rozwiązania zadania 1. Wizualne oczyszczenie (Koszyk i Szuflada) * Filtrowanie Właściwości Elementów Linii: W pliku main-cart-items.liquid (lub podobnym w Twoim motywie) skonfiguruję pętlę wyświetlania właściwości tak, aby ukrywać techniczne klucze (zaczynające się od _), pozostawiając tylko zrozumiałe dla klienta: Rozmiar, Konfiguracja. * Ukrycie ilości: Jeśli Twój kalkulator przekazuje powierzchnię lub objętość w polu quantity, zamienię wyświetlanie tej liczby na „1 szt.” lub całkowicie ukryję linię ilości przez CSS/Liquid, aby klient widział tylko finalny niestandardowy produkt. 2. Praca z Checkout (Ograniczenia i rozwiązania) * Shopify Plus: Jeśli masz plan Plus, edytuję checkout.liquid dla pełnej personalizacji. * Basic/Advanced: Jeśli plan jest standardowy, dostęp do pól checkout jest ograniczony. W takim przypadku zastosuję technikę „opakowania” danych w nazwę produktu lub użycie ukrytych atrybutów, które Shopify poprawnie wyświetla w rachunku bez zbędnego bałaganu. 3. Wielowalutowość (RON / MDL) * Logika Waluty: Skonfiguruję Twój kalkulator JS tak, aby pobierał aktualny Shopify.currency.active (lub obiekt Cart). * Synchronizacja Cen: Zrealizuję przeliczenie ceny w czasie rzeczywistym. Jeśli cena w kalkulatorze jest stała (Hardcoded), powiążę ją z współczynnikiem konwersji sklepu, aby w Checkout kwota w lejach (MDL) była matematycznie poprawna w odniesieniu do rumuńskiego leja (RON). 📋 Etapy i Terminy * Audyt aktualnego kodu JS kalkulatora: 1 dzień roboczy. * Oczyszczenie koszyka i mini-koszyka (Liquid + CSS): 1–2 dni. * Konfiguracja wielowalutowości i logiki MDL: 1–2 dni. * Testowanie przepływu (od wyboru do płatności): 1 dzień. * Całkowity czas: 4–6 dni roboczych. 💰 Orientacyjny koszt Koszt realizacji „pod klucz” z uwzględnieniem wielowalutowości: 450 – 750 USD. Dlaczego ja: Mam doświadczenie w pracy z sklepami z tapetami i niestandardowymi zasłonami na Shopify, gdzie cena zależy od wprowadzanych rozmiarów ($/m²). Wiem, jak „oszukać” standardową logikę Shopify, aby nie wyświetlała parametrów technicznych w potwierdzeniu zamówienia. Bonus: Bezpłatnie sprawdzę Twoją stronę pod kątem Mobile UX, ponieważ na mobilnych
Budżet: 700 USD Termin: 7 dni
Dzień dobry
Nazywam się Dmitro, firma King Kong Lab. Mamy doświadczenie w pracy z Shopify, w tym z niestandardowymi kalkulatorami, właściwościami pozycji zamówienia i modyfikacjami koszyka/checkout bez naruszania istniejącej logiki.
Możemy starannie rozwiązać Twoje zadanie:
oczyścić koszyk i checkout z niepotrzebnych elementów technicznych
zostawić tylko potrzebne dane (konfiguracja, rozmiary, cena końcowa)
zrobić zrozumiały i czysty wynik jak w Photowall
sprawdzić przesył danych i nie złamać aktualnej logiki kalkulatora
Również skonfigurujemy poprawne działanie z drugą walutą (MDL), aby cena z kalkulatora całkowicie zgadzała się z checkout w zależności od waluty.
Pracujemy ostrożnie z Liquid i ograniczeniami Shopify, bez "kółek ratunkowych", aby wszystko pozostało stabilne i skalowalne.
Jesteśmy gotowi przejrzeć Twój projekt i szybko wprowadzić poprawki.
Budżet: 400 USD Termin: 4 dni
Cześć!
Jestem gotów dokończyć Twój projekt Shopify i starannie doprowadzić koszyk oraz checkout do czystego i zrozumiałego wyglądu bez utraty obecnej logiki kalkulatora.
Doświadczenie
Shopify (Liquid, ograniczenia koszyka, checkout)
Kustomne kalkulatory i logika konfiguratora
Praca z właściwościami pozycji / niestandardowe ceny
Czyszczenie i dostosowywanie interfejsu koszyka
Wielowalutowość (Shopify Markets / synchronizacja walut)
Co zrobię
Czyszczenie koszyka / checkout
ukryję zbędne elementy:
ilość wierszy (np. “221 artykułów”)
techniczne właściwości pozycji
usunę wyświetlanie “Dimensiuni personalizate” jako oddzielnego wiersza
zostawię tylko:
rozmiary z kalkulatora
ostateczną cenę
wybraną konfigurację (podgląd/pozycja)
Zrobię staranny wyświetlacz danych (zgodnie z UX jak w Photowall)
Praca z danymi
sprawdzę przesyłanie danych przez właściwości pozycji
w razie potrzeby zoptymalizuję strukturę (aby techniczne pola nie były “widoczne”)
zapewnię poprawne wyświetlanie bez utraty logiki obliczeń
Wielowalutowość (RON → MDL)
ustawię poprawne działanie drugiej waluty
zsynchronizuję:
cenę kalkulatora
cenę w koszyku / checkout
wykluczę rozbieżności przy konwersji
Podejście
Analiza obecnej realizacji (JS + Liquid)
Czyszczenie wyświetlania koszyka
Korekta struktury właściwości pozycji
Sprawdzenie checkout (z uwzględnieniem ograniczeń Shopify)
Ustawienie walut i testowanie
Ostateczne wygładzenie UI
Ważne
Rozumiem ograniczenia checkout Shopify (szczególnie bez Plus), dlatego:
robię maksimum przez koszyk + Liquid + JS
bez łamania obecnego kalkulatora
starannie, bez wpływu na płatności i zamówienia
Ocena
Czas: 2–5 dni
Wynik
✔ Czysty i zrozumiały koszyk
✔ Poprawne wyświetlanie konfiguracji
✔ Synchronizacja cen między walutami
✔ Stabilna praca bez błędów
Jestem gotów zobaczyć obecną realizację i szybko wprowadzić poprawki
Z poważaniem,
Oferty ukryte
Aktualnie brak ofert
Aktualne zlecenia dla freelancerów w kategorii Javascript & Typescript
Strona działa na frameworku Next.js (opartym na React). Trzeba zrealizować wszystkie punkty zgodnie z TŻ. TŻ jest dołączone w pliku. Oczekuję na propozycje.
Strona do oceny: https://copy.eurobrands-shop.de/ Zadanie: naprawić błędy frontendowe na poziomie motywu Magento 2 / motyw Amasty: CSS/LESS/JS, mobilny, RTL, minicart, rozwijane menu językowe, przesunięcie układu/CLS. Format pracy: - bez lokalnego uruchamiania Magento; - praca przez DevTools + źródła motywu; - poprawki w plikach CSS/LESS/JS/template motywu; - wynik: diff / commit / archiwum zmienionych plików; - wdrożenie i budowa po naszej stronie; - praca przez bezpieczną transakcję; - NDA do przekazania źródeł/dostępów. Co należy sprawdzić i ocenić: 1. RTL / wersja arabska: - telefon w nagłówku wyświetla się niepoprawnie; - przesunięcia elementów w nagłówku, minicart, wishlist/konto, strona produktu; - marginesy, kierunek, unicode-bidi, pozycjonowanie. 2. Nagłówek: - rozwijane menu językowe; - koszyk/wishlist; - obszar kliknięcia ikon. 3. Minicart: - niestabilnie otwiera się na niektórych stronach; - sprawdzić Konsolę / Sieć / Nasłuchiwacze zdarzeń / dane klienta / z-index / nakładkę. 4. Mobilny: - etykiety koszyka/wishlist są zbyt duże; - blok Kategorii jest ściśnięty/obcięty; - mobilne menu / Menu-Konto. 5. Strona produktu: - przesunięcie układu / CLS obrazów; - Dodaj do koszyka / Ilość / BOX / PALLET w RTL. 6. Wishlist/konto: - /wishlist/ - /mwishlist/ - zakładki, przycisk Wstecz, przepełnienie liczników. Problemowe URL: - https://copy.eurobrands-shop.de/alpro - https://copy.eurobrands-shop.de/producers - https://copy.eurobrands-shop.de/wishlist/ - https://copy.eurobrands-shop.de/mwishlist/ W odpowiedzi napisz: 1. Czy masz doświadczenie z frontendem Magento 2? 2. Czy masz doświadczenie z RTL? 3. Ile godzin potrzebujesz na pierwszy etap? 4. Jaka jest cena? 5. Kiedy możesz zacząć? 6. Jakie dostępności są potrzebne? 7. Czy jesteś gotów pracować przez bezpieczną transakcję i podpisać NDA? Ważne: potrzebny jest konkretny wynik — poprawki lub techniczne wyjaśnienie dla każdego punktu: naprawione / nie reprodukuje się / nie jest problemem frontendowym.
Opis zamówienia: Poszukujemy doświadczonego frontend-dewelopera/specjalisty od OpenCart do optymalizacji szybkości ładowania strony (kategorie i karty produktów) zgodnie z wymaganiami Google Core Web Vitals. O projekcie: * CMS: OpenCart. * Specyfika: Strona działa w trybie katalogu (brak koszyka i składania zamówienia). * Zakres: 2900 pozycji. * Część serwerowa: Już zoptymalizowana (działa na OpenLiteSpeed). * Stos: Prace prowadzone są wyłącznie z kodem szablonu, modyfikatorami i frontendem. Bez pracy z bazą danych. Co należy zrobić (Zadanie techniczne): 1. Opóźnione ładowanie skryptów (Delay JS): * Problem: Zewnętrzne skrypty analityczne (GTM, Google Tag) blokują główny strumień na urządzeniach mobilnych przez około 4,3 sekundy. * Zadanie: Skonfigurować opóźnione uruchamianie tych skryptów. Skrypty powinny aktywować się ściśle po pierwszej akcji użytkownika (pierwsze przewinięcie, dotknięcie ekranu lub ruch myszą). * Ważne: Zbieranie statystyk, analityka i działanie reklamy muszą pozostać w pełnym zakresie. 2. Poprawa metryki CLS (Stabilność układu): * Problem: Strona "skacze" i przesuwa się podczas ładowania obrazków. * Zadanie: W plikach stylów lub szablonu motywu sztywno wpisać atrybuty HTML width i height dla wszystkich obrazów produktów w katalogu (listach) oraz kartach produktów. * Cel: Zarezerwować miejsce pod obrazki w drzewie DOM do ich faktycznego załadowania, aby uniemożliwić przesunięcie treści. Sprawdzić, aby responsywność (CSS) nie została uszkodzona. 3. Optymalizacja krytycznej ścieżki (LCP): * Zadanie: Wpisać dla głównego (najważniejszego) obrazu produktu na pierwszym ekranie tag fetchpriority="high". To da przeglądarce polecenie ładowania głównego zdjęcia produktu w priorytetowy sposób. Wymagania wobec wykonawcy i warunki przyjęcia: 1. Bez zbędnych modułów: Praca wykonywana jest czystym kodem/modyfikatorami, bez instalowania dodatkowych zewnętrznych lub płatnych wtyczek optymalizacyjnych. 2. Bezpieczeństwo i układ: Ponosisz pełną odpowiedzialność za układ. Po wprowadzeniu poprawek wizualne wyświetlanie strony na urządzeniach mobilnych i PC, a także funkcjonalność (filtry, przełączanie zdjęć w galerii, menu) muszą pozostać bez zmian. 3. Kryterium oddania pracy (DoD): Przedstawienie zrzutu ekranu oraz linku do żywego testu raportu Google PageSpeed Insights (dla wersji mobilnej). Wskaźnik wydajności nie może być niższy niż 75 punktów, a metryka CLS — nie więcej niż 0,1 (w zielonej strefie). Poprawki wprowadzać należy wyłącznie przez modyfikatory (OCMOD) lub kopię motywu, aby nie nadpisać aktualizacji jądra. W odpowiedzi proszę podać: 1. Czy miałeś doświadczenie w konfiguracji Delay JS właśnie dla GTM na OpenCart? 2. Termin realizacji zadania. 3. Koszt pracy.
Pełne szczegóły prześlemy w wiadomościach prywatnych Cel Maksymalne przyspieszenie ładowania strony, szczególnie na urządzeniach mobilnych. KPI (obowiązkowe) Po zakończeniu prac należy osiągnąć następujące wskaźniki. Mobile Performance 90+ LCP mniej niż 2.2 sek INP mniej niż 200 ms CLS mniej niż 0.1 TBT mniej niż 200 ms Desktop Performance 95+ Co należy zrobić 1. Pełny audyt strony 2. Optymalizacja obrazów 3. CSS 4. JavaScript 5. Caching 6. Serwer 7. CDN 8. WordPress 9. Baza danych 10. Czcionki 11. WooCommerce 12. Wtyczki 13. Core Web Vitals 14. naprawić przekierowanie HTTPS
To jest roboczy, czysto zaprojektowany projekt na Odoo 19 Community — CRM dla ukraińskiego hotelu, już w infrastrukturze produkcyjnej. Nie planujemy przepisywać od zera. Szukamy jednej osoby, która przejmie projekt, zachowa działające i poprowadzi go dalej: najpierw CRM → potem HMS → księgowość. To długoterminowa współpraca, nie jednorazowe zadanie. Kogo szukamy Seniora w Odoo 19 CE — inheritance-only (_inherit, _inherits, xpath), OCA-first, bez hacków core, czyste granice modułów. Realny praktyk Claude Code w rozwoju. Umie rozwijać cudzy kod, a nie refleksyjnie przepisywać. Stos technologiczny Odoo 19 Community + OCA · PostgreSQL 16 · Docker · Hetzner + Coolify · GitHub Actions CI/CD · pre-commit (ruff, pylint-odoo) · ADR w MADR · JSON-2 (nie XML-RPC) · Standalone Owl, gdy standardowe widgety są niewystarczające. Rozwój wspomagany AI — to norma pracy, a nie dodatek. Zakres prac: 1 zadanie: przeprowadzić analizę aktualnego stanu projektu 2 zadanie: sporządzić plan poprawy 3 zadanie: dopracować blok CRM i uruchomić w pracy Jak aplikować Opisz jeden realny projekt, który przejąłeś (cudzy kod) i rozwijałeś w produkcji. Jak rozszerzałeś, nie dotykając core? Twój workflow Claude Code w Odoo — konkretnie. Jakie moduły OCA rzeczywiście używałeś/kontrybuowałeś dla v18/v19 — wymień. Jeden przypadek, gdzie wybrałeś Studio/config lub OCA zamiast custom, i jeden — gdzie odwrotnie poprawnie poszedłeś w custom. Nie zgłaszaj się, jeśli Jesteś agencją/zespółem-przedsprzedawcą · pierwszy instynkt „przepisać od zera” · Odoo tylko ≤ v16 lub teoretycznie · Claude Code „nauczę się w trakcie” · Warunki Start — płatny test (mały, realny) → długoterminowa współpraca Start: już Projekt zorganizowany: udokumentowana architektura, ADR, CI/CD, czysta historia git. Dziedziczysz porządek, nie chaos.