Создание блога

[miketomlin]

Ну вот есть статья, там должна быть кнопка редактировать?

Нафиг-нафиг. Максимально отделяй морду сайта от CMS'ки (админки). Можешь даже сначала сделать морду, а потом админку. Только учитывай при создании морды, как потом ее контентом управлять из админки.

Для слагов лучше сделать отдельную таблицу? Чтобы и редиректы хранить.

Это сложнее и поиск по таблицам будет дольше. Я выше написал, что различать осн. сущность и редирект можно по флажку или отдельному полю. Соответственно таблица одна для одной разновидности сущности. Слаги уже давно хранятся вместе с соотв. сущностями. Иное – это древность, когда слаги были всего лишь примочкой для красоты. Также выше писал, что тебе для своего блога можно пока забить на редиректы. Они нужны, когда ты за кем-то подчищаешь адреса. Или когда в твой блог пишут обычные юзеры, которые меняют заголовки/слаги каждую неделю. Выше уже рассказали, как делается редирект для такого случая: для выбора сущности ты ориентируешься на числовой id и делаешь редирект, если прилагаемый к этому id слаг на входе не соответствует заложенному в БД. Тебе пока это тоже нафиг не надо. Делай просто /<slug> или /post/<slug>

P.S. Для первого варианта можешь роуты хранить отдельно, а потом обходить таблицу постов безусловно или за счет какого-то обобщенного роута на дне твоего «стека». Также есть фишка все слаги/сущности «первого порядка» хранить в корневой таблице. Уже давал ссылку на пример дампа такой таблицы. Вот еще один вариант (см. первую таблицу): https://gency.ru/g-drive-blog (готовые посты от всего прочего отделяются по полю category, в частности пост становится публичным/готовым, т.е. попадает в списки, когда ты ему назначаешь категорию, отличную от нулевой или NULL'вой; в текущей версии есть категория Draft, так что скорее всего черновики помечаются нулевой категорией).

 

[firep91613]

Нафиг-нафиг. Максимально отделяй морду сайта от CMS'ки (админки). Можешь даже сначала сделать морду, а потом админку. Только учитывай при создании морды, как потом ее контентом управлять из админки.

Ну админки еще нету, только регистрация и авторизация. Пока что я сделал просто котроллер для добавления статей.

Это сложнее и поиск по таблицам будет дольше. Я выше написал, что различать осн. сущность и редирект можно по флажку или отдельному полю. Соответственно таблица одна для одной разновидности сущности. Слаги уже давно хранятся вместе с соотв. сущностями. Иное – это древность, когда слаги были всего лишь примочкой для красоты. Также выше писал, что тебе для своего блога можно пока забить на редиректы. Они нужны, когда ты за кем-то подчищаешь адреса. Или когда в твой блог пишут обычные юзеры, которые меняют заголовки/слаги каждую неделю. Выше уже рассказали, как делается редирект для такого случая: для выбора сущности ты ориентируешься на числовой id и делаешь редирект, если прилагаемый к этому id слаг на входе не соответствует заложенному в БД. Тебе пока это тоже нафиг не надо. Делай просто /<slug> или /post/<slug>

Ок. Тогда сделаю пока что без редиректов. У меня сейчас две таблицы для статей - articles и articles_content. В articles: id, name, putdate, announcements, в articles_content: id, content, article_id. Соответственно в articles добавляю колонку slug и туда буду вписывать. Так нормально для начала?

 

[firep91613]

P.S. Для первого варианта можешь роуты хранить отдельно, а потом обходить таблицу постов безусловно или за счет какого-то обобщенного роута на дне твоего «стека». Также есть фишка все слаги/сущности «первого порядка» хранить в корневой таблице. Уже давал ссылку на пример дампа такой таблицы. Вот еще один вариант (см. первую таблицу): https://gency.ru/g-drive-blog (готовые посты от всего прочего отделяются по полю category, в частности пост становится публичным/готовым, т.е. попадает в списки, когда ты ему назначаешь категорию, отличную от нулевой или NULL'вой; в текущей версии есть категория Draft, так что скорее всего черновики помечаются нулевой категорией).

Ну пока что так, в отдельном файле:

$router->get('articles/create', 'articles/create.php')->only('auth');
$router->get('articles/(?P<slug>[a-z0-9-]+)', 'articles/show.php');
$router->post('articles', 'articles/store.php');
$router->delete('articles', 'articles/destroy.php');

 

[firep91613]

Все хорошо работает. Только один ньюанс хочу уточнить. Есть статья, называется "C++ language", сейчас в слаге "c-language", но это как-то не правильно, все таки это не Си. Заменять "+" на слово "plus"? По идее же не должно быть никаких "+"? Цифры, буквы, дефис.

 

[miketomlin]

У меня сейчас две таблицы для статей - articles и articles_content. В articles: id, name, putdate, announcements, в articles_content: id, content, article_id. Соответственно в articles добавляю колонку slug и туда буду вписывать. Так нормально для начала?

Перенеси content в articles и удали articles_content.

Заменять "+" на слово "plus"? По идее же не должно быть никаких "+"? Цифры, буквы, дефис.

Заменить "++" на "-plus-plus". Вообще плюс в URL-кодировке обозначает пробел, а символ "+" надо кодировать. Поэтому нафиг этот символ.

 

[miketomlin]

Заменить "++" на "-plus-plus".

Как вариант: cpp-language

 

[firep91613]

Перенеси content в articles и удали articles_content.

А почему так как у меня плохо? Я просто читал в книге по БД, там автор делал две таблицы: Order и OrderItems. Подумал сделать так же.

 

[firep91613]

А JS'ом слаги делать плохая идея? Ну типо сразу пишешь название статьи и тут же поле со слагом заполняется.

 

[miketomlin]

Я просто читал в книге по БД, там автор делал две таблицы: Order и OrderItems.

Автор делал правильно, а ты нет. Там OrderItems – связующая таблица между Order и Item(s) в связи многие-ко-многим.

Если бы у тебя статья конструировалась из принадлежащих только ей блоков, можно было использовать две таблицы вроде articles и blocks. И то это не дотягивает до многие-ко-многим. Это была бы связь один-ко-многим.

 

[miketomlin]

А JS'ом слаги делать плохая идея?

Я тебе выше советовал делать слаги именно на клиенте, т.е. JS'ом. Внимательнее читай посты.

 

[AnrDaemon]

Вообще плюс в URL-кодировке обозначает пробел

Нет. Плюс означает пробел только в строке запроса, но не в пути и не в фрагменте.
Если у тебя где-то в пути плюс ВНЕЗАПНО организовался вместо пробела (curseforge, привет!), значит, где-то внутри путь передаётся как параметр и не сделано корректное перекодирование.

А JS'ом слаги делать плохая идея? Ну типо сразу пишешь название статьи и тут же поле со слагом заполняется.

Это как раз хорошая идея, к тому же позволяет на ходу руками подкорректировать особо отдельные случаи (C++ => cpp, см. выше).

А вообще слаги - тема спорная.

 

[firep91613]

Ок. Сделаю JS'ом.

 

[miketomlin]

Нет. Плюс означает пробел только в строке запроса, но не в пути и не в фрагменте.

Путь по символам ничем не отличается от строки запроса/фрагмента кроме запрета на вопросительный знак по понятной причине. Я вспомнил. Там другое. Кодировать пробел плюсом – это устаревшее (%20 – современное). Но обозначать можно. Типичный пример – строка поискового запроса. И т.к. она чаще всего передается в строке запроса, ты мог подумать, что это специфично для строки запроса. Но в наших движках, например, строка поискового запроса часто передается в пути (/search/bla-bla-bla) и все норм., т.е. плюс можно использовать точно так же, как в строке запроса.

 

[AnrDaemon]

Путь по символам ничем не отличается от строки запроса/фрагмента

Ссылку на RFC.

 

[firep91613]

Как спроектировать админку? В папке контроллеров создать папку admin?

/admin
   - index.php
   - login.php
   - dashboard.php
   ...

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

$router->get('articles/create', 'articles/create.php')->only('auth');

Но надо же тогда, получается иметь маршрут такой?

$router->get('admin/articles/create', 'articles/create.php')->only('auth');

 

[firep91613]

Да, еще сейчас есть таблица users. Я думаю добавить туда колонку is_admin, сделать там, допустим у админа значение 1, а у обычного юзера - 0. Что думаете по этому поводу? Или должна быть отдельная таблица?

 

[miketomlin]

Ссылку на RFC.

Поищи в WHATWG URL Spec. Там где-то есть тремя короткими абзацами-предложениями, из каких символов может состоять путь, строка запроса и фрагмент. Путь описан через его компоненты, отделенные слешем. И там же еще про «.» и «..» говорится. А про устаревшее кодирование плюсом – это RFC 1xxx, а %20 – RFC 3xxx, которая тоже достаточно древняя. В статье мана пыха по поводу функции построения строки запроса, кажется, есть точные номера.

Сам-то дашь ссылку на RFC с прувом твоей точки зрения?

 

[miketomlin]

Как спроектировать админку?

Я голосую за админку в виде отдельного приложения. Но это опять надо роуты тащить в БД, чтобы не дублировать код Ща вообще распространены админки, которые связаны с мордой сайта только по БД + upload-dir (или upload-stor), либо через API в основном для морды.

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

Ее надо наверно надо убрать?

Да, я уже писал: снести нафиг!

 

[miketomlin]

Или должна быть отдельная таблица?

Одной достаточно. Еще иногда данные доступа админа прописываются прямо в конфиге (отдельно или совпадают с данными доступа к БД со стороны приложения), а еще иногда аутентификация выполняется через СУБД (и данные доступа кешируются при успешной аутентификации).

Ты вообще можешь сделать для начала только админа без какого-либо разграничения прав. И позволить ему делать все или ограничить его возможности. Если ограничить возможности, то чтобы что-то сделать сверх них, нужно напрямую лезть в БД/ФС. Хотя обычные юзеры могут быть нужны для создания комментов, а не статей. Можешь тупо для админа использовать нулевой идентификатор, а для всех прочих комментаторов любые другие.

 

[miketomlin]

Я посмотрел таблицу пользователей блога, на который ссылался. Там «авторы» отличаются от обычных пользователей наличием слага:

(2, 'mike', 'Михаил', ...
(256, NULL, 'Дмитрий', ...

У админа числовой id – 0, но походу его функционал ничем не отличается от функционала др. авторов. У нас авторы сами модерирует свои статьи (комменты к ним), а если я как редактор вижу какие-то косяки в тексте, то просто показываю их авторам.