Naprawa wtyczki (WordPress, używany Elementor)

To niedopracowana wtyczka do After Effects: https://drive.google.com/drive/u/0/folders/1Nq9a672OK6ep9Com1lqelUhZxbx3_3f1 to, jeśli dobrze rozumiem, wtyczka CEP (Adobe Extension) do After Effects. To panel HTML/JavaScript przez Adobe CSXS, który współdziała z After Effects przez ExtendScript. Celem było zautomatyzowanie procesu tworzenia wideo w stylu "maze challenge", odniesienie na YouTube GOALRUSH-f8x lub analog. Wideo ręcznego montażu: https://drive.google.com/file/d/1Ylzvax6w2JGDwaBqeCdbD49jh5wB5buY/view?usp=sharing Plik jednego z projektów: https://drive.google.com/file/d/15vKd1L9VfHtDqK2wtLQdYEmDpH1d8Jvy/view?usp=sharing Oprócz "bugowatości" systemu przez vibe coding (dlatego vibe coderzy odpadają), nie odpowiadały takie szczegóły (rzeczywiste poprawki): https://docs.google.com/spreadsheets/d/18Svc6GoQ34PgLe1HY7gNX5tPLH0Cpv9E4mfjCRBCMFU/edit?gid=0#gid=0 Trzeba stworzyć system, który będzie generował projekty w After Effects ze wszystkimi niezbędnymi komponentami wideo, które są opisane w Baza.pdf, bardziej szczegółowa logika w formie zdjęć, dokumentu tekstowego oraz mapy myśli dla zrozumienia wszystkich możliwych wariacji na dysku: https://drive.google.com/drive/folders/1Uf4Pnw3SKmwpmhL7sjPZFnfAbN0arUjr?usp=sharing Jeszcze bardziej szczegółowo (z bardziej rozwiniętą częścią opisową oraz linkami do timestampów w referencjach) tzw. będzie formułowane w roboczej przestrzeni projektu Końcowy rezultat to system, który tworzy wideo: od 40 sekund do 1 minuty, całkowicie unikalna treść przy każdym tworzeniu, bez metadanych AI w pliku wideo, w nim powinien być zrozumiały fabuła (pułapki, ślepe zaułki, różne emocje postaci-celebrytów w wyniku jakichś zwrotów akcji w wideo), dźwięk projektowy pod fabułę (krzyki i inne emocje, wybuchy itd.), stylistycznie nie różniące się od wideo referencyjnego z kanału

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.

Istnieje działająca platforma produkcyjna z katalogiem i automatycznym aktualizowaniem zewnętrznych ofert i cen. Stos technologiczny: — Node.js / TypeScript; — PostgreSQL; — istniejąca usługa odświeżania cen i cron; — oddzielny gotowy moduł walidacji i wyboru ofert w Pythonie; — staging i produkcja. Konieczne jest punktowe dopracowanie istniejącego pipeline'u odświeżania cen bez pełnego przepisywania backendu. OBOWIĄZKOWY ZAKRES 1. Integracja modułu Python — Moduł Python pozostaje oddzielnym komponentem; — zwraca zorganizowany wynik: oferty, wybrana oferta, statusy i flagi ryzyka; — Node.js waliduje wynik i wykonuje zapis w bazie danych; — przewidzieć obsługę błędów i częściowych/nieudanych uruchomień; — pipeline dziedziczony nie jest wyłączany do zakończenia QA. 2. Uruchomienie odświeżania według listy Dodaj uruchomienie: — po jednym slug/id; — po przekazanej liście slug/id. Możliwe CLI lub istniejące API serwisowe. Nowy interfejs użytkownika nie jest wymagany. 3. Tryb Shadow Nowe wyniki powinny być zapisywane oddzielnie i nie wpływać na produkcję do QA. Wymagane pola shadow: — cena; — ID wybranej oferty; — bezpośredni URL; — status oferty; — flagi ryzyka/QA; — checkedAt; — engineVersion. 4. Rozszerzenie istniejącej tabeli ofert Dodaj: — źródło; — external_offer_id; — last_seen_at; — last_checked_at; — engine_version; — flagi ryzyka lub przechowywanie w istniejącym JSON; — unikalne ograniczenie dla ochrony przed duplikatami. Nie jest wymagane tworzenie nowego równoległego systemu ofert, jeśli istniejącą tabelę można bezpiecznie rozszerzyć. 5. UPSERT, STALE i transakcja DB Zamień obecną schemę DELETE → CREATE: — UPSERT istniejących i nowych ofert; — oferty, które nie występują w pełnym udanym snapshot, są przekazywane do STALE; — w przypadku błędu API, częściowego wyniku lub niedokończonego snapshot aktywne oferty nie powinny stawać się STALE; — aktualizacja ofert, metadanych wybranej oferty i pól shadow według jednego modelu odbywa się w ramach jednej transakcji DB; — w przypadku błędu wykonywany jest pełny rollback. 6. Bezpieczne odświeżanie kanoniczne Odświeżanie cen nie powinno zmieniać: — marki; — referencji; — modelu; — kolekcji; — nazwy/tytułu; — slug; — opisów; — obrazów; — pól SEO. Aktualizowane są tylko oferta, cena i dane shadow. 7. Zachowanie obecnej logiki cron Zachować: — istniejący cron; — rolling batches; — cooldown; — sprawdzenie PRICE_REFRESH_MIN_DAYS przed wywołaniem zewnętrznego API; — dziedziczony pipeline produkcyjny do zakończenia Shadow QA. 8. Audyt wyników Wystarczy jedna opcja: — kolumna shadow w istniejącej tabeli administracyjnej; lub — eksport CSV. Minimalne dane: — model/referencja; — cena produkcyjna; — cena shadow; — delta; — URL produkcyjny/shadow; — status; — flagi ryzyka; — checkedAt; — engineVersion. Nowy skomplikowany dashboard nie jest wymagany. 9. Staging i QA — migracje DB; — wdrożenie staging; — test dymny na 5 przekazanych modelach; — następnie Tryb Shadow na około 50 modelach; — naprawa błędów technicznych wykrytych podczas tych uruchomień; — krótka dokumentacja kontraktu Python → Node.js i procedura rollback. OPCJONALNIE OCENIĆ ODDZIELNIE Prosta promocja techniczna bez nowego UI: — promocja jednego modelu po slug; — promocja listy slug; — przeniesienie potwierdzonych wartości shadow do produkcji; — techniczna weryfikacja po rollout. WYNIK — Pull Request; — migracje DB; — działająca integracja Python → Node.js; — Tryb Shadow; — UPSERT, STALE i transakcyjne aktualizacje; — uruchomienie po slug/id; — wdrożenie staging; — wyniki testu dymnego; — krótka dokumentacja; — nie mniej niż 7 dni na poprawki błędów w zrealizowanym zakresie po akceptacji. W ODPOWIEDZI WSKAZAĆ 1. Stała cena za obowiązkowy zakres. 2. Oddzielny koszt mechanizmu promocji. 3. Termin. 4. Ocena godzin. 5. Kiedy gotowi do rozpoczęcia. 6. Doświadczenie z transakcjami PostgreSQL, migracjami i pipeline'ami wczytywania. 7. Jakie pytania należy wyjaśnić przed rozpoczęciem. 8. Czy wliczone są staging, QA, migracje i okres naprawy błędów. Szablonowe odpowiedzi bez konkretnej oceny nie będą rozpatrywane. Dostęp do produkcji na pierwszym etapie nie jest udostępniany. Praca zaczyna się od ograniczonego przeglądu kodu i stagingu.

Dzień dobry, 1) zaktualizować jQuery** do aktualnej wersji (3.x) z podłączeniem jQuery Migrate 2) Dokładnie przetestować funkcjonalność aplikacji 3) i usunąć możliwe błędy, aby skrypty były ze sobą kompatybilne pod względem wersji tutaj trzeba całkowicie przepisać https://filtry.in.ua/assets/libs/libs.js pod nową wersję jQuery, ponieważ tam jest stary Bootstrap i wiele funkcji niestandardowych zapisanych

Opis: Należy stworzyć skrypt JavaScript do rozszerzenia Tampermonkey. Skrypt będzie działał w wewnętrznym systemie CRM.Logika działania: Skrypt ma odczytywać unikalny tekstowy ID bieżącego aktywnego dialogu na stronie (jest 5–10 różnych ID). W zależności od ID, skrypt pobiera odpowiednią tekstową instrukcję (System Prompt) z ustawień. Mapę parametrów po ID należy przenieść do osobnego wygodnego okna ustawień skryptu. Po pojawieniu się nowej wiadomości w oknie czatu, skrypt wysyła ten tekst wraz z promptem przez API OpenAI (model gpt-4o-mini). Otrzymaną odpowiedź skrypt wstawia w pole wprowadzania tekstu i inicjuje wysyłkę z losowym opóźnieniem od 20 do 45 sekund, aby zasymulować naturalną pracę operatora.Praca wyłącznie z tekstem. Budżet — 6000 zł. Czekam na oferty od programistów z doświadczeniem w pracy z OpenAI API oraz pisaniu skryptów automatyzacji przeglądarki.