:) В данном случае не о том переборе речь :)
Я имел ввиду
$my_custom_field = get_post_meta($post->ID, $mykey, false); foreach ( $my_custom_field as $key => $value ) echo $key . " => " . $value . "<br />";
Хотя, да я забыл, тебе же не все, а только несколько значений дано получить. Тогда наверное не стоит городить огород.
Да удобная, кто ж спорит. Я ж говорю - наверное лучший из аналогов. В 99% случаев он вполне..
Но вот есть там не всё (во всяком случае с полгода назад). Я сейчас не вспомню чего конкретно нет, но нет. И на оф форуме ВП не так давно тоже разбирали проблемку, оказалось именно из-за этого плага. То ли из-за дефолтных значений, которые нельзя изменить (нет их в настройках), то ли просто из-за нехватки этих настроек.
И опять же. быстрота работы. Этот функционал работает на фронтеэнде. А настройки не прописываются в functions.php, а хранятся в базе. Так что, как мне кацца, это доп нагрузка.
Да, был какой-то аналогичный плаг, который в админке генерил код, который по идее должен быть в functions.php. Я первое время его юзал для того, что бы не писать вручную :) Настроил - скопировал - вставил.
Сейчас, если доходит дело до этого - мне проще скопировать из ранних проектов (или даже нагугленого и мануалов ;) ) и просто изменить что надо :)
Зачем? Нормальных нет что ли?
+1
Так как ты написал - наверное ещё больше, чем если сделать правильно - перебором массива (через foreach например) ;).
У тебя ж там не 30-40шт вычислений\выводов, а 30-40шт Х 200-300CPT = 6000-12000.
Хотя повторюсь - я не уверен. Как-то не вникал в такие нюансы.
Ты же, как я погляжу, с английским дружишь (в отличии от меня ;) ), думаю сможешь найти эту инфу и поделиться с народом :)
Если ты про плаг, то, да плаг хорош, но не всемогущ. Он много чего пропускает. А русский там такой, что лучше бы он был английским :)
Хотя это, наверное, лучший, из всех подобных. Если надо быстро развернуть - проверить. На реальных сайтах всё же лучше чуток заморочится и вручную прописать.
Признаться, заставил задуматься-засомневаться :).. Могу ошибаться, но по-моему не прав.
Читай переписку с поста 868 по 871
АПД. И вот ещё
Вот основная нагрузка. Ты же хочешь вывести 200-300 постов (СРТ) со "некоторыми" CPF. Т.е. это тысячи запросов.
А при сохранении это такие мелочи :)
кеширование, кеширование и ещё раз кеширование.
Ну а сам способ реализации задачи "общих данных" хотя и несёт некоторую избыточность, но почему бы и нет.
Почти так же :)
Почти - потому что теперь видно, что в принципе можно и без них - просто выводя CTF, но если на странице будет 300 позиций моделей двигателя, то это минимум 3х300+300=1200 запросов. Некисленько так :)
В любом случае без кеширования тут не обойтись.
Под параллельными сущностями я имел ввиду существование 2х независимых CPT. И одна из решаемых задач как раз создать зависимость.
Bitman, то ли я не выспался, то ли такой тупой. А что дадут доп. столбцы в таблице (списке) постов? Это же никак на вывод и хранение не влияет. Единственное что - да, массово править может быть удобнее. (можно и сортировочку прикрутить для большего удобства).
Но мне кажется это всё полумеры. Надо бы структуру чуток поменять. ИМХО.
Кстати, парни, свете топика думаю будет полезен и этот пост Тимура.
Было бы интересно на парочку примеров посмотреть.
Ну зачем так сразу? Тут далеко не все продвигатели. А тем более услуг, требующих таких анализов.
На это идут налоги. Читай - оплачено.
Как же вы (не догоняющие причин "нововведений") утомили своими фантазиями, переводом стрелок и увиливанием от вопросов.
Им говоришь - "нафига мне ваша шляпа, если мне на жопу трусы надо одеть". А они - "Ты дурак - шляпа-то в полосочку и со стразами. А трусы тебе зачем, ты что, разве не лысый? А раз так надо трусы - значит ты обосрался".
Такой вот диалог..
Утомили..
Судя по логам апач убивается (killed process ..httpd).
А выше не понятно что сказал mysqld. Видимо он тоже крашиться.
Промониторь запросы к БД на дефолтной теме и на своей (апд: на разных страницах) - возможно именно тут затык.
Да, думаю тебе нужно подумать над кешированим. А если оно есть - видимо работает не правильно.
