чанки тут лежат modx_site_htmlsnippets
в целом, если они используют ещё что-то из TV, то можно сразу так http://forums.modx.com/?action=thread&thread=70100
а вообще, все ваши чанки только этими промо-кодами что-ли отличаются? тогда проще иметь только один чанк, а коды определять в качестве набора свойств, передавая нужное свойство при его вызове (хотя, всё зависит от того, как у вас оно там используется), и когда нужно будет поменять коды - просто создаёте новый Property Set
ну, если вы обратили внимание, это личное видение касательно только первого пункта
в посте была ссылка на форум, а форум подразумевает возможность ответа любого пользователя, не только администратора. ТСа интересовало видение, я изложил своё, и предложил поинтересоваться на форуме посвящённом сабжу, а свой сарказм оставьте при себе.
при беглом знакомстве с сайтом из примера - стандартный shopkeeper из коробки + галерею каждого товара будет проще всего организовать на migx... это по самому магазину и это стандартные задачи для MODx, куда входит: установка и настройка окружения и модулей, натяжка свёрстанного диза, установка shopkeeper + создание необходимых чанков, сниппетов, организация структуры каталога и базовое заполнение товарами (или написание компонент импорта, если вы должны скопировать)
то есть, эта часть - просто стандартные решения из коробки, сколько вы за это обычно берёте - решать вам ;)
Остальные и самые важные части:
1. должны ли вы полностью продублировать имеющийся контент и структуру? Здесь уже больше зависит не от какой-либо конкретной CMS, и оценивается совершенно отдельно
2. вот эти пункты меню: Вход и Регистрация - что там? полноценная мемберка, просто статистика заказов, есть ли ПП и т.д. В общем, реализация кастомного бэкенда может отличаться от относительно простых кастомных CMP и плясок с настройками политик безопасности до разработки полноценного виртуального офиса клиента с навороченной партнёркой, поэтому, без ТЗ по этой части, где описано, что от вас требуется, прикидывать что-либо невозможно.
и того: первая часть до $100, по остальным, прикинуть на глаз что-либо - не вариант ;)
p.s. поинтересуйтесь у самого автора shopkeeper что он об этом думает
да Kohana тоже рулит, но дело в другом:
зачем там вообще тогда mvc-фреймвёрк, типа зенда, коханы, йии и прочих ?) а во втором вообще всё на автолоадинге с неймспейсами построено
выбирайте
ну cck, и что? CMF != CCK ;) в MODx подобное имеется - TV + migx если для красивости... а вообще, это не MODx-вей по сотням чекбоксов с селектами (как во Views например) тыкать... проще свой сниппет/сервис написать, с xPDO или напрямую, в обход ORM, если того требует производительность.
ссылочек на RTFM уже накидали, ок, тогда просто сошлюсь на мнение независимых экспертов - Best Open Source CMS of 2012;)
ничего не понял, но попробуйте position: relative для контейнера и такое же позиционирование для вложенного с требуемыми смещениями, который должен "отступать", но так же и продолжать находиться в основном потоке занимая место
никогда больше чем на 500 страниц не делал... даже когда они не банились, так как щас и можно было внутряком по самому же дору ссылочное разливать
первый. потому как основная фишка html5, это не просто новые тэги, а особое семантическое значение этих новых тегов для всяких там ридеров и прочих микродевайсов. Основная суть использования html5-тэгов именно в передаче семантического смысла Document Outline в разметке страницы, а не просто, потому что новый стандарт, а микроформаты схема.орг, это в основном только для гугла, бинга и яхи, но более универсальнее, юзать именно семантику html5 для прочих девайсов... хотя лично я никогда с микроформатами не замарачиваюсь )
да, будет. тем более, что это #! теперь чуть ли не часть спецификации такой же структуры придерживается так же яндекс, бинг и яха (а вот как байду - не знаю, но и он тоже скорее-всего ;)
www.example.com/ajax.html#key=value
www.example.com/ajax.html#!key=value
в целом конкретно от темы зависит (много всяких служебных файлов и т.д.) но в большинстве случаев functions.php смотрите. Если это модуль добавляет, смотрите по последовательности инклюдов/вызовов
