Camaro67

Код программы или игры, используемые в ней изображения, звуки, сюжет, сеттинг, игровая система (например, Dungeon&Dragons) могут быть защищены копирайтом. Название может быть защищено торговой маркой. В остальном самостоятельно сделать аналог вполне законно. На идеи и алгоритмы в России авторское право не распространяется.

Как избежать претензий правообладателя на фото, если фото загружает любой пользователь сайта?

Никак. Правообладатели имеют право предъявлять претензии.

Сейчас я получаю запрос по почте о нарушении авторских прав на эти фото и выкатывается значительная сумма.

Вы тоже можете кому-нибудь выкатить по почте запрос на пару миллионов. Глядишь и заплатят. Не заплатят, так и фиг с ними, благо отправка e-mail'ов бесплатная.

К письму приложены сканы протокола осмотра доказательств заверенные нотариусом.

Круто. Кто проводил осмотр доказательств? Следак? В рамках какого дела? При чем тут нотариус?

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

Если вы согласитесь значит лох. Если нет - не лох. Вот и все.

update
Поймите простую вещь - вы не знаете достоверно кто написал письмо, и является ли он правообладателем.
Если вы заплатите деньги - кому вы их заплатите, и за что? А через месяц к вам придет реальный правообладатель и потребует с вас денег в суде, и ему будет до лампочки что вы платили каким-то левым дядям.
В вашем случае даже обращаться к юристу нет небходимости в данной ситуации - достаточно просто попросить того кто вам написал представиться, предоставить доказательства того, что он является правообладателем, и четко пояснить суть претензий к вам.
Вот когда он это сделает - можно будет и у юриста проконсультироваться, обсудить адекватность требований, и поторговаться насчет суммы компенсации.
А без этого - пустая трата времени и денег.

Допустим это реальный правообладатель и он подаст в суд -

И еще момент чисто из практики - реальный адекватный правообладатель как правило вежливо просит вас удалить авторский контент с сайта, а в случае если вы не выполните просьбу предупреждает, что будет защищать свои права в порядке искового производства. Но уж никак не будет требовать срочно платить бабло.
И если в тексте обращения есть требования денег, и слова про нотариально заверенные копии сайта это на 99.9% тупой развод.

При чём тут какая-то связка с php? Как php вообще относится к вёрстке? Если вы там адаптивности боитесь, то, лично моё мнение, вам ещё нужно подтянуть знания и вы себя в оценке переоценили))

Что насчёт самого макета, то я бы сказал, слишком лёгкий. Чё тут делать то? Карту вставить? Подвигать стрелочки при наведении через css? Сделать кнопку с раскрытием меню?

P.S. Я никак не хочу обидеть или оскорбить вас, но я не понимаю, сути вашего вопроса. У вас навыки 70% х 30%, а вы вместо того, что бы начать верстать, пришли сюда с глупым вопросом, а не слишком ли сложно!

Потому что такие вещи нужно делать через списки, ul li.

Пример для размышления:
HTML:

<div class="ui container">
<div class="ui three column grid">
  <div class="column">Логотип</div>
  <div class="column">
    <button class="ui button">Меню</button>
    <div class="ui flowing popup">
      <ul class="ui secondary menu">
        <li><a class="item active" data-tab="1">Категория #1</a></li>
        <li><a class="item" data-tab="2">Категория #2</a></li>
        <li><a class="item" data-tab="3">Категория #3</a></li>
      </ul>
      <div class="ui tab active" data-tab="1">Вкладка категории #1</div>
      <div class="ui tab" data-tab="2">Вкладка категории #2</div>
      <div class="ui tab" data-tab="3">Вкладка категории #3</div>
    </div>
  </div>
  <div class="column">Вход/Регистрация</div>
</div>
</div>

CSS:

li {
list-type: none;
}

Stacks
Blade allows you to push to named stacks which can be rendered somewhere else in another view or layout. This can be particularly useful for specifying any JavaScript libraries required by your child views:

@push('scripts')
    <script src="/example.js"></script>
@endpush

You may push to a stack as many times as needed. To render the complete stack contents, pass the name of the stack to the @stack directive:

<head>
    <!-- Head Contents -->

    @stack('scripts')
</head>

https://laravel.com/docs/5.7/blade#stacks

Упрощаю вопрос:
Я запланировал сделать это за две недели, но ошибся в оценке. Что делать?
Ответ на мой взгляд очевиден:
Извиниться, признать ошибку, сделать выводы. Все остальное (типа привлечение доп ресурсов, введение ночных смен и т.п.) это попытка прикрыть свою ошибку как менеджера за счет компании.

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

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде ( сортировка, текущая страница в блоге, строка поиска и т.п. ).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта ( логины, пароли, номера кредиток, сообщения и т.п. ).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

держите

UPD. Или, с использованием вашей демки.

Я просто пишу обёртки над jquery-плагинами.
Пример из официальной документации: https://vuejs.org/v2/examples/select2.html

Да, хорошо. Сводит издержки почти к нулю при переходе на https в будущем.

Это описано 20 лет назад, в июне 1995-го года в RFC 1808 (раздел 4), так что практически все браузеры должны поддерживать эту фичу.

Да, это хорошо, это древняя фича, браузер выбирает протокол такой же как у странице с которой переходят по ссылке.