В модулі OpenCart пофіксити проблеми з Facebook API

Бюджет: 1400 UAH Термін: 1 день

Вітаю! Готовий розпочати роботу прямо зараз.
Чітко розумію задачу і маю успішний досвід у реалізації саме таких проєктів (приклади є у відгуках). Виконаю завдання сьогодні, швидко та без зайвих питань.
Давайте обговоримо деталі та стартуємо! 🚀

Бюджет: 700 UAH Термін: 1 день

Привіт! Можу розпочати роботу вже завтра о 10:00, очікую завершити проблему протягом 48 годин. Дякую за довіру.

Бюджет: 5000 UAH Термін: 2 дні

Вітаю, Володимире!

Ознайомився з описом та вашим Google-документом. Задача зрозуміла: потрібно зупинити лавиноподібний ріст API-запитів і прибрати помилки gr:get:InvalidID при відкритті сторінки модуля.

З OpenCart та інтеграцією Facebook Graph API / Webhooks працюю давно. Симптом вказує на зацикленість (нескінченний polling або некоректний рендер/рекурсія), коли скрипт намагається опитати застарілі чи невалідні ID об'єктів без умови зупинки. Також поправлю вивід ніку й підписників (імовірно, через зміни у версіях API).

⚡ Коли можу почати: Готовий приступити до роботи сьогодні / найближчим часом.

⏱ Скільки часу потрібно: * 1-й день: Локалізація проблеми, аналіз запитів і логів модуля, пошук точки зациклення.

2-й день: Фікс, додавання валідації ID перед відправкою, тестування стабільності API.

Загалом на роботу: 1–2 дні.

Для старту знадобляться доступи до адмінки (тестового стенду) та FTP/SFTP. Буду радий допомогти, пишіть у приватні повідомлення! Розгорнути

Бюджет: 1800 UAH Термін: 2 дні

Доброго дня! Почати можу сьогодні. Картина знайома: при відкритті сторінки модуля фронт стартує цикл синхронізації й починає сипати запитами в Graph API — або це періодичний polling, що не зупиняється, або перебір товарів, де частина не має валідного facebook-айді в каталозі, і кожен такий товар повертає gr:get:InvalidID. Помилки множаться, бо запит повторюється на кожен рендер/інтервал.

План: спершу подивлюсь логи модуля й мережеві запити на сторінці (звідки і з якою періодичністю летять виклики), знайду точку ініціалізації — це майже завжди невдалий setInterval/рекурсія або синхронізація без перевірки, чи існує FB-ID. Далі ставлю guard, прибираю зайві повтори, кешую відповіді й коректно маплю/пропускаю товари без валідного ID, щоб InvalidID не генерувався взагалі. ТЗ із Google-доку перегляну перед стартом.

Орієнтовно: діагностика й локалізація — у день старту, фікс і перевірка стабільності запитів — ще 1 день. Питання: дасте доступ до тестового стенду (адмінка + лог-файли модуля), чи правите на бойовому? І яка версія OpenCart — 3.x чи 4.x?

Бюджет: 1800 UAH Термін: 1 день

Вітаю, можу взятись за діагностику і фікс OpenCart інтеграції з Facebook/Instagram, зазвичай такі проблеми виникають через некоректні цикли запитів у модулі (авторекурсія, дубль OAuth викликів або неправильна обробка Webhook/ID параметрів), перевірю логи, місце ініціалізації API викликів і причину росту gr:get:InvalidID, після чого пофікшу джерело запитів і стабілізую інтеграцію без зайвих звернень до API.

Бюджет: 1700 UAH Термін: 3 дні

Доброго дня! Готовий почати сьогодні. OpenCart модуль інтеграції Facebook/Instagram: знайду причину лавинного росту API-запитів і помилок gr:get:InvalidID, додам логування/тести, виправлю цикл/неправильні ID і перевірю webhook/OAuth.
Термін: 3 дні.

Бюджет: 1700 UAH Термін: 2 дні

Доброго дня. Завдання зрозумів: у модулі інтеграції OpenCart з Facebook та Instagram через API, OAuth і Webhook після відкриття сторінки модуля починає лавиноподібно рости кількість запитів до Facebook і збільшується кількість помилок gr:get:InvalidID. Треба знайти причину і пофіксити.

З OpenCart і інтеграціями через API працюю давно, тому загальний механізм такої проблеми мені знайомий. Симптом, коли запити починають множитися саме при відкритті сторінки модуля, зазвичай означає або цикл повторних викликів при завантаженні сторінки (повторний рефреш токена чи опитування в циклі без умови зупинки), або невалідний обʼєкт чи ID, що передається у Facebook Graph API і викликає InvalidID, після чого логіка повторює запит знову і знову. Перевірю, що саме тригериться при відкритті модуля, як формуються ID у запитах до Graph API, і де відсутня зупинка або кешування, щоб прибрати зайві виклики і самі помилки.

Подивлюся ваше детальне ТЗ зі скріншотами в Google-доку, щоб звʼязати помилки з конкретним місцем у коді модуля. Почати можу найближчим часом. По строку: спершу треба відкрити документ і подивитися код модуля, щоб назвати точно, але за досвідом подібний фікс це орієнтовно кілька днів, де більша частина часу це локалізація причини, а сам фікс зазвичай невеликий.

Дайте, будь ласка, доступ до коду модуля і середовища, де відтворюється проблема. Це самописний модуль чи готовий з маркету?

Бюджет: 3000 UAH Термін: 2 дні

Доброго дня! Уважно прочитав ТЗ — задача зрозуміла.

Дві проблеми вирішуються окремо:
1. Нік і кількість підписників — швидше за все зміни в Graph API (v14+) прибрали поля які раніше поверталися за замовчуванням, треба явно їх запитувати.
2. Масові запити з gr:get:InvalidID — скоріш за все polling-скрипт звертається до API з ID які вже не існують (видалені повідомлення, сторінки або аватарки). Треба знайти де формуються ці запити, додати валідацію ID перед відправкою і прибрати зайві виклики.

Почати можу завтра. На діагностику і фікс — 1-2 дні залежно від обсягу коду модуля.

Бюджет: 1300 UAH Термін: 1 день

Доброго дня. Готов вирішити проблему сьогодні. Добре знаю OpenCart, маю досвід розробки власних модулів.

Бюджет: 1300 UAH Термін: 1 день

Вітаю
Виконаю зараз
Пишіть в особисті повідомлення
Обговоримо деталі

Бюджет: 2000 UAH Термін: 2 дні

Вітаю!

Ознайомився з ТЗ. Маю досвід з OpenCart, API-інтеграціями та пошуком подібних проблем, коли фоновий JS/PHP-код генерує зайві запити й швидко вибиває ліміти зовнішнього сервісу.

Можу перевірити, яка саме функція викликає запити gr:get:InvalidID, додати логування відповідей Facebook/API, прибрати некоректні звернення без поломки поточного функціоналу модуля та окремо поправити вивід ніка/підписників. Бачу в ТЗ, що важливий критерій - щоб при відкритій сторінці модуля більше не росли помилки й не витрачались ліміти API.

Почати можу сьогодні/завтра.

Бюджет: 1000 UAH Термін: 1 день

Доброго дня! Готовий взятися за діагностику та виправлення проблеми з API Facebook/Instagram в OpenCart. Почати можу сьогодні.

Бюджет: 2800 UAH Термін: 1 день

Доброго дня.

Готовий взятися за задачу вже зараз.

План робіт:

* Проаналізую модуль OpenCart та інтеграцію з Facebook/Instagram API.
* Знайду причину масових запитів до Graph API та помилок gr:get:InvalidID.
* Додам детальне логування проблемних запитів і відповідей Facebook.
* Визначу конкретні функції та файли, які викликають перевитрату лімітів.
* Виправлю відображення ніка користувача та кількості підписників.
* Перевірю, щоб після змін не ламався поточний функціонал модуля.

Термін виконання: до 2 днів.
Вартість: 2800 грн.

Після отримання доступу до коду та модуля можу почати роботу одразу сьогодні. Розгорнути

Бюджет: 2000 UAH Термін: 1 день

При вірному розкладі робота займе не більше доби. Почати можу в будь-який час, хоч зараз.

Бюджет: 1400 UAH Термін: 1 день

Привіт! У мене є відповідний досвід з подібними завданнями, і я можу допомогти з вашим проектом. Я можу швидко ознайомитися з вимогами, запропонувати найкраще рішення та ретельно виконати роботу. Готовий обговорити деталі та почати.

Бюджет: 2500 UAH Термін: 1 день

Доброго дня! Маю досвід з PHP/OpenCart та інтеграціями Facebook/Instagram
Graph API, OAuth, Webhooks.

Прочитав ТЗ - обидві проблеми (зникнення ніку/підписників та витік лімітів
АПІ з ростом gr:get:InvalidID) дуже ймовірно пов'язані з кодом, який
періодично оновлює дані профілю клієнта (нік, кількість підписників,
аватар) через окремі API-запити при polling'у непрочитаних повідомлень.
Якщо ID користувача в цих запитах став невалідним (наприклад, через зміну
формату ID в Graph API або застарілий токен), кожен цикл polling генерує
помилку gr:get:InvalidID і витрачає ліміт.

План роботи:
1. Знайти функцію(ї) яка робить ці запити (швидше за все в polling-скрипті
адмінки)
2. Додати логування запит/відповідь Facebook у окремий файл
3. Визначити точну причину невалідного ID
4. Виправити запит, відновити відображення ніку та підписників
5. Перевірити що ліміти АПІ більше не витрачаються при відкритій вкладці

Термін: розпочну сьогодні, орієнтовний час діагностики + фіксу —
4-6 годин (можливо швидше, залежить від структури коду модуля).
Орієнтовна вартість: 2500-3000 грн (за весь обсяг - діагностика, логування,
фікс обох проблем, документація змін).

Готовий розпочати з аналізу коду надайте доступ до файлів модуля
(FTP/SSH чи архів) та лог запитів якщо є. Розгорнути