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

Во времена 5.2 заюзал пакеты laravel-filemanager и laravel-ckeditor. Подойдут тебе?

WYSIWIG

WYSIWIG-редактор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кажется мы говорим об одном и том же, но я не уверен

Я про атрибут download.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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