Перейдем к проблеме: Не работает функция, которую мы активируем в Администраторской панели Virtuemart’а, «Автоматический выбор способа доставки«. 

Я начал гуглить, копаться в коде, копать в шаблонах в папке View, а ответ был прост — просто не указывайте НИКАКИЕ страны для этого способа доставки.

Даже если вы используете две страны: Россия и Украина, и укажите их в способе доставки, скрипт будет сначала выводить форму, для заполнения пользователем, а потом страницу с вариантом доставки. Исходя из этого я сделал вывод, что автоматический выбор доставки выполняется по странам.

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

Я бы реализовал алгоритм так: (проверка на активацию функции)  -> (проверка количества опубликованных возможных способов оплаты), если один — то даже не смотреть на страны и ставить его. Все!

Надеюсь помогла статья, удачного кодинга!
Спасибо за внимание!

Сегодня расскажу вам о том, как решить проблему, с которой я столкнулся во время работы с новым Virtuemart 2.0.2. Проблема заключалась в том, что после того как человек вводит свои данные и нажимает на кнопочку «Подтвердить заказ» загружается абсолютно пустая страница,  но сам заказ сохраняется в администраторской панели, и не отправляются письма, уведомляющие пользователя и администратора о заказе через Virtuemart.

Немного покопавшись в коде, я нашел решение этой проблемы.

Я гуглил, но ничего не смог найти, потом оклеветал хостинг, т.к. на Denwer’e все работало нормально, начал настраивать почту, пробовать разные варианты отправки php mail(); SMTP, sendmail. Но ничего не помогало. И тут я увидел что  в начале письма, которое отправляется пользователю (у Denver’a сохраняются письма, отправленные через php mail(); в папке WebServers\tmp\!sendmail ), выводится сообщение об ошибке. Оповещение говорит о том, что что-то не так с передаваемым параметром в функцию substr(); в файле

administrator/components/com_virtuemart/models/orders.php на строке 997

Открыв файл, я нашел нужную строку. Она находилась в условии:

if(empty($data['invoice_number'])) {

//$variable_fixed=sprintf("%05s",$num_rows);

$data['invoice_number'] = str_replace('-', '', substr(JFactory::getDate(),2,8)).substr(md5($orderDetails['order_number'].$orderDetails['order_status']),0,3).'0'.$count;

}

Там есть два вызова функции substr(); и на один из них ругается сервер.

$data['invoice_number'] = str_replace('-', '', substr(JFactory::getDate(),2,8)).substr(md5($orderDetails['order_number'].$orderDetails['order_status']),0,3).'0'.$count;

Удаление первого выражения:

str_replace('-', '', substr(JFactory::getDate(),2,8))

привело к тому, что ошибка пропала, и все нормально начало работать. Не знаю чем чревато такого рода изменение, но сайт начал работать нормально. Отправляются все письма: администратору и пользователю, грузится страничка с подтверждением оформления заказа.

Вот в конечном итоге что у меня получилось на строке 997:

$data['invoice_number'] = substr(md5($orderDetails['order_number'].$orderDetails['order_status']),0,3).'0'.$count;

Вообще, это функция присвоения номера/кода заказа к нему же. Условие проверяет указан ли уже номер/код, если нет, то формирует его из двух строк: первая часть — цифры текущей даты, вторая — md5(); от номера заказа и от его статуса.

Т.е. в принципе мы ничего критического не сделали, но если у вас есть более элегантное и красивое решение данной проблемы — милости просим в комментарии.

Удачного кодинга!