А phpThumbOf не стал ставить по умолчанию?
Я ставил исходя из своего опыта. На самом деле я вообще мало пакетов использую, и тот же getResource практически никогда. Вот Wayfinder — вообще всегда. А под ресайзинг картинок часто свои процессоры пишу. Ведь phpThumb стандартно в MODX включен. Вот развернешь облачко, добавишь, что считаешь нужным, и мне отправляй, я гляну. Единственное, про что я забыл — Gallery. Тоже маст хэв.
думаю, надо добавить еще и sitemap.xml + robots.txt
Да, надо будет сразу включить. GoogleSiteMap воткнуть и MetaX. Еще TV-ху keywords.
Host: [[++site_url:replace=`http://== `:replace=`/== `]] Sitemap: [[++site_url]]sitemap.xml
Не по религии. Старайся полностью исключать операнды в чанках и шаблонах. Для роботс.тхт конечно еще можно закрыть глаза, но в целом по сайту вообще этого избегай.
Насчет дерева проще — их можно отметить как «Не показывать в дереве» — они все равно не нужны для редактирования, ну и не показывать в меню тоже выставлять
Скачать не дает — Пишет Ошибка: Ошибка — Нет доступа (кстати и профиль не дает редактировать)
Использую что-то подобное — скрипты от Kenters. Вот с источниками файлов, как их прописать не смог разобраться, буду копать.
Кстати да, как и у ilyautkin robots.txt и sitemap.xml в ресурсах + еще style.css (в нем вызов lessphp).
Единственный минус, в корне, они постоянно в Wayfinder мешаются, ну и смущают контент-менеджеров.
У меня как раз такой плагин часто использовался на сайтах. В него прописывался mainHost, и если хост не совпадал, то редиректилось на основной. Но на уровне nginx-а это гораздо правильней, так как нагрузки на движок нету.
А я в принципе не вижу особой опасности в этом… Если есть возможность прописать такое правило сразу в сборку, то можно заморочиться, а так — для каждого нового сайта прописывать правила — в любом случае когда-нибудь да забудешь…
А phpThumbOf не стал ставить по умолчанию? Думаешь, редко кто будет использовать? Просто я, например, без него уже не могу — особенно списки дочерних документов с кратким описанием и картинкой… Плюс помимо страниц 404 и 401, думаю, надо добавить еще и sitemap.xml + robots.txt Я их всегда ресурсами делаю и о них после даже не задумываюсь. robots.txt у меня такой, например:
User-agent: * Allow: / Disallow: /core/ Disallow: /connectors/ Disallow: /manager/ Host: [[++site_url:replace=`http://== `:replace=`/== `]] Sitemap: [[++site_url]]sitemap.xml
О, здорово! Хорошая вещь))) Спасибо)
На modxcloud.com этот вопрос легко решается просисыванием nginx-правил для конкретного облака. Пример:
if($http_host != 'mydomain.ru'){ return 301 mydomain.ru$request_uri; }
Алишер, привет! По мультиязычности можно будет на днях провести совместную он-лайн конференцию. А пока немного информации: MODX очень хорошо поддерживает мультиязычность, и дает несколько вариантов решения. Для оптимального выбора в основном надо ориентироваться на уникальность структуры сайтов на разных языках и как много полей у создаваемых документов. Если на разных языках сайты будут отличаться по структуре, то лучше всего это делать на разных контекстах с уникальными документами для каждого сайта в отдельности. Если же структура везде одинаковая, только языковые поля будут отличаться по содержанию, то однозначно лучше создавать TV-параметры под разные языки, и в одном документе сразу наполнять тексты на разных языках в разных полях. А глобально по всему сайту текущий язык определять по системной переменной cultureKey.
$modx->getOption('cultureKey', null, 'ru');
Или [[++cultureKey]] в чанках. Или в Смарти {config name=cultureKey}
Валерий, ты все правильно говоришь. Это потому что ты и специалист, и представитель заказчика со стажем. То есть ты и техническую сторону понимаешь, и роль заказчика на себе прочувствовал. И я действительно как раз эти цели перед собой и ставлю. Не зря же я всю ночь докручивал свой modLivestreet, чтобы не просто обеспечить статус страницам скрыт/не скрыт, а именно обеспечить уровни доступов на уровне ACL MODX-а. У нас уже на этом сайте настроены групповые политики, чтобы не просто распределить людей на программист/не программист, а еще и рулить кто куда какой доступ имеет. То есть и будут тимлиды, и проджект-менеджеры, и рядовые исполнители и т.п. И именно поэтому я добавил в профили типовые поля контактов, необходимые для работы (гит, битбканет, modxcloud). Но наша сегодняшняя проблема заключается в распределенности технологий. То есть modxcloud обеспечивает хостинг с фишками для разработки. Битбакет — трекер и гит-репозиторий. И на битбакете, и на modxcloud если политики доступов, можно расшаривать проекты и т.п. Но минус заключается в том, что для выполнения каких-то задач приходится переходить именно туда. То есть хочешь создать проект — идешь на битбакет, кликаешь Создать (там же трекер), создал новый тикет здесь, программист откликнулся, с заказчиком они договорились, заказчик посмотрел у него в профиле аккаунт на битбакете, у себя в панели на битбакете дал доступ программисту (если проект не новый и работы уже велись ранее, программист сможет увидеть, что и как раньше выполнялось), а делать это все он будет на modxcloud. Как бы все единое и в рамках одного бизнеспроцесса, на на трех системах. И вот я как раз хочу это доработать. На битбакете вроде есть API. Если мы настроим отсюда, то не придется переходить на битбакет, все взаимодействия клиента со специалистами будут проходить здесь.
Между заказчиком и разработчиком очень часто нехватает так сказать «руководителя проекта сайта» — это необхимый элемент для того, чтобы можно было гарантировать 100% качество исполнения проекта и возможность поддержки проекта в любое время и на любом этапе дальнейшего развития.
Здесь дело не только в непонимании. MODX — очень мощная система, но она не накладывает никаких стандартов. Сколько программистов, столько методов разработки. Каждый проект на MODX — отдельная уникальная система. Здесь мы будем вырабатывать единые стандарты разработки. Сайты не будут сразу выполняться на чистом MODX-е. Сначала разрабатывается сборка-база для разработки типовых решений, и только потом на ней выполняется конкретный сайт. То есть если это сайт-визитка, то большинство таких сайтов отличаются только дизайном и структурой документов (которые создаются через дерево документов в админке). То есть правильный сайт-визитка вообще не должен разрабатываться. Берется движок, в шаблонизации создается новый шаблон, натягивается новый дизайн и наполняется сайт. Все. 100 сайтов-визиток, а движок один. Посмотрел как в нем что сделано, знаешь как сделаны все эти 100 сайтов. Если это магазин — то создается движок магазина. Понятно, что на индивидуальных проектах могут быть доработки, но и доработки в пакеты можно оформлять. Здесь у нас будет репозиторий пакетов, все будет храниться в одном месте. Все будет документироваться. Использование единых стандартов и методик исключит большинство типовых проблем.
Другой вариант — это сделать клуб только для внутреннего использования разработчиками.
Нет, не стоит. Мы может тематически разграничить области сайта, так, чтобы клиенты видели больше информации для клиентов, а программисты для программистов. Но все должны быть в одной информационной системе, так как и у клиентов есть необходимость обмениваться опытом и учиться. Ведь для кого-то порой просто вставить картинку может оказаться проблема. А так уже один клиент что-то спросил, ему ответили, и другие клиенты для себя могут что-то новое узнать. Я последнее время часто на вопросы клиентов видеоролики снимаю что и как делается, буду здесь выкладывать.