Александр Епихин

Нарисовать на js ¯\_(ツ)_/¯

Без ограничений высоты самый простой способ - сделать миниатюры на абсолюте.

Еще можно попробовать гриды, делал что-то похожее.

Typescript работает только с кодом, он не знает что-там в Vue шаблоне, увы. Потому в $refs у него лежат голые компоненты Vue или Element'ы.
Я лично вручную указываю через объединение интерфейсов - внизу добавляю перекрывающий:

@Component
export default class Login extends Vue { 
  // ...
}
export default interface Login {
  $refs: {
     loginForm: any; // на самом деле не any, а интерфейс компонента, поддерживающий нужные методы
  }
}

localstorage, как советовали выше не нужен. Просто напишите функцию которая будет возвращать разницу между нужной датой и текущим временем - это и будет ваше время до события

const parse = float => parseFloat(float.replace(/,/g, ''));

const number = parse(objectFloat.param1) + parse(objectFloat.param2); // 2353.66
console.log(number.toLocaleString('en-US')); // 2,353.66

Во-первых, запомнить раз и навсегда 2 простые истины:

1. Продакшн база данных должна быть только на продакшне и больше нигде. Эти данные нельзя as-is использовать локально - в том числе по причинам юридическим и privacy (привет логины-пароли клиентов, их персональные данные и тд). Грубо говоря, за это можно и пострадать.
2. Локальная / development база данных работает только с тестовыми / посевными данными.

Между ними никакой синхронизации не должно быть, никогда. От слова совсем. И WordPress тут вообще ни при чем - эта проблема существует и в Laravel, Symfony, Ruby on Rails и тд. Просто там с нуля сразу учат решать ее правильно. Впрочем, продакшн-данные можно (и даже нужно) использовать как пример для генерации локальных данных. Например, в production БД можно посмотреть какие реальные first name и last name используются юзерами, чтобы улучшить валидацию и/или отображение.

Как с этим жить?

1. Для переноса изменений структуры базы данных используются миграции. В WordPress для этого есть dbDelta().
2. Для переноса посевных данных используются посевы (seeds). Например, если нужно залить список терминов в глоссарий (custom taxonomy), заполнить список отделов компании и тд - все это сеется.
3. Все остальное (настройки мышкой в админке, добавление контента и тд) делается руками. Локально вы вообще не должны даже думать о том, чтобы создавать какие-то страницы 1 в 1 с рассчетом на то, что потом будете их как-то "синхронизировать" на боевой сервер. Это в корне неправильный mindset, который и привел вас к этой проблеме. На локальной версии вы все тестируете с тестовыми данными. Даже если вы не используете lorem ipsum, а вставляете реальный текст предоставленный клиентом - это все равно тестовые данные.
4. Чтобы сайт не ломался в процессе выкатывания изменений (когда код залили, а контент еще делается) код нужно писать с учетом этой логики (опять же - дело в mindset). Например, есть такое понятие как feature flags, есть function_exists(), есть isset(). Ваш код должен работать корректно всегда - например, если данные для какого-то блока не заполнены, то блок не выводится вообще.

// Проверяет подходит ли элемент на который кликнули по селектору 

if (e.target.matches('.menu, .menu *')) { 
  // Если кликнули в меню — не делаем ничего
  return
}

// Клик куда-либо за пределами меню
menu.classList.remove('menu_active');
content.classList.remove('content_active');
burger.classList.remove('active');

https://getcomposer.org/doc/04-schema.md#extra

Arbitrary extra data for consumption by scripts.
This can be virtually anything.
Optional.

Простым языком - это секция, в которой можно устанавливать свои кастомные параметры, которые будут использоваться вашими скриптами или надстройками для Composer. Например, есть плагин composer/installers, позволяющий устанавливать пакеты не в vendor, а по нужным путям для разных платформ/CMS. Он использует секцию extra для конфигурации этих путей. Например, для WordPress у меня это выглядит вот так:

{
  "extra": {
    "wordpress-install-dir": "core",
    "installer-paths": {
      "app/{$name}": ["type:wordpress-dropin"],
      "app/mu-plugins/{$name}": ["type:wordpress-muplugin"],
      "app/plugins/{$name}/": ["type:wordpress-plugin"],
      "app/themes/{$name}/": ["type:wordpress-theme"]
    }
  }
}

Object.entries(obj).map(([k, v]) => ({ [k]: v }))

Базу данных можно выбрать любую. Она не играет роли в realtime приложениях. Позвольте вам немного объяснить. Для передачи данных между клиентом и сервером в браузере существует всего два протокола. HTTP и Websocket. Firebase не магия и также использует их. Если браузером не поддерживается Websocket, то firebase откатывается на HTTP. Используя общераспространенный подход к разработке на PHP у вас не получится использовать websocket протокол поскольку типичные PHP приложения не живут дольше 1 запроса. Соответственно да, в таком варианте остается только ajax. Но точно также работает и firebase если в браузере нет поддержки websocket, так работает facebook, telegram и много всего остального. Они используют long-polling. Клиент отправляет запрос к скрипту на сервер, скрипт в цикле опрашивает хранилище mysql или более продвинутый вариант mysql+redis (чтобы не грузить запросами mysql) и пока данных не будет, цикл так и продолжит крутиться, для клиента это просто выглядит как повисший запрос к серверу. Как только данные появляются, они отправляются на клиент, соединение разрывается, а клиент сразу же отправляет новый запрос.

Есть развитие этой идеи. Называется HTTP Streaming. Отличие от long-polling в том, что после отправки данных клиенту соединение не разрывается, а сервер продолжает отправлять последующие данные по этому же соединению. Соединение разрывается по таймауту. Минус в том, что прокси-сервера могут кешировать небольшие пакеты данных и данные нужно раздувать например пробелами, чтобы пакет данных достигал минимального размера и был способен пробить кеш прокси-сервера. Плюс в том, что если у вас данные для клиента появляются скажем с переодичностью раз в секунду, то не будет происходить постоянного открытия-закрытия соединения как при long-polling.

Есть вариант, когда можно реализовать небольшую прослойку на socket.io. Ваше PHP приложение пишет данные для клиента например в redis. Приложение на socket.io подписывается на redis. Когда PHP что-то отправляет в redis, то socket.io мгновенно об этом узнает и рассылает это событие по websocket протоколу всем подключенным клиентам. Минусы. Раздуваете стек. Нет консистентности данных между записью в основное хранилище (mysql/postgre/mongo/etc) и redis. Соответственно может возникнуть ситуация, когда данные записали, но в redis событие не ушло. Поменяете местами, будет наоборот, событие есть, данных в базе нет.

Вариантов в целом очень много. Всё это называется Comet. Вам проще всего реализовать long-polling.

А реал-тайм база, которая умела пушить данные клиенту по tcp протоколу (но не в браузер) была и называлась она rethinkdb.com. Ныне не развивается. IP в России заблокирован. На сайт можно сходить по VPN.

Зачем Вам бутстраповские колонки для этого?
Это обычная таблица
https://jsfiddle.net/aynf8d05/

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

Всё это должно быть в игровой форме и максимально быть интересным и простым для понимания.

Например, на прогулке можно спросить:
Как отмерить ровно 2м веревки, если есть длинная верёвка неизвестной длины и рядом столб, диаметром 50 см?

И подобные.

Как только он научится правильно принимать простые логические решения, он - уже программист!

Останется ему (уже без Вашей помощи!) выучить любой язык, чтобы стать кодером и воплотить логику своих мыслей в алгоритм в виде кода.
А 3D, C, OSI или еще что - это уже вопрос десятый...

Один общий блок с картинкой,
внутри несколько блоков с белыми рамками без фона.
Внутренние блоки флексами.

Нашел ответ. НЕ знаю почему но #map не хотел никак работать а вот #mapd заработал