Комментарии 51
Спасибо Вам еще раз за труд.
НЛО прилетело и опубликовало эту надпись здесь
А можно ли этот плагин прикрутить к друпаловскуму модулю FCKeditor и будет ли он там работать?
спасибо
ужас какой…
и это современный файловый менеджер..?
и это современный файловый менеджер..?
Ну вот, пример работы уж не работает :(
StopDesign, а что не так? Зато он быстрый. Конечно можно было бы завернуть его в какой-нибудь красивый фантик, например мой любимый Ext, но здесь я думаю это и не нужно.
StopDesign, а что не так? Зато он быстрый. Конечно можно было бы завернуть его в какой-нибудь красивый фантик, например мой любимый Ext, но здесь я думаю это и не нужно.
Интерфейс плохой. Много лишних элементов. Они еще и «пляшут» как попало…
И открывать отдельное окно браузера, чтобы файл выбрать — это перебор.
А если быстрый — это хорошо.
Насчет «завернуть в красивый фантик» — могут быть проблемы: обычно в таких штуках половина оформления сделана хардкодингом.
И открывать отдельное окно браузера, чтобы файл выбрать — это перебор.
А если быстрый — это хорошо.
Насчет «завернуть в красивый фантик» — могут быть проблемы: обычно в таких штуках половина оформления сделана хардкодингом.
отлично! спасибо!
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Подглючивает сайтик…
Хы-хы, хабраэфект? ^_^
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Подглючивает сайтик…
Хы-хы, хабраэфект? ^_^
Capa, Creep — знакомые места)
Вот только пару дней назад искал достойный файловый менеджер на PHP. Обьязательно на днах попробую
Вот только пару дней назад искал достойный файловый менеджер на PHP. Обьязательно на днах попробую
Супер! Мы давно такой искали… Будем использовать у себя в проектах и багтестить заодно.
К сожалению, визуально у меня ничего не изменилось, новые поля не добавились, да и папку скрипт прочитать не может :( Что я делаю неправильно?
Изменения должны быть видны, так как стандарная папка filemanager меняет содержание на новое (так должно быть по крайней мере). Может не туда скопировали папку? Или это кэш?
Версия с кешем отпадает, так как в разных браузерах одно и то же. Пробовал разными способами — заливал полностью новый FckEditor, скачанный с вашего сайта, пробовал отдельно папку — результат одинаков ._О
Папки создаются, файлы заливаются, однако ничего не отображается. Выглядит нижняя панель следующим образом:
Папки создаются, файлы заливаются, однако ничего не отображается. Выглядит нижняя панель следующим образом:
а как с безопасностью? вроде у FCKeditor дырки были. есть инфа у Вас?
Отвратительно.
Предложите лучшее, хабровцы оценят по достоинству.
sftp/ftp, лол.
И объяснять каждой секретарше, как пользоваться и потом вставлять нужные ссылки? А тут более-менее интуитивно понятно.
ЗЫ: следуя вашей логике от CMS надо вообще отказаться в принципе.
ЗЫ: следуя вашей логике от CMS надо вообще отказаться в принципе.
Секретарша должна отвечать на звонки и говорить с людьми, а не администрировать контент сайта.
Считаете что любой владелец сайта/блога должен содержать веб-мастера или веб-отдел с дизайнерами, ретушерами, верстальщиками, редакторами и контент-менеджерами?
Впрочем, в одном вы правы. Администрировать сайты построенный на большинстве современных CMS хоть халявных, хоть платных может не каждая секретарша. Но это не потому что секретарши тупые, а потому что редакторские интерфейсы чудовищные.
Впрочем, в одном вы правы. Администрировать сайты построенный на большинстве современных CMS хоть халявных, хоть платных может не каждая секретарша. Но это не потому что секретарши тупые, а потому что редакторские интерфейсы чудовищные.
От битриксов, уми цмс, друпала, джамблы, неткатов всяких и прочего говна — да, всенепременно отказаться.
Понимаете, мне кажется отвратительной не конкретно Ваша разработка, а вообще идея файловых менеджеров, встроенных в визивиг редакторы. Файловый, блядь, менеджер! Внутри визивиг, блядь, редактора! Одно говно обмазываем другим говном. Кому все это нужно? Кому нужен весь этот говнокод, весь этот говноинтерфейс, все эти деревянные велосипеды, которые люди выдумывают от банального нежелания учиться? У них, блядь, девочка-секретутка будет администрировать сайтик, так что сделайте, пожалуйста, так, чтобы ей все было понятно и легко, как в ворде! Так давайте сразу же обезьянку посадим!
Есть Markdown, Textile, етсетера. Есть HTML, который сам по себе нихуя не сложный. Есть стандартные протоколы для передачи данных с кучей отличнейших клиентов. Есть администратор, который может настроить доступ в папочку /uploads/ по этим протоколам. Но все это, блядь, никому не нужно, потому что с одной стороны находится обленившееся мудачье, не желающее тратить время на изучение новых вещей, а с другой стороны находится куча пэхеров, которые готовы плодить говнокод тоннами. Достало.
Есть Markdown, Textile, етсетера. Есть HTML, который сам по себе нихуя не сложный. Есть стандартные протоколы для передачи данных с кучей отличнейших клиентов. Есть администратор, который может настроить доступ в папочку /uploads/ по этим протоколам. Но все это, блядь, никому не нужно, потому что с одной стороны находится обленившееся мудачье, не желающее тратить время на изучение новых вещей, а с другой стороны находится куча пэхеров, которые готовы плодить говнокод тоннами. Достало.
Разработка как бы не моя ;-) Не горячитесь. Если есть спрос — будет и предложение, это и так ясно. Просто надо понимать, что подобные инструменты появились для упрощения работы. Могу привести пару примеров, когда применение их вполне оправдано. Но, думаю, не стоит продолжать флэйм.
если вам не трудно — приведите пару примеров, где это оправдано, хотя б 3. спасибо.
>пару примеров, где это оправдано, хотя б 3
Так три или пару? :)
Вообще чисто мое мнение, что фтп нужен для быстрой и надежной передачи достаточно большого количества или просто объемных файлов. Использовать его для того, чтобы вставить картинку в пост на блоге — нет, можно, конечно, никто не спорит. Но я не сказал бы, что это лучший вариант. Итак, пару примеров:
1. Маленькая фирма. Штат ограничен. Кому заниматься обновлением сайта, кроме как не секретарше (знаю, что достал я с секретаршами:) )? А для студии, которая делала этой маленькой фирме сайт, гораздо проще сделать WYSIWYG редактор с аплоадом файлов, чем объяснять директору фирмочки, что секретарше стоило бы выучить html на базовом уровне. Ведь у директора сразу появится вопрос — на кой черт и за что он платит деньги, если ему надо в дополнение ко всему еще и людей обучать.
2. Уже упомянутые выше блоги, но это не лучший пример.
3. Различные баг-трекеры и тестовые системы (пример — tesklink, там есть свой броузер файлов и используется tinymce и fckeditor в качестве редакторов). Нужен ли там — WYSIWYG, это спорно, конечно. Но вот броузерный аплоадер просто необходим.
Так три или пару? :)
Вообще чисто мое мнение, что фтп нужен для быстрой и надежной передачи достаточно большого количества или просто объемных файлов. Использовать его для того, чтобы вставить картинку в пост на блоге — нет, можно, конечно, никто не спорит. Но я не сказал бы, что это лучший вариант. Итак, пару примеров:
1. Маленькая фирма. Штат ограничен. Кому заниматься обновлением сайта, кроме как не секретарше (знаю, что достал я с секретаршами:) )? А для студии, которая делала этой маленькой фирме сайт, гораздо проще сделать WYSIWYG редактор с аплоадом файлов, чем объяснять директору фирмочки, что секретарше стоило бы выучить html на базовом уровне. Ведь у директора сразу появится вопрос — на кой черт и за что он платит деньги, если ему надо в дополнение ко всему еще и людей обучать.
2. Уже упомянутые выше блоги, но это не лучший пример.
3. Различные баг-трекеры и тестовые системы (пример — tesklink, там есть свой броузер файлов и используется tinymce и fckeditor в качестве редакторов). Нужен ли там — WYSIWYG, это спорно, конечно. Но вот броузерный аплоадер просто необходим.
Удобная загрузка файлов с привязкой к какому-то объекту (статье, новости, пользователю) и файловый менеджер — это разные вещи.
Если есть текстовые блоки с форматированной информацией, хотябы с минимальным форматированием, даже стили можно прописать заранее — красный блочек, синий блочек, рамочка картинки… чтоб это все вписывалось в дизайн и потом уже редактор сайта будет использовать их для создания контента — вставка картинок, вставка файлов и ссылок к ним (повторюсь что это делается в блоках с форматируемым текстом). Там где структура подразумевает картинку (вид товара к примеру), там безусловно указывается именно картинка в админке без каких либо файловых менеджеров.
спасибо.
но если подумать, что у сайта есть WYSIWYG редактор, то какая разница какой там аплоад файлов, результат будет не таким как ожидает разработчик сайта. и в итоге или кому-то придется над этим работать или на сайт попросту забьют.
но если подумать, что у сайта есть WYSIWYG редактор, то какая разница какой там аплоад файлов, результат будет не таким как ожидает разработчик сайта. и в итоге или кому-то придется над этим работать или на сайт попросту забьют.
Поддержу ваш «крик души», но и заступлюсь за интерфейсы.
Люди, которые умеют делать интерфейсы (а таких в мире — единицы), почему-то не взялись за интерфейс администратора сайта. Нет хороших визуальных редакторов. Нет удобной загрузки файла (даже одного)! Возможно, веб-разработчикам не хочется терять рынок поддержки готовых сайтов… Но не думаю, что так вот сразу все смогут редактировать контент, даже в хорошей админке. Просто заказчик совершенно не ценит такие штуки, да и ничего в них не понимает, чаще всего. А дизайнерам не интересно делать какие-то внутренние механизмы, которые никто не увидит. Поэтому их делают программисты, руководствуясь удобством разработки, а не использования. И время на это выделяется по остаточному принципу… А программисты не только не могут сделать нормальный интерфейс, но даже и не понимают, чем плохо то, что они сделали.
Хороший интерфейс администрирования сайта — это сложно. Очень сложно. Но он нужен и может быть сделан.
Люди, которые умеют делать интерфейсы (а таких в мире — единицы), почему-то не взялись за интерфейс администратора сайта. Нет хороших визуальных редакторов. Нет удобной загрузки файла (даже одного)! Возможно, веб-разработчикам не хочется терять рынок поддержки готовых сайтов… Но не думаю, что так вот сразу все смогут редактировать контент, даже в хорошей админке. Просто заказчик совершенно не ценит такие штуки, да и ничего в них не понимает, чаще всего. А дизайнерам не интересно делать какие-то внутренние механизмы, которые никто не увидит. Поэтому их делают программисты, руководствуясь удобством разработки, а не использования. И время на это выделяется по остаточному принципу… А программисты не только не могут сделать нормальный интерфейс, но даже и не понимают, чем плохо то, что они сделали.
Хороший интерфейс администрирования сайта — это сложно. Очень сложно. Но он нужен и может быть сделан.
Вы ни разу неправы с обоих сторон.
>Есть Markdown, Textile, етсетера. Есть HTML,…
>потому что с одной стороны находится обленившееся мудачье, не желающее тратить
>время на изучение новых вещей
эффективность работы с любым интерфейсом максимальна продуктивна, если интерфейс знаком. В данном случае интерфейс MS знаком большинству пользователей, а экзотические языки разметки — очень небольшой группе разработчиков. А уж заставлять писать статьи на валидном HTML — чистое издевательство.
> а с другой стороны находится куча пэхеров, которые готовы плодить говнокод тоннами
Когда речь идет об UI абсолютно не принципиально на каком языке написан этот самый интерфейс.
ЗЫ А файл-менеджер действительно так себе. Родной FCK-менеджер хорош тем, что не задает лишних вопросов.
>Есть Markdown, Textile, етсетера. Есть HTML,…
>потому что с одной стороны находится обленившееся мудачье, не желающее тратить
>время на изучение новых вещей
эффективность работы с любым интерфейсом максимальна продуктивна, если интерфейс знаком. В данном случае интерфейс MS знаком большинству пользователей, а экзотические языки разметки — очень небольшой группе разработчиков. А уж заставлять писать статьи на валидном HTML — чистое издевательство.
> а с другой стороны находится куча пэхеров, которые готовы плодить говнокод тоннами
Когда речь идет об UI абсолютно не принципиально на каком языке написан этот самый интерфейс.
ЗЫ А файл-менеджер действительно так себе. Родной FCK-менеджер хорош тем, что не задает лишних вопросов.
Про какие [лишние вопросы] Вы говорите?
Изменить размер картинки при загрузке — единственный дополнительные поля с галочкой. Если редактор сайта загрузит фото на 5 мегапикселей (ну лень ему или некогда открывать графический редактор и менять размер фото), а потом чтобы оно хорошо смотрелось на странице сделает width=«200» height=«300» у нее, то это принесет больший вред.
Изменить размер картинки при загрузке — единственный дополнительные поля с галочкой. Если редактор сайта загрузит фото на 5 мегапикселей (ну лень ему или некогда открывать графический редактор и менять размер фото), а потом чтобы оно хорошо смотрелось на странице сделает width=«200» height=«300» у нее, то это принесет больший вред.
>Про какие [лишние вопросы] Вы говорите?
Обычному пользователю знать порядок хранения документов на сервере вообще не надо. Он вообще не должен думать о внутреннем устройстве CMS. Об этом должны думать разработчики CMS.
Размеры картинки — то же самое. Эта опция вредна и в оригинальном FCK. Есть две опасности.
1) поользователь не может просчитать пропорции картинки и обязательно их нарушит.
2) ужатая картинка потеряет качество.
Если п.2 пренебречь — FCK позволяет масштабировать картинки в тексте, при этом пропорции картинок сохраняются. Можно распарсить текст документа и привести размеры закаченных картинок к том что пользователь задал визуально через визивиг. В этом случае для любого материала можно получить список картинок. И в этом случае еще решается вопрос о том как удалить страницу и все связанные с ней картинки.
Обычному пользователю знать порядок хранения документов на сервере вообще не надо. Он вообще не должен думать о внутреннем устройстве CMS. Об этом должны думать разработчики CMS.
Размеры картинки — то же самое. Эта опция вредна и в оригинальном FCK. Есть две опасности.
1) поользователь не может просчитать пропорции картинки и обязательно их нарушит.
2) ужатая картинка потеряет качество.
Если п.2 пренебречь — FCK позволяет масштабировать картинки в тексте, при этом пропорции картинок сохраняются. Можно распарсить текст документа и привести размеры закаченных картинок к том что пользователь задал визуально через визивиг. В этом случае для любого материала можно получить список картинок. И в этом случае еще решается вопрос о том как удалить страницу и все связанные с ней картинки.
1 — В инструкции к изменениям размеров есть разъяснения — ссылка [?] — что если оставить 0, то сделается пропорционально.
2 — Почему она потеряет качество? Преобразует imagemagick'ом, он достойно это делает, практически не ухудшая его
2 — Почему она потеряет качество? Преобразует imagemagick'ом, он достойно это делает, практически не ухудшая его
1) Инструкции никто никогда не читает.
2) Масштабировать GIF — занятие нетривиальное. Можно конечно в три прохода. Но даже в Photoshop потерь качества не избежать.
2) Масштабировать GIF — занятие нетривиальное. Можно конечно в три прохода. Но даже в Photoshop потерь качества не избежать.
1 — неправда, если нужно читают, help находится прямо около функционала
2 — прекрасно ресайзит — floomby.ru/content/XOwSs8Qk2k/
2 — прекрасно ресайзит — floomby.ru/content/XOwSs8Qk2k/
1. Я рад за ваших пользователей. Они исключительные
2. Картинка по png. Я говорил про оптимизированный gif. Пропустите черно-белый график/схему/таблицу без доп. манипуляций и посмотрите что получится.
Самый главный вопрос — зачем пользователю _думать_ о структуре директорий для файлов возражений не имеет?
2. Картинка по png. Я говорил про оптимизированный gif. Пропустите черно-белый график/схему/таблицу без доп. манипуляций и посмотрите что получится.
Самый главный вопрос — зачем пользователю _думать_ о структуре директорий для файлов возражений не имеет?
2 — эта картинка как раз 256-цветный gif, уменьшенный в размере раза в 3.
Не пойму про "_думать_". Пользовательсам может раскидать материалы по папкам для удобства их использования в других текстовых блоках. Эти файлы предназначаются для данных, которые вводятся через визуальный редактор. Он их сам стркутурирует на серваке. Если не хочет — кинет все в кучу, без папок — его право.
Не пойму про "_думать_". Пользовательсам может раскидать материалы по папкам для удобства их использования в других текстовых блоках. Эти файлы предназначаются для данных, которые вводятся через визуальный редактор. Он их сам стркутурирует на серваке. Если не хочет — кинет все в кучу, без папок — его право.
Интересненько!
Вот только имя параметра $Config['Delete'] можно сделать лучше.
Delete чего? А если другой кто-то напишет плагин и тоже захочет Delete что-нить?
Лучше что-то типа AllowFileDelete или что-то типа того.
См. «Совершенный код», главу про названия.
Вот только имя параметра $Config['Delete'] можно сделать лучше.
Delete чего? А если другой кто-то напишет плагин и тоже захочет Delete что-нить?
Лучше что-то типа AllowFileDelete или что-то типа того.
См. «Совершенный код», главу про названия.
Есть очень хорошее и качественное решение AjaxFileManager
www.phpletter.com/Our-Projects/Ajax-File-Manager-Project/
www.phpletter.com/Our-Projects/Ajax-File-Manager-Project/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Файловый менеджер для FCKeditor — FCKfsys 2.0 (PHP)