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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вітаю!

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

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

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

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

Доброго дня.

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

План робіт:

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

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

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

Доброго дня
Завдання зрозумів, по ТЗ пройшовся, можу взяти в роботу

За описом найбільш підозрілими виглядають такі місця:
періодичний AJAX-запит з адмінки;
оновлення лічильника непрочитаних повідомлень і коментарів;
отримання аватарок користувачів або сторінок;
отримання інформації про сторінки Facebook та Instagram;
запити до коментарів або повідомлень, які були видалені;
… запити за ID об'єктів, які вже не існують або стали недоступними.

ці механізми можуть призводити до постійного виконання запитів до Graph API, зростання кількості помилок gr:get та поступового вичерпування доступних API-лімітів додатка.

в цілому попередньо по термінам 1-2 дні
по вартості орієнтовно можу запропонувати 1700грн, або якщо є бажаний орієнтир по сумі, теж можете сказати, я зможу розглянути

наразі не завантажений , зможу оперативно приступити до виконання після того як зв'яжемось

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

Показати оригінал

Перекласти

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

Доброго дня! Маю досвід з 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 чи архів) та лог запитів якщо є.