Мишко

Хочу переделать функционал галереи дефолтной под себя.

remove_shortcode('gallery');
 add_shortcode('gallery', 'parse_gallery_shortcode'); 


function parse_gallery_shortcode($atts) {
            global $post;

    extract(shortcode_atts(array(
                'orderby' => 'menu_order ASC, ID ASC',
        'id' => $post->ID,
        'itemtag' => 'dl',
        'icontag' => 'dt',
        'captiontag' => 'dd',
        'columns' => 3,
        'size' => 'thumbnail',
        'link' => 'file'
    ), $atts));
 
    $args = array(
        'post_type' => 'attachment',
        'post_parent' => $id,
        'numberposts' => -1,
        'orderby' => $orderby
        ); 
    $images = get_posts($args);
        $imagcount = count($images);
 
        $i = 1;
        $imtitle = get_the_title();
    foreach ( $images as $image ) {    
    
...

Все параметрі, если они присутсвуют в шоркоде, работают, заменяя назначеній мной дефолтніе. Кроме параметров сортировки. Как я не страрался, срабатівает лишь ручная сортировка в окне управления загружеными файлами, а разные варианции order и orberby в шорткоде – игнор. А хотелось бы так…
Если есть порядок сортировки в шоркоде – берем его. если пользователь задал порядок сортировки в окне загрузки – берем его. Если ничего нет – берем параметры из кастомн-функции.

С появлением возможности создавать кастомные типы контента меня понесло )) Но похоже закончилось все печально. Теперь замечаю, что они создают большую нагрузку, генеря непомерное кол-во запросов, даже когда напрямую их никто не вызывает. Скажем, сайт з 8 кастомными типами записей. Но на страницах где они не запращиваются все равно получаем картину:

453 (!!!) запроса, больше 3 секунд выполнение запроса

тот же сайт, с отключеннымми кастомными типами записей

36 запросов, 0,4 секунды

Уж не думал что разработчики, делая что-то новое в функционале, будут делать такие промахи. Надеюсь что все-таки я где-то протупил и не выставил какой-то параметр. Вот, скажем в register_post_type есть параметр query_var:

Ставим false, чтобы убрать возможность запросов или устанавливаем название запроса для этого типа записей.
    По умолчанию: true - устанавливается аргумент $post_type

Не совсем понятно. С первого прочтения кажется, что если поставить false то запрос к этому типу записей нельзя будет сделать даже с помощью спец-запросов в кастом-шаблонах. Но, если подумать, а как иначе могут использоваться тогда этот тип записей, если с него нельзя ничего получить?

Возможно, кто-то уже разобрался лучше меня и знает как заставить движек "забыть" про кастомные типы записей пока ему про них не напомнят и не спросят? 🙂

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

а) current
б) style если таковой задан в самом пункте меню
в) кастомный id для списка субменю

?

Прикольно, при использовании фильра add_filter(‘the_content’, ”); код фунции фыглядит таким образом:

$content .= "<p>Строка, добавленная ниже поста</p>";
return $content;

Т.е. мы добавили одну строку текста после самого поста. Но если сделать вот так

echo "<p>Строка, добавленная ВЫШЕ поста</p>";
$content .= "<p>Строка, добавленная ниже поста</p>";
return $content;

То это тоже будет работать, и над текстом поста появится наша строка. Собственно, мне это и надо было сделать, но я не понимаю – как это работает? закрадываются сомнения, что так делать не совсем правильно и корректно. Ведь по идее, функция должна возвращать лишь то, что мы делаем с переменной $content. Или же данный фыльтр более продуман и учитывается весь код, помещенный в функцию? Извините, если мой вопрос кому-то покажется смешным 🙂

Собственно, сабж. Никак не могу нагуглить, может кто-то знает функции вордпресса, с помощью которых можно было бы обезопасить себя при записи данных, переданных с помощью Get и Post в базу данных.

Создал новый тип контента, после активации поставил flush_rewrite_rules(); и тут же полезло… Переш шапкой админки вылезла куча кода, как будто кто-то забыл поставить <?php перед началом кода. Закомментил flush_rewrite_rules(); – все стало ок, но на странице изменения пермалинков та же проблема, только уже в тебе страницы, хотя крякозябров уже нет и старица фунционирует, если прокручивать вниз )))

убрал весь добавленный код нового функционала, отключил все плаги, перезалил админку, проблема осталась….

Структура пермалинков – /post/%postname%

Что это может быть и как быть?

Каюсь, MySQL не очень знаю, но примеров тоже не могу найти…
Вобщем, не могу понять как в кастомном запросе выбрать записи опубликованные и подготовленные для будущего. ОR не срабатывает…

SELECT $wpdb->posts.* 
    FROM $wpdb->posts, $wpdb->postmeta
    WHERE $wpdb->posts.ID = $wpdb->postmeta.post_id 
    AND $wpdb->posts.post_type = 'event'
    AND $wpdb->posts.post_status = 'publish' OR $wpdb->posts.post_status = 'future'
    ORDER BY $wpdb->posts.post_date DESC

Собственно, вопрос в том, реально ли добавить какие-либо поля к описанию терма, чтобы кроме поля description получить возможность вносить информацию в другие поля?

Надыбал на форумах упоминания о интреснои параметре к query_posts – meta_compare. Но нигде в кодексах описания его нет (или поиск и контрал + Ф не находит).
Пробую вот так выводить только те записи у которых в поле price не указан ноль.

query_posts( $query_string . '&cat=1&meta_key=price&meta_compare=!=&meta_value=0' );

как горошох о стенку, все равно выводит проданные товары 🙂 🙁

Кто-то работал с данным параметром?

Оказывается, до сих никто не придумал (либо же не поделился для гугла кодом) решения, которое бы позволяло брать все посты сети вордпрес и выдавать самые свежие в хронологическом порядке. С кучи перебранных мною форумов нашлось только решение которое сначала создает массив обновленных блогов а потом прокручивает их в цикле, выводя по одной записи из каждого. Но при этом никак не получается хрнологический список постов всех сайтов сети. Ибо в одном блоге добавился один пост, в другом – пять. Решение только в том, чтобы связывать все таблицы с постами всех сайтов воедино и формировать вывод уже оттуда.

Для этого создал заготовку, которая как-бы рабоатет

$allposts = $wpdb->get_results("
(SELECT ID, post_date, post_content, post_title, post_excerpt, post_status, guid, post_type FROM wp_7_posts WHERE post_status = 'publish' AND post_type = 'post' ) 

UNION ALL

(SELECT ID, post_date, post_content, post_title, post_excerpt, post_status, guid, post_type FROM wp_1_posts WHERE post_status = 'publish' AND post_type = 'post' )

ORDER BY post_date DESC LIMIT 5
    ");

foreach ($allposts as $post) {
     setup_postdata($post);

(Кстати, тут интересно почему при запросе через звездочку * оно не работает)

Теперь бы надо бы не ручками подключать таблицу с постами каждого блога/сайта, а как-то автоматизировать.

Чтобы получить айди всех наявных сайтов в сети есть такой кусок

$query = "SELECT blog_id FROM $wpdb->blogs WHERE blog_id !='1'";

Но как теперь все эти запросы с юнионами прокрутить в цикле? Т.е. по сути надо в SQL-запрос втулить перебор массива. Как такое можно реализорвать? Гугл не помогает, тут без чудого опыта не обойтись…

Включил вот в конфиге define(‘WP_DEBUG’, true);

И как к этому относиться? Половина плагинов, даже самых популярных, несет в себе разые, по версии движка, баги и отключенные функции.

Забить или править ручками?

Есть какой то хак, хук или функция, которая позволяла бы при сохранении поста (а еще лучше при сохранении конкретного типа записи) запускать определенный скрипт (например тот, что дописывает данные из кастом-филдов в какой-нибудь файл на сервере),

Спасибо!

Был у меня сайт, на котором первоначально в насторйках адреса сайта везде были добавлены www. Т.е. вбывай ты адрес хоть с www, хоть без них, ссылка работала.

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

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

Боюсь, так и придется для подсайтов ставить отдельные движки, причем основной будет на домене с www, а поддомены – без… 🙁

Сабж. Погуглил, ничего действенного не нашел. Неужто никто пока не додумался?

Хочу сделать механизм петици, основанный на Сforms. Для этого в плагине есть практически все что нужно. Но есть одна проблема – непонятно как сделать механизм проверки автентичности емейла человека, заполнившего форму. Есть у кого-то идеи?

Буду так же благодарен просто за наводки в направлении общих принципов работы схем верификации емейлов. Спасибо!

Есть рубрики

напитки

• алкогольные
• безалкогольные
• слабоградусные

Как можно написать проверку if (in_category(‘напитки’) or in_category(‘алкогольные’) or in_category(‘безалькогольные’) in_category(‘слабоградусные’))

в виде "если в рубрике "напитки" или в любой из ее дочерних", чтобы не перечислять все дочерние, коих может быть сотня… ? Неужели еще не придумано?

http://www.site.ua/
и
http://site.ua/

В чем разница? Какие плюсы и минусы в каждом из случаенв?

А что, если настроить в options-general.php адрес вордпрес и адрес сайта по-разному (чот-то одно с www, а что-то нет)?

Давно интересует, cуществуют ли в Вордпрессе какие-то штатные возможности для кеширования или же может кто знает способы простой организации кеширования методами PHP? – Ну пугают меня все эти страшные и огромные плагины кеширования с кучей настроек, когда непонятно что ты там накрутил и как все на самом деле происходит… 🙁

На одном из сайтов сделал вывод постов по опереденным критериям через аякс. Ну, вы в курсе: скрипт передает через get определенные парметры другой странице, которая формирует запрос и возвращает результат на текущую страницу. И меня "принимающая сторона" выглядит приблизительно так:

$taxquery['strany'] = $_GET["teg"];
if (isset($_GET["pu"])) {
   $taxquery['npopositions'] = $_GET["pu"];
}
$taxquery['post_type'] = $_GET["pt"];
$taxquery['posts_per_page'] = 10;
$taxquery['paged'] = $paged;
$wp_query->query( $taxquery ); ?>
<?php while ($wp_query->have_posts()): $wp_query->the_post(); ?>

Но вот начитался про всякие иньекции и т.д. и вот теперь думаю – а насколько подобные решения безопасные? Может действительно надо начать городить кучу фильтров для проверки поступающих через get данных? Нет? В каких случаях это надо делать?

Первое что странно, это то что при использовании ссылок на категории в виде /?cat=id некотоые подхватываются и переводятся в ЧПУ, а другие так и остаются в таком виде.

А главная проблема в том что при пагинации в категориях уже при переходе на вторую страницу отдает 404.

В нете куча записей по поводу данной траблы, но только для структуры пермалинков типа /%category%/%postname%/ а у меня просто /%postname%/

Вордпрес 3.1.1.

Код самого вывода

<h2><a href="/?cat=6" title="Все записи рубрики">Видео</a></h2>
<?php 
//$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
//query_posts( 'posts_per_page=2&'.$query_string . "&paged=$paged" );

query_posts($query_string . '&posts_per_page=2'); 
?>
<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
    <div class="nws">
       бла-бла-бла
    </div>
<?php endwhile;?>
<?php get_template_part('navigation'); ?>
<?php else: endif;
wp_reset_query();
 ?>

.htacess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Cпасите кто может!!