LINUX.ORG.RU

Редактор текста в Laravel с картинками и прикрепляемыми файлами

 , , , ,


0

2

Смотрю всякие туториалы по Laravel, везде показывают одно и тоже: как через CRUD сделать редактирование простой текстовой записи.

Но мне нужно другое: не просто редактировать текстовую запись, не просто всунуть WYSIWIG редактор, а иметь возможность вставлять в запись картинки, добавлять файлы, чтобы и картинки и файлы складывались на диск а не болтались в базе, и чтобы каждой записи соответствовала отдельная директория с файликами для этой записи.

И я не могу найти готовое решение.

Пока планирую такой путь: взять для редактирования какой-нибудь WYSIWIG-редактор типа TinyMCE или Summernote. Главное чтоб у этого редактора была возможность создания кастомных кнопок. Сделать кнопку, по которой будет вызываться контроллер, который создаст директорию с id записи (если таковой директории нет), а затем откроет какой-нибудь визуальный файловый менеджер (какой?), который натравлен на данную директорию.

В файловом менеджере можно будет добавлять картинки/файлы, получать их URL и вставлять в текст.

В связи с чем вопросы:

1. Существует ли похожее готовое решение? (laravel 5.5)
2. Какой редактор выбрать?
3. Какой файловый менеджер выбрать?

★★★★★

WYSIWIG

WYSIWIG-редактор

Это что-то новенькое. Расшифруй. А то я знаю только WYSIWYG, WYSIWYW, WYSIWYN, YAFIYGI и т. п.

anonymous
()
Ответ на: комментарий от shooter93

Я нашел вот такую статью, и сделал по ней:

https://web-programming.com.ua/podklyuchaem-tekstovyj-wysiwyg-redaktor-k-lara...

Но сразу появились вопросы:

— А как удалять картинки с диска, если они перестают использоваться в тексте?
— А как загружать не картинки, а прикрепляемые файлы и получать на них ссылки? И чтобы имена файлов были не рандомными а родными? И как удалять эти файлы?

То есть решение совсем-совсем начального уровня, без нужного естественного функционала.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

И чтобы имена файлов были не рандомными а родными?

Вот не советовал бы в файловую систему сохранять под родными именами. Потому что «родные имена» приходят от клиента, и могут быть с сюрпризами. Распределение имён тоже неравномерное, поэтому не вполне очевидно, как уменьшать число файлов, хранящихся в одной директории. С хешами проще. Если хеш считается от содержимого, то заодно получаешь возможность потом проверить файлы на целостность.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

1. Но ведь есть нормирование имен.

2. Если делать один каталог для одной записи, то в нем пересечение имен зависит только от пользователя.

3. Если имя повторяется, файл можно не принять, и сказать пользователю что файл с таким именем уже есть. Да, это хорошо работает для метода «одна запись - одна директория», а не когда все файлы в одну директорию сваливаются.

4. Вместо хеша лучше уж случайную строку+таймштамп. У хешей могут быть коллизии. Хеш файлов с разным именем, но одинаковым содержимым совпадет.

5. Если для картинок случайное имя - это норм (неудобно, но норм), то для прикрепляемых файлов - вообще ад. Мало кто нормально разберется что значит скачанный файл pT12s758GFdjS798bAfF9.zip

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea
  1. Если файл это не просто файл на диске, а ещё и запись в БД, то можно хранить там человеческое имя и отдавать с ним. Правда на каждый запрос придётся дёргать php (php возвращает X-Accel-Redirect с указанием на файл, дальше nginx отдаёт файл сам).
MrClon ★★★★★
()
Ответ на: комментарий от MrClon


  • Если файл это не просто файл на диске, а ещё и запись в БД, то можно хранить там человеческое имя и отдавать с ним. Правда на каждый запрос придётся дёргать php (php возвращает X-Accel-Redirect с указанием на файл, дальше nginx отдаёт файл сам).


Обычно же пикчи тянут не по прямой ссылке и можно с фронта брать нормальное имя(если оно было).

ritsufag ★★★★★
()
Ответ на: комментарий от Xintrea

— А как удалять картинки с диска, если они перестают использоваться в тексте?

Сохранять вместе с текстом список файлов, которые в нём используются. При изменении текста сравнивать новый список со старым. Если в новом списке отсутствуют какие-нибудь файлы из старого, и эти файлы не используются в других текстах, — то удалять.

theNamelessOne ★★★★★
()
Ответ на: комментарий от theNamelessOne

Это все примитивно, и не решает вот какую проблему.

Сейчас существующие решения позволяют закидывать на сервер добавляемую в редакторе картинку, и удалять ее если она удаляется в редакторе. И это происходит сразу в момент редактирования. Казалось бы, хорошо!

Но внизу есть кнопка «Сохранить». Предположим, человек ее не нажал. Что произойдет? Текст останется прежним со ссылками на картинки, а картинок на диске сервера нет.

И таких тонкостей до жопы. Я не понимаю, почему до сих пор не существует готового нормального решения, в котором все эти вещи учтены.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Сейчас существующие решения позволяют закидывать на сервер добавляемую в редакторе картинку, и удалять ее если она удаляется в редакторе. И это происходит сразу в момент редактирования. Казалось бы, хорошо!

Но внизу есть кнопка «Сохранить». Предположим, человек ее не нажал. Что произойдет? Текст останется прежним со ссылками на картинки, а картинок на диске сервера нет.

Нет, ты меня неправильно прочитал.

При изменении текста сравнивать новый список со старым. Если в новом списке отсутствуют какие-нибудь файлы из старого, и эти файлы не используются в других текстах, — то удалять.

Это происходит, когда когда ты нажимаешь кнопку «сохранить», а не в процессе редактирования текста.

theNamelessOne ★★★★★
()
Ответ на: комментарий от Xintrea

Не знаю насчет ларавеля, но я пришел к выводу, что куда удобнее использовать блочные редакторы типа Editor.js. Во-первых, их контент ты в базе хранишь в json - то есть из него извлечь картинки гораздо проще (и красивее, на мой взгляд), чем парсить html-ки и вытаскивать из них ссылки на картинки. Потому что ты можешь определить свой блок «картинка» и сделать так, что в итоговый json будут подставляться idшники, например, а не ссылки. Во-вторых, это позволит тебе удобно управлять рекламой (например). Создаешь свой рекламный блок для editor.js с нужными полями и свойствами и размещаешь его где угодно между блоками «абзац». А при отрисовке статьи с помощью шаблона проектирования «стратегия» ты определяешь правила отрисовки блоков. То есть ты уйдешь от парсинга html с контентом статей вообще. В любой момент стратегию отрисовки блоков ты можешь изменить - и тебе не придется парсить html всех статей, переделывая там все. Вообще хранить контент статей в виде блоков в json гораздо удобней, чем в виде html целиком.

По поводу удаления картинок, которые были загружены, но в статью не добавлены. Раз в сутки по крону забирай из базы html всех статей (или json-структуры, если решил блочный редактор юзать). Парсишь его (если html) или декодируешь (если json) и находишь там все картинки. После чего ты пробегаешься по таблице в БД с картинками и удаляешь те записи изображений, которые у тебя не присутствуют в статьях (или еще где-либо) и которые были загружены более суток назад (например). Ну и файлы следом выпиливаешь. Таким образом, ни к чему не привязанные картинки у тебя будут автоматически удалятся раз в день.

Я советую тебе сделать загрузку картинок не прямо в текст статьи, а отдельным модальным окном. То есть у тебя будет везде, где нужно (не только в редакторе статьи) кнопка «изображения». Нажимаешь на нее - открывается окно с табличкой загруженных изображений, всякие сортировки, поиски и т.п. Сверху кнопка «загрузить», позволяющая загрузить еще. В самом редакторе статей у тебя будет кнопка «изображения», при нажатии на которую у тебя будет открываться это окно для загрузки и просмотра загруженных картинок. Это позволит тебе одну и ту же картинку использовать многократно, если это требуется, без необходимости повторно ее же загружать, плодя лишние файлы на диске.

P.s. к сожалению, я не уверен, что найдется готовое решение для этого. Но я пилю для таких целей свои «балалайки», потому что бэк у меня везде в виде REST API, а админки я пилю на React. Но в таком случае монстры вроде Laravel, Django и т.п. вообще не нужны и избыточны.

dimuska139 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.