Если речь не о считывании трёх с половиной постов одного пользователя, то это вопрос больше не к python, а к тому, чтобы обманывать Facebook, изображая легальных пользователей. Всякие куки, прокси, разгадывание капчи, управление частотой запросов... Готовое решение никто не даст, так как готовое можно хорошо продать на рынке, а в случае его массовой доступности Facebook может подсуетиться и внести изменения, которые его сломают.
getaxe, нет, ничего не сломает. Просто будет срабатывать обработчик на тех событиях, на которых раньше не срабатывал. Но нужно будет проверять свойство partial и при необходимости делать fetch для получения отсутствующего в кэше объекта (он при этом также загрузится в кэш и при следующей реакции уже отработает без этой магии).
Partials как раз и позволяют получать события по объектам, которые не найдены в кэше и поэтому определены лишь ЧАСТИЧНО (например, известен id сообщения, но неизвестен текст, имеющиеся реакции и другие данные). По умолчанию такие события игнорируются, но можно уговорить библиотеку всё-таки их обрабатывать.
NonVer, на этом сайте помогают решать проблемы, а не решают их заместо спрашивающего. За готовым решением можно обратиться на фриланс, где "под ключ" сделают что угодно. А с вопросами сюда следует приходить хоть с какими-то попытками решения. Например, можно показать кусок собственного кода, вызывающий ошибку, или работающий не так, как ожидалось
lolrofl01, нельзя указывать цену продаваемого товара в валюте, если это, например, магазин предлагает товар широкому кругу лиц. В договоре между двумя сторонами можно использовать цену в валюте, при этом надо явно указать в какой и как определяется курс этой валюты (например, самое простое это по курсу ЦБ). Вообще, по словам "цена в долларах в договоре" в гугле довольно много результатов.
Например, если у каждой страницы есть номер, то при показе страницы N делаем кнопки с call_data=page:N-1 и page:N+1 (отдельно учитываем первую и последнюю страницу. При нажатии на кнопку редактируем сообщение, заменяя его текст на содержание страницы N+1/N-1 и кнопки на соответствующие.
serhiops, в обработчике команды ничего не надо отправлять. В нём нужно только добавить задание в очередь с указанием времени. Например (но необязательно!), очередь можно хранить в таблице в базе, для чего сделаем таблицу message_queue с такими полями:
id - главный ключ;
send_time - время отправки;
recipient_id - id получателся;
message - текст сообщения;
status - статус сообщений, пусть имеет значения awaiting или sent.
Вместо отправки добавим сообщение в таблицу в статусе awating (ожидает).
Регулярно пусть выполняется выгрузка из базы сообщений, которые ещё awaitng, но время уже наступило:
SELECT id,send_time,recipient_id,message FROM message_queue WHERE status='awaiting' AND send_time<NOW();
Извлечённые сообщения отправляем. Каждое переводим в статус sent, чтобы не отправить второй раз:
UPDATE message_queue SET status='sent' WHERE id=<id сообщения в очереди>;
Остаётся вопрос: как организовать регулярную выборку сообщений из очереди? Можно сделать по-разному:
1. Сделать отдельный тред в скрипте, который будет отслеживать очередь, перемежая это вызовами sleep. Или вместо треда таску в asyncio (если уже используется aiogram, то это более чем разумно).
2. Обрабатывать очеред в отдельном постоянно запущенном скрипте, либо запускать скрипт из cron каждую минуту.
Первый способ хорош тем, что всё в одном скрипте и потенциально очередь можно хранить не в базе, не в файле, не в брокере очереди типа rabbitmq, а прямо в переменной в скрипте. Правда, при этом в случае падения скрипта все запланированные задания на отправку будут потеряны. Второй хорош тем, что проблемы/тормоза скрипта отправке не будут вредить основному коду бота.
И, наконец, есть ещё один способ, при котором можно избежать организации очереди своими силами - использовать модули schedule/aioschedule (синхронный и асинхронный соответственно). Фактически, они берут на себя сохранение задания в очереди и вызов запрошенной функции в нужное время. Именно это тут посоветовали в первом ответе.
