такое значение поля slug уже существует mangalib
Такое значение поля slug уже существует mangalib
Для работы со слагами в Laravel нам понадобится простой и удобный пакет cviebrock/eloquent-sluggable. Устанавливаем его для Ларавел 5.5:
Если вы захотите изменить какие-либо дефолтные настройки, то создайте файл конфигурации:
После этой команды будет создан новый конфиг: config/sluggable.php в котором можно поменять некоторые значения. Думаю, что разберетесь с этим.
Теперь выбираете файл модели, к которой хотите создать слаг. Пусть, к примеру, эта модель называется Post. В этой модели нужно указать пространство имен и создать метод для генерации слага из какого-либо поля таблицы:
Рассмотрим вариант, когда таблица у вас уже существует и необходимо создать новую миграцию, для добавления одного поля:
После чего будет создана новая миграция и вы увидите в командной строке, что-то наподобие этого:
Внутри созданного файла создаем новое поле:
И запускаем миграцию:
Вначале мы проверяем, не является ли слаг числом. Зачем мы это делаем?! Часто слаги внедряют в программу уже после того, как был другой механизм построения пути. Например, через числовые индексы. Тогда может получится ситуация, что пользователь, зайдя на сайт по старой ссылке, увидит 404 ошибку, что такой страницы не существует. Ведь мы теперь работаем через слаги. Поэтому, нам необходимо сделать 301 редирект со старой страницы, на новую.
Для этого мы и проверяем полученный аргумент на числовое значение, пытаемся по этому значению получить коллекцию (collection), и если такой пост действительно существует (если нет, то выводим 404 ошибку), то делаем 301 редирект на страницу со слагом.
Если же вы создаете сайт с нуля и сразу используете слаги, то вам такой проверки и редирект делать не нужно.
Построения ссылки в шаблоне тоже очень простое:
В принципе, это и все!
Как видите, сложности нет вообще никакой, а использование слагов очень просто и удобно для пользователей и поисковиков.
Русскоязычный вариант для термина slug
Как корректно на русский переводится термин ‘slug’?
Контекст употребления можно найти в этих вопросах:
Судя по всему это что-то имеющее отношение к ЧПУ (человекопонятный url), но что именно?
3 ответа 3
Технически обычно это уникальный человекочитаемый ключ для поиска, который может не только идентифицировать единственную запись, но и быть осмысленным для пользователей при прямом прочтении. В конкретных случаях бывают и другие требования, вроде безопасности для вставки в URL (не всякие символы разрешены), определённой максимальной длины или чувствительности к регистру.
Известный устоявшийся перевод, кроме англицизма «слаг», мне неизвестен, и, возможно, не существует вовсе.
Но бывает и иначе. Реже случается, что их уникальностью пренебрегают.
То, что используется здесь, на Stack Exchange:
Хотя если при обсуждении кто-то назовёт последний сегмент slug’ом, я пойму, что он имеет в виду идентификатор для человека (необязательно уникальный технически).
Получается, вот ещё одно определение, которым пользуются на практике. А значит, термин не является однозначным.
Я мог бы предложить несколько вариантов перевода, возможно даже в процессе обсуждения здесь на чём-то остановимся, но донести это до широкой общественности видится мне задачей практически невыполнимой.
Добавляем слаги (slug) к URL-адресам
На этом занятии мы сделаем отображение отдельных статей по их слагу (slug). Если кто не знает, то slug – это уникальный фрагмент URL-адреса, ассоциированный с конкретной записью и, обычно, состоит из набора маленьких латинских букв, цифр, символов подчеркивания и дефиса. Например, статья «Арифметические операции» на сайте https://proproprogs.ru доступна по следующему адресу:
Здесь slug – это последние символы, по которым и выбирается данная страница из БД. Использование слагов – рекомендуемая практика в веб-программировании. Такие страницы лучше ранжируются поисковыми системами и понятнее конечному пользователю.
Давайте вначале сделаем отображение статей по их идентификатору, а затем, заменим адрес на слаг. У нас уже есть функция-заглушка show_post() в файле women/views.py. Мы ее перепишем, следующим образом:
Здесь функция get_object_or_404 выбирает одну запись из таблицы Women, которая имеет идентификатор, равный post_id, либо генерирует исключение 404, если запись не была найдена. Это довольно частая операция, когда нужно найти какую-либо отдельную запись, а в противном случае, перенаправить пользователя на заготовленную страницу 404. Поэтому в Django для таких случаев заготовлена специальная функция.
Далее, формируется словарь из параметров шаблона и отображается страница на основе шаблона post.html. У нас пока нет такого файла, добавим его со следующим содержимым:
Здесь все достаточно очевидно. Вначале отображаем заголовок h1, затем, фотографию статьи, если она есть, ну и потом уже содержимое самой статьи.
Если теперь перейти по ссылке, то увидим полноценную статью. Если же указать неверный адрес, то получим исключение 404. Повторю еще раз, исключения в таком развернутом виде отображаются только в режиме отладки сайта. При эксплуатации с константой DEBUG = False вместо исключения отображается заготовленная страница 404.
Добавление слага
Следующим шагом сделаем отображение статей по их слагу. Но откуда нам его взять? Для этого в модели Women необходимо прописать еще одно поле, которое так и назовем – slug:
Я его определил после поля title, указал уникальным, индексируемым и имя URL, отображаемое в админке. Однако, если сейчас попытаться создать миграцию для внесения этих изменений в структуру таблицы women:
python manage.py makemigrations
то увидим предупреждение, что поле не может быть пустым (так как у нас есть записи в таблице). Чтобы таблицы были сформированы как надо, я решил создать БД заново. Поэтому сразу добавил такое же поле в модели Category:
Удалим все файлы миграций, прежний файл БД и выполним команду
python manage.py makemigrations
для создания первой мигации. Затем, с помощью команды:
python manage.py migrate
сформируем таблицы с новыми структурами. Этот пример хорошо показывает, как важно заранее продумывать структуры таблиц для сайта. Осталось восстановить записи в БД. Для этого я заново создам суперпользователя для админки:
python manage.py createsuperuser
с именем root, почтой root@coolsite.ru и паролем 1234. Запускаем веб-сервер и заходим в админ-панель.
Для начала добавим категории. Здесь нам предлагается ввести ее название и слаг (URL). Конечно, можно заполнить оба поля вручную, например, «Актрисы» и «actrisi». Но, так как слаг, обычно, повторяет заголовок, только записанный латиницей, то фреймворк Django позволяет этот процесс автоматизировать. Давайте откроем файл women/admin.py и для модели Category в классе CategoryAdmin добавим атрибут:
Это специальное свойство, которое указывает фреймворку автоматически заполнять поле slug по данным поля name.
Возвращаемся в админку, обновляем страницу и, смотрите, при вводе строки в поле name, автоматически формируется поле slug. Это очень здорово и значительно облегчает нашу работу. Теперь можно совершенно спокойно добавить две рубрики «Актрисы» и «Певицы».
Далее, прежде чем добавлять статьи, сделаем такую же связку по слагу для модели Women в классе WomenAdmin:
только здесь мы указываем поле title. Возвращаемся в админ-панель и на вкладке добавления женщин введем информацию по актрисам:
Анджелина Джоли, Дженнифер Лоуренс, Джулия Робертс, Марго Робби, Ума Турман
А также по певицам:
Ариана Гранде, Бейонсе, Кэтти Перри, Рианна, Шакира
Отлично, база данных готова и теперь можно сделать отображение статей по слагу. Для этого откроем файл women/urls.py и в списке urlpatterns изменим маршрут для постов на следующий:
Затем, в файле women/views.py немного поменяем функцию представления show_post:
И в модели Women (в файле women/models.py) будем формировать URL-адрес по параметру slug:
Все, обновляем главную страницу сайта и видим, что теперь посты доступны по слагу, а не идентификатору. Этот пример показывает как в Django легко и просто можно менять URL-адреса и вместо id использовать другие поля, в частности, слаг. При этом, мы не производили совершенно никаких изменений в шаблонах, благодаря использованию метода get_absolute_url() в модели Women. Кроме того, Django автоматически защищает такие адреса от SQL-инъекций, когда злоумышленник пытается выполнить SQL-запрос, прописывая его в адресной строке браузера. Благодаря всем этим мелочам, которые берет на себя фреймворк, даже начинающий веб-мастер может конструировать вполне безопасные сайты с богатым функционалом.
Аналогичную операцию использования слагов можно сделать и для отображения рубрик. Предлагаю вам выполнить это самостоятельно для закрепления материала.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта