Привет всем мастерам Drupal. По данной теме скорее всего поднимались вопросы, но всё же после того как ничего не нашел в просторах интернета я решил обратится к Вам!
Проблема очень даже тривиальна. Нужно в форме оформления заказа вывести селект-лист со списком способов доставки заказа к примеру "Новая Почта", "Интайм" ...
И я не смог найти где в Ubercart добавить вообще способы доставки именно в Drupal 7, такая же история с модулями. Перелопатив десятки модулей они не давали мне тот результат который я хотел, но а если давали то они были написаны для Drupal 6. Мне бы хотя бы решить вопрос с добавлением способов доставки, а дальше что то придумаю. Подскажите какие решения по добавлению способов доставки в Ubercart Вы видите? Мне интересно все Ваши варианты. Я их переберу и может что то и получится.
Заранее большое спасибо!!! Вы мне очень поможете. А то не знаю что делать...
Комментарии
Что ни кто не знает как сделать?
Ну что тут нету профи по Drupal и Ubercart? Очень нужна Ваша помощь... Работа на этом моменте стала...=((((((
Хоть в кратце опишите как это можно реализовать. Я не говорю что б дотошно мне описывать... Хоть чуток..
доставка наверняка в Убере добавляется модулем (не имел удовольствия работать с У7) В модуле хук или пара, они дают знать уберу что есть вот такая доставка. В DC именно так. Также есть модули которые предоставляют интерфейс для создания своих доставок, например в DC это Flat Rate.
всё то же самое что и в d6/uc2
судя по уровню вопросов, для начала надо разобраться с азами
никто такие элементарные вещи в сотый раз объяснять не будет
Ну чего на новичка накинулись-то? Все такие были.
Все зависит от тарификации службы доставки. Цена может быть фиксированной, зависеть от количества единиц в заказе, их веса и/или объема, а может быть, что калькулятор стоимости (учитывающих эти параметры) доступен через API транспортной компании. В случае фиксированной цены или небольших вариаций можно обойтись встроенным в Ubercart3 модулем FlatRate. Для некоторых служб доставки есть готовые модули. Ну а если модуля нет, то можно написать свой.
После установки модуля на странице /admin/store/settings/quotes/methods появляется дополнительная ссылка на добавление соответствующего метода расчета. У каждого метода можно задать специфичные для него параметры, а можно задать условия, при выполнении которых этот метод отображается в списке. Например, если доставка по городу Жмеринка заказа стоимостью до 100 гривен стоит 5 гривен, а доставка заказа стоимостью от 100 гривен делается бесплатно, то можно создать два метода расчета FlatRate, указав у первого цену 5, доп. цену 0, в условиях: [order:delivery-address:city] = "Жмеринка" и [order:order-total] <= 100. У второго цена будет везде 0, в условиях: [order:delivery-address:city] = "Жмеринка" и [order:order-total] > 100. При этом в зависимости от общей стоимости заказа в списке будет отображаться только один пункт. А если город будет не "Жмеринка", то ни один из написанных вариантов отображаться не будет. Вообще, если грамотно пользоваться условиями, то с помощью FlatRate можно много чего оценить. Я например, сделал расчет доставки по зонам при указании названия города, правда, пришлось немного расширить функциональность Rules, добавив собственный обработчик условий.
Что касается например, Новой Почты, я глянул на сайте, API у них, видимо, нет, но тарифы все доступны, можно написать свой калькулятор.
Есть, но дают ключик не каждому. Мне дали
А если юзер ввёл название по своему? Ваше решение конечно хорошее, но оно на коленке сделано, и по нормальному там не тока "немного расширить функциональность Rules"
Все равно нужно свой модуль писать. А я так понимаю, ТС вряд ли за это возьмется.
Это решается добавлением автокомплита к полю города в checkout. Я как раз этим сейчас и занимаюсь. Правда, пока безуспешно. Готового ничего не удалось найти. Придется изучать исходники и скорее всего добавлять свой модуль. У меня проблема осложняется еще и тем, что служб доставки несколько, у каждой свой список городов, и эти списки время от времени обновляются. Поэтому нужно создавать некую объединенную таблицу городов и работать уже с ней.
Я уже пробовал это. Ничего сложного, но я пришёл к выводу, что это также не исключает ошибки поэтому добавил в своём модуле также зависимые селекты: юзер выбирает сначала область, потом город (аякс)Там же ссылочка - "Не нашёл свой город" - клик - свободная форма.
Ну и понятно, нужно иметь своё централизированное хранилище городов, куда вручную или аплодом через csv можно добавлять города.
У меня тоже области будут указаны. Но я хочу упростить и область писать в скобках после названия города. Человек начинает писать свой город, а дальше просто выбирает из списка.
Не подскажете, как добраться до настроек полей в checkout? Только желательно без правки кода модуля. А дальше с аяксом мне уже все понятно.
Нужно усложнять.
Заведите табличку под базу городов. В ней мин 3 поля - уникальный Айди, город, область
через форм альтер добавьте невидимое поле в форму чекаута. Колбэк автокомплита должен возвращать эти три поля. На селект, вставлять айдишку города в невидимое поле. Далее его считать или считать сразу аяксом, но это походу лишнее
Могу подсказать по DC, c убером не работаю
Зачем так сложно? В таблице городов делаем поле, содержащее город+область. На форме автокомплитом значение из этого поля предлагаем. Айди использовать необязательно, полное название выполняет его роль. Когда модули расчета доставки получают в качестве аргумента название города, они могут пробить его ID по таблице городов. Другой вопрос, что каждому модулю нужен свой ID города - для "своей" службы доставки. Т.е. в базе надо будет создавать таблицу городов, таблицу регионов и по таблице на каждую транспортную компанию. Плюс еще создавать механизмы регулярного обновления списков городов с сайтов ТК и дальнейшего их полуавтоматического сопоставления с имеющимися в базе.
Возможно по DC тоже подойдет. Мне бы идею уловить.
Вообще, удивительно, что по доставке и работе с городами все настолько плохо. Практически ни одного модуля нет на эту тему. КЛАДР вроде прикручивать начали, но все заглохло практически на взлете.
Кладр сам по себе протух, вместо него ФИАС
Обязательно. Всё что лежит в БД должно иметь свой уникальный идентификатор, латинскими буковками и цифирками
И да, насчёт КЛАДР - если у вас есть айдишка тогда вы сможете подрубить туда код из КЛАДР или Фиас
только тогда разумеется его нужно делать не автоинкрементным, а обычным varchar,
Я имел в виду, что ID не нужен в автокомплите - достаточно названия города. А в таблицах уникальный ID каждой записи - это обязательно.
У меня одна из транспортных компаний как раз использует коды КЛАДР и это правильно. Хотя для написания модуля практически все равно, откуда код, т.к. все равно соответствие есть в таблице.
Ок, делайте как хотите, моё мнение - оно только моё. Просто я писал модуль для этого, только там поболее - отделения для забора посылок, с поиском ближайшего на гуглкарте, расчёт доставок по визуальным формулам, добавление перевозчиков любых прямо из панели и тд, так что имею представление кое какое
Сильно. А в паблике этого нет?
Я вчера весь мозг взорвал поиском возможности дописать свойство autocomplete_path к полю города. Через form_alter это сделать невозможно - поля адреса не существуют при генерации формы, а подгружаются позже. В общем, создал тему: http://www.drupal.ru/node/99808.
в паблике не будет, я завязал с благотворительностью
Неправильно.Корный автокомплит убог. В ядре есть jquery.ui.autocomplete его используйте.
ммм. странно, не замечал такого. Может стоить проверить вес модулей?
Да, скорее всего так и сделаю.
Про вес модулей не понял. Что имеется в виду?
порядок выполнения хуков, в данном случае hook_form_alter
пример, как добраться до страны
<?php function ВАШМОДУЛЬ_form_alter(&$form, &$form_state, $form_id) {
}
if ($form_id == 'commerce_checkout_form_checkout') {
if (!empty($form['customer_profile_shipping']['commerce_customer_address']['#language'])) {
$language = $form['customer_profile_shipping']['commerce_customer_address']['#language'];
if (!empty($form['customer_profile_shipping']['commerce_customer_address'][$language][0]['country'])) {
$country = $form['customer_profile_shipping']['commerce_customer_address'][$language][0]['country'];
// взять опции $country['#options'];
}
} ?>
как прикрутить автокомплит к полю "город", даю свой код
var autocompleteInput = $("input:text.locality");
autocompleteInput.autocomplete({
source: function(request, response) {
$.ajax({
url: settings.basePath + "autocomplete-api/source",
dataType: "json",
data: {
term : request.term,
},
success: function(data) {
response(data);
}
});
},
select: function(event, ui) {
$("input[name=commerce_carrier_geopoint_id]").val(ui.item.geopoint_id); // вставляем ID города в невидимое поле формы, его нужно добавить заранее через форм альтер
autocompleteInput.val(ui.item.city); // вставляем название города
$("input:text.state").val(ui.item.state); //вставляем название области
return false;
},
});
if (autocompleteInput.data()) {
var ac = autocompleteInput.data("autocomplete");
if (ac) {
ac._renderItem = function(ul, item) {
return $( "<li></li>" ).data("item.autocomplete", item).append("<a><span class='autocomplete-item-wrapper'><span class='city'>" + item.city + "</span><span class='administrative-area'> (" + item.state + ")</span></span></a>").appendTo(ul);
};
}
}
}
Действительно, это мысль. Мне нужно, чтобы мой хук выполнялся последним. А от чего это зависит? Если что, я функцию называл МОЙМОДУЛЬ_form_uc_cart_checkout_form_alter, соответственно, она замечательно отрабатывала на форме uc_cart_checkout_form. Вот только путь к полю, который должен был бы быть ($form['panes']['delivery']['delivery_city']['#default_value']) оказался несуществующим. Как показала проверка, существует только объект $form['panes']['delivery'], в который позже все и загружается. Не исключено, что это делается более поздним хуком. Подскажите, как это проверить?
данный конфиг jquery.ui.autocomplete нестандартный, стандартный намного проще, но мне надо HTML в результатах плюс ещё кое чего поэтому так
Разумеется нужно добавить также библиотеку в autocomplete через #attached в form_alter
Колбэк по адресу autocomplete-api/source должен выглядеть примерно так (можно обойтись без foreach )
<?phpfunction _city_similar_get() {
$out = array();
$results = db_select('my_geobase', 'g')
->fields('g')
->condition('g.city', db_like($_GET['term']) . '%', 'LIKE')
->range(0, 10) // ограничиваем десятью результатами
->execute()
->fetchAllAssoc('id');
if ($results) {
foreach ($results as $result) {
$out[] = array(
'city' => $result->city,
'state' => $result->state,
'geopoint_id' => $result->id,
);
}
}
drupal_json_output($out);
}
?>
А, стоп, я всё про DC говорю. Тогда не знаю конкретно
В любом случае большое спасибо за примеры, поразбираюсь.
порядок вызова хуков зависит от веса модулей - чем вес больше, тем позже будет вызван обработчик
обычно, вес задают в hook_install, но можно, пока никто не видит, залезть руками в таблицу system и поправить значение поля weight там, не забывая сбросить кеш после этого
до полей формы в убере добирался через
function my_module_element_info_alter(&$type){
array_push($type['uc_address']['#process'], 'my_tools_process_address_field');
}
function my_module_process_address_field($element, $form_state){
$element['billing_city']['#default_value'] = 'город';
return $element;
}