abushyk

abushyk собака gmail.com Закиньте main.php из папки шаблона + /apps/system/lib/system/user/register_using_model.php + /apps/system/lib/system/user/profile_using_model.php

Не может форма из редактирования профиля отправлять на /register. В принципе не может. Но я еще и у себя проверил. Отправляет на профиль. Больше там ничего не меняли, кроме описаного мной? Там где вы ставили видимость для группы Незарегистрированные, Незарегистрированные означает группу. Группу может иметь только созданный пользователь. Гость, только что зашедший на сайт, не имеет никакой группы. Группа Незарегистрированные - не означает гостей, а означает некоторую специфичную группу на сайте. ПС. "залогиненный админ" значит, что был вход с логином-паролем админа на фронт сайта? Или был вход в админку, а потом просто переключена страница на фронт?

А должен ли?

1. Можно практический пример такого использования? 2. Никак. Максимум, завести заявке поле куда заявитель будете вставлять ссылки на свои картинки и откуда вы потом сможете их взять. 3. Смотря куда его потом вставлять.

Тогда оно плавно вливается в ряд с 2., 4, 5 Из того, что я планировал - это указание на какой имейл\имейлы отправлять какую именно заявку вместо жесткого админ-мыла. Вариант слияния нескольких типов заявок в одну форму и их дифференциацию по полую выбора, например, честно скажу совершенно не рассматривал, а потому и наметок никаких в эту сторону не было. Средствами движка можно сделать наверное много чего, просто тут вопрос что понимать под этими "средствами"))). Думаю то, что имеете в виду вы, вряд ли сможет. Вон там, чуть выше, ваши слова про "актуальность и нужность чего-то для кого-то"))) Вот и это точно так же было "актуально и нужно" и ему тоже удалось убедить нас в том, что он имеет зерно истины))).

Я предполагаю так. Поскольку эта модель может быть востребованой, то имя ее должно быть универсально. Планировал user_register (и лучше придерживаться этого именования), что бы они в Редакторе форм становились рядом с user (не чужие же друг другу). Эта модель должна по сути иметь 4 must have поля - newpass, newpass_retype, login и email полностью идентичные таким же из user. Я привел системные имена. Имена меток значения не имеют, а вот системные имена имеют, так как эти данные будут проэцироваться на одноменные колонки в таблице пользователей, куда на такие же поля аналогично будет проецироваться и модель user, для редактирования профиля, например. Главное отличие модели user_register от user - первая не нуждается в реальной таблице, поэтому в ее заголовке жать кнопку Создать таблицу не нужно. Страшного ничего не будет, но и новой таблицы в БД не требуется. Внедрение. /apps/system/lib/system/user/register_using_model.php есть строка $form_data = $this->data_model;Она встречается в _defaultAction() и в _new_doneAction() почти в самом начале. Это подключение модели для формирования формы регистрации. В таком виде берется модель user, так как регистрация - это потомок пользователя. Что бы распаралелить это место, мы эту строку заменяем (в _defaultAction() и в _new_doneAction()) на if(file_exists(SITEBILL_DOCUMENT_ROOT.'/apps/table/admin/admin.php') && file_exists(SITEBILL_DOCUMENT_ROOT.'/apps/columns/admin/admin.php') && file_exists(SITEBILL_DOCUMENT_ROOT.'/apps/table/admin/helper.php') ){require_once SITEBILL_DOCUMENT_ROOT.'/apps/table/admin/helper.php';$ATH=new Admin_Table_Helper();$form_data=$ATH->load_model('user_register', false);}if(!$form_data || empty($form_data)){$form_data = $this->data_model;}else{$form_data[$this->table_name] = $form_data['user_register'];}Т.е. запрашиваем редактор форм на наличии модели user_register и, если таковая есть, и в ней есть поля, то мы "рабочую" модель user подменяем нашей оптимизированной. И дальше код работает с нашей моделью регистрации так, как будто это родная user. Не следует забывать, что модель user_register не наследует, а подменяет модель user. И если вы добавите поля с "Хранить в таблице" в модель user_register, но не предусмотрите таких же полей в user (а именно по ней формируется таблица под пользователей в БД), то получите ошибку на запросе.

1. Не до конца понял. Не может поле быть "чуть-чуть обязательным". Если оно отмечено как обязательное, то будет стопорить отправку данных вне зависимости от обязательности или заполнености остальных полей 2., 4, 5. Программно. Средства фаст-форм не предназначены под такие цели. Как мини-вариант - свой приемщик-прослойка между "Клиент" и форма, как оптимальный-вариант - даже не трогать "Клиент", ну может кроме части сохранения заявки в БД (если таковая требуется). 3. Мы стараемся по максимуму фильтровать входящие данные. 6. Ключ из списка опций -> адрес (список адресов через обусловленый делиметер). Если вообще нужна таблица для такого случая. А в чем забавность-то?

Названия полей паролей можно изменить через Редактор форм. Но тогда они изменятся и в редактировании профиля. Есть еще вариант сделать отдельную модель, похожую на user, чисто под регистрацию пользователя, куда поместить только нужные для регистрации поля, типа той же галочки, что бы она не фигурировала в форме редактирования профиля. Там же можно задать те же поля под пароли, но уже с другими меткам. Для переименования кнопки в данным момент можно воспользоваться только методом локализации модуля регистрации, в котором и указать новое имя для кнопки. Тогда можно даже и изменение имен полей паролей вложить туда же и не делать отдельную модель.

Поменял ссылочку на архив)

1. Добавлен ли в модель user чекбокс под галочку? Если да, от какие права видимости на него поставлены? 2. Поле группа - поставьте на нее права видимости в модели data - Для админов. 3. Нет капчи на форме? Добавьте поле с системным именем captcha и типом captcha в модель user через редактор форм.

Само всплывающее окно лежит в /template/frontend/realia/login_register.tpl а управляющие скрипты от него в /template/frontend/realia/js/interface.js Но само всплывание окна отсюда http://bootstrap-ru.com/javascript.php#modals. Эта библиотека подключена, так что можно пихать их по всему шаблону невозбранно.

ПС. Регистрацию из всплывающего окна я бы вообще вырезал.

Это Редактор форм. Просто когда писали инстукцию, еще не определились с финальным названием. Да. Он честно попытался создать колонку, но у него не получилось, так как она возможно уже существует. Вот он и предупредил вас.

Свяжитесь со мной завтра через скайп или аську. Контакты в профиле.

Добавляем тайтл для страницы регистрации. Поскольку регистрация - это функция, а не приложения, то какого-то кармана для настроек под него нет. Поэтому добавить заголовок мы может прямо в зоне точки входа. В /template/frontend/realia/main/main.php находим точку входа регистрации if ( !$has_result && preg_match('/^register/', $REQUESTURIPATH) ) {...//тут все что уже есть между скобок$this->template->assert('title', 'Регистрация'); //Это мы добавляем от себя в заголовок страницы$this->template->assert('meta_title', 'Мета заголовок для регистрации'); //... и для эстетов ))}

Суть задачи - разместить на форме регистрации контрольный чекбокс состояние которого будет определять возможность нажатия кнопки завершения регистрации и невыбраное состояние которого не даст пройти процесс регистрации до конца. Рядом с чекбоксом разместить ссылку на какие-то доки или страницы с ознакомительной информацией. В чистом виде задача не решаема, поэтому придется немного смодернизировать код системы. Для избежания перегрузки всплывающего окна снесем всю регистрацию в полноценную страницу. Основной объект - файл /apps/system/lib/system/user/register_using_model.php Дополнительно нам понадобится файл /template/frontend/realia/register_user.tpl - шаблон точки входа регистрации. 1. Регистрация по своей сути - это заполнение полей модели user. Поэтому основой выступаем именно эта модель. Добавляем на нее поле типа checkbox с системным именем iam_agree, галочкой обязательно к заполнению и снятой галочкой Хранить в таблице. 2. В /apps/system/lib/system/user/register_using_model.php в функции _defaultAction() в самом конце функции находим строки $rs = $this->get_form($form_data[$this->table_name], 'new', 0, '', SITEBILL_MAIN_URL.'/register/');return $rs;которые заменяем на if(file_exists(SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/register_user.tpl')){global $smarty;$smarty->assign('register_form', $this->get_form($form_data[$this->table_name], 'new', 0, '', SITEBILL_MAIN_URL.'/register/'));return $smarty->fetch(SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/register_user.tpl');}else{return $this->get_form($form_data[$this->table_name], 'new', 0, '', SITEBILL_MAIN_URL.'/register/');}Смысл: мы ищем в папке шаблона файлик страницы регистрации и если находим, то компилим его в разметку и выдаем на гора. Если нет, то ведем себя как и раньше, выдавая просто форму. 3. Подобные манипуляции проделаем и с функцией _new_doneAction(), где вместо строки return $rs;ставим if(file_exists(SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/register_user.tpl')){global $smarty;$smarty->assign('register_form', $rs);return $smarty->fetch(SITEBILL_DOCUMENT_ROOT.'/template/frontend/'.$this->getConfigValue('theme').'/register_user.tpl');}else{return $rs;}Смысл аналогичный. 4. Переходим к шаблону страницы регистрации /template/frontend/realia/register_user.tpl примерный код которого тут http://pastebin.com/jchtk1W8. Это привычный файл шаблона в котором обязательным является только строка4: {$register_form}все остальное призвано либо украсить, либо выполнить нашу миссию. Поскольку мы не можем вставить в форму ничего лишнего в обход модели, то мы воспользуемся скриптом, что бы прикрепить ссылку на Правила\Оферту к нашему чекбоксу. Саму ссылку мы размечаем вне формы в строке 7, и по ее id скриптом переносим ее на форму. Так же в скрипте мы проверяем состояние добавленого чекбокса и гасим-активируем кнопку отправки формы в зависимости от его состояния. Там же в скрипте мы блокируем отправку формы при невыбраной галочке. Естественно, после отправки на сервер, галочка опять будет проверена, что бы нас не обманули (за это отвечает галочка Обязательное поле в настройках элемента модели, то не имеет смысла в обычных условиях, но то, что надо в данном случае.). Мы получим что-то вроде

Для любителей эскпериментов. Свежий геодата, прям с печи. http://my.digitalwerkstatt.ru/files/geodata/admin.zip По ссылке файл /apps/geodata/admin/admin.php Изменена функция массового геокодирования. Если раньше у нее был свой алгоритм, то теперь она будет работать через тот же алгоритм, что и геокодирование при сохранении\правке. Соответственно и настройки по полям по которым идет геокодирование у нее те же самые. NB. Пока не оптимизирована по нагрузке до оптимального уровня. PS. Не забываем про бекап.

Это не баг, и уж тем более не фича. Это концепция)) Которую мы, благодаря пользователям, пытаемся улучшить.

Почему ноль-то по дефолту? Большинство сайтов, что я трогал руками, как раз таки по умолчанию разрешают.

геокодинг при сохранении, что гугль, что яша отрабатывают верно по параметрам "Беларусь Дзержинск". В массовом страна не учитывается. только город\улица и дом. Нужно будет туда тоже вводить параметры как при сохранении.

Одно другого не исключает. Можно изменить логику ссылки кнопки. Можно убрать точку входа в контроллере. Просто, если решение использовать подачу объявлений только для авторизированных принято окончательно, то после смены логики кнопки имеет смысл убрать и точку входа. Если где-то там в глубине души есть желание когда-то расшарить эту возможность, то тогда можно и не удалять.

Понял. Это другой шаблон. Не realia. Я через выходные посмотрю как там все устроено и можно ли использовать похожий способ.

Геодате в настроках прописываются системные имена полей модели. И именно по модели она формирует сет параметров строки для геокодинга. Нет поля - нет куска строки с текстом имени страны.

А поле Страна в редакторе форм в модели есть? Именно в модели. активное. существующее.

не учитывает country_id в каком именно процессе? Геодата много где пытается использовать данные объявления для геокодинга.