Денис Дыранов

Есть сайт, который хранит фотки на селектел. Сейчас сайт внезапно не работает и в логах:

/core/components/swift/model/swift/swiftmediasource.class.php : 115) [SwiftMediaSource] Could not authenticate: This service [swift] does not have access to the [common] endpoint.

То есть сайт не открывается вообще: 500 ошибка. Не работает, похоже, весь день. До этого всё было ок, ничего не трогали. SwiftMediaSource обновлён до последней версии. Есть идеи куда копать?

В очередной раз понадобилось перенести блог из Вордпресса в MODX. Раньше я для этого пользовался хитрым костылём с Articles. Сейчас он не работает, поэтому пришлось чинить. Доделывать мне его лень, так что это опять костыль. Но у меня он сработал.

Скачиваем файл, создаём новый сниппет, например, wpimport, вставляем в него текст из файла, и настраиваем всё параметры прямо в коде (я предупреждал — костыль!)

• На 20-й строке указываем путь к файлу, экспортированному из WP.
• На 100-й строке появляется функция, которая расставляет теги абзаца, которых в файле WP нет.
• 115-я строка — ID родителя (куда будем импортировать?)
• 119-я — ID шаблона для постов.
• На 126 устанавливается class_key Tickets. Если хотите, можете сделать ModResource.
• Со 132-й строки пробуем скопировать все изображения из WP в папку, указанную на 152-й строке. Попутно меняем css классы у картинок на bootstrap.
• На 180-й строке пытаемся поменять href у ссылок, внутри которых были картинки.
• 199 – Сохраняем в интротекст всё, что перед катом.
• 209,210 — вызываем функции, которые сохраняют description и keywords в соответстующие ТВ, если в WP вы использовали All In One SEO Pack. ТВ для сохранения указаны в самом конце.
• ТВ для тегов на 339-й строке.

Что-то я зачастил, так что постараюсь покороче. Вот картинка, которая всё объясняет:



Внутри: новый плагин CET Builder, удобная тема для админки и обновлённые AssetsTV и CKEditor.

У редакторов типа TinyMCE или CKEditora есть серьёзный недостаток – им нужны, не знаю как это по-русски, root elements. То есть, в большинстве случаев — этот долбаный тег p. Соотвественно, если мы хотим вставить в текст страницы чанк, то он у нас будет окружён этими p, что совсем не круто, особенно, если у нас в чанке какой-нибудь закрывающий div. Кроме того, мы даже картинку без этого p вставить не можем.

Есть много вариантов решения, но я решил сделать бронебойное: разбить поле content на блоки: RTE и обычная textarea, куда можно писать любой код и он не будет обрамляться. Теоретически, однажды это решение может превратиться в вариацию content blocks.

Продолжаю пилить свой набор дополнений Content Editor Tools.



Видео работы (как, кстати, вставлять видео?): youtu.be/uQEYW7e6Z54

Новое в CET_assetsTV:

• Возможность отобразить дропзону для загрузки файлов в отдельной панельке внизу окна.
• Возможность выбрать и вставить в content сразу несколько файлов.

Новое в CET_CKEditor:

• Новый плагин типографа (в настройках плагина на выбор: типографы Лебедева или Муравьева)
• Поддержка bootstrap (так же включается в настройках)
• Добавлен плагин bootstrapTabs
• Настроен autoGrow

На TinyMCE пока забил.

CET_assetsTV: yadi.sk/d/oEhPx2BKoEywn
CET_CKEditor: yadi.sk/d/PCWFwPG7oEyya

Это до сих пор сильно бета. И вообще, не факт что работает :-)

Если вам вдруг, не дай Бог, захотелось перенести блог из wordpress'а в Tickets, то у меня для вас очередной костыль.

Порядок действий:

1. Ставим Тикетс
2. Ставим Articles :-)
3. Заменяем файлы articlesimport.class.php и articlesimportwordpress.class.php в папке /core/components/articles/model/articles/import/ на эти: yadi.sk/d/dXcAXDKIo83UN
4. Создаём раздел Articles и нажимаем кнопку Импортировать. (Во всплывающем окне не работает комбобокс, так что для выбора опции импорта из ворпресса надо как-то исхитриться с клавиатуры — вниз и энтер :-))
5. Импортируем XML от WP. Статьи и комментарии станут тикетами.
6. Лезем в БД и меням class_key у контейнера со статьями с ArticlesContainer на TicketsSection.
7. Удаляем Articles и прочие Quip'ы.

Проверено 2 раза. Если что-то сломается — я не виноват :-)

Ах, да! Вероятно, если вы у контейнера Articles пропишите в настройках шаблон для дочерних документов, то он и подставится к тикетам.

Я так и не понял баг это или фича. Tickets сохраняет content, обработанный Jevix, в introtext. Делает это даже когда Jevix отключен. Чтоб избавиться от этого нужно отредактировать 2 файла: create.class.php и update.class.php по адресу /core/components/tickets/controllers/ticket/.

Я решил немного облегчить себе жизнь и сделал 2 плагина (на самом деле 3) для работы с контентом из админки. Этот набор плагинов я назвал Content Editor Tools, чтоб не путать их с похожими имеющимися.

Первое, это Rich Text Editor. Тут на выбор: TinyMCE или CKEditor. Второе: AssetsTV — это для работы с файлами. Пока всё в статусе беты.

Появилась бы отдельностоящая версия TicketComments, чтоб можно было бы просто комментарии цеплять к обычным ресурсам (или товарам) — было бы мне счастье. Но пока так. И в том виде, в котором сейчас существует Tickets меня напрягает одна вещь — то как тикеты отображаются в админке.

Поле с контентом становится очень узким, чтоб в правой части экрана отобразись дополнительные поля. Та же история в Articles, кстати. Зачем оно так мне совершенно не понятно. Поэтому я залез своими грязными лапами в файлик ticket.common.js (/assets/components/tickets/js/mgr/ticket/), чтоб сделать тикеты внешне похожими на обычные ресурсы modx. Так как я вообще ни разу не программист, получилось у меня это сделать не до конца: выбрать автора тикета теперь не получится, но в остальном вроде норм.


Теперь контент отображается как обычно: снизу и на всю ширину. Настройки страницы в соответствующей вкладке, комментарии в отдельной.

Собственно, вот мой ticket.common.js: yadi.sk/d/ytW6fEy3o6vgF

Задача следующая. К определенному ресурсу на сайте зарегистрированный пользователь оставляет заявку. В заявке некоторое количество полей (не просто комментарий, и поля могут быть разные в зависимости от конкретного ресурса) + обязательно возможность прикрепить файлы. Менеджеру сайта заявка приходит по почте и сохраняется где-то в базе сайта. Пользователь в личном кабинете видит все заявки, которые он оставлял и статус каждой: в очереди, исполняется, выполнена и т. д. Статус выставляет менеджер в админке. При смене статуса заявки пользователь получает письмо.

Это может быть заказ доставки груза и одного города в другой или вызов мастера на дом, или предложения компаний-партнеров по запросу, опубликованному на сайте.

Какой компонент проще заточить под решение такой задачи? FormIt — вроде как слабоват, даже когда научился сохранять формы. Tickets — не понятно как обстоят дела с дополнительными полями и можно ли грузить аттачи (вроде как к комментариям нет). EasyComm —?