Проблема с WP

У ТСа изначальная "проблема" в выводе двух подряд идущих картинок. Первая нужна, а вторая нет. А вот потом оказалось, что ещё и ДОМ парситься. (на это я и отреагировал)

И это как бэ не есть правильно. Но если не хочется писать в базу (в ПП или как изображение записи), то вывести в анонс только первую можно, используя фильтры the_cоntent или же в ту же function_to_get_first_image() записал первую картинку из поста, взяв её из базы (да, простой регуляркой). Хотя я бы лучше прописал тумбы и выводил уже их. Есть даже готовые плагины, которые и внешние подхватят и первую картинку пропишут.

Я понимаю когда фильтры и сортировки напр таблиц так делаются. Или нечто, зависимое от юзер-агента и тп. Но в данном случае это операция на прямой кишке через гланды

Я помогал ТСу в решении его проблемы. Изначально, код функции выглядел так:

function get_post_image() {

    global $post, $posts;

    $first_img = '';

    ob_start();

    ob_end_clean();

    $output = preg_match_all('/<img.+src=[\'"]([^\'"]+)[\'"].*>/i', $post->post_content, $matches);

    $first_img = $matches [1] [0];

        //Если на странице нет картинок, то ставим картинку по-умолчанию

    if(empty($first_img)){

    $img_dir = get_bloginfo('template_directory');

    $first_img = $img_dir . '/images/post-default.jpg';

    }

    return $first_img;

}

Прилагался пример контента, на котором эта функция возвращала не первую, а вторую картинку. Ещё было уточнение, что контент "грязный" потому что собирался парсером.

Чтоб не париться с регуляркой, в которой будут предусмотрены все возможные варианты(одинарные, двойные ковычки в src="", атрибуты до и после...) взял вариант с DOM.

Да, вариант не лучший, зато ТС получил быстрый результат и бесплатно.

Специалист по ВП никогда бы ТАК не решал задачу.

А в чём проблема? На производительность это не оказывает значительного влияния. Специально даже тесты проводил, сравнивал, сколько времени потребуется регулярке, а сколько DOM.

Отсюда видно, что регулярка значитально быстрее найдёт url первой картинки в контенте. Но при 10-20 вызовах(примерно столько бывает записей на странице рубрики) DOM справляется за тысячные доли секунды. Да, выполняется ненужная работа, строится DOM дерево из контента в 2,5к символов(примерно столько было в примере). На современных серверах эта операция занимает очень мало времени.

Вариант с DOM дал два существенных преимущества клиенту: быстрое решение задачи и универсальность(не нужно думать, какие же кавычки использовались в контенте и тп). И всё это бесплатно.

Не согласны? Доведите обратное.

Нет. Т.е. да, не согласен.

Довести куда?;)

А доказать.. смысл? Хотя ты вот уже сам доказал:

Это как построить фундамент из... доски напр. Да, дом какое-то время простоит, но вот изменить конструкцию или достроить уже будет проблемой.

Специалист же знает, что фундамент - это цемент, а не доска.

Цена этой ненужной работы = тысячные доли секунды. Зато решение по умолчанию универсально и получено быстро. Для клиента плюсов намного больше, чем минусов.

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

Иногда нужно выполнять лишнюю работу чтоб получить достойный результат. Самый простой пример, это двигатель внутреннего сгорания автомобиля. Из четырёх тактов полезное действие происходит только на одном. Выход есть: автомобиль с электродвигателем. У электродвигателя КПД выше, чем у ДВС. Но и стоить это будет дороже.

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

А я специалистом называю того, кто лечит язву, а не замазывает её зелёнкой.

А медвежьи услуги оказывает плохой специалист. Может быть он и грамотный, но плохой, тк делает временку, через Ж. И плохо, если не понимает этого. Хотя.. ещё хуже, если понимает и всё равно делает.

Производительность в данном случае - сиюминутный показатель. Пойдёт трафик, переедет на др хост, добавит виджетов/рекаламы и всё..

Язва вылечена. Зелёнкой не замазана, тесты тому показатель. Данное решение нельзя назвать через Ж. т.к. оно вполне рабочее и не ухудшает работу сайта существенно. Производительность в данном случае константа, которая на каждом хостинге будет своя, но разброс будет не большой. А то что можно виджетов добавить, это уже не ко мне вопрос - к моему решению он никакого отношения не умеет.

Ваши доводы не убедительны. Я решаю проблемы, помогаю людям, а не обсуждаю чужие решения.