nezzard

Лично мне понравились две вещи - разделение вёрстки и логики и повторное использование кода. Есть у меня в боевом проекте два компонента из которых один пришлось разбивать на три, а второй просто огромный - и развесистый template и просто бесконечная портянка script. Дождусь стабильного релиза vue3 и буду переделывать на composition api.
Еще один плюс, который я для себя нашел - нормальная отладка. Почему то у меня отладчик в devtools имеет смещение на одну строку в коде, который находится в .vue и совершенно нормально работает с чистыми .js файлами. И console.log тоже врет на 1 строку в первом случае и точно выводит номер строки во втором.
Ну и рекомендую к просмотру https://youtu.be/v6AVfIupNB8 и https://youtu.be/Ix8wcwrnPns

AI действует на сервере. И там и живет. Представляется таким же клиентом по сути.

Надо регуляркой проверять, типа new RegExp('^'+pass2).test(pass1)
И лучше не на keyup обработчик ставить, а на input (если нужна поддержка старых ослов, то ещё и на propertychange - было у них такое событие)

var buttonLocked = false;
$('button_selector').on('click', function(e) {
  e.preventDefault();
  if(!buttonLocked) {
     buttonLocked = true;
     $.ajax(...)
       .always(function(data) { buttonLocked = false; });
  }
})

Внимательно читайте документацию и best practices в блогах опытных разработчиков. На русском языке действительно качественной информации по WordPress очень мало. Читайте хотя бы Константина Ковшенина (блог на английском, блог на русском).

1. Никогда не используйте query_posts. Это неэффективно - данная функция заменяет основной запрос (Main Query), но выполняется ПОСЛЕ него. То есть, выполняет запрос к БД повторно, уже с новыми аргументами. Кроме того, практически гарантированно вылезут проблемы с постраничной навигацией. И не забывайте, что все дополнительные данные (виджеты с категориями, последними постами и комментами и т.д.) будут продолжать пытаться использовать данные из основного запроса, а данная функция глобальные переменные заменит, большая часть template tags будет выдавать совершенно неожиданные вещи. Бардак обеспечен. При использовании этой функции нужно не забывать в нужных местах вставлять wp_reset_query(), с чем точно запутаетесь. Данную функцию можно использовать только в одном случае - вызывать ДО основного loop, чтобы изменить параметры запроса. В этом случае WordPress проигнорирует те параметры, которые получит в запросе (GET / ваш урл), и будет использовать те, которые ему передать через query_posts. Но для этих задач есть более правильные решения.

2. Функция get_posts() предназначена для получения небольших, конкретных списков постов мимо основного Loop. Когда не нужна постраничная навигация и все дополнительное добро. Например, под статьей вывести список 5 последних статей из этого раздела. Или в боковой колонке вывести 10 статей, помеченных тем же тегом, что основная статья.

3. Если КРОМЕ основного запроса нужно сделать еще один, используйте новый loop:

$myquery = new WP_Query( $args );
if( $myquery->have_posts() ) :
    while( $myquery->have_posts() ) : $myquery->the_post();
    ...
    endwhile;
endif;

Например, есть раздел "События", и этот раздел - не обычные posts, а custom post type 'event'. И нам в ленте надо вывести не в обычном виде, а 2 блока - первый это ближайшие события (по дате от сегодня и в будущее), второй - прошедшие события (по дате от сегодня и в прошлое). Первый блок выводим модифицированным основным запросом (см. дальше про модификацию основного запроса), второй - нашим новым лупом.

3. Если нужно модифицировать основной запрос, и все что с ним связано (глобальные переменные и т.д.), единственно правильный способ - через хук pre_get_posts. Использовать надо в файле functions.php

add_action( 'pre_get_posts', 'my_function' );
function my_function( $query ) {
    // здесь можно (и нужно) использовать conditional проверки 
    // и модифицировать запросы для разных страниц и исловий, 
    // все в одной фукнции.
    if( $query->is_archive() && $query->is_main_query() ) :
        $query->set(
            'tag_id'                  => '1,10,15,2,30,31,32,35,89,55,120,140,150,4',
	    'author'                 => '1,2,3,50,150,140,35',
	    'posts_per_page'   => '10',
	    'orderby'                => 'date',
        );
    endif;
}

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

Я тоже за обобщение рейтинговых объектов.
То есть, допустим у вас есть Article и Comment. Введём объект RatingEntity c результирующим рейтингом и добавим связь с ним 1-к-1 для Article и Comment ratingEntityId. Таким образом таблицы будут выглядеть так:

rating_entities
------------
id | rating_sum

articles
------------
id | rating_entity_id | ...

comments
------------
id | rating_entity_id | ...

Далее делаем Rating такого вида:

ratings
------------
id | rating_entity_id | user_id | value

где будет составной ключ (rating_entity_id + user_id), а value иметь значения +/- 1.

Что касается производительности, то проблемы не вижу. Дело в том, что при голосовании очевидно, что нужно показать текущий рейтинг +/- 1, что можно сделать средствами frontend. То есть можно послать запрос на сервер и не ждать ответа.
Обновлять результирующий рейтинг можно через триггер в БД.

Судя по коду, не нужно.
Последняя строчка метода, который вызывается из insert:

return $this->query( $this->prepare( $sql, $data ) );

Мы пожу систему делаем и работаем в ней. В итоге пришли к системе похожей на вконтакте и скайп.
Каждый новый чат это пост.
Но сообщения внутри чата это комменты.
Таким образом можно определять участников чата. Можно тет а тет писать, а можно подключть товарищей и дать чату заголовок.
Пока что лучше схемы не смогли придумать.

Очень просто → iperf. Настроек там довольно приличное количество, думаю даже для самого требовательного пользователя хватит ;-)

Делается так:

1. На сервере: iperf -s
2. На клиенте: iperf -c [server_ip]

Вывод:

root@server:/home/server# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local [server_ip] port 5001 connected with [ip] port 49262
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.5 sec  57.9 MBytes  46.1 Mbits/sec

root@server:/home/server# iperf -c [server_ip]
------------------------------------------------------------
Client connecting to [server_ip], TCP port 5001
TCP window size: 22.7 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 49262 connected with [server_ip] port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  57.9 MBytes  47.7 Mbits/sec

<?session_start();?>
<form action="" method="post">
	<input type="submit" name="send">
</form>
<?
if(isset($_POST['send']))
{
    // Если нет ошибок
    if(true)
    {
        $_SESSION['flash'] = 'Запись добавлена';
        // обновление страницы
        header("Location: ".$_SERVER['REQUEST_URI']);
    }
}else{
    // Обычный GET запрос
    if(!empty($_SESSION['flash']))
    {
        print $_SESSION['flash'];
        unset($_SESSION['flash']);
    }
}

Вообще, попробовать сделать редирект на тот же урл, если я правильно понял вашу проблему.
Например:
header('Location: /test.php');

незнаю может быть вам подойдет.. http://yupe.ru/