Andrews32

А здесь смотрели? - события fullscreenenter, fullscreenexit.

UPD. Вынесено из комментариев:

что-то не получается с ними работать

Обработчики надо привязывать не к самой карте, а к элементу управления, отвечающему за переключение фулскрин режима:

const fs = map.controls.get('fullscreenControl');
fs.events.add('fullscreenenter', () => console.log('ON'));
fs.events.add('fullscreenexit', () => console.log('OFF'));

Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.

создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)

Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель develop в распакованной (checkout) в рабочий каталог ветке.

Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?

Моё мнение — нужно. Ведь ваша задача состоит не в создании сферических файлов в вакууме, а в изменении файлов проекта. Причём изменений относительно уже устаревшего состояния. Желательно чтобы ваша работа опиралась на актуальный проект, а не на старую версию.

Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?

Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (merge) с основной веткой (develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.

Способов собственно два:

1) Мы забираем новое состояние develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную develop, обновлять её (pull) а затем возвращаться к себе чтобы сделать git merge develop. Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте git merge origin/develop. Указатель origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (fetch). В принципе эти два шага эквивалентны одной команде git pull origin develop — внутри делается всё то же самое.

2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально git fetch, затем собственно пересадим ветку на актуальное состояние git rebase develop. Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через git push --force. Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.

Если вы не коммитите напрямую в master и в develop, то держать их у себя локально (делать checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются origin/master или origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.

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

Возвращаем копию объекта, затем присваиваем эту копию новой переменной:

let user = {
   name: "David",
   age: 25,
}

function objectClone(object) {
   let newObject = {};

   for (let key in object) {
      newObject[key] = object[key];
   }

   return newObject;
}

let user2 = objectClone(user);

console.log(user2.name); // выводит "David"

Ответ — пресеты. Создаёте, сохраняете (как видно, объекты практически аналогичны и их нужно просто клонировать, меняя один параметр). А дальше — что захотите. Пресетов может быть сколько угодно с любыми именами.

Update: По молчаливой просьбе собеседника добавил сторонние элементы

var points = [
		[55.831903,37.411961],
		[55.763338,37.565466],
		[55.763338,37.565466],
		[55.744522,37.616378],
		[55.780898,37.642889]
	],
	markers = {};

ymaps.ready(function () {
	ymaps.option.presetStorage.add('custom#default', {
		iconLayout: 'default#image',
		iconImageHref: 'marker.png',
		iconImageSize: [30, 40],
		iconImageOffset: [-15, -40],
		iconImageClipRect: [
			[0, 30],
			[30, 70]
		],
		hideIconOnBalloonOpen: false
	});
	ymaps.option.presetStorage.add('custom#active', {
		iconLayout: 'default#image',
		iconImageHref: 'marker.png',
		iconImageSize: [30, 40],
		iconImageOffset: [-15, -40],
		iconImageClipRect: [
			[0, 70],
			[30, 110]
		],
		hideIconOnBalloonOpen: false
	});

	var myMap = new ymaps.Map('map', {
			center: [55.751574, 37.573856],
			zoom: 9
		});

	for (var i = 1; i <= points.length; i++) {
		markers['id' + i] = new ymaps.Placemark(
			points[i - 1],
			{
				hintContent: 'Какая красивая метка...'
			},
			{
				preset: 'custom#default'
			}
		);
		$('<a href="#" data-type="marker" data-id="id' + i + '">').html(i + '-я метка').appendTo($(document.body));
	}

	placemark.events.add('click', function (e) {
		changeMarker(e.get('target'));
	});

	myMap.geoObjects.add(placemark);
});

function changeMarker (marker) {
	marker.options.set('preset', {
		preset: 'custom#active'
	});
}

$(document).on('click', 'a[data-id][data-type="marker"]', function (e) {
	e.stopPropagation();
	e.preventDefault();
	changeMarker(markers[$(this).data('id')]);
});

Метка тут такая

Делаем сначала ksort(). Потом получаем первый элемент reset(), и получаем последний end()

Проблема решилась. Путь необходимо указывать без слеша в начале :)

Вот такой рецепт получился (если я правильно понял вопрос)

const path   = require('path');
const gulp   = require('gulp');
const pug    = require('gulp-pug');

const cities = [
    {
        cityName : 'city1',
    },
    {
        cityName : 'city2',
    }
];

gulp.task('views', function(done) {

    cities.forEach(function(city, index, cities) {

        gulp.src('template/city.pug')
            .pipe(pug({
                data : city
            }))
            .pipe(gulp.dest(path.join('..', '..', 'domains', city.cityName)));
    });

    done();
});

Нашел ответ:
Просто вспомнил что следует заглянуть в коллекцию плагинов к phpstorm.
Надо установить
И настроить phpstorm: The IDE now recognises .pcss files. You can also enable PostCSS support for your .css files in Preferences | Languages & Frameworks | Stylesheets | Dialects.



В итоге было/стало:

Корневое пространство имен

<?php

namespace myNameSpace;

function in_array($value, $arr)
{
    return 'Local function';
}
$arr = [1, 2, 3];
$value = 1;

var_dump(in_array($value, $arr));
var_dump(\in_array($value, $arr));

Результат:

string(14) "Local function"
bool(true)

Зачем это нужно? Только если в текущем пространстве имен объявленна одноименная функция как и в глобальном. И что бы обратиться к глобальной, используется слеш - глобальное пространство имен.

Что бы сделать две цены на один товар, нужно использовать "Торговые предложения". Если же вы хотите использовать разные типы цен ( не путать с ценой ), то вы должны в настройках компонента выбрать эти типы цен для отображения и в административном разделе сайта, в настройках "Тип Цены" (где вы её создавали) выбрать для каких пользователей, какой тип будет отображаться.

Тип цены

Торговые предложения

1) Копируете шаблон компонента
2) Открываете template.php
3) Если проект рабочий, и пользователи уже пользуются ресурсом, выводите под админом $arResult или $arItem ( в зависимости какой у вас компонент ). Делается это так

<?global $USER;
		if ($USER->IsAdmin()){?>
                      <pre><?print_r($arResult)?></pre>
             <?}?>

Ищите в этом массиве ваши типы цены.

Далее выводите

<?echo $arResult["PRICE"]["PRICE_1"]["VALUE"]?> 
     <?echo $arResult["PRICE"]["PRICE_2"]["VALUE"]?>  // у вас пути до значения и названия типа цен могут отличаться

Важно! Если вы используете комплексный компонент каталог. То при создании копии шаблона компонента путь до нужных teamplate.php будет примерно такой:

/public_html/bitrix/templates/Название шаблона сайта/components/bitrix/catalog/название шаблона компонента/bitrix/catalog.element/.default - для карточки товара

/public_html/bitrix/templates/Название шаблона сайта/components/bitrix/catalog/название шаблона компонента/bitrix/catalog.section/.default - для списка товаров

screen и tmux. Вот вам уже готовый рецепт.
Как работает (примерно):

$ ssh localhost
$ screen
запускается процесс screen, в нём bash или что-нибудь ещё.
Запускаете вашу команду:
$(screen) php script.php
нажимаете Ctrl+A, Ctrl+D. Попадаете обратно в первый шелл.
отключаемся
$ exit
пьём кофе.
подключаемся вновь:
$ ssh localhost
$ screen -r
Видим результат работы нашей команды и приглашение ввести новую.
$(screen)

Остальное описано в man screen.

Структура проекта какая-то странная, в нем, судя по всему, контроллером называется роутер, но на этом я останавливаться не буду, обработка исключений от этого не зависит.

Основных правил при обработке исключений три:
1. Не использовать исключения там, где они не нужны. Например, при проверке пользовательских данных.
Собственно, эмпирическое правило звучит так: функция должна бросать исключение, если она не может выполнить ту работу, для которой она предназначена.

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

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

2. Системные ошибки обрабатывает глобальный обработчик исключений, логируя саму ошибку, а на клиент отправляя статус 500 и какое-нибудь абстрактное сообщение о проблеме на сервере. Это самое важное в системных исключениях - текст ошибки никогда, не при каких обстоятельствах не уходит наружу.

Пример такого исключения - когда запрос в БД порождает ошибку.

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

Для информирования можно действительно ловить исключение через try..catch и писать какое-то свое сообщение.
Но можно и автоматизировать этот процесс, вот две статьи, которые показывают примеры, как это можно сделать:
https://angelovdejan.me/2022/11/24/centralized-exc...
https://habr.com/ru/articles/688202/