Budżet: 100000 UAH Termin: 60 dni
Приветствую!
Описание проекта актуальное? Оставляли коментарий в "Обсуждение". Будем рады помочь.
Требуется создание крупного бизнес-портала на базе Drupal 8.
Портал должен включать в себя коммерческий каталог, доску объявлений, блог и раздел новостей и личный кабинет пользователя.
ВАЖНО:
Специалистов только по wordpress и joomla просьба не беспокоить!
Разница между этими CMS и Drupal 8 - как "между небом и землёй".
Поэтому, нужны люди хорошо знающие именно Drupal 8 версии.
ВОЗМОЖНОСТИ:
У пользователя должна быть возможность добавлять объявления на доску объявлений, а также при желании, возможность выбора премиум-функций (поднятие в топ, рекламирование на главной странице и т.д.), которые активируются после оплаты в liqpay или Приват24. Готовых модулей нет, нужно разрабатывать функции с нуля.
Аналогичные функции должны быть также для коммерческого каталога.
Должна быть реализована система личных сообщений между клиентами и продавцами с привязкой к конкретным объявлениям с уведомлениями на электронную почту. Уведомления (письма) должны поддерживать HTML формат.
Готовых модулей нет, нужно разрабатывать систему с нуля.
Должна быть реализована возможность добавления в избранное объявлений, с последующей возможностью просмотра их в личном кабинете.
Также должна быть возможность авторизации/регистрации с помощью facebook. Готовый модуль есть, требуется доработка.
Должна быть реализована рейтинговая система с возможностью голосования пользователями (система отзывов). Готовые модули есть, но требуются крупные доработки.
Верстка должна быть выполнена на Bootstrap 4 с полной (!!!) адаптированностью к мобильным устройствам и без ошибок при проверке в валидаторах. Макет имеется.
Плюс требуется реализация других мелких функций, поэтому умение разрабатывать свои модули под конкретные проекты - обязательно!
Также обязательно отличное знание Views и шаблонизатора Twig.
Выслушаю Ваши предложения по стоимости и срокам!
Рассматриваются как одиночные исполнители, так и группы разработчиков.
Budżet: 100000 UAH Termin: 60 dni
Приветствую!
Описание проекта актуальное? Оставляли коментарий в "Обсуждение". Будем рады помочь.
Budżet: 75000 UAH Termin: 25 dni
Здравствуйте! Имею 7 лет опыта разработки на Drupal. Выполню Вашу задачу в кратчайшие сроки с наилучшим качеством. Напишите мне , давайте обсудим детали.
Budżet: 75000 UAH Termin: 30 dni
Здравствуйте!
Готов разработать нужный вам сайт на Drupal 8.
Опыт работы с друпал 5лет
Цена и сроки указаны исходя текущий требований.
Budżet: 30000 UAH Termin: 45 dni
Здравствуйте, Вадим!
Хочу обсудить проект, который Вам нужен в деталях.
Мой опыт в сфере веб-разработок более 8 лет, более 200 проектов реализовано.
Знания Друпал с 6-й версии, программирую и верстаю
Один из последних ИМ на Друпал: ansaligy.com.ua
Портфолио: http://bit.ly/31Zmzcv
Буду рад сотрудничеству!
С уважением, Юрий!
Budżet: 50000 UAH Termin: 30 dni
Готов взяться за ваш сайт.
С Drupal работаю более восьми лет, делал сайты любой сложности.
Budżet: 125000 UAH Termin: 90 dni
Здравствуйте!
Ознакомился с Вашим заданием. Будем рады разработать Вам один из лучших бизнес порталов на рынке (с технической точки зрения).
Обращайтесь, обсудим все детали и приступим к работе.
Специалистов только по wordpress и joomla просьба не беспокоить!
Разница между этими CMS и Drupal 8 - как "между небом и землёй"
Тут Вы не правы. CMS все одинаковы. Расположение файлов только другие.
Если уже пошло, то я склонен относить Drupal больше к CMF, чем к CMS. Тем более с его тесной связью с symphony и особенностями архитектуры.
Разница между ними колоссальная.
Сам занимаюсь Drupal ещё с шестой версии, для 8 делал много модулей и разрабо́ток и знаю о чём говорю.
Про кривую обучения Drupal я вообще промолчу.
На ВордПресс сайт поднимет даже восьмиклассник, но для высоконагруженного портала с определёнными возможностями и способностью к масштабированию, он не подойдёт, а разбираться с архитектурой Drupal - нужны время и знания.
Сейчас просто загружен другими проектами, поэтому времени на разработку нет, могу только контролировать процесс и гарантировать нормальную оплату за труд.
Перед этим за проект уже бралась одна фирма, привыкшая штамповать сайты на ВордПресс и Джумле, спустя две недели отказались от работы. Никто из шести (!!!!!) разработчиков не сталкивался с разработкой модулей под Drupal, не знает про хуки, шаблонизатор twig и др.
Думали научиться в процессе работы над проектом, но увы... это не ВордПресс.
Drupal 8 - МАЗОХИЗМ в сичтом виде. Бросайте его!!)) Я бросил, не друпалю уже год, и не понимаю почему раньше не бросил. Теперь у меня Laravel здорового человека.
Здравствуйте, работаю только с друпал , опыт более 6ти лет. Делаю вёрстку сразу под друпал. Можем созвонится или может пообщаться в телеграмм или скайп?
я могу сделать 80% примерно проекта. Что нужно сделать по оплате увы не смогу. А так основное смогу качественно сделать. Много работаю с друпал 8.
по оплате я бы просто отдельно взял специалиста, кто круто в этом разбирается. Я со своей стороны сделаю сайт так, чтобы после меня смогу легко работать другой специалист.
Там где вы написали, готовых модулей нет, вообще-то под D8 есть, если не отдельные модули, то решения из нескольких.
Вы могли бы прислать более детальное ТЗ? Что бы определиться, смогу я такой проект сделать или нет.
Приятно читать и понимать, что есть настоящие фанаты и ценители Drupal!
Мы также команда, которая давно работает и может создать сложно арзитектурный проект. Прошу ознакомиться с нашим портфолио на drupal.org, чтобыпонимать, что мы мастера Drupal: https://www.drupal.org/golems-gabb
Пишите, нам будет интересно сделать крутой и сложный проект и выпить шампанского после успешного релиза на прод!
По вашему запросу более предметно:
1. Доска обьявлений - да, это будет кастомное решение, будет выводиться через views, чтобы меньше было кастомного кода. Также будет добавлена интергация с платежными системами. (модуль для liqpay) + кастомный модуль, который даст возможность выбирать и управлять премиум функциями.
2. Система личных сообщений - да, здесь нет стандартных Drupal модулей, интересный пункт) нужно будет искать качественные решения, нароботки должны быть, есть походие готовые модулт, ну да, необходимо будет немного его подшаманить)
3.Добавление в избранные - зависит от ключевого модуля, но можно использовать один из этих модулей:
https://www.drupal.org/project/commerce_wishlist
https://www.drupal.org/project/entity_wishlist
4. Регистрация facebook, кастомная доработка. Интересно услышать, что именно планируется доделать, что не покрывает контрибная часть модуля.
5. Голосование - мы мейнтейнеры Voting API модуля (https://www.drupal.org/project/votingapi), имели дело на практике с необходимым функционалом, и были проекты, где были более серьезные требования.
6. Bootstrap 4 - мы давно уже работаем с Bootstrap 4.х, также мы интегрировали некоторые элементы с Bootstrap 4 в Bootstrap 3. Мы всегда стараемся использовать все возможности Bootstrap "с коробки", а не писать кастомные стили. Ну конечно, все зависит от требований заказчика.
7. Мелкие модули - каждый день работаем над этим и развиваем Drupal community: https://www.drupal.org/golems-gabb
8. Views и шаблонизатор Twig - фундамент работы с Drupal!
Пишите, нам будет о чем поговорить) (Не пишу здесь цены, забанят)
Warm Regards
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.
Witam! Trzeba zrobić, aby na odpowiednich stronach, poniżej głównego tekstu, wyświetlał się link, który był wskazany w osobnym polu w panelu administracyjnym (na tej samej stronie) i sformatowany za pomocą CSS.
Konieczne jest dodanie 129 produktów. Jest plik z eksportem produktów, jednak standardowy import nie jest odpowiedni, ponieważ przed załadowaniem należy stworzyć strukturę katalogu: kategorie, działy i w razie potrzeby podkategorie. Następnie należy wykonać import produktów i sprawdzić, czy wszystkie karty zostały poprawnie przypisane do kategorii. Jeśli masz doświadczenie w realizacji podobnych zadań, prześlij przykłady prac, terminy realizacji i koszt.
CO TRZEBA ZROBIĆ Prace podzielone są na bloki, można zająć się wszystkim lub poszczególnymi blokami: Blok 1 — Optymalizacja prędkości (Mobile-First) Aktualna ocena mobilnej wersji PageSpeed — 51/100. Należy podnieść do 80+. Docelowe metryki: LCP < 2.5 s (obecnie 7.4 s), FCP < 1.8 s (obecnie 3.9 s), TBT < 200 ms. Prace: krytyczny CSS inline, opóźniony JS, WebP/AVIF, lazy load, audyt wtyczek. Blok 2 — GTM i analityka Usunąć hardcoded skrypty GA4/Google Ads z header.php. Zainstalować i skonfigurować wtyczkę GTM4WP. Wdrożyć Google Consent Mode v2 (skrypt lub cookie-banner). Blok 3 — Szablon karty produktu Jedyny Mobile-First szablon Single Product w Elementorze. Sticky przycisk „Kup” podczas przewijania na urządzeniach mobilnych. Cross-sell blok usług pod przyciskiem zakupu. Sprawdzenie automatycznego przesyłania zdarzeń view_item, add_to_cart przez GTM4WP. Blok 4 — Feed produktowy dla Google Merchant Center Zainstalować Product Feed Pro (AdTribes) lub CTX Feed. Skonfigurować XML-feed z poprawnym mapowaniem pól (id, title, gtin, brand, price, availability). Codzienne aktualizacje przez WP-Cron, automatyczne wykluczanie produktów „brak w magazynie”. Blok 5 — 6 stron docelowych (landingów) w Elementorze 3 strony e-commerce: katalog komponentów, gotowe rozwiązania UPS, zestawy SES. 3 strony lead generation: montaż UPS pod klucz, SES dla domu, rozwiązania dla biznesu. Istnieją szczegółowe prototypy ze strukturą i blokami każdej strony. Blok 6 — Formy i zdarzenia dataLayer 6 unikalnych zdarzeń dataLayer przy pomyślnym przesłaniu formularzy (CF7 i Elementor Pro Forms). Wymagania obowiązkowe dla wszystkich formularzy: maska wprowadzania telefonu, ochrona przed ponownym przesłaniem, reCAPTCHA v3 lub Honeypot. --- WYMAGANIA — Praktyczne doświadczenie z Elementor Pro (szablony Single Product, niestandardowe Page Templates) — Zrozumienie WooCommerce dataLayer i działania GTM4WP — Doświadczenie w optymalizacji prędkości WordPress (Critical CSS, WebP, WP Rocket lub analogiczne) — Doświadczenie w konfiguracji zdarzeń dataLayer dla CF7 lub Elementor Pro Forms — Portfolio lub przykłady podobnych prac — obowiązkowo Znajomość Google Consent Mode v2 będzie atutem. --- WARUNKI PRACY Strona na produkcyjnym hostingu — wszystkie zmiany tylko przez staging lub testowy duplikat. Jakakolwiek optymalizacja nie powinna naruszać inicjalizacji GTM i dynamicznego dataLayer. Szczegółowe wymagania zostaną przekazane po pierwszym kontakcie. Wynagrodzenie etapowe według bloków lub za cały projekt (dogadamy się) Napisz w odpowiedzi: 1. Twoje doświadczenie z podobnymi zadaniami (link lub krótki opis przypadku) 2. Czy jesteś gotów wykonać cały projekt czy poszczególne bloki 3. Orientacyjny koszt i terminy po zapoznaniu się z wymaganiami
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.