Any notice can now be made dismissible by ensuring the it has the classes .notice and .is-dismissible (recognize that naming convention?). Core handles adding the close button and removing the notice for you. However, for the best possible user experience, you should ensure that those notices will not come back on a page refresh or when navigating to another page. There are two different paths for this. The first applies to notices that are added when a query arg is present in the URL, such as message=6. Core will now remove certain query args and use JS to replace the URL in the browser with that “cleaned up” version. By default, core handles 'message', 'settings-updated', 'saved', 'update', 'updated','activated', 'activate', 'deactivate', 'locked', 'deleted', 'trashed', 'untrashed', 'enabled', 'disabled', 'skipped', 'spammed', and 'unspammed'. To add (or remove) items to this array to accommodate your needs, use the removable_query_args filter.
The second path, for notices that persist across different page loads, is to bind to the click event on the .notice-dismiss element in your own notice and trigger whatever it is your plugin may need to do to remember that the notice has been dismissed, such as storing a site or user option using Ajax. A note of caution that in an ideal scenario, core would eventually provide a framework for persistently dismissible notices that are not tied to query args, so be prepared for future changes if you choose to use this method.
Дмитрий: в целом утверждение вроде и правильное, однако спорное. Писать свое решение для роутинга и ЧПУ? Вперед. Написать такое же толковое, как у WP - нехилый кусок работы, и особенно отладки. Взять готовое вместе с фреймворком? Те же яйца, только в профиль - надо знать как этим пользоваться. Шило на мыло.
Не совсем. ООП - да, singleton - очень и очень спорно. Вообще-то, у синглтонов есть как ярые фанаты, которые только его и используют тупо везде, так и ярые противники.
Egor Nedbailo: то же самое из опыта WP - даю доступ в админку клиенту когда готова основа - больше не беспокоят :)
И MODx, и WordPress, и Drupal, и даже местами Joomla (как и Expression Engine или менее известные платные решения, или нишевые) - все это инструменты. В ровных руках они просто делают свою работу. В не совсем ровных - создают проблемы на пустом месте. То же самое, на самом деле, касается Laravel, Yii, CodeIgniter. Symfony и тд
Конечно не поймут :) Ибо удобство и простота админки WordPress - одна из причин его популярности. Обычные юзеры по всему миру сделали свой выбор. Цифры, так сказать, говорят за себя.
iborisbelov: очень даже поверю, это помогает в 9 случаях из 10. Один из самых частых нюансов, связанных с пермалинками. А вот flush_rewrite_rules() - это как раз функция, которая обновляет правила пермалинков. Нормальные плагины при активации добавляют свои правила и корректно обновляют пермалинки. Добавив же свой код вручную, вы правила вроде как добавили, только вот используете закешированные старые - потому и не работает.
зы: только аккуратно с этой функцией - она ресурсоемкая, поэтому и используют ее разово в нужных местах - при активации плагина, смене настроек через плагин, и... на странице настроек постоянных ссылок! :)
dicem: Теперь по функционалу все стало понятно. Сразу вопрос - вы PHP знаете? Программист, или просто пользователь? Если пользователь (подозреваю именно этот вариант) - вынужден вас разочаровать. Это кастомный функционал, к тому же с опасными местами (недостаточно безопасные формы - это одна из главных дыр на сайтах). Все это сделать можно, и даже ничего сложного в нем нет, но - для опытного разработчика. Для обычного пользователя это куча абракадабры, в которой вы утонете. К тому же, задачка весьма объемная, это не формат "вопрос-ответ" на Тостере, тут по-хорошему только ТЗ нормальное на 2 листа А4 выйдет. В общем, наймите специалиста, для такового тут не больше 1 рабочего дня.
Anton Essential: > включить гзип
где и как включили? и что значит гугл "пидалит"?
> ругается на кэш браузера я добавил дериктивы в htaccess
подробнее, что ругалось, что добавили, что ругается дальше
и тд.
HAbRAhabp: для этого есть таксономии - рубрики, например, или custom taxonomy. Ваш производитель должен быть термином таксономии. А на страничке "постоянные ссылки" укажите "/%category%/%postname%/" - будет вам и слэш, и возможность реальной фильтрации ваших моделей по производителям.
Я изначально подозревал, что вы что-то делаете не так. Потому и настаивал на ответе на вопрос "зачем" - потому что понимая цель, можно помочь найти решение. Вы попытались использовать "родительскую страницу" там, где используется таксономия.
HAbRAhabp: Да, все верно. Я же ответил в п.1, возможно ли это - нет. Не возможно. Слэш - это не просто символ, а символ, который в URL имеет особое значение. Поэтому в левых местах он вырезается.
Ответ на п.2 дадите? Зачем вам это?
Any notice can now be made dismissible by ensuring the it has the classes .notice and .is-dismissible (recognize that naming convention?). Core handles adding the close button and removing the notice for you. However, for the best possible user experience, you should ensure that those notices will not come back on a page refresh or when navigating to another page. There are two different paths for this. The first applies to notices that are added when a query arg is present in the URL, such as message=6. Core will now remove certain query args and use JS to replace the URL in the browser with that “cleaned up” version. By default, core handles 'message', 'settings-updated', 'saved', 'update', 'updated','activated', 'activate', 'deactivate', 'locked', 'deleted', 'trashed', 'untrashed', 'enabled', 'disabled', 'skipped', 'spammed', and 'unspammed'. To add (or remove) items to this array to accommodate your needs, use the removable_query_args filter.
The second path, for notices that persist across different page loads, is to bind to the click event on the .notice-dismiss element in your own notice and trigger whatever it is your plugin may need to do to remember that the notice has been dismissed, such as storing a site or user option using Ajax. A note of caution that in an ideal scenario, core would eventually provide a framework for persistently dismissible notices that are not tied to query args, so be prepared for future changes if you choose to use this method.