TiA

Staff92, эта задача решается достаточно просто: Get The First Image From a Post

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

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

Если вам требуется вытаскивать именно прикрепленные к записи изображения, которых нет в тексте, то можно использовать функцию get_attached_media

Да. На хостинге в настройках PHP отключен вывод ошибок.

Вероятно, возникает какая-то ошибка в коде, которая не выводится на экран из-за отключенного в настройках PHP вывода.

Попробуйте выполнить эти рекомендации: https://wordpress.org/support/topic/register_http_request_failed-2?replies=2#post-3746933

Как вариант можете рассмотреть эту библиотеку http://joliclic.free.fr/php/javascript-packer/en/

maximka77, нужно немного поправить файл \catalog\controller\module\latest.php. Там нужно заменить

$data = array(
	'sort'  => 'p.date_added',
	'order' => 'DESC',
	'start' => 0,
	'limit' => $setting['limit']
);

на

$data = array(
	'sort'  => 'p.date_added',
	'order' => 'DESC',
	'start' => 0,
	'filter_category_exclude' => 'ID-категории, которую нужно исключить'
	'limit' => $setting['limit']
);

В файле \catalog\model\catalog\product.php нужно для метода getProducts внести такие изменения:

if (!empty($data['filter_category_id'])) {

заменить на

if (!empty($data['filter_category_id']) or !empty($data['filter_category_exclude'])) {

И перед строкой

if (!empty($data['filter_manufacturer_id'])) {

добавить

if (!empty($data['filter_category_exclude'])) {
	$sql .= " AND p2c.category_id != '" . (int)$data['filter_category_exclude'] . "'";
}

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

По поводу самого кода.

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

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

Возьмем, например, получение ID продукта:

$data = JRequest::get('get');
$product_id = $data['prod_id'];

Казалось бы, все тут хорошо, но нет. Здесь сразу две проблемы:

1. Если свойства 'prod_id' нет, то мы получим критическую ошибку, которая может поломать весь скрипт. Это же касается и $task = $data['task'];

2. Тип значения 'prod_it' вообще никак не проверяется. Это потенциальная дыра в безопасности, которая позволяет произвести SQL-инъекцию. Да, при вызове метода JRequest::get все свойства проходят очистку от тегов, но все равно остается вероятность, что вместо нужной переменной будет передано что-то не то.

Решить эти проблемы достаточно просто:

$data = JRequest::get('get');

if (!empty($data['prod_id'])) {
    $product_id = intval($data['prod_id']);
}

Можно пойти еще дальше и сделать это с использованием встроенного функционала JInput:

$jinput = JFactory::getApplication()->input;
$product_id = $jinput->get('prod_id', 0, 'int');

Еще одна проблема - это написание SQL-запросов как есть. В Joomla есть полноценный инструментарий по работе с базой данных. Он описан в документации. Примеры использования можно найти в моделях. Выглядит это примерно так:

// Initialize variables.
$db     = $this->getDbo();
$query = $db->getQuery(true);

// Create the base select statement.
$query->select('*')->from($db->quoteName('#__content_rating'))->where($db->quoteName('content_id') . ' = ' . (int) $pk);

// Set the query and load the result.
$db->setQuery($query);

// Check for a database error.
try
{
	$rating = $db->loadObject();
}
catch (RuntimeException $e)
{
	JError::raiseWarning(500, $e->getMessage());

	return false;
}

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

Проблема тут в том, что система перевода строк в WP сделана не очень оптимально. Грубо говоря, если в админке выбран язык отличный от английского, то каждый раз при загрузке страницы обрабатывается кучка MO-файлов. Это достаточно затратная в плане вычислительных ресурсов операция. Запускается она в самом начале сразу после события setup_theme.

Для ускорения этого всего счастья можно кешировать весь массив с нужными переводами где-то в APCu или Memcached. В крайнем случае можно использовать Transients API. Это в принципе реализуемо, но нужно немного повозиться, чтобы не лезть грязными руками в код движка.