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. Это в принципе реализуемо, но нужно немного повозиться, чтобы не лезть грязными руками в код движка.
