nowm

Можно это сделать двумя способами:

1. Доработать PHP-код, чтобы он реагировал на сигналы, переданные через вебсокет. Например, если ему послать команду «stop», то он должен останавливаться и, соответственно, процесс завершается, освобождая TTY или тот скрипт, который запускал этот вебсокет.
   
2. Скрипт с вебсокетом можно запускать в фоновом режиме, а потом, если нужно его завершить, просто убивать процесс по его PID. Чтобы запустить скрипт в фоновом режиме, нужно добавить & в конце команды. Для примера: php bin/chat-server.php &
   

Судя по вашей терминологии («перезагрузка php») вы из скрипта PHP вызываете команду php bin/chat-server.php, а сам этот скрипт вызывается с помощью HTTP-запроса из браузера. В этом случае имеется ввиду перезагрузка PHP-FPM, так? Если так, то самое простое решение проблемы с подвисанием скрипта — это способ 2.

Я обычно пользуюсь DOM в PHP. Конечно, можно отдельные поля регулярными выражениями отловить, если знаешь их название, но есть большая вероятность, что у одного инпута сначала будет идти `type`, потом `name`, а у другого наоборт, и придётся для каждого инпута писать отдельный код, который будет из него вытаскивать значение. Проще воспринимать их как сущности с одинаковыми признаками и переложить парсинг на специализированные билиотеки.

Насколько я понял, судя по особенностям наименования инпутов, это был форум на базе hoop.la (не путать с hoopla). Я бы примерно так организовал парсинг:

$dom = new \DOMDocument();

libxml_use_internal_errors(true);
if (!@$dom->loadHTML('содержимое страницы в виде HTML')) {
    /** @var \LibXMLError $error */
    $error = libxml_get_last_error();
    if ($error->level > LIBXML_ERR_ERROR) {
        throw new \Exception($error->message);
    }
}

$xpath = new \DOMXPath($dom);

/** @var \DOMNodeList $form */
$form = $xpath->query('//form[@name="mainLoginForm"]');
if (!$form->length) {
    throw new \Exception('Форма не найдена');
}

$post_data = [];

/** @var \DOMElement $input */
foreach ($xpath->query('.//input', $form->item(0)) as $input) {
    $post_data[$input->getAttribute('name')] = $input->getAttribute('value');
}

$post_data['email'] = 'логин';
$post_data['password'] = 'пароль';

// В $post_data находятся все данные которые нужно отправлять

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

В каких-то других ситуациях, кроме инпутов нужно будет искать ещё и селекты, или предусматривать ситуации, когда нужно делать выбор из нескольких radio-элементов, либо предусматривать ещё более комплексные ситуации, но конкретно в случае с hoopla этого не потребуется — там одни инпуты, и они динамически с помощью JS вроде бы не модифицируются (сильно не тестировал).

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

Если два массива имеют одинаковую длину, можно просто двигать по кругу первый массив и сравнивать его элементы с элементами второго. Потом можно просто выбрать максимальное совпадение и перегнать в проценты. Примерно так:

$arr1 = [1,2,3,4,5,7,2,8];
$arr2 = [2,9,5,5,7,2,8,1];

$len = count($arr1);
$conformity = [];

for($i = 0; $i < $len; $i++) {
	/**
	 * $temp содержит нули в позициях, где числа в двух массивах 
	 * по одному и тому же индексу не равны. Единицы — там, где равны.
	 */
	$temp = array_map(function($x,$y){return intval($x==$y);}, $arr1, $arr2);
	
	// Элементы полученного массива суммируются и добавляются в отчётный массив
	$conformity[] = array_sum($temp);
	
	// Массив прокручивается на одну позицию
	$arr1[] = array_shift($arr1);
}

//С помощью max($conformity) выбирается максимальное совпадение элементов
echo sprintf("Max conformity is %s%%\n", number_format(100*(max($conformity)/$len), 2));

Это конкретно для ситуации, когда длина «колец» одинаковая.

Update: ещё один вариант:

$arr1 = [1,2,3,4,5,7,2,8];
$arr2 = [2,9,5,5,7,2,8,1];

function conformity($arr1, $arr2) {
	$len = count($arr1);
	$max = $curr = 0;
	
	for($i = 0; $i < $len; $i++) {
		array_map(function($x,$y)use(&$curr){$curr += intval($x==$y);}, $arr1, $arr2);
		
		if($curr == $len) {
			return 100;
		}

		$max = $max > $curr ? $max : $curr;
		$curr = 0;
		
		$arr1[] = array_shift($arr1);
	}
	
	return 100*($max/$len);
};

echo sprintf("Max conformity is %s%%\n", number_format(conformity($arr1, $arr2), 2));

%%

Вы же затёрли предыдущее значение $rez. Поэтому $rez->response->games — это несуществующее свойство.

Смотрите сами:

$rez = json_decode($getUrl); // $rez->response->games существует
$rez = $rez->response->games; // $rez->response->games больше не существует

Нужно просто другую переменную использовать. Например так:

$rez = json_decode($getUrl);
$app_list = $rez->response->games;

Тогда у вас $rez->response->games будет доступно и вы сможете делать foreach как для $app_list, так и для $rez->response->games.

1. Точка с запятой необязательна, если выполняется только одна инструкция. В вашем случае её можно не писать, так как выполняется только одна инструкция «INSERT». Если инструкций несколько, то каждая инструкция обязательно должна заканчиваться точкой с запятой (кроме последней инструкции, кажется — там не обязательно).

2. Да, запрос правильный.

Тот запрос, который у вас был «как вариант», не будет работать, потому что вы пытаетесь нормальный PHP-шный NULL скопировать в строку. Там не появится слово «NULL» в итоге, так как вместо него подставится пустая строка. Итоговый запрос будет выглядеть примерно так:

INSERT INTO users (user_id, user_name, user_adddate) VALUES ('', 'user', '1404721764')

У вас здесь сразу две ошибки. Первая — вы передаёте значение NULL, а нужно передавать строку со словом «NULL». Вторая — вы пытаетесь сгененрировать строку так, что у вас слово «NULL» будет в SQL-запросе стоять в кавычках. В таком случае это для SQL-сервера будет считаться не значением «NULL», а строкой. Будет выдана ошибка, потому что у вас user_id — целочисленное, а вы пытаетесь в него писать строку. Правильнее будет так (разобью на строки для читаемости):

<?php
$insert_sql = sprintf("
    INSERT INTO users (user_id, user_name, user_adddate) 
    VALUES (%s, '%s', %d)
", 'NULL', $user_name, time());
?>

Со sprintf вы движетесь в правильном направлении. После этого вам будет легко понять принцип работы подготовленных запросов PDO, которые я вам советую использовать вместо mysql_*-функций.

<?php
/* 
 * Инициализация. Эту строку нужно писать там, 
 * где вы делаете mysql_connect. А сам вызов mysql_connect 
 * и прочего сопутствующего можно удалить.
 */
$db = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass');

// . . .

/* 
 * Вставляемые переменные заменяются знаками вопроса. Никаких кавычек
 * тут ставить не нужно — PDO сам поставит их в нужном месте.
 */
$sth = $db->prepare('INSERT INTO `users` (user_id, user_name, user_adddate) VALUES (NULL, ?, ?)');

/* 
 * Передача значений в запрос происходит в виде массива;
 * порядок элементов в массиве имеет значение. 
 * $user_name — первый элемент, значит его значение подставится 
 * на месте первого знака вопроса. time() — второй элемент, значит
 * его результат подставится вместо второго «?»
 */

$sth->execute( array($user_name, time()) );
?>

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

<?php 
// . . . 

$sth = $db->prepare('INSERT INTO `users` (user_id, user_name, user_adddate) VALUES (?, ?, ?)');

/*
 * Важный момент: нельзя писать
 * $sth->bindParam(1, NULL, PDO::PARAM_NULL);
 * Перед тем, как биндить NULL, его нужно присвоить переменной 
 * и биндить уже эту переменную. Иначе будут выскакивать ошибки.
 */
$null_value = NULL;
$sth->bindParam(1, $null_value, PDO::PARAM_NULL);

$sth->bindParam(2, $user_name, PDO::PARAM_STR);
$sth->bindParam(3, time(), PDO::PARAM_INT);

/*
 * Так как параметры уже переданы с помощью bindParam-ов,
 * в вызов execute не нужно ничего добавлять.
 */
$sth->execute();
?>

По поводу NOW() или CURDATE(). У вас выскакивает ошибка потому, что это не функции PHP. Это функции MySQL и их нужно писать в запросе как есть — они выполняются не в интерпретаторе PHP.

Как я понял, вы пытались что-то вроде этого делать:

<?php
$insert_sql = sprintf("
    INSERT INTO users (user_id, user_name, user_adddate) 
    VALUES (%s, '%s', %d)
", 'NULL', $user_name, NOW());
?>

А нужно так:

<?php
$insert_sql = sprintf("
    INSERT INTO users (user_id, user_name, user_adddate) 
    VALUES (NULL, '%s', NOW())
", $user_name);
?>

Так же, если вы добавляете user_adddate с помощью NOW() или CURDATE(), лучше для этого столбца изменить тип с bigint(20) на datetime.

Вот так:

$rows = $bd->exec("INSERT INTO test (tab$j) VALUES ('$nomer')");

У вас не срабатывает текущий вариант из-за того, что вы пишете так: '{$j}'. Дело в том, что в одиночных кавычках подстановка значения переменной не происходит. Для подстановки значения нужно использовать двойные кавычки. Я проиллюстирую:

$variable = 'John';

echo 'Hello, $variable'; // Выведет: Hello, $variable
echo "Hello, $variable"; // Выведет: Hello, John

Так же, судя по вашему коду, под tab0 и tab1 подразумеваются названия полей в таблице test, а не названия отдельных таблиц tab0 и tab1.

И, под конец: несмотря на то, что вы используете PDO, вы зачем-то пихаете значение переменной в строку запроса напрямую, как это делается при использовании mysql_query(); Это ни на грамм не добавляет безопасности такому запросу. Почитайте про подготовленные запросы в PDO. Если не ошибаюсь, вот такая конструкция может сработать:

$st = $bd->prepare("INSERT INTO test (tab$j) VALUES (?)");
$st->execute(array($nomer));
$rows = $st->rowCount();

Ссылка на мое убожество

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

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

Спросите у того, кто вам это сказал. Поинтересуйтесь, что можно исправить и в каком направлении работать. Просто в одной компании у Senior PHP Programmer может быть даже меньше навыков, чем у Junior PHP Programmer в другой компании. Если кто-то говорит, что код — гавно, попросите объяснить, почему он плохой. Если люди не объясняют, просто забейте и программируйте в своё удовольствие.

Чётких критериев деления на Junior, Middle и Senior нет. Но есть признаки, по которым можно примерно ориентироваться.

1. Если человек пишет программу так, что вывод нарушает семантику выходного формата, это явный признак юниорства. Для примера, в файле /framework/index.php есть такой код:

echo '<!-- Код выполнен за '.number_format(microtime(1)-$t,3).' секунды -->';

Это выведет примерно такой код:

<html>
. . .
</html>
<!-- Код выполнен за 0.531 секунды -->

Семантически это неправильно, так как после закрывающего тега HTML больше не должно ничего быть.

2. Русские и английские комментарии смешиваются. Вообще, лучше писать комментарии на английском, так как код вы выкладываете на ресурс, где большинство посетителей англоговорящие (я про GitHub, а не про Тостер). При этом, без проблем можно писать комментарии на русском, если вам глубоко параллельно на англоязычную аудиторию. Но в этой ситуации нужно писать все комментарии на русском. У вас же там мешанина — автоматически сгенерированные фреймворком англоязычные комментарии и рядом комментарии на русском языке. В вашем случае нужно либо переписать английские комментарии на русский, либо русские комментарии перевести на английский.

Дополнительно, не нужно писать комментарии для обыденной фигни, вроде:

$config['per_page'] = 10; // сколько записей показывать на странице

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

3. Не-единообразный подход к оформлению кода. Например, фреймворк сгенерировал такой код:

if (defined('ENVIRONMENT'))
{
    switch (ENVIRONMENT)
    {
        case 'development':
            error_reporting(E_ALL);
        break;

        case 'testing':
        case 'production':
            error_reporting(0);
        break;

        default:
            exit('The application environment is not set correctly.');
    }
}

Это код по стандарту PSR-2

Код, написанный вами, не попадает под этот стандарт. Для примера:

if (strlen($uri)>1) {// если не главная страница...
  if (rtrim($uri,'/')!=$uri) {
    header("HTTP/1.1 301 Moved Permanently");
    header('Location: http://'.$_SERVER['SERVER_NAME'].str_replace($uri, rtrim($uri,'/'), $_SERVER['REQUEST_URI']));
    exit();
  }
}

Я предлагаю самостоятельно определить, что здесь не соответствует PSR-2. В целом, я чаще всего забиваю на PSR-2. Но я пишу так, как написан основной код. Если основной код написан по стандарту PSR-2, я свои правки тоже делаю в этом стиле. Мешать стандарты, делать в одном месте отступ в два пробела, в другом — в четыре пробела, а в третьем в один TAB — это тоже признак юниорства. Сразу видно, что вы писали мало и не можете понять, что в коде должно быть единообразие, чтобы он выглядел не-юниорским.

4. Велосипеды — ещё один признак новичка. Раз уж вы таким способом (как в листинге выше) пытаетесь определить главную страницу, можно сократить код (про «велосипед» объяснение в пунктах «в» и «г»):

a) Нафига добавлять в блок IF единственный блок IF? Такая вложенность блоков нужна только если у вас внутри первого блока IF есть несколько IF-операций, а не одна единственная. Например:

if (x = 0) {
    if ( isset(y) ) {
        echo 'The Y is set';
    }

    if ( isset(z) ) {
        echo 'The Z is set';
    }

    echo "Echo something";
}

Нужно так писать в вашем случае:

if (strlen($uri) > 1 && rtrim($uri, '/') != $uri) {
    // some code
}

б) Если вы несколько раз пытаетесь использовать вызов функции с одними и теми же параметрами, и функция определённо возвращает один и тот же результат, лучше один раз присвоить её результат переменной и использовать переменную. Например, «rtrim($uri,'/')» вызывается несколько раз. Совершенно понятно, что она всё время будет возвращать один и тот же результат. Конечно, rtrim работает быстро и разницы не будет заметно в итоге. Но вот, например, если у вас функция будет делать запрос в БД, и вы будете её таким способом каждый раз дёргать, это скажется на производительности.

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

// Плохой подход
echo 'У меня есть ' . get_my_apples_from_database() . ' яблок, потому что ' . get_my_apples_from_database() . ' яблок — это круто';

// Хороший подход
$my_apples = get_my_apples_from_database();
echo "У меня есть $my_apples яблок, потому что $my_apples яблок — это круто";

// Плохой подход
$my_apples = get_my_apples_from_database();
echo "У меня есть $my_apples яблок";

// Хороший подход
echo 'У меня есть ' . get_my_apples_from_database() . ' яблок';

в) Если вы пользуетесь CodeIgniter, почему бы не пользоваться его возможностями определения факта, что сейчас открыта главная страница?

г) Вобще, редиректы со слеша на страницу без слеша нужно делать средствами веб-сервера, а не средствами PHP-интерпретатора.

Если у вас установлен Apache, можно добавить в .htaccess в корне веб-сайта такой код:

RewriteCond %{REQUEST_URI} ^.+
RewriteRule ^(.*)/$ /$1 [L,R=301]

Это только для иллюстрации. Я не гарантирую, что эта конструкция будет работать идеально, но как пример она хорошо подходит.

5. Вот такой интересный код в контроллере application/mvc/controllers/blog.php:

$query = $this->db->query("SELECT count(`id`) FROM `blog_page` WHERE `category`='$id'");//Считаем

CodeIgnitor — это MVC-фреймворк, он помогает понять, что такое MVC и как правильно писать MVC-приложения. Куча документации же на эту тему. Предлагается разделять код на модель, контроллер и представление. Это означает, что каждая часть выполняет свои какие-то функции. Модель, например, кроме прочего, занимается добычей данных из базы данных. Только модель этим должна заниматься. SQL-запросы в контроллере — это... есть такое выражение: «толстые тупые уродливые контроллеры». Это обычное определение, ничего обидного. Так называются контроллеры, которые делают запросы к БД и частично генерируют HTML-код. Они появляются в ситуации, когда разработчику влом прыгать по файлам и он начинает лепить всё в контроллер. Или когда у него нет достаточного количества знаний по MVC, чтобы правильно разделять код.

* * *

Вот. У вас куча таких вещей (и ещё дохрена вещей, которые можно покритиковать) в коде. Они показывают, что вы только недавно начали программировать, у вас небольшой «словарный запас», много велосипедов в коде, много неоптимальных подходов, вроде такого:

$i = 0;

foreach($query->result_array() as $row)
{
	$myrow[$i]['url'] = $row['url'];
	$myrow[$i]['title'] = $row['title'];
	$myrow[$i]['text'] = substr(strip_tags($row['text']),0,255);
	$i++;
}

Вместо этого можно было написать так:

$myrow[] = array();

foreach($query->result_array() as $row)
{
	$myrow[] = array(
		'url' => $row['url'],
		'title' => $row['title'],
		'text' => substr(strip_tags($row['text']),0,255)
	);
}

Переменная $i тут не нужна. Можно нормально обойтись без неё. А вот $myrow обязательно нужно определить, чтобы не сталкиваться с неожиданными ошибками, если $query->result_array() вернёт 0 запией.

Читайте разный код. Понятно, что это универсальный совет, на который вы ответите: «я знаю». Но если вы не будете читать, останетесь безграмотным, вне зависимости от того, знаете вы про полезность этого совета или нет.

Если пишете на CodeIgniter, почитайте его исходники и документацию. Не почитаете — будете плодить велосипеды, вместо которых можно было бы использовать API фреймворка.

Используете MVC? Почитайте, для начала: ru.wikipedia.org/wiki/Model-View-Controller Там про толстые контроллеры тоже есть.

* * *

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

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

В первую очередь — из-за этого:

$doc->load($str);

«load» — это для загрузки файлов и в качестве параметра ей нужно давать путь к файлу. Если вы хотите загрузить строку, нужно использовать функцию «loadHTML».

Дальше у вас появится куча предупреждений. Если появится сообщение про то, что непонятки с кодировкой появились, от него можно избавиться, если поправить строку с loadHTML:

$doc->loadHTML(mb_convert_encoding($str, 'HTML-ENTITIES', 'UTF-8'));

Кроме строки про кодировку будет ещё куча предупреждений, вроде:

Warning: DOMDocument::loadHTML(): Opening and ending tag mismatch: li and div in Entity
Warning: DOMDocument::loadHTML(): htmlParseEntityRef: expecting ';' in Entity
Warning: DOMDocument::loadHTML(): Opening and ending tag mismatch: td and b in Entity

Чтобы эти уведомления не засоряли эфир, можно добавить символ «@» при вызове «loadHTML»:

@$doc->loadHTML($str);

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

$res = $xpath->query('.//*');
foreach($res as $obj) {
	echo $obj->getNodePath() . "\n\r";
}

Из листинга будет видно, что упоминание связки «table/tbody/tr» некорректно. «TBODY» там нет. Такой XPath-запрос сработает нормально в FirePath из Firefox, например. И работает он из-за того, что Firefox самостоятельно достраивает DOM документа до идеального по его мнению состояния — например, добавляет «TBODY», где его нет, закрывает незакрытые теги и так далее.

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

В вашей ситуации нужно из запроса просто убрать «tbody». Получится такой запрос:

//*[@id="content-all"]/div[2]/div/table/tr[3]

Как я вижу, решение уже появилось, но, вообще, такой подход, который я описал, поможет искать ошибки в подобных ситуациях.

С самого начала у вас должно быть понимание, что Query можно вызывать только для DomXPath, который инициализируется только с DomDocument. Всё. Ему нельзя подсовывать DomNodeList или DomNode. Только DomDocument. Из-за этого нужно применять другой подход к получению данных.

Вы думаете, что можно найти запросом таблицу, потом ещё одним запросом найти в ней DIV, потом ещё одним запросом найти в этом DIV какой-нибудь SPAN, а в нём ещё одним запросом найти A. С DomXPath так нельзя работать. Хотите найти элемент, ищите его сразу — от корня DOM.

Прямо сейчас могу что-то неточно написать в самих XPath-запросах, но делать нужно примерно так:

$pageDom = new DOMDocument();
@$pageDom->loadHTML($pageHtml);
$pageXPath = new DomXPath($pageDom);

$elementsName = $pageXPath->query('.//table/.//div[class="name"]');
$elementsDescription = $pageXPath->query('.//table/.//div[class="description"]');
$elementsRating = $pageXPath->query('.//table/.//div[class="rating"]');

$elements = array();

for ($i = 0; $i < $elementsName->length; $i++) {
    $elements[] = array(
        'name' => $elementsName->item($i)->nodeValue,
        'description' => $elementsDescription->item($i)->nodeValue,
        'rating' => $elementsRating->item($i)->nodeValue,
    );
}

//Profit

Однако!

Якориться к предыдущим результатам поиска всё-таки возможно. У функции DomXPath::query есть необязательный параметр с типом DOMNode. Получаются такие неявные под-запросы.

$pageDom = new DOMDocument();
@$pageDom->loadHTML($pageHtml);
$pageXPath = new DomXPath($pageDom);

$elementsDom = $pageXPath->query('.//table/tr');

$elements = array();

foreach ($elementsDom as $elementDom) {
    $elements[] = array(
        'name' => $pageXPath->query('.//div[class="name"]', $elementDom)->item(0)->nodeValue,
        'description' => $pageXPath->query('.//div[class="description"]', $elementDom)->item(0)->nodeValue,
        'rating' => $pageXPath->query('.//div[class="rating"]', $elementDom)->item(0)->nodeValue,
    );
}

Особенность в том, что используется всё тот же $pageXPath, а не происходит попытка создать из DOMNode отдельный DOMXPath. И дальше происходит поиск в контексте предыдущих результатов запроса — за счёт добавления в функцию DomXPath::query дополнительного параметра, уточняющего контекст, в котором происходит поиск — DomXPath::query(строка_запроса, контекст_поиска). Так что в такой ситуации «.//div[class="name"]» будет искаться не во всём документе, а только в текущей строке TR.

В целом, насколько я вижу из своего опыта (я «переезжал» сайты с Bitrix, WebAsyst и Shop-Script), переезд на Опенкарт может обойтись примерно в 17-20 тысяч (миграция категорий/товаров/производителей/атрибутов/опций, создание/миграция шаблона).

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

Сорри за лирическое отступление — я всё никак не найду, кому поплакаться в жилетку. :)

Реально ли вообще построить на Open Cart серьезный проект?

Да, на Opencart вполне возможно построить серьёзный магазин. У него большой плюс в том, что модули к нему можно очень легко и быстро писать. Даже, в принципе, начинающий программист может с этим справиться. И людей, которые что-то дорабатывают/пишут, очень много. Много всего можно найти на opencartforum.ru.

С какими проблемами можно столкнуться в первое время?

В первое время можно столкнуться с тем, что он будет тормозить на большом количестве продуктов и категорий. Он всё время пытается считать количество товаров в каждой категории, даже если в настройках это отключено. В официальный репозиторий больше года назад была принята правка, которая этот момент исправляет, но почему-то в последние версии эта правка так и не попала, как я вижу (и в v1.5.6 и в v1.5.6.1 эта недоработка всё ещё присутствует). Если этот момент исправить, скорость поразительно увеличивается. Я один раз умудрился $150 заработать на этом моменте — за пару минут работы. Там всего-то две небольшие правки сделать нужно.

В остальном, движок особенно неприятных сюрпризов больше не доставляет.

Какие могут быть размеры вложений для исправления основных проблем этой CMS?

150 долларов — это была удача. Вообще, цена такой правки — примерно рублей 500, но вы наверняка можете и дешевле найти на профильных ресурсах. В MaxyStore, кажется, вообще этот момент поправлен. Так что он вполне нормально будет из коробки работать, и никаких основных проблем исправлять вообще не придётся.

Оправданы ли мои опасения насчет того, что бесплатный продукт может принести слишком много проблем?

Продукт продукту рознь. Сам Opencart особенно много проблем вам не принесёт. Но проблемы могут принести дополнительные модули. У Opencart довольно-таки низкий порог вхождения, поэтому качество кода может быть ужасным. Один модуль может начисто убить весь jQuery на странице. Другой сделает так, что у вас отзывы о продукте не будут отправляться. Третий (от какого-нибудь французского разработчика, который очень любит делать навигационные модули) будет на каждый пук дёргать базу данных, генерируя по 86 дополнительных запросов к БД на одной странице. Вообще, в ситуации с Опенкартом, лучше постоянно работать с одним и тем же программистом, который будет и модули устанавливать и дорабатывать и ошибки устранять и т.д. Мороки будет меньше, потому что на русскоязычных ресурсах расспрашивать, почему выскакивает такая-то и такая-то ошибка — неблагодарное дело.

Есть проект MaxyStore на основе OpenCart - может стоит взглянуть в его сторону или нет смысла?

Попробуйте ещё посмотреть в сторону ocStore с сайта opencartforum.ru. Мне кажется, что он немного лучше. С позиции разработчика мне лично MaxyStore не нравится. Я не могу внятно описать причины, но в ситуации, когда есть выбор между MaxyStore и Opencart, я однозначно выберу Opencart.

У таких сборок, как MaxyStore и ocStore плюс в том, что они интегрируют много полезных модулей.

Минусы. Они часто отстают по версиям на 1-2 релиза. К примеру, какой-нибудь новейший ***Store может быть основан на версии Opencart, которая вышла больше года назад.

Зачастую финтиклюшки, которые разработчики сборок добавляют в ядро, замедляют работу движка. Как я вижу (может быть я не прав), разработчики движков на основе Opencart больше внимания уделяют внешнему виду, а не архитектурным вопросам, которые позволят повысить скорость или безопасность. А если они и начинают заниматься архитектурными вопросами, то движок частично теряет совместимость с модулями, написанными для оригинального Opencart.

На какие еще CMS стоит обратить внимания, учитывая мои требования?

Я вообще после того, как мой пул-реквест отшили, решил вообще больше не заниматься Opencart (такой вот я чувствительный) и перейти на разработку для Magento. Из всех движков, о которых я слышал (или которые щупал) он мне больше всего нравится. Хотя, вообще-то, я не так уж и много движков щупал.

Первый способ: сохранить запросы в файл и импортировать этот файл через командную строку. mysql -u user database < /home/username/mysqldump.sql

Второй способ: можно сократить количество запросов немного поменяв логику построения запроса. Вместо

UPDATE `products` SET `status` = 1 WHERE `product_id` = 1;
UPDATE `products` SET `status` = 1 WHERE `product_id` = 2;
-- 
UPDATE `products` SET `status` = 1 WHERE `product_id` = 1000;

можно писать так:

UPDATE `products` SET `status` = 1 WHERE `product_id` IN (1, 2, 3, 4, 5);
UPDATE `products` SET `status` = 2 WHERE `product_id` IN (6, 7, 8, 9);

Update: оу... я так медленно пишу. Когда начинал писать, ни одного ответа ещё не было. ))