Я наверно что-то не понимаю, мне не понятен принцип. Как приходит заказчик? Какой критерий качественных достойных веб-студий?
Я так понимаю, ориентир на CMS Magazine? И студии с количеством работ, сотрудников и остальная информация парсится от туда. А почему бы и нет? Если будет достойный сервис, который может составить конкуренцию, в нише MODX. Хочу заметить что уровень студии необходимо оценивать не только с точки зрения программирования на этой замечательной CMS, но также вёрстка, адаптивность и конечно же дизайн, по-этому считаю необходимым сделать раздел с кейсами, разбитыми на тематики(мебель, медицина, авто итд), где заказчику можно расписать подробно что сделано и как оно работает. Но самый главный вопрос у меня, как Вы намерены привлекать потенциальных заказчиков на http://modxclub.ru/, не видел ваших аналитических инструментов, но думаю портрет аудитории http://modxclub.ru/ 90% это разработчики.
Еще вопросик. Подскажите плиз, ни как не найти ответ. Modx revo русский. А после установки shop английский в cms. Где поменять язык на русский можно?
Да, все верно. До 2.3 прокачаем чуть позже.
нашла ответ Николай Ланец | 2014-08-22 18:35:16 | http://dev.modxclub.ru/blog/vehicles/340.html#comment-3351 Проблема в том, что ставите на 2.3.1 (там внутряк весь изменили). Ставить надо на 2.2+ (сейчас актуальная 2.2.15).
Подскажите пож. что не так делаю. Установила MODX Revolution 2.3.1-pl, дата релиза: 22.07.2014 Через пакеты rest.modxstore.ru/extras/ и у меня после обновления страницы пропадает в админке верхнее горизонтально меню. (пробовала на modx-2.2.13-pl все нормально).
Все-таки, иногда в MODX-е встречаются вещи, которые меня заставляют негодовать, мягко говоря. К примеру вот эти два метода: И modObjectUpdateProcessor::fireBeforeSaveEvent() Заметили как много "отличий" у этих методов? То есть как минимум можно было один метод на оба процессора сделать общим. Но главная соль вот в этой строчке: В create- процессоре она есть, а в update- процессоре ее нет. Уточню, что это ключ массива данных, передаваемых в массив $scriptProperties, доступный в навешиваемых плагинах. При этом они еще и советуют этот ключ не использовать, и используйте типа ключ $this->objectType. Вот у меня вопрос? Зачем так усложнять? Почему было не оставить тупо элемент object? Дело в том, что в случае когда у нас object, тогда мы не паримся и не задумываемся будет этот объект или нет. Это всегда объект, с которым будет выполняться сохранение. А вот в случае с $this->objectType нам совершенно нет гарантий какое именно название будет у этого объекта. Спросите зачем его вообще кому-то может понадобиться менять? А вот иногда надо. Простой пример - лексиконы. Может понадобиться изменить тип объекта, чтобы изменить выводимые системные сообщения, ведь там все на лексиконах, к примеру: И вот пишу я тут "универсальный" плагин на апдейт, и не знаю, будет там ключ resource, или будет какой-то другой. И главное - нельзя обратиться к процессору и "поинтересоваться", а кокой это тип объекта и как к нему обратиться... Вот такая фигня... Есть только вариант обратиться к элементу data, который содержит данные этого объекта, но это все-таки не объект.