Как передать значение из JS в переменную PHP
 

Всем привет! Стоит задача, с которой пока справиться не смог. Есть:

document.getElementById('product-price').innerHTML = rezultatRadio + totalPrice;

мне нужно передать значение

'product-price'

из

document.getElementById('product-price').innerHTML

в php-переменную, типа

$product_price

Выводить на этой же странице результат получается вот так:

<output id="product-price"></output>

И нужно значение id='product-price' передать новой переменной $product_price функцией mail(), которая находится на этой же странице order.php... Заранее благодарен!

Опшен ваш является элементом списка, а список элементом формы. При отправке формы получайте, присваивайте, отправляйте почтой, какие проблемы?

Ну а как можно присвоить значение JS переменной PHP???

На сервере не будет никакой js-переменной. Если речь идет о форме, то в зависимости от метода ее передачи ее данные будут на сервере в массиве $_GET или $_POST, можно их получить и из массива $_REQUEST. А чтобы элемент формы передавался на сервер, у него должен быть атрибут name, который будет ключом в вышеуказанных массивах.

laimas, у меня и форма оформления заказа, и код отправки на почту находится на одной странице.


В письме общая сумма заказа отправлялась таким образом:

$tprice =  substr(htmlspecialchars(trim(number_format($product['price'] * $quantity ,2))), 0, 1000000); 
        

$message .= 'Общая сумма: ' . $tprice . '<br />';

Но после добавления функции выбора типа доставки появился этот код:

<input type="radio" name="nameRadio" value="300" > Наш курьер (Стоимость доставки 300 руб)
    <input type="radio" name="nameRadio" value="0">Самовывоз
    
	 <p class="total" align="center">Общая сумма заказа: <span class="product-price"><output id="product-price"></output> руб</span></p>

Вот как теперь $tprice поменять на id="product-price", вот в чём вопрос??????

substr(htmlspecialchars(trim(number_format($produc t['price'] * $quantity ,2))), 0, 1000000); - вы можете объяснить зачем здесь htmlspecialchars, а trim после number_format, и весь этот бедлам еще и должен быть обработан substr?

Вот как теперь $tprice поменять на id="product-price", вот в чём вопрос??????

Поменять где, на сервере? Никак. Вставить видимо нужно $tprice в id="product-price"?

<output id="product-price"><?=$tprice ? $tprice : null?></output>

Ну а какой смысл в этой вставке???? Нужно как раз этой переменной $tprice присвоить значение, которое несёт в себе id="product-price", чтобы отправить общую сумму заказа учитывая стоимость доставки.

Тег output не является элементом формы, более того, он доступен только в современных браузерах. А не являясь элементом формы, он как ее значение не передается на сервер. Если вам нужно передать текст из этого тега, помещайте его в скрытое поле формы на клиенте. Но если этот тег содержит produc t['price'] * $quantity, то какой смысл его передавать?

А вот это substr(htmlspecialchars(trim(number_format($produc t['price'] * $quantity ,2))), 0, 1000000); - полнейшая чушь, выбрасывайте это.

$produc t['price'] - цену продукта должен знать сервер, передавать ее с клиента не стоит. Клиент должен сообщать серверу только количество выбранного.

substr(number_format($produc t['price'] * $quantity ,2), 0, 10);

Существует сессия: $_SESSION['total_price'], так я выводил "общую сумму заказа" до появления выбора типа доставки с JS.

$total_price = $_SESSION['total_price'];

$total_price я заносил в БД "общую сумму заказа"

Теперь с помощью JS общая сумма заказа заносится в id="product-price"

<script>
  window.onload = function(){ totalPrice = "<?=$_SESSION['total_price']?>"; }
  
window.onclick = function onclickRadio() {
  var nameRadio = document.getElementsByName('nameRadio');
  for (var i = 0; i < nameRadio.length; i++) {
    if (nameRadio[i].type === 'radio' && nameRadio[i].checked) {
        rezultatRadio = nameRadio[i].value;       
        
    }
  }
  document.getElementById('rezultatRadio').innerHTML =  rezultatRadio;
  document.getElementById('product-price').innerHTML =  new Number (+rezultatRadio) + new Number (+totalPrice);
  
 
}
</script>

И вот как теперь значение данного id можно передать переменной PHP, чтобы можно было это дальше обрабатывать в PHP?

<script>
window.onload = function(){ totalPrice = "<?=$_SESSION['total_price']?>"; }
var totalPrice = "<?=$_SESSION['total_price']?>";

Хранение данных в сессии никак не оправдывает substr(number_format($produc t['price'] * $quantity ,2), 0, 10), это глупость, ибо в контексте типа данных с которыми вы работаете, этого совсем не требуется, тем более htmlspecialchars и trim.

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

Ну так что думать то, если я не представляю, как можно из JS id="product-price" сделать PHP $tprice?????????

A number_format нужен для числовых выражений, и substr ограничиваю количество символов (хотя это нужно для ввода в форме)

У вас общая концепция ни к черту не годиться, а вы решаете проблему как из чего-то вытащить.

Если речь о price, то значит либо товары, либо услуги. Значит в сессии должна храниться корзина выбранных клиентом товаров/улуг.

Выбор клиента, это отправка на сервер идентификатора товара/услуги и количество выбранного.

Товар/услуга добавляется в корзину только в том случае, если запрос в базу возвращает цену товара/услуги для указанного идентификатора.

Хранить в сессии общее количество выбранных товаров/услуг и их общую сумму вообще не требуется, это можно быстро просчитать функциями РНР.

number_format нужен только при выводе на страницу.

Отправка почтой, это уже оформление заказа, а не реакция на выбор каждого товара/услуги на странице.

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

Почему концепция не годится? Пока не появился выбор типа доставки с использованием JS - всё отлично работало. Теперь полный тупик.....

И корзина с добавлением у меня совсем по другому работает.

А можно из value достать значение в переменную php не используя JS???

<input type="radio" name="nameRadio" value="300" > Наш курьер

А то с ним полная засада получается... :(

Почему концепция не годится?

Потому, что, если цену товара определяет не сервер, а клиент, то ваша концепция, это котел для сбора мусора.

Цена товара, как все параметры товара, достаётся из БД sql-запросом SELECT

То есть $produc t['price'] - это значение выборки? Тогда нормально, но почему при выборе каждого товара вы производите расчет количества?
Выбор это добавление в корзину, и считать нужно то, что в корзине. Добавлять же в нее вы можете как угодно, хоть руками записывать, а вот просчитать, так для этого есть готовые функции.

<input type="radio" name="nameRadio" value="300" >

При отправке формы на сервере будет получено в массиве GET/POST как 'nameRadio' => 300. Что тут вытаскивать да еще средствами JS я не понимаю.

Про готовые функции ничего не слышал.....

Средствами JS я вытаскиваю значение value для показа "общей суммы заказа" в <output></output> без перезагрузки страницы с учётом стоимости доставки.

И у меня на этой же странице order.php собирается и отправляется mail(), куда я хочу "засунуть" значение id='product-price' с учётом стоимости доставки, а не старую $total_price, где доставка не учитывается.

Про готовые функции ничего не слышал.....

А вы читали по ссылке? Если товары в корзине, это массив, ключами которого являются идентификаторы товаров, а его значениями массив, где первый элемент, это количество товара, а второй его цена, то:

$total_cnt = array_sum(array_map('current', $array_name)); //количество товаров в корзине
$total_sum = array_sum(array_map('array_product', $array_name)); //сумма товаров в корзине

Зачем вам брать на клиенте какую-то стоимость с чем-то или без чего-то, если в это с успехом можете высчитать на сервере, ведь на нем у вас все данные о корзине есть?

С вышеприведённом кодом вообще ничего не понял. У меня даже намёка на такой скрипт нету.

И у меня в корзине собрана вся информация о продукте или продуктах, но там нет стоимости доставки. Её я выбираю уже на странице order.php и здесь нужно внести изменения в "общую стоимость заказа".

Если вы не поняли, значит вы не знаете РНР, тут увы я вам не помогу. Если вы считаете количество товаров в корзине и их суму как проходом в цикле, значит структура вашей корзине неудачна.

Просчитать с учетом доставки, значит получить от клиента не ее стоимость, а параметры ее определяющие (ну не клиент же ее определяет), а уж сервер должен по этим параметрам высчитать стоимость доставки, добавив ее к стоимости заказа (суммы товаров в корзине). Клиенту вы должны возвращать эту рассчитанную сервером стоимость. Как вы ее выбираете на странице order.php, что на ней делается я не знаю.

Да, именно в цикле я и считаю. Других вариантов для примера не видел, научился только так.

А вы можете показать скрипты, где выбирается тип доставки (с учётом стоимости), где можно увидеть принцип осуществления подсчёта всех составляющих заказа? Иначе я так и будут стоять на месте, упершись в стенку....

Я вам уже говорил - циклом, значит неудачна корзина, и не знание РНР. Прочтите о функциях которые в коде, что я написал, станет понятно как. Цикл может потребоваться, если выводится список наименования товара, наряду с его ценой, количества, суммы за количество. В ином случае, как то для отображения информации о корзине на страницах, это излишество.

Скрипты, какие? Я вам дал ссылку на тему о корзине. Собственно ваш случай ничем от этого отличаться не будет, только лишь деталями какими либо.

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

Что такое стоимость доставки? Ну наверное же не 35 руб. которые вам прислал пользователь. Наверное же это зависит от веса отправления, расстояния и прочего, на основе которых и рассчитывается стоимость доставки. То есть в любом случае это некие параметры. Сервер должен знать эти параметры, которые может получать от пользователя, или получать не сами параметры, а идентификаторы их. Например, если речь идет о доставке в черте города, то это может быть идентификатор улицы, а в базе по нему уже параметр как расстояние от магазина до этой улицы, или уже готовая цена доставки. Если параметры, значит расчет по формуле.

Что у вас за доставка, кем (есть ведь доставка и курьерами, есть и почтой, у которой свои расценки), мне откуда знать?

Ну Php я изучаю, для себя. Сколько смотрел уроков, корзины были тоже с циклами. Но посмотрю, изучу как у вас устроено, может что то и пойму и для себя вынесу (искренне на это надеюсь). Думаю с помощью вашего кода и подхода к корзине я сумею правильно выводить размеры обуви, так как пока не получается так, как я хотел бы.

А вот доставка.... Попробуйте на этом сайте: http://top-top.bl.ee (на нём я тренируюсь и пытаюсь обучаться) выбрать какой-нибудь ботинок, зайти в корзину и там нажать оформить заказ. Появится страница order.php, где будет выбор типа доставки (пока в упрощённом виде) и вывод стоимости.

array_map это тоже обход массива циклом, просто явно его нет, это встроенная РНР функция написанная на Си.

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

У вас рядом с кнопкой Корзина отображается ее краткое описание - количество товара и общая сумма. Следовательно эта информация требуется часто, и ее получать выгоднее как функцией или процедурой. А разве не проще и лаконичнее в таком случае ее код как:

function total_basket($a) {
    return [array_sum(array_map('current', $a)), array_sum(array_map('array_product', $a))];
    //с учтом структуры корзины как описано по ссылке
}

где $a - массив корзины товаров. Можно непосредственно в функции обращаться к корзине, так как $_SESSION, это суперглобальный массив. А так как обращений к корзине будет много, это и добавление товара, и вывод корзины, и ее редактирование, то имя массива можно определить в одном месте через константу, например:

define('BASKET', 'bsk_name');
//и везде при обращениях, включая и внутри функции total_basket
return [array_sum(array_map('current', $_SESSION[BASKET])), array_sum(array_map('array_product', $_SESSION[BASKET]))];

Это гарантия того, что не будет дубликатов имен, или имен переменных и имен в $_SESSION. Если потребуется изменить, это нужно будет сделать только в одном месте.

Массивы, это тип данных с которыми в рамках веб приложения вы будете сталкиваться постоянно. А поэтому крайне желательно знать эти функции, и не просто знать, а уметь ими пользоваться.

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

echo '<form><table><tr>ячейки шапки таблицы</tr>' . implode(array_map(function($k, $v) {
   //return сформированная строка таблицы 
}, array_keys($_SESSION[BASKET]), $_SESSION[BASKET])).'</table><button>Send</button></form>'

В вашей корзине выбор доставки, это два типа, причем только первый имеет цену. Эти типы доставки должны быть прописаны в базе под идентификаторами, сделав запрос по которому можно получить цену 300 или 0, добавив ее к сумме заказа. И делать это надо в сценарии, который оформляет заказ. От клиента требуется только выбранный ID доставки, и получать его надо на той же странице, которая содержит сценарий оформления заказа.

PS. Примеры под РНР не ниже 5.4

laimas, ну допустим тип доставки я буду доставать из БД. Как тогда при нажатии на ту или иную кнопку тут же будет меняться "общая сумма"? Я и попробовал JS, чтобы на этой же странице без перезагрузке менялась "сумма".

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

laimas, в общем вы меня вообще в тупик поставили. Думал, что можно каким то образом передать значение в php-переменную, а теперь вообще не знаю что делать. Так было с размером, так теперь и с доставкой.....

Чем я вас загнал в угол? Вот ваш вопрос:

ну допустим тип доставки я буду доставать из БД. Как тогда при нажатии на ту или иную кнопку тут же будет меняться "общая сумма"? Я и попробовал JS, чтобы на этой же странице без перезагрузке менялась "сумма".

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

Конечно, курьера не обманешь, но ведь и ваш магазин может разбогатеть на ботинках, появятся новые виды услуг, которые могут быть связаны с безналичными расчетами, и если их стоимость вы будете отдавать на откуп клиенту, то вы и в суде не докажите, что вас обманули. А расширение услуг их добавление/редактирование означает, что описывать их как переменные не удобно, а вот в базе удобно, храня их описания и значения в полях типа ENUM. И на текущий момент пусть у вас в базе будет только два enum значения, а цена определяется по ходу и правкой текста, типа такого в таблице конфигураций:

CREATE TABLE IF NOT EXISTS `config` (
  `delivery` enum('Наш курьер (Стоимость доставки 300 руб)','Самовывоз') NOT NULL 
  DEFAULT 'Наш курьер (Стоимость доставки 300 руб)' 
  COMMENT 'Тип доставки',
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='Конфигурации'

Понимание этого не заводит вас в тупик? Тогда далее.

б) Мне трудно отвечать конкретно по действам нажатия на ту или иную кнопку потому как сумма заказов зависит не только от каких-то ваших кнопок, но и от изменений количества товаров в корзине. Речь ведь в данном случае идет о полном представлении корзины, ее редактировании, и для операций с ней необходимости прикручивать Ajax нет. Ajax это всего лишь один из способов общения с сервером, за кнопки и действия по ним он не отвечает, поэтому описывать задачу редактирования корзины как нечто зависящее от него не стоит. Достаточно иметь js-сценарий который будет просчитывать сумму заказа при изменениях количества товаров или их удалении. Сохранение же изменений может быть принято сервером при таких действиях как Сохранить (Обновить), Очистить, Оформить заказ. При этом, в последнем случае перед оформлением заказа нужно проверить не изменялось ли состояние корзины.

Это не вызывает проблем?

в) Ну и последнее - камень преткновения, общая сумма + доставка.

Выбор доставки у вас производится на странице оформления заказа. Если тип доставки описывается полем ENUM, как показано выше, то этому описанию на странице будет соответствовать выбор посредством двух радиокнопок:

<label>
    <input type="radio" name="delivery" value="1" data-dlv="300" checked />
    Наш курьер (Стоимость доставки 300 руб)
</label>
<label>
    <input type="radio" name="delivery" value="2" data-dlv="0" />
    Самовывоз
</label>

значения которых 1 и 2, соответствуют значениям ENUM описывающем тип доставки, а атрибуты data-dlv содержат значения цены за доставку, которые будет использовать js-сценарий при расчетах.

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

После вывода страницы и при смене типа доставки уже сценарий на клиенте будет получать из атрибута data-dlv стоимость выбранной доставки изменяя сумму с доставкой в ячейке таблицы. При оформлении заказа же, на сервер будет отправлено ее значение 1 или 2, которое и заносится в таблицу базы описывающей заказы.

Этого достаточно чтобы выйти из тупика?

Ну и как резюме: если вы учитесь, то учитесь не прикручивать сразу разные плюшки к своему проекту, они не есть главное. Главное научится видеть/представлять задачу целиком, ее поэтапное решение, что необходимо выполнять на каждом ее этапе, какими данными придется оперировать и что является их источником. Принцип только один - от общего к частному. Частности можно решать множественными способами, но без видения общего частности будут как кошка, которая сама по себе.

laimas, очень интересно, есть над чем поразмыслить. А какой код будет обрабатывать данный data-dlv="..."

Конечно надо размышлять.

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

Если же помимо регистрированных пользователь магазин не отказывает в заказе и не регистрированным, то и в этом случае можно обойтись без постоянного заполнения данных. Корректный ввод адреса, даже свое ФИО, это ахиллесова пята в форме, то, в чем наиболее часто допускают ошибки. Но если данные введены корректно, то их можно запомнить на клиенте в локальном хранилище (о регистрированных пользователях данные хранятся в базе), и при выдаче страницы этими данными заполняются поля формы. Правда это делать нужно с согласия клиента, ибо эти данные никак не защищены.

2) Сводная таблица о заказе должна отражать о нем все, а не так как у вас - товар, количество, всего за товар, а общего количества товаров нет, как и нет общей суммы за товары. Доставка в таблице при таком выборе как у вас вообще может не отражаться, ибо и тип и цену отражают радио кнопки. Но если думать о расширении услуг, то да, выбор должна отражать сводная таблица, и она же должна отражать и конечную сумму к оплате, которая будет просчитываться при выборе доставки. У вас же эта сумма сама по себе как текст после радио кнопок. А если еще будут бонусы и скидки, и что тоже раскидывать по странице? Зачем распылять внимание покупателя?

3) Должна быть определена доставка по умолчанию, о чем написано ранее - одна из двух как та что не требует лишних затрат или та что удобнее. Тоже самое потребуется, если магазин будет предлагать различные способы оплаты. Используйте тег LABEL, иначе искать и щелкнуть кнопку среди текста не совсем удобно.

Все надо обдумать, определиться со структурой, а уж потом думать о коде ее обрабатывающем. Поэтому конкретно какой код будет обрабатывать data-dlv я сказать не могу, а получить это значение в среде jQuery - $(selector).data('dlv').

laimas, регистрацию же делал в качестве урока. Привязку данных зарегистрированного пользователя пока даже не представляю, как делать. Видимо данные должны заносится в базу, и при входе в "личный кабинет" данные должны доставаться из базы данных...

Про бонусы, скидки пока очень сложно для меня, если элементарно не могу доставку внедрить... :((

А так - благодарю! Много полезного рассказали. В уроках о создании магзинов такого не видел.

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

А личный кабинет, это уже редактирование личных данных, установка/изменение каких либо опций, к примеру предпочтения по тому же типу доставки или способе оплаты.

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

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

>В уроках о создании магзинов такого не видел.

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

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