Может есть какой плагин для таких вещей?
Есть множество плагинов для управления возможностями ролей.
Только я рекомендую не править дефолтные роли, а создавать на их основе новые.
Но зачем Вам столько авторов-редакторов? Одни пишут, другие проверяют, третьи перепроверяют…
@sevlad,
Есть множество плагинов для управления возможностями ролей.
Только я рекомендую не править дефолтные роли, а создавать на их основе новые.
И даже один из этих плагинов у нас стоит — User Role Editor.
Но тут 2 проблемы.
1. Возможно конечно в каком-то из плагинов есть функционал, который решает вопрос, но кмк, тут дело не в возможностях, а в модификации принципе работы со статьями.
У существующей статьи есть только кнопка Обновить.
При её нажатии статья публикуется на сайте, а это не подходит, нужно что бы она сохранялась в черновике, т.е. в идеале должна быть кнопка Сохранить.
А уже если в статью зашел редактор и посмотрел изменения, он уже мог бы нажать кнопку Обновить и опубликовать измененную статью.
Проблема в том что нет такой кнопки, соответственно разрулить ролями и возможностями ничего не получается.
У WP есть действие — публикация, но оно работает ТОЛЬКО с неопубликованными ранее записями, а у нас записи опубликованы и их можно только сохранять.
2. Плагинов как Вы и пишете масса.
Перепробовать все в теории можно, но хотелось бы как-то сузить их кол-во за счет опыта коллег 🙂
Но зачем Вам столько авторов-редакторов? Одни пишут, другие проверяют, третьи перепроверяют…
А сколько столько?
Пусть будет один автор один редактор.
А в целом классический подход издания.
Главред, несколько редакторов, авторы и т.д.
Модератор
Юрій
(@yube)
Одни пишут, другие проверяют, третьи перепроверяют…
Кстати, это стандарт работы для информационных агентств.
Покурил интернеты, выяснил что кроме черновика (draft) есть еще один интересный статус — на утверждении (pending).
По логике этот статус подходит больше чем черновик, но один фиг не понятно как автоматом присваивать этот статус при работе редактора и при этом показывать на сайте запись со статусом publish относящуюся к этому посту.
Т.е. логика работы та же что и с черновиками…
Нашел хук, который при редактировании статьи со статусом publish автоматом ставит pending, но опять таки, запись в этом случае пропадает с сайта.
-
Ответ изменён 7 лет, 1 месяц назад пользователем
noindex.
Обновить
Для пользователей кому не разрешена публикация по этой кнопке пост уйдет на модерацию (утверждение, pending). Именно это вам и нужно.
Кстати, это стандарт работы для информационных агентств.
Хм.. На 10 рулевых (где всего один с правами, у остальных же только ответственность) один гребец. Но может быть, может быть. Не в курсе.
Спс, бум знать 🙂
@sevlad,
Для пользователей кому не разрешена публикация по этой кнопке пост уйдет на модерацию (утверждение, pending). Именно это вам и нужно.
Даже если и так, и по этой кнопке запись уйдет на модерацию, она пропадет на сайте.
А это не то что мне нужно.
Мне нужно что бы в данном случае на сайте отображалась версия страницы, которая была утверждена ранее.
А после того как главред утвердит её, на сайте отобразилась новая утвержденная версия.
-
Ответ изменён 7 лет, 1 месяц назад пользователем noindex.
-
Ответ изменён 7 лет, 1 месяц назад пользователем noindex.
@noindex, есть ещё редакции (ревизии) постов. Если они не отменены, то сохраняются автоматически. Или по CTRL+S. Это конечно не наглядно и вряд ли устроит как рабочее решение, но можно что-то придумать.
Или как вариант — создавать копию записи, а потом менять на проверенную. Тоже «сырое» решение.
Модератор
Юрій
(@yube)
где всего один с правами, у остальных же только ответственность
Наоборот 🙂 Вся ответственность (в т.ч. уголовная) на выпускающем редакторе, т.е. на том, у кого есть кнопка «опубликовать».
Даже если и так, и по этой кнопке запись уйдет на модерацию, она пропадет на сайте.
Именно. Лет N назад мне, кажется, попадался плагин, позволяющий вносить изменения в статью так, чтобы они не показывались на фронт-энде до тех пор, пока изменения не утвердит имеющий на это право. Но это было так давно, что я даже не помню, был ли это готовый плагин или обсуждение «как такое замутить».
Модератор
Юрій
(@yube)
Или как вариант — создавать копию записи, а потом менять на проверенную.
Еще вариант: писать контент в кастом филд по кнопке «утвердить», и выводить на фронте этот кастом филд вместо post_content.
Наоборот 🙂 Вся ответственность (в т.ч. уголовная) на выпускающем редакторе, т.е. на том, у кого есть кнопка «опубликовать».
Угу.. Это за редким исключение виноват не стрелочник и проходянком не наказывают простых исполнителей 🙂 Вне зависимости от стран и политики. Но да лано, не будем развивать.
Еще вариант: писать контент в кастом филд по кнопке «утвердить», и выводить на фронте этот кастом филд вместо post_content.
Хороший вариант, да. Но ИМХО лучше/проще/надёжнее заменить контент. Ну или как «ещё один вариант» 🙂
@sevlad, да, ревизии в данном вопросе имеют важную роль и он не отключены.
Но манипуляциями только с ними не обойтись, нужно переделывать принцип работы WP с ними.
На счет копии тоже думал, но как Вы заметили это решение сырое и требует лишних телодвижений от редактора.
Лет N назад мне, кажется, попадался плагин, позволяющий вносить изменения в статью так, чтобы они не показывались на фронт-энде до тех пор, пока изменения не утвердит имеющий на это право.
Да, это было бы то что нужно…
Еще вариант: писать контент в кастом филд по кнопке «утвердить», и выводить на фронте этот кастом филд вместо post_content.
Вариант кстати интересный, только я бы предпочел во фронте выводить стандартный post_content (во избежание неожиданностей), а чтобы редактор работал как раз с кастомным полем, в которое при определенных условиях копировалось бы содержимое post_content.
Соответственно при утверждении правок и нажатии кнопки, содержимое кастомного поля копировать в post_content…
Единственный недостаток помимо того что придется это кодить — пропадает стандартный механизм WP по сравнению ревизий, который для наших целей очень подходит.
Точнее ревизии сравнить будет можно, но только после принятия изменений.
Хотелось бы до.
-
Ответ изменён 7 лет, 1 месяц назад пользователем noindex.
@noindex
нужно переделывать принцип работы WP с ними.
Переделывать наверное не нужно. Нужно доделать, получив более удобную и надёжную работу с ними.
А так как редакции — это элемент, зависящий от поведения ВП (не только по времени/хотекю, а напр при разрыве связи он создаст реакцию. какую потом проверять может быть не понято. К тому же будет много редакций, дилемма между удалением старых и надёжным сохранением), то возможно не плохо бы было совместить с кастостомными полями.
Напр проверяемый пост редактируется в кастомном поле, при отправке на утверждение копируется в контент редакции.
