Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

База данных плагина: 5 ошибок, которые потом больно чинить

Если плагин хранит данные в WordPress, не пиши всё в одну таблицу «на всякий случай». Разделяй сущности: настройки, логи, связи, временные данные. Иначе поиск, миграции и очистка превращаются в ручной ремонт.

Схема должна отвечать на вопрос: как быстро я найду нужную запись и как безопасно её изменю. Для этого:
— выбирай осмысленные ключи и типы полей;
— не храни лишнее в post_meta, если данные используются часто;
— индексируй колонки, по которым идёт фильтрация;
— заранее продумывай удаление данных при деактивации плагина.

Отдельная ошибка — писать запросы без подготовки. Используй $wpdb, экранирование и prepared statements, а не конкатенацию строк. Это снижает риск поломок и делает код предсказуемым при росте объёма данных.

И ещё: любая таблица должна иметь понятный план жизни. Если запись создаётся один раз, обновляется редко и не участвует в поиске, ей не место в «горячем» хранилище. Чем проще схема, тем легче поддержка и перенос между сайтами.

Настройки плагина: 5 параметров, которые ломают WordPress чаще всего

В плагине важно не “включить всё”, а настроить только то, что реально нужно. Иначе он начинает тормозить сайт, конфликтовать с темой и плодить лишние запросы.

Проверь базовые блоки:
— доступы и роли: кто может менять настройки и запускать действия;
— загрузку скриптов: подключать их только там, где они нужны;
— кэширование: не мешает ли плагин кешу страниц и объектному кэшу;
— формы и валидацию: пустые поля, неверные типы, дубли.

Отдельно смотри на хранение данных. Если плагин пишет всё в одну таблицу или в autoload, сайт со временем раздувается. Для опций, которые меняются редко, autoload лучше отключать. Для часто используемых значений — наоборот, держать рядом с логикой, а не тянуть из базы на каждом шаге.

Ещё один частый промах — настройки без ограничений. Если можно выбрать любой путь, вставить любой HTML или загрузить любой файл, обязательно добавляй whitelist, проверки типа и sane defaults. Это снижает и баги, и риск поломки при ручной правке.

Перед релизом пройдись по настройкам как пользователь: что будет, если поле пустое, чекбокс снят, значение удалено, а плагин уже активен на живом сайте. Именно такие сценарии чаще всего показывают слабые места.

Локализация плагина: 5 мест, где чаще всего забывают переводы

Локализация в плагине — это не только файлы .po/.mo. Чаще всего перевод «ломается» в мелочах: строка выведена не через gettext, часть текста собрана вручную, а часть вообще сидит в JS.

Проверьте базу: все пользовательские строки должны идти через __(), _e(), _x(), _n() и иметь единый text domain. Если домен в одном месте отличается, переводчик его просто не увидит.

Отдельно смотрите на:
— уведомления и ошибки в админке;
— шаблоны email и тексты кнопок;
— сообщения в AJAX и REST-ответах;
— настройки в JavaScript и inline-строки;
— метки в блоках, виджетах и shortcodes.

Частая ошибка — переводить только интерфейс, но забывать про динамические фразы: «Удалено %s записей», «Осталось %d шагов». Для таких строк нужны плейсхолдеры и правильный порядок аргументов, иначе в других языках фраза развалится.

Хорошая привычка: перед сборкой плагина прогоняйте поиск по проекту на голые строки в кавычках. Если текст видит пользователь, он должен быть готов к переводу — иначе локализация останется только на бумаге.

База данных плагина: 6 ошибок, которые потом дорого чинить

Если плагин хранит данные в WordPress, не лепите всё в один массив “на всякий случай”. Для настроек, логов и сущностей нужны разные таблицы или хотя бы разные ключи: так проще искать, обновлять и удалять записи без мусора.

— Не используйте wp_options для всего подряд: там быстро растёт шум и тормозится админка.
— Не сохраняйте большие JSON-объекты, если потом нужен фильтр по полям.
— Не забывайте про индексы на часто запрашиваемых колонках.
— Не делайте запросы внутри цикла, если можно получить данные одним JOIN.

Ещё одна типовая проблема — отсутствие схемы удаления. Плагин отключили, а таблицы, кэши и служебные записи остались. Сразу продумайте, что удаляется при деактивации, а что — только при полном удалении плагина. Это экономит время на поддержке и убирает “призрачные” баги.

Для рабочих выборок используйте $wpdb, prepare и явные типы данных. Так вы снижаете риск SQL-инъекций и делаете код понятнее для следующего разработчика.

Хорошая база данных в плагине — это не “как сохранить”, а “как потом быстро найти, обновить и безопасно удалить”.

Локализация плагина: 4 ошибки, из-за которых перевод ломается

Если плагин нужен не только вам, локализацию стоит продумать до первой строки интерфейса. Иначе потом приходится искать текст по шаблонам, править вручную и ловить «непереводимые» места в админке.

• Не хардкодьте строки прямо в PHP. Любой текст для пользователя должен проходить через функции перевода, а не лежать в коде как обычная строка.
• Не собирайте фразы конкатенацией без нужды: переводчик должен видеть целое предложение, а не набор обрывков.
• Не забывайте про контекст. Одно и то же слово в кнопке, подсказке и заголовке может переводиться по-разному.
• Не держите тексты только в одном месте: проверяйте экраны, письма, уведомления и ошибки.

Отдельно следите за плейсхолдерами: если в строке есть имя, число или ссылка, используйте безопасную подстановку и сохраняйте порядок аргументов. Иначе перевод становится неудобным или ломает смысл.

Хорошая локализация — это не «добавить .pot-файл», а сразу писать интерфейс так, чтобы его можно было перевести без правок логики.

База данных плагина: 5 ошибок, которые потом ломают скорость и поддержку

Если плагин хранит данные как попало, проблемы всплывают не сразу: сначала дубли, потом медленные запросы, а затем сложная миграция. База данных — не место для «потом разберёмся».

• Не создавайте таблицы без префикса WordPress — это мешает совместимости и безопасности.
• Не храните всё в одной записи options, если данные часто меняются: обновления станут тяжелее.
• Не забывайте про индексы в колонках, по которым идёт поиск или сортировка.
• Не пишите запросы через конкатенацию строк — используйте подготовленные запросы.
• Не удаляйте данные плагина при деактивации, если это ломает восстановление или перенос.

Отдельно следите за типами полей: число должно быть числом, дата — датой, текст — текстом. Когда всё складывают в длинную строку, фильтрация и выборка превращаются в боль.

Ещё одна частая ошибка — отсутствие схемы обновления. Если структура таблицы меняется, заранее продумайте миграцию: добавление колонок, перенос данных, обратную совместимость. И обязательно проверяйте, что плагин переживает пустую базу и повторную установку без ручных правок.

Хороший плагин не просто пишет в базу, а делает это предсказуемо: быстро ищет, легко обновляется и не мешает администратору через полгода.