Umi cms ошибка 16005

Удалось ли выяснить в чем была проблема?

Записан

Записан

Записан

Записан

При установке любой программы иногда возникают вопросы. Большинство вопросов при установке CMS связано с настройками хостинга и системными требованиями. Обычно при возникновении ошибки система сообщает вам ссылку вида http://errors.umi-cms.ru/{номер}/, по которой доступно развёрнутое описание ошибки и способы её устранения.

Мы собрали для вас частые вопросы наших пользователей и их успешные решения:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -f

RewriteRule ^(cache|xmldb|static|packages)/.*$ /500/ [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^robots.txt$  /sbots.php?path=$1%{QUERY_STRING} [L]

RewriteRule ^config.ini$ / [L,R]

RewriteCond %{REQUEST_URI} !^styles

RewriteCond %{REQUEST_URI} !^css

RewriteCond %{REQUEST_URI} !.css

RewriteCond %{REQUEST_URI} !^js

RewriteCond %{REQUEST_URI} !.js

RewriteCond %{REQUEST_URI} !^images

RewriteCond %{REQUEST_URI} !^webstat

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*).xml$ index.php?xmlMode=force&path=$1&%{QUERY_STRING} [L]

RewriteRule ^(udata|upage|uobject|ufs|usel|ulang|utype|umess|uhttp):?(//)?(.*)$ releaseStreams.php?scheme=$1&path=$3?%{QUERY_STRING} [L]

RewriteCond %{REQUEST_URI} !^styles

RewriteCond %{REQUEST_URI} !^css

RewriteCond %{REQUEST_URI} !.css

RewriteCond %{REQUEST_URI} !^js

RewriteCond %{REQUEST_URI} !.js

RewriteCond %{REQUEST_URI} !^images

RewriteCond %{REQUEST_URI} !(.ico|.ICO)$

RewriteCond %{REQUEST_URI} !(.jpg|.JPG)$

RewriteCond %{REQUEST_URI} !(.jpeg|.JPEG)$

RewriteCond %{REQUEST_URI} !(.png|.PNG)$

RewriteCond %{REQUEST_URI} !(.gif|.GIF)$

RewriteCond %{REQUEST_URI} !(.css|.CSS)$

RewriteCond %{REQUEST_URI} !(.js|.JS)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ index.php?path=$1&%{QUERY_STRING} [L]

RewriteCond %{REQUEST_URI} (.ico|.ICO)$

RewriteCond %{REQUEST_URI} (.jpg|.JPG)$

RewriteCond %{REQUEST_URI} (.jpeg|.JPEG)$

RewriteCond %{REQUEST_URI} (.png|.PNG)$

RewriteCond %{REQUEST_URI} (.gif|.GIF)$

RewriteCond %{REQUEST_URI} (.css|.CSS)$

RewriteCond %{REQUEST_URI} (.js|.JS)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ [R=404]

<IfModule mod_mime.c>

       AddType application/x-java-applet .class

   AddType text/x-component .htc

</IfModule>
 

Важно: Начиная с версии 2.8.4, блок инструкций в файле «.htaccess», необходимых для корректной работы UMI.CMS, обрамляется строками UMI_CMS_HTACCESS_BEGIN и UMI_CMS_HTACCESS_END. Маркеры предназначены для дальнейшего автообновления данного файла. Рекомендуется удалить старые инструкции UMI.CMS, находящиеся выше этого блока. Обратите внимание, что ваши кастомные инструкции не следует вносить в этот блок, поскольку при обновлении системы он будет полностью заменён на новый.

Если в самом верху страницы будет написано PHP 5.3.1 и выше, значит UMI.CMS будет работать (при соблюдении остальных системных требований).
Если же будет написано PHP 4, то система работать не будет. В таком случае, вам следует обратиться в техническую поддержку вашего хостинг-провайдера с вопросом о включении или установки PHP5.

• 
  Вопрос задан

  более трёх лет назад

• 3153 просмотра

Пригласить эксперта

• 
  Показать ещё
  Загружается…
  

Переношу сайт с umi застрял на стадии тестирования жду довольно долго в чем ошибка? Повторял уже несколько раз

Ответы (6)

Можно ссылку на скриншот или на домен, посмотреть о каком тестировании идет речь хоть?

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

поменял версию PHP , помогло ! большое спасибо!

Похожие вопросы

UMI.CMS: ошибка 15000

Что это за ошибка такая и как ее исправить — кто знает?

Ваш баланс 10 ТК

1 ТК = 1 ₽

Неперехваченное исключение

Ошибка (coreException): Not found template «/home/visasrussia/site.ru/templates/demooldschool/xslt/layouts/default.xsl».

Помогите исправить пожалуйста! Даже когда захожу в админку, там эта ошибка..

Нет «дефолтного» файла «default.xsl» его нужно создать и назначить основным шаблоном в настройках модуля «Структура».

Файл тот есть там.. а в админку не как не попасть.. там точно такая же ошибка вылезает.

У меня такая ошибка была, решил путем восстановления «дефолтного» файла «default.xsl». Как правило «coreException» в «default.xsl» может возникать из-за «Undefined templater» — это значит, что CMS не понимает шаблон. Вы скорее всего убрали «дефолтный» шаблон или удалили всю информацию о нем (название, адрес файла и т.д.), так?

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

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

Нет, это не так. Лицензионная политика UMI.CMS не является прозрачной. Вашу проблему нужно рассматривать «под другим углом».

Если Вы переносили с локального хоста на рабочий хостинг-аккаунт, тогда причина ошибки (coreException): Not found template «/home/visasrussia/site.ru/templates/demooldschool/xslt/layouts/default.xsl» объяснима и логична, заключается она в относительном пути скрипта. Но не факт, ведь относительный путь, phpinfo, права на файлы и надстройки должны полностью соответствовать текущим параметрам и требованиям хостинг-аккаунта.

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

Так же возможно изменения кода в фаиле installer.php и всегда ворзращать успех якобы проверка прошла успешно но в дальнейшем этот способ вылетает в трубу или занимает очень много времени

От теории к практике. Для игнорирования ошибки необходимо найти файл testhost.php на вашем аккаунте, где пока присутствуют лишь файлы для установки CMS:

Это и есть файл, ответственный за проверку хоста на пригодность для установки UMI.CMS

Для того, чтобы игнорировать данную ошибку необходимо закомментировать или удалить тело функции checkSession

/**
 * Проверка работы сессии
 */
 function checkSession($mode = 'fopen') {
 /*if (!$this->domain) return;

file_put_contents(CURRENT_WORKING_DIR . '/umi_smt.php', '<?php 
 	@session_start(); 
 	$_SESSION["test"] = "test"; 
 	$sessionId = session_id();
 	@session_write_close(); 
 	unset($_SESSION["test"]); 
 	@session_start($sessionId);
 	echo($_SESSION["test"]);');

	if (!defined("PHP_FILES_ACCESS_MODE")) {
 	$mode = substr(decoct(fileperms(__FILE__)), -4, 4);
 	chmod(CURRENT_WORKING_DIR . '/umi_smt.php', octdec($mode));
 	} else {
 	chmod(CURRENT_WORKING_DIR . '/umi_smt.php', PHP_FILES_ACCESS_MODE);
 	}
	
	$checkUrl = 'http://' . $this->domain . '/umi_smt.php';
 	$result = '';
	
	if ($mode == 'fopen') {
 	$result = file_get_contents($checkUrl); 
 	} else {
 	$ch = curl_init();
 	curl_setopt($ch, CURLOPT_URL, $checkUrl);
 	curl_setopt($ch, CURLOPT_HEADER, 0);
 	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 	$result = curl_exec($ch);
 	}
	
	$this->assert($result == 'test', 13083);
	
	unlink(CURRENT_WORKING_DIR . '/umi_smt.php');*/
 	return;
 }

Как убрать UTF-8 BOM метку

Чтобы убрать BOM, например в Notepad++, нужно открыть в нём проблемный файл, кликнуть по пункту «Кодировки» в верхнем меню и выбрать «Преобразовать в UTF-8 (без BOM)». Далее сохраните файл и загрузите его на сервер (хостинг).

Сервер ограничен в вычислительных мощностях, поэтому есть ограничения по нагрузке для каждого аккаунта и есть лимиты через конфигурацию веб-сервера. Если серьезная нагрузка длится слишком долго — может «рухнуть» весь сервер, все аккаунты пользователей и все сайты — вот тут и возникает ошибика 503 (Service Temporarily Unavailable) говорящая о том, что веб-сервер временно не может обрабатывать больше запросов на данном сайте и необходимо подождать пока очередь текущих рабочих процессов уменьшиться и можно будет дальше обрабатывать запросы.
Мы рассмотрели, как устроен хостинг и теперь постараемся описать основные причины, при которых может расти очередь, и, по возможности, пути решений этой проблемы. Иногда это может быть очень сложной задачей и собственных знаний может не хватить, но тем не менее, рассмотрим варианты:

— Зависание скриптов при передаче больших статичных файлов через PHP.

Пример — отдача изображений миниатюр не напрямую по URL таких статичных файлов, а через php. Статичные файлы, к примеру изображения, лучше всего передавать напрямую, не используя скрипты. Почему? Скрипты работают определенное время, а не постоянно и при окончании времени работы скрипта прерывается передача файла, соответственно файл не будет передан полностью, а запрос оставит процесс веб-сервера работать ещё длительное время. Также, каждая передача файлов через PHP — это отдельный рабочий процесс веб-сервера apache (количество которых ограничено), а для передачи статичных файлов напрямую будет использоваться отдельный многопоточный процесс веб-сервера nginx, который может обрабатывать множество потоков, а значит не будет влияния передачи файла на загрузку и срабатывания лимита при отдаче статики.

— Удаленное соединение с другим сервером (сайтом и т.д.).

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

Также часто используют вставки отдельных функций, кодов и т.д. (include) и если эти функции располагаются в одном аккаунте — используйте только локальные пути, а не в виде вставки url-адреса (http://site.ru/file.php). Лучше вставить конструкцию, например, такого вида: include 'file.php';. Это не будет делать дополнительный внешний запрос на сервер и тем самым вы снизите нагрузку, уменьшите количество создаваемых процессов.

— Очень тяжелые или испорченные дополнения систем управления сайтами (при использовании CMS и прочих скриптов).

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

— Задания выполняющиеся долгое время.

Иногда в самих скриптах пишут задания на выполнение чего-либо по расписанию (например в тех же mambot’ах в joomla и wp-cron в wordpress). Если их можно перенести в планировщик (cron), то лучше это сделать через cron, так как такие задания выполняются вместе с запросами пользователей и тем самым замедляют загрузку сайта и увеличивают нагрузку, а в некоторых случаях сайт вовсе перестает загружаться если задание «тяжелое» и выполняется длительное время.

— Почтовые рассылки.

Рассылки писем могут влиять на загрузку сайта, тем не менее они часто бывают необходимы и их так же лучше оптимизировать. Скрипт запуска рассылки можно добавить в планировщик (cron), как и в случае с mambot’ами в joomla. Управление планировщиком находится в панели управления хостингом и доступно при соответствующем тарифе. Запускать такие скрипты лучше во время наименьшей нагрузки, например ночью, когда на сайте меньше всего посетителей.

— Медленные или не оптимизированные запросы sql к базе данных.

Пути решения в этом случае – использование кеширования, оптимизация запросов и индексация таблицы базы данных по столбцам (сортировка, упорядочивание). Также, если все это не помогает, стоит подумать о смене скрипта на более оптимизированный.

— Большое количество запросов к серверу.

Старайтесь избегать лишних запросов. Запросы могут исходить не только от посетителей ваших сайтов, но и, например, от индексирующих ботов с поисковиков, sape-подобные биржи и т.д, также увеличивается количество запросов при использовании большого количества url на файлы (изображения, js-скрипты, css-стили), которые загружаются через отдельные запросы (при включенном только apache вместо nginx+apache кеш статики). По возможности, объединяйте большое количество css, js файлов в один файл по типу.

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

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

Этот код ответа означает, что клиентский запрос nginx передал apache, а apache не смог в установленный лимит времени вернуть HTTP-ответ?, в рузультате сервер разрывает сетевое соединение по таймауту. Причиной может быть долгая работа процесса — сценария, запущенного скриптом веб-сайта.

Можно попробовать увеличить выделенное время для php, прописав в корне сайта в файл .htaccess код:

# время выполнения скрипта - сценария
php_value max_execution_time 60
# время загрузки данных 
php_value max_input_time 60

XML
1 <xsl:apply-templates select="document(concat('udata://data/getFilteredProduction/(',./page/@link,')'))/udata/items//item"

HTML5
1 2 3 <select name="manf" tabindex="0"><option value="">любой</option> <option value="1"></option> <option value="1"></option></select>

XML
1 <xsl:for-each select="document(concat('udata://data/filters/',$page-id))/udata//field">

XML
1 2 3 <field id="1" name="ma" title="свойство"> <item id="5" active=""/> </field>