Скрипт обновления с PHP 5.6 до 7.2 появляется ошибка для Paypal

  • Автор темы tanmatra
  • 98
  • Обновлено
  • 13, May 2024
  • #1
Привет

Мой веб-сайт предназначен для того, чтобы люди могли покупать программное обеспечение на моем сайте.

На сайте есть один значок, на котором пользователь может увидеть «купить сейчас». Когда пользователь нажмет на этот значок, он будет перенаправлен в Paypal, а затем совершит платеж. Теперь проблема в том, что когда я перешел с PHP 5.6 на PHP 7.2, это действие просто дало мне пустой экран.

Это означает, что версия PHP 7.2 не может завершить оплату через Paypal.

Просто отметим, что скрипт отлично работает с другими функциями, такими как домашняя страница и страница контактов, и полностью функционален в PHP 7.2, но невозможно завершить только оплату по значку «Купить сейчас».

Как это исправить в каком-то файле?

Спасибо

tanmatra


Рег
01 Jan, 2011

Тем
1

Постов
3

Баллов
13
  • 18, May 2024
  • #2
@смертельная тень

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

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

Запрос, который ожидает числового ввода, «должен» сначала пройти проверку как минимум на «is_numeric» и т. д.

Это наша ответственность как программистов, а не разработчиков языков кодирования.

Во-вторых, написание собственной функции — это не перегрузка.

Это похоже на написание «класса», который можно снова и снова использовать в разных проектах.

Подумайте об этом так:

У вас есть веб-сайт, на котором загружается 20 различных типов страниц, каждая страница отправляет 4-5 запросов.

Это около 100 вызовов функции запроса в «одном» написанном вами скрипте.

Допустим, у вас есть 5 веб-сайтов, 500 вызовов функций запроса.

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

Не лучше ли вместо этого обновить один файл класса/функции?

Я написал для себя файл функции много лет назад, в нем много основных функций, в том числе и второстепенных, и когда PHP решил удалить mysql_query, все, что мне нужно было сделать, это изменить код моей функции «myQuery», которая находится в этом файл.

Затем загрузил этот новый файл функции во все мои проекты.

Задача решена!
 

Никита Феклинов


Рег
09 Mar, 2013

Тем
0

Постов
3

Баллов
3
  • 20, May 2024
  • #3
Скрытая информация :: Авторизуйтесь для просмотра »
, пожалуйста, не делитесь такими файлами с помощью файлообменников. Загрузите сюда или скопируйте исходный код. @deathshadow прав в том, что ваш новый хост, вероятно, не поддерживает функции MySQL. Вместо этого вам нужно будет перейти на функции «mysqli».
 

SamsungS


Рег
06 Dec, 2012

Тем
0

Постов
1

Баллов
1
  • 20, May 2024
  • #4
Если вы не сообщите нам об ошибке, которую вы получаете, исправить ее будет невозможно... Проверьте наличие ошибок в файле журнала или отправьте их в браузер. Я тоже пользуюсь PayPal, проблем с переключением с 5 на 7 не было. Я думаю, что либо вы используете устаревшую функцию перед перенаправлением пользователя на PayPal, либо вы забыли загрузить какой-то файл при переключении сервера...
 

AMS Partner


Рег
21 Apr, 2015

Тем
0

Постов
1

Баллов
1
  • 21, May 2024
  • #5
Не тогда, когда у вас есть фундаментальные изменения, такие как переход от полных переменных Pakled в строках запроса к использованию PDO с подготовкой/выполнением, если только вы не тратите кучу памяти, делая копии значений даром и перемещая их в стек, передавая их к вашим функциям и/или методам.

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

Особенно, когда многие из этих «проверок» больше не актуальны — используйте правильные типы для вашего поля, перехватывайте код ошибки.

или даже не заходите так далеко и выплевывайте форму обратно пользователю LONG еще до того, как ты подумаешь о взаимодействии с базой данных. Эти бесконечные обертки мусора просто добавляют больше кода даром, ОТКРЫВАЮТ дыры в безопасности, позволяя разработчику лениться, и в целом являются пустой тратой времени, усилий и денег. Особенно сейчас, когда нет особых оправданий не использовать PDO.

еще одна причина, по которой я предпочитаю его умственно ослабленному TRASH, которым является mysqli.

который даже не удосужился использовать один и тот же чертов объектный интерфейс для ->query и -> exec, что он делает для ->prepare. Да пошло оно. Хотя, я думаю, именно здесь большинство людей ошибаются — используют mysqli, когда она так же устарела и неэффективна, как и функции mysql_. КОНЕЧНО, вам нужен дополнительный мусор проверки, учитывая, насколько он нарушен, и мучительный способ реализации подготовки/выполнения.
 

shemil


Рег
26 Mar, 2013

Тем
0

Постов
1

Баллов
1
  • 21, May 2024
  • #6
Возвращаясь к вашему лицу, у вас есть пример этого? Поскольку большая часть нагрузки должна приходиться на сам движок, а не на интерфейс, это действительно вызывает у меня тревогу BS, если только вы не делаете что-то совершенно ошибочное.

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



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



. Конечно, Shin-ola не кажется медленнее, если только вы не делаете что-то совершенно неправильно и/или не устарело/устарело. Это еще одна проблема с тем, как mysqli не позволяет людям заново учиться что-то делать.

ТАК ЖЕ, как описанные вами оболочки не позволяют людям заново учиться делать что-то, когда методология радикально отличается от той, что была до нее.

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

... а если серьезно, тоbind_result и отсутствие возврата того же объекта для ->prepare, что и ->query/exec, является потрясающим примером того, почему mysqli может работать сама по себе и почему я не предлагаю никому тратить время на его изучение.

Это МУСОР! Вероятно, поэтому люди продолжают бросать вокруг него бессмысленные «обертывающие» объекты или функции.
-- редактировать -- кроме того, за последние два десятилетия у нас было только три интерфейса, а между PDO и mysqli десятилетие назад не прошло и шести месяцев.

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

что, похоже, ЕДИНСТВЕННАЯ вещь, для которой созданы эти фреймворки/обертки.

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

Вот какими одурманивающими и тупыми кажутся мне такие «обертки». За последнее десятилетие я очистил слишком много сломанных и раздутых веб-сайтов, которые обливали себя подобной ерундой.

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

sea-fon


Рег
08 Apr, 2015

Тем
0

Постов
2

Баллов
2
  • 03, Jun 2024
  • #7
Привет Я использую Centos, Apache. Я установил mysqlnd для версии 8.0 и теперь перенаправляюсь на Paypal, но при этом перенаправлении я получил ошибку, например:
Предупреждение: Неопределенный ключ массива «c» в /home/======/public_html/ipp/buy.php В сети 26

Предупреждение
: Неопределенная переменная $used_coupon в /home/======/public_html/ipp/buy.php В сети 60

После этой ошибки пользователь может перейти в Paypal, но это сообщение появится примерно через 2 секунды. Не подходит для глаз посетителя. Нужно ли мне было устанавливать что-то еще?
 

kontent-stydiya


Рег
20 Aug, 2013

Тем
1

Постов
3

Баллов
13
  • 03, Jun 2024
  • #8
Даже при переключении на PDO с mysqli все равно будет легко изменить один файл класса вместо изменения 500 экземпляров mysqli по всему сценарию.

Это не лень, это эффективность.

И, честно говоря, я не вижу, как PDO повышает безопасность.

И PDO, и mysqli «нуждаются», чтобы программист следовал лучшим практикам, таким как экранирование строк.

Плохому программисту, который игнорирует этот шаг, PDO не сможет ему помочь...

И пока вы избегаете ввода, вам не нужно беспокоиться о дырах в безопасности.

Можете ли вы показать мне один пример, где экранирования строки недостаточно?

Всего один пример, когда PDO помогает, а mysqli нет, даже после выхода?

Все, что мне нужно, это один пример.

На данный момент единственной причиной перехода на PDO является наличие нескольких механизмов баз данных, к которым он может подключаться 12, я думаю, на данный момент.

Какая польза от этой возможности, если CPANEL по умолчанию предлагает «только» движок MYSQL?

Производительность PDO медленнее, чем mysqli.

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

Вы этого хотите, тогда вам следует. Я не вижу сейчас в этом необходимости.
 

татка1


Рег
27 Jan, 2011

Тем
0

Постов
5

Баллов
5
  • 05, Jun 2024
  • #9
Вместо этого я бы предложил PDO, он менее тупой, более последовательный, более простой в использовании и не работает полностью, как mysqli, позволяя использовать устаревшие методологии, такие как тупые бессмысленные «функциональные оболочки».

Я также не согласен с ерундой «напишите свои собственные функции». Зачем вводить дополнительные накладные расходы без уважительной причины? Тем более, что если вы используете объектную модель mysqli или PDO, нет никаких законных функций, которые можно было бы добавить.

Скрытая информация :: Авторизуйтесь для просмотра »
, чтобы уточнить, поскольку условия волей-неволей разбрасываются.

mysql — механизм базы данных, хотя вы, вероятно, используете MariaDB и даже не подозреваете об этом.

mysql_ - обратите внимание на это подчеркивание, оно относится ко ВСЕМ функциям PHP, которые имеют подчеркивание, разрешающее доступ к mysqli; например mysql_connect, mysql_query и т. д. ПЕРЕСТАНЬТЕ ИСПОЛЬЗОВАТЬ ЭТО!

mysqli — еще один интерфейс, позволяющий получить доступ к MySQL из PHP.

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

PDO — еще ДРУГОЙ интерфейс, позволяющий получить доступ к базе данных из PHP.

Разработанный для использования практически с любым механизмом SQL, он открывает двери не только для MySQL, обеспечивая большую универсальность.

Независимо от того, выберете ли вы mysqli или PDO, вам все равно придется переписать способ обработки всех ваших запросов в модели подготовки/выполнения.

Это НЕ так просто, как поиск/замена, чтобы изменить mysql_ на mysqli_ в вашем коде, это распространенное заблуждение.

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

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

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

seo81783


Рег
24 Aug, 2011

Тем
1

Постов
2

Баллов
12
  • 05, Jun 2024
  • #10
Во всей этой кодовой базе так много неправильного, поскольку методология PHP больше 4, чем 5, что я бы просто выбросил весь этот беспорядок в мусор и начал все сначала. Даже строки, о которых вы упомянули, на 100% устарели на пятнадцать лет.

НЕБЕЗОПАСНЫЙ мусор. Хотя ваша настоящая ошибка должна быть строкой 61.
 

$sql = "Insert into tblOrders(ProductID, ProductName, ProductPrice, FileName, OTO, CustomerID, Paid, Odate, OTOcode, coupon_code)

VALUES ({$info['ProductID']}, '{$info['ProductName']}', {$price}, '{$info['FileName']}', 'N', 0, $paid, $odate, '".$OTOcode."', '".$used_coupon."');";

Код (разметка): PHP 5.6 и более поздние версии выдавали предупреждения об использовании функций mysql_, поскольку они устарели.

ОНИ УЖЕ НЕ СУЩЕСТВУЮТ в PHP 7. Это устаревший, устаревший и небезопасный способ ведения дел.

Прямо перед этим:
  mysql_query($sql) or die(mysql_error()); 


Код (разметка): Включение переменных в строку запроса — это снова то, что действительно не имеет никакого значения, даже если это делается в ЛЮБОЙ версии PHP 5.x, а тем более PHP 7. Это называется подготовка/выполнение, используйте это.

НЕ то чтобы это вообще должно было зайти так далеко, поскольку сначала должен был произойти mysql_connect, и это тоже выдает большое предупреждение в версии 5.6 и не существует в версии 7.

См. гигантское красное предупреждающее окно за последнее ДЕСЯТИЛЕТИЕ о функциях mysql_ в руководстве:

https://www.php.net/manual/en/function.mysql-connect.php

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

Чтобы перенести его в это десятилетие, необходимо полностью и полностью переписать его сверху донизу – будем надеяться, что это будет сделано до того, как десятилетие закончится.

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

dobermann1


Рег
21 Feb, 2012

Тем
1

Постов
3

Баллов
13
  • 10, Jun 2024
  • #11
Почти наверняка на вашем сервере/хостинге отсутствует ДОПОЛНИТЕЛЬНЫЙ модуль mysqli для PHP. Полная проблема с настройкой сервера. Какая операционная система хоста и как вы установили на нее PHP 8? У вас также установлен mysqlnd?




 

Suka4ev


Рег
11 Feb, 2016

Тем
0

Постов
2

Баллов
2
  • 10, Jun 2024
  • #12
Привет, ребята, это снова я

Спустя 2 года я столкнулся с той же проблемой при переходе на PHP 8.0.

Предыдущая проблема была решена для работы в версии PHP 7.2, но теперь я хочу перейти на 8.0. Когда я перехожу на 8.0 с сайта WHM, все работает нормально, но когда я нажимаю кнопку «купить», а затем меня не перенаправляют на Paypal, я вижу только сообщение о: Фатальная ошибка: Неперехваченная ошибка: вызов неопределенной функции mysqli_connect() в .... (я не копировал все сообщение об ошибке). Итак, из предыдущей решенной проблемы для работы в PHP 7.2 это нормально, и теперь я хочу переключиться на PHP 8.0, но получил эту ошибку.

Что мне нужно сделать еще раз, чтобы решить проблему, чтобы перенаправление платежей Paypal работало с PHP 8.0?

Заранее еще раз спасибо за помощь

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

Artsalana


Рег
11 Mar, 2011

Тем
1

Постов
17

Баллов
27
  • 11, Jun 2024
  • #13
Да, функции MySQL исчезли в php7. Вместо этого использует mysqli.

Лучше всего написать собственную функцию запроса mysqli, которая принимает запрос, выполняет его и отправляет результат в результирующую переменную.

Тогда вместо использования встроенных функций mysqli php на всех страницах скрипта просто используйте свою собственную функцию, которая вызывает встроенную функцию php.

Избавляет от многих хлопот во время таких обновлений.
 

nikseo2011


Рег
15 Feb, 2011

Тем
3

Постов
5

Баллов
35
Тем
49554
Комментарии
57426
Опыт
552966

Интересно