wildapache

В обработчике проверяйте на наличие хотя бы одного изображения. Если изображений нет, не применяйте изменения, а пользователя оповещайте, что необходима хотя бы одно изображение для обложки.

Так не пойдёт, потому что пользователь может удалять все свои аттач файлы. Отдельный аплоад тоже не вариант.

Тем кто будет реализовывать аплоад файлов, мой совет, делайте его отдельным от редактирования поста, то есть, так чтобы обработка аплоада была отдельно от обработки поста — когда он сохраняется. Потому что при реализации двух вариантов, выбор пал на второй, так как нагрузка только во время загрузки файла в форме, т.е если сравнивать с первым вариантом, практически нулевая.

На счёт обложки удалось решить задачу, когда пользователь удаляет обложку, мы её просто скрываем, если он, выбирает файл обложки, тогда она заменяется, а если он ничего не делает, т.е типа нажал удалить, она просто скрылась, после перезагрузки она опять появляется, так как сам файл не удаляется, потому что нет файла для замены. (это если коротко и по простому описать). Можно додумать сделать ещё логичнее и правильней на базе этого варианта.

Такое бывает, но смысла особого не имеет, так как данные сохраняются в рамках одного визита (может быть жизнь кук продлена разработчиком до ХХ дней, но общей сути это не меняет). Проще говоря, функциональность сильно ограничена, да и метод реализации сомнительный.

Почему сомнительный ? К примеру по быстрому пройтись по товарам, добавить что нужно, потом когда время придёт, зашёл посмотрел опять. На самом деле такой вариант много-где используется, т.е ссылки храняться в браузере клиента (там не совсем кукисы, забыл как назвывается, там именно данные сохраняются на стороне клиента), т.е это почти как ты добавил в избранное (функционалом браузера) только — на сайте. Потом пользователь может зайти в это избранное на сайте и удалить ссылку, грубо говоря он её удаляет из своего браузера.

Просто проект не очень крупный, вот думаю что прикручивать, первый функционал на данных браузреа или же на php+sql c айди. Можно конечно было бы просто сделать счётчик, мол кто-то добавил себе в избранное, а там удалил он оттуда или нет уже неизвестно. (такая реализация была бы простой и без особой нагрузки, так как просто бы считывался счётчик — кликов) а не проверка у пользователей который добавили или удалили..

По поводу безопасности вы имеете ввиду сторону wordpress как я понял ? То есть именно — действия после того как «мы» получаем данные из facebook ?

Мне нужно понять общую логику работы, когда на сайте есть обычная регистрация и регистрация через facebook. С обычной всё ясно, пользователь вводит данные сам, после чего на его почту приходит письмо чтобы он подтвердил регистрацию.

А вот с фейсбук как ? К примеру он нажимает авторизироваться через фейсбук, далее после того как юзер разрешает доступ, функция возвращает его имя, почту, далее нужно как я понял, на это имя и почту нужно создать аккаунт (типа авторегистрации без подтверждения, так как пользователь уже дал доступ к фб), т.е на выходе мы получаем аккаунт в самом вордпрессе с данными из фейсбука !

Потом к примеру, не ясно, если пользователь выйдет из аккаунта в вордпресс, и потом снова нажмёт авторизироваться с помощью фейсбука что должно происходить ? Типа поиск такого емайла в базе и если есть — давать ок на вход (без ввода пароля) ?

Готовые решения мне не нужны как и эти грамоздкие плагины, в которых ради хайпа понапихивали что надо и что не надо.

Я тоже придерживаюсь мнения что просто к айди прикрутить отдельную таблицу и систему в общем, а айди использовать ввиде адресатов что кому куда. То есть по сути будут использоваться только айди юзеров. Но пока как это правильно рализовать — не знаю, наверно пока не начну.

Я сделал по другому, я его вообще отделил от плагина и wordpress. Ибо понял что так намного проще. Выходит что скрипт — сам по себе как отдельный функционал, который к примеру собирает данные из БД и что-то сними делает по вызову крона. Так как он запускается не часто, то и нагрузки никакой в принципе нет.

В каком смысле весь api доступен ?