abushyk

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

Можете поделиться ссылкой на сайт? Для начала можно посмотреть с фронта.

На работу карт на фронте не повлияет. Для тех, кто пользуется гуглем и кого нервирует это уведомление, можно получить ключ для карт и добавить его в подключение скрипта апи.

Гугль перестал отдавать публичную библиотеку. Очередное точечное решение))) /apps/system/lib/system/form/form_generator.php Найти все строки $str .= '<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/md5.js"></script>'; и заменить на $str .= '<script src="'.SITEBILL_MAIN_URL.'/apps/system/js/md5.js"></script>'; Потом качнуть дистрибутив сайтбилля установочный и скопировать из него файл /apps/system/js/md5.js по такому же адресу в сайте.

Да. Хром как-то стал жестче относиться к тому, что выдается под заголовком text/xml. За последние две недели я видел это на десятке выгрузок самых разных форматов от самых разных компаний. И при том обработка xml-парсером этих выгрузок проходит без ошибок. Т.е. хмл "битый" только с точки зрения браузера.

#prettyLogin .tab-content { overflow-y: scroll; } кажется это то, что вам нужно.

в таком случае нужно не обвешивать условиями стандартный поток списка (который выводится на главную обычно), а для главной страницы формировать свой список с блекджеком нужной сортировкой и отбрасыванием объектов без фото. Выводить объекты без фото в конце списка и не выводить их в определенном списке - это две разные задачи, первая из которых не совсем проста в исполнении. Впрочем, как и вторая затратная по ресурсам.

ну да. хоть бы минимальное описание украшений бы не помешало.

Только одна эта связка отключилась или в целом линкед-депендед не срабатывают?

Отличие сейвстринг от селектбокс в том, что в первом мы храним значения, но никак их не трактуем. Т.е. значение -2 в поле floor случае сейвстринг означает только "минус два" и больше ничего. При селекбоксе все точно так же, но есть подсказка в интерфейсе в виде значения {-2~~подвал}, т.е. не нужна отдельная подсказка, что писать при указании подвала. На всяких выгрузках-загрузках нужно посмотреть, но для селектбоксов обычно в выгрузку идет именно значение, а не ключ, и для -2 выгрузится скорее всего "подвал", а вот остальные значений типа {1~~1} выйдут как нужно. Переход между сейвстринг и селектбок при наличии числовых ключей у последнего вполне безболезнен, как в одну сторону, так и в другую. В обех случаях в БД хранится либо число введенное в текстовое поле, либо ключ выбранного значения из селекта. Вся разница опять же отразится только в представлении этого поля в шаблон или иной поток вывода.

Как работает движек. Он получает некоторый линк, чистит его от фрагменто, анкоров, параметров и получает литеральную строку. Например /somelink/. После этого он отстригает лидирующие и финальные слеши /somelink/ ---> somelink /somelink/aaaa/ ---> somelink/aaa Т.е. с его точки зрения адрес site.ru/somelink/aaaa/ и site.ru/somelink/aaaa эквивалентны. Что принципе правильно, поскольку финальные слеши несут исключительно субъективную информацию и сами по себе не означают ровным счетом ничего. Вне зависимости от того, что у вас выдает сайтмап, со слешем или без, нужно принимать решение какой урл правильный. Делается это либо через хацесс, либо внутри кода, где проводится анализ того какой урл пришел, был ли у него слеш и какой урл допустим. В результате происходит либо отработка, либо 301 редирект на "правильную" ссылку. Обработка в коде обычно более громоздка, поскольку требует сохранения и проверки множества каких-то правил. Тогда как хтацесс делает то же самое, но чуть ранее. Так же следует помнить, что не смотря на то какие урлы выдает сайтмап, могут стоять ссылки с других сайтов, которые могут быть не такими как в сайтмапе, без слеша например. иными словами обработчик-анализатор должен быть в любом случае. Этот случай аналогичен борьбе с www субдоменом. Он точно так же редиректится с хтацесса. И совершенно не играет роли то, что в сайтмапе у вас никогда не будет ссылок с www - они просто есть и все.

UPDATE re_data SET `room_count`='' WHERE `topic_id` NOT IN ( 23,24,25,26,27,13,14,15,16,17 ); Либо, если тип колонки room_count в БД INT (целое), то UPDATE re_data SET `room_count`=0 WHERE `topic_id` NOT IN ( 23,24,25,26,27,13,14,15,16,17 );

Отрывная листовка - это как объявления у подъезда с корешками для отрыва?

Может это какая-то особенность. У меня сейчас 4.6.4 + бутстрап2 и от фоторамы я не видел ни одного сообщения.

не настолько жутко кончно, но удаление большого количества файлов естественно будет более трудозатратным по сравнению с удалением самой записи. + накладные расходы, так как для uploadify нужно вычитать из БД записи соотв. линкам на файлы для картинок и оичстить записи в связанных таблицах, а в uploads кусок времени уйдет на распаковку блока информации о картинках, той страшной строки, которая выгружается в Эксель, если выгрузить поле картинок. точных цифр никто не скажет, но на минуты для записи там счет точно не идет, до секунды - это самый страшный предел.

Type:int,Min:-2,Max:9 плюс не мешает, но можно не писать. но это правило будет значить любое значение от -2 до 9 целое, и ноль.

не совсем в обход, поскольку стандартная проверка данных, которая включает в себя проверку по правилам rules, обычно применяется. пропущен только пункт который собирает данные из запроса по полям с помощью модели - фактически работа с формой. Но базовые низкоуровневые проверки такие как "непустота", "обязательность" применятся. по крайней мере насколько я помню почти все добавления в общеупотребительных местах идут через стандартный интерфейс. На сайте не отобразится тоже местами. Там где для вывода используется модель - карточка, похожие и данное берется из .value_string то не покажется. А вот если запросить значение .value то там как раз будет то самое которое пришло из парсинга.

функция удаления, нормального с детскими объектами, одной записи, или некоторого набора записей есть. она используется когда вы с админки галочками натыкиваете нужные и жмете удалить выбранные. все упирается в что-то что будет определять этот набор удаляемых, грубо говоря некоторая "форма поиска". Разбивать на шаги удаление можно, но не из-за количества записей, из data они вытрутся моментально, а из-за того, что вместе с записью будет идти удаление картинок (физических файлов).

занесется. селект как двери, защищает только входной проем, но не поможет, если вы залезли через окно. но кстати можно его использовать и для проверки.

Флеш имеет смысл как контрол. Бывают на сайтах такие карты на флеше с возможностью тыкнуть нужный район страны, или меню какое-то прикольное (но только для случаев, когда такое же нельзя сделать другим способом). Но ставить его в качестве рекламы нерационально. Он довольно толстый. Да и как заметил Игорь Иванович его не особо уже жалуют. Мозилла давно его запинала. Хром тянул своим встроенным флеш-модулем, отказываясь от внешних плагинов.

Из-за очень сильной специфичности верстки, хоть и хтмлем, но именно для ограниченных площадей, при этом не имея ни малейшего понятия о том, сколько места в принципе занимают эти объекты на странице, да еще и с учетом страничности пдф-документа, процесс сводится к мозговскипающему циклу "поменял-проверил-чертыхнулся-вернулся к первому пункту". Вместе с полным остуствием реализации WYSWYG процесс верстки под пдф жутко нудный и сказочно непредсказуемый. И да, половина привычных для веба стилей там просто не работает. Но, в принципе, поменять самостоятельно сможете)

вот именно что в "большинстве". в этом еще один плюс правил на элементе в отличии от селектбокса. селект применяется только на форме. выставив для него разрешенные значения вы просто запрещаете пользователю выбрать недопустимое. но селать пост-запрос с "кривыми" значениями или при парсинге, где формы нет, а сразу есть готовые значения, и селект уже не сработает, в отличии от правил, которые проверяются перед самим процессом сохранения. так что селект - это больше интерфейсное ограничение, а правила - внутреннее.

единственное требование - это реально меньше свободы пользователям. любыми способами. даже не говоря о тетях "с улицы", но и "профессиональные" риелторы способны написать самое разнообразное там, где это не запрещено)

В плане юзабилити пальма у селекбокса, так как там можно не только ввести отрицательные значения, но и указать их человеческими словами {-2~~подвал}...{1~~1}{2~~2}. Да и людям он понятнее. в плане оптимальности - сейвстринг. поскольку селекбокс - это встроенный элемент-такой который "все свое носит с собой". если много вводят люди и колоссальных по объему выборок не делается, то может быть селект. если все импорты или большинство идут с парсингов, то сейвстринг.

такой как в пюре малость плохой или заумный. посмотрите fotorama. Если подойдет, то я покажу как его заюзать.