Расскажи про MongoDB (желательно с CRUD, пагинацией, с фильтрацией), Elasticsearch (так же с пагинацией и прочим). С примерами и хорошими практиками. Будет пушка! С Redis уже есть, за что отдельный лайк от меня)))
спасибо за ролик первый случай: не рассмотрел вариант создания такого же поста с такимже слагом: нужна какая-то магия, чтоб слаги не дублировались (добавлялись индексы и проч: slug, slug-1, slug-2 и тд...) второй способ какой-то нежизнеспособный. если есть задача от сеошника иметь слаги, то наверное надо ими управлять как-то, сохранять. тайтл поменялся - слаг изменился, пост теперь недоступен по старой ссылке а вообще надо бы посоветовать использовать какие-нибудь готовые решения, где все это продумано, например, spatie
Ролик супер. Хотелось бы короткий но ёмкий ролик про теорию реляционных баз данных. Чего там по полгода в институтах преподают этот курс? Используется ли оно на практике? Как часто?
3й вариант интересный с точки зрения изучения фреймворка, но в жизни это полный ахтунг ибо будут дубли страниц и очень много и от них потом будет очень сложно избавиться. Так же с редиректами никак не поработать, когда будете избавляться от дублей или просто изменится заголовок.
Третий способ очень интересный, но конечно далек от жизни, потому что у внутреннего сеньора есть внутренний тимлид, который знает наверняка, что сегодня сеошнику нужно генерировать автоматически, но наступит день икс, когда понадобится поменять слаг(на более короткий например), а у вас поля то и нет, и что тогда?)))
Отличная инструкция: "Как сжить со света ненавистного SEO-шника". ✌😼🏴☠ Ибо SEO-шника после такой реализации обязательно (и очень скоро) навестит Кондратий и заобнимает вусмерть. )) А всё потому, что Гоогле с Яндексом начнут слать письма ему "с того света" о том, сколько у него дублей страниц, и как низко будет ещё падать его подопечный сайт в поисковой выдаче. 😝 И дело не в тех самых "дурачках", о которых автор в ролике упоминает, а в том, что найдутся умники, которые специально нагенерят для поисковиков мусорных ссылок для дублей контента. Ибо нефиг лезть в ТОП поисковой выдачи! 😉
У первого варианта есть еще один затык. если мы используем софтдэлит и уникальное поле на уровни базы то второй слаг после удаления нам не даст создать, а логически должен быть. проблема второго варианта что после удаления мы не можем восстановить статью на том же урле, а это плохо.
Перед удалением записи меняем слаг (я добавляю номер, делаю проверку, добавляю ещё если проверка это требует). Но вообще это зависит от политики бизнес-логики, возможно запись должна остаться в "архиве" и быть занята "вечно" (допустим, это артикул).
Наверно лучше добавлять не через Request, а добавить в модель метод boot class Post extends Model { public static function boot() { parent::boot(); self::creating(function ($model) { $model->slug = Str::slug($model->title); });
Здравствуйте, это не правильный подход, дело в том, что slug по seo не должен менятся, потому что индиксация пропадет. Если у модели меняется title то эта страница полностью выпадает из поисковых систем, для них это уже новая статья или продукт .Вы правильно сделали через trait , и уникальность более менее пойдет , лучше конечно делать просто slug, и проверять при создании на уникальность, а если он не уникальный, тогда добавлять id или timestamp. вот я вам накидал более менее нормальный trait. А в роуте вы просто указываете какое поле у параметра тянуть .конечно его можно улучшить при желании. И ваш метод, тоже можно использовать, если вы 100% знаете , что никто никогда не сможет изменить title - что очень маловероятно, поэтому нельзя получать слаг на основе динамического поля.
снимите видео по популярным паттернам, как это все используется на ларавел, ребята накидайте лайков, что бы он это увидел
Расскажи про MongoDB (желательно с CRUD, пагинацией, с фильтрацией), Elasticsearch (так же с пагинацией и прочим). С примерами и хорошими практиками. Будет пушка! С Redis уже есть, за что отдельный лайк от меня)))
Спасибо! "Датабазе" топ! )
Поржал с ситуации с телегой)
Спасибо за урок)
Классный урок! Очень жду про Elasticsearch прям мастхев
спасибо за ролик
первый случай: не рассмотрел вариант создания такого же поста с такимже слагом: нужна какая-то магия, чтоб слаги не дублировались (добавлялись индексы и проч: slug, slug-1, slug-2 и тд...)
второй способ какой-то нежизнеспособный. если есть задача от сеошника иметь слаги, то наверное надо ими управлять как-то, сохранять. тайтл поменялся - слаг изменился, пост теперь недоступен по старой ссылке
а вообще надо бы посоветовать использовать какие-нибудь готовые решения, где все это продумано, например, spatie
Отличное видео
Ролик супер. Хотелось бы короткий но ёмкий ролик про теорию реляционных баз данных. Чего там по полгода в институтах преподают этот курс? Используется ли оно на практике? Как часто?
Спасибо за урок!
спасибо ) полезный материал!
Ого, автор жив)
а про сео и мултиязычные категории aws и digital ocean расскажешь ?)
3й вариант интересный с точки зрения изучения фреймворка, но в жизни это полный ахтунг ибо будут дубли страниц и очень много и от них потом будет очень сложно избавиться. Так же с редиректами никак не поработать, когда будете избавляться от дублей или просто изменится заголовок.
Третий способ очень интересный, но конечно далек от жизни, потому что у внутреннего сеньора есть внутренний тимлид, который знает наверняка, что сегодня сеошнику нужно генерировать автоматически, но наступит день икс, когда понадобится поменять слаг(на более короткий например), а у вас поля то и нет, и что тогда?)))
Отличная инструкция: "Как сжить со света ненавистного SEO-шника". ✌😼🏴☠
Ибо SEO-шника после такой реализации обязательно (и очень скоро) навестит Кондратий и заобнимает вусмерть. ))
А всё потому, что Гоогле с Яндексом начнут слать письма ему "с того света" о том, сколько у него дублей страниц, и как низко будет ещё падать его подопечный сайт в поисковой выдаче. 😝
И дело не в тех самых "дурачках", о которых автор в ролике упоминает, а в том, что найдутся умники, которые специально нагенерят для поисковиков мусорных ссылок для дублей контента. Ибо нефиг лезть в ТОП поисковой выдачи! 😉
Спасибо!
датабазе))
спасибо)
супер
КотоЛьвище передаёт пример
У первого варианта есть еще один затык. если мы используем софтдэлит и уникальное поле на уровни базы то второй слаг после удаления нам не даст создать, а логически должен быть. проблема второго варианта что после удаления мы не можем восстановить статью на том же урле, а это плохо.
Перед удалением записи меняем слаг (я добавляю номер, делаю проверку, добавляю ещё если проверка это требует). Но вообще это зависит от политики бизнес-логики, возможно запись должна остаться в "архиве" и быть занята "вечно" (допустим, это артикул).
Наверно лучше добавлять не через Request, а добавить в модель метод boot
class Post extends Model
{
public static function boot() {
parent::boot();
self::creating(function ($model) {
$model->slug = Str::slug($model->title);
});
static::updating(function($model)
{
$model->slug = Str::slug($model->title);
});
}
}
Азиз Азизов)
Здравствуйте, это не правильный подход, дело в том, что slug по seo не должен менятся, потому что индиксация пропадет. Если у модели меняется title то эта страница полностью выпадает из поисковых систем, для них это уже новая статья или продукт .Вы правильно сделали через trait , и уникальность более менее пойдет , лучше конечно делать просто slug, и проверять при создании на уникальность, а если он не уникальный, тогда добавлять id или timestamp. вот я вам накидал более менее нормальный trait. А в роуте вы просто указываете какое поле у параметра тянуть .конечно его можно улучшить при желании. И ваш метод, тоже можно использовать, если вы 100% знаете , что никто никогда не сможет изменить title - что очень маловероятно, поэтому нельзя получать слаг на основе динамического поля.
Ахаха датабазé, спс поржал 😂
Круто, давно ждали! Спасибо) Еще проблема второго варианта, что будут создаваться дубли страница, например 1-post будет тоже самое что и 1-ne-post.
То есть сео уже до api добралось?
А почему php .\artisan а не php artisan?
Это после курса?