В примере указано просто <form>, Вам необходимо изменить на <form action="/mail.php" method="post">, далее, в корне сайта создайте файл mail.php с подобным содержимым:
<?phpmail($_POST['email'], "Вам письмо от ".$_POST['name'], $_POST['message']); header('Location: /');?>
Самый примитивный способ решения задачи, без фильтрации, защиты от спама и различной информации об успешной отправке или нет.
На части проектах стоит РобоКасса, но не нравится то, что комиссия платежных систем перекладывается на клиента. Не знаю, может сейчас иначе, на старых аккаунтах было так.
Для новых проектов используем unitpay.ru, молодая и перспективная система, очень хороший функционал, целеустремленны, быстро развиваются. Все основные платежные системы есть.
Попробуйте перенести все на новый формат ссылок и аккуратно поставить переадресацию через файл .htaccess и mod_rewrite.
Когда-то занимался решением подобной проблемы, на вид система была чистой, но что-то трафик потребляло. Долго перебирал программы для Windows, которые бы показывали потребление трафика каждой из программ. Название забыл уже, было очень давно это, но поищите что-нибудь подобное и посмотрите, что трафик потребляет.
Сейчас вроде KIS умеет показывать потребление трафика в режиме реального времени. Если не пользуетесь, поставьте Trial, посмотрите, есть ли там такое.
Немного непонятна проблема все равно. Сайт открывается по доменному имени? Или идет сразу переадресация на IP?
Если сайт открывается по доменному имени, а ссылки на нём в виде IP, то мне кажется это проблема в настройке Joomla.
Автор, почистите как можете, после повторного заражения посмотрите дату изменения зараженных файлов. Поднимите acces_log, посмотрите, что делалось в это время.
Недавно чистили сайт, была подобная ситуация. В шаблоне сайта лежал файл, с помощью которого можно было редактировать любые файлы сайта, так называемый шелл. Удалили - стало спокойно.
Спасибо. Итак, что я увидел, много ошибок от PHP Warning (внимание): Invalid argument supplied for foreach()
Данный тип ошибок не останавливает выполнение скрипта, то есть, сайт должен отображаться, но может отображаться некорректно. Также, большое обилие любых ошибок может влиять на скорость выполнения скрипта.
Данные ошибки находятся в плагине dynamic-multi-level-fields, если быть точным, в файле multi-level.php, около 34 строки в цикле foreach. Что за ошибка? Циклу foreach передается неверный аргумент, вероятнее всего не массив и не объект.
Как это исправить? Посмотреть код, выяснить, почему в некоторых случаях или всегда передается неверный аргумент для функции foreach. Но для начала можно попробовать обновить плагин до последней версии, если уже последняя, тогда только руками или писать авторам и приложить данный файл error.log
Еще есть вот такой интересный отрезок:
[Tue Mar 25 14:31:35 2014] [error] [client 85.26.164.128] \xd0\x91\xd0\xb0\xd0\xb7\xd0\xb0 \xd0\xb4\xd0\xb0\xd0\xbd\xd0\xbd\xd1\x8b\xd1\x85 WordPress \xd0\xb2\xd0\xbe\xd0\xb7\xd0\xb2\xd1\x80\xd0\xb0\xd1\x82\xd0\xb8\xd0\xbb\xd0\xb0 \xd0\xbe\xd1\x88\xd0\xb8\xd0\xb1\xd0\xba\xd1\x83 Can't create table '_domobyavleniy.#sql- 26da_1d26c4e' (errno: 121) \xd0\xb2 \xd0\xbe\xd1\x82\xd0\xb2\xd0\xb5\xd1\x82 \xd0\xbd\xd0\xb0 \xd0\xb7\xd0\xb0\xd0\xbf\xd1\x80\xd0\xbe\xd1\x81 ALTER TABLE wp_slim_stats ADD CONSTRAINT fk_browser_id FOREIGN KEY (browser_id) REFERENCES wp_slim_browsers (browser_id), \xd0\xb2\xd1\x8b\xd0\xbf\xd0\xbe\xd0\xbb\xd0\xbd\xd0\xb5\xd0\xbd\xd0\xbd\xd1\x8b\xd0\xb9 require_once('wp-admin/admin.php'), require_once('wp-load.php'), require_once('wp- config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), call_user_func_array, wp_slimstat_admin::init, wp_slimstat_admin::update_tables_and_options, referer: http://www.domobyavleniy.ru/wp- admin/update.php?action=update-selected&plugins=vkontakte-api%2Fvkapi.php%2Cwp-slimstat%2Fwp-slimstat.php&_wpnonce=87ecd01720
Данная ошибка в плагине WP SlimStat. Ошибка заключается в неверном формировании SQL запроса и получения ошибки. Попробуйте обновить плагин.
Скопируйте кусочек или приложите полный файл, посмотрим, тогда можно будет что-то посоветовать.
Автор, весьма кстати напомнили о себе. Мы со связки Apache (itk) + mod_php перешли на Apache (prefork) + PHP-FPM заметили отличный рост производительности при измерении Битрик'сом. К Вам можно как-то попасть на повторное тестирование? :)
Собственно, по нашим тестам на PHP 5.5 вот такая картина (на PHP 5.3 чуть похуже):
Единственное, боролись с ростом времени отдачи страницы, так ничего и не добились. Может кто сталкивался? На графике синяя линия, происходит рост при повышении количества одновременных соединений. Свободные процессы Apache есть с запасом, ограничений на соединения нет. Ресурсы также полностью не используются...
А относительно последнего тестирования. Как-то странно, обратиться за тестированием и предоставить OpenVZ сервер. Как-то смешно выглядит и неправдоподобно 😂
Некоторые пользователи все равно будут попадать на старый сервер некоторое время, как TTL не крути. Если простой критичен, то переносите полностью все на новый хостинг, на старом меняете настройки базы данных на базу данных у нового хостера (у нового хостера должны разрешить удаленные подключения к базе данных). Можно сказать простоя избежали. С нового или старого хостинга будут писать на форум, записи будут отображаться везде.
После этого можно хоть не спеша обновлять DNS.
Единственный подвох может быть в том, если пинг высокий или каналы слабые между хостингами, а обращений к БД много, то возможны тормоза у клиентов, которые попадают на старый хостинг.
