Веб Мастерская | Веб разработка и программирование | ИТ | IT

ИЗ ПРОФЕССИИ:

Как новичку не бояться первого коммита

Помните свой первый git commit? Руки над клавиатурой, как у сапёра перед красным проводом. В голове крутится: «А вдруг я что-то сломаю? А вдруг кто-то увидит мой код и решит, что я не программист, а случайно забредший человек?»

Спокойно. Я тоже так сидел. Серьёзно. Первые три коммита я переписывал сообщение по десять раз, потому что «а вдруг оно недостаточно профессиональное».


Давайте разберём страх по винтикам

1. Вы ничего не сломаете!
Git создан для того, чтобы ошибки были обратимы. Это не продакшен, не сервер заказчика. Это ваша песочница. Даже если вы закоммитили мусор — git reset вам в помощь. Мир не рухнет.

2. Никто не ждёт шедевр
Первый коммит — это не защита диплома. Сообщение fix stuff на этапе обучения — абсолютно нормально. Красивые конвенции придут потом. Сначала — привычка фиксировать изменения.

3. Практическое упражнение на сегодня
Создайте пустой файл hello.txt. Напишите в нём «я не боюсь коммитов». Сделайте:





git add hello.txt
git commit -m "first: я живой, я коммичу"

Всё. Вы это сделали. Без ревью, без CI/CD, без последствий. Просто для себя.

4. Смените рамку
Коммит — это не экзамен. Это заметка самому себе из будущего. Вы пишете не для тимлида. Вы пишете для того парня, который через неделю будет смотреть в код и говорить: «Что за чёрт тут происходит?»

Главный принцип мастерской
Не бывает «слишком раннего» коммита. Бывает только отсутствие коммита, когда всё потеряно в 23:47.

Так что открывайте терминал, пишите хоть git commit -m "тут пока каша, но я работаю". Это уже победа над страхом. А страх, коллеги, — единственный баг, который не фиксится стэком. Фиксится только действием.

Вот так. Идем кодить дальше! 🚀

БАЗА:

rel="noopener noreferrer" — или как не отдать ключи от сайта чужой вкладке

Коллеги, признавайтесь: сколько раз вы писали target="_blank" без единой мысли о том, что происходит «под капотом»? Я тоже так делал. А потом разобрался — и теперь делюсь, чтобы вы не наступили на те же грабли.


Суть проблемы

Когда вы открываете ссылку через target="_blank", новая страница получает доступ к объекту window.opener вашего сайта. Через него она может выполнить:





window.opener.location = 'https://фишинг-сайт.рф'

И вуаля — пока пользователь читает «ту самую статью», его оригинальная вкладка тихо перенаправляется на фейковую страницу логина. Это называется reverse tabnabbing. Звучит как теория? В 2018–2020 годах на этом ловили реальные фишинговые кампании.


Решение — одна строка





<a href="https://example.com"
target="_blank"
rel="noopener noreferrer"
>Внешний ресурс</a>

Разберём по полочкам

• noopener — рубит доступ к window.opener. Новая вкладка становится «сиротой» и не знает, кто её открыл.

• noreferrer — прячет Referer-заголовок + автоматически включает noopener.


А зачем указывать, если браузеры и так добавляют noopener?

С 2021 года все современные браузеры (Chrome 88+, Firefox 79+, Safari) автоматически ставят noopener для target="_blank". Но!

1. Вы не контролируете, какой браузер у пользователя.

2. Код читает следующий разработчик — пусть сразу видит намерение.

3. Линтеры (ESLint vue/no-template-target-blank, react/jsx-no-target-blank) ругаются, если атрибут не указан явно.

4. Меньше шума в CI — спокойнее сон.


Когда можно обойтись без noreferrer

Если вам нужна аналитика переходов по Referer (партнёрские ссылки, метрики) — ставьте только noopener. Но для обычных внешних ссылок — полный комплект.


Чек-лист для продакшена

✅ Все <a target="_blank"> на внешние домены → rel="noopener noreferrer"

✅ Кнопки-ссылки (<button onclick="window.open(...)">) → noopener передаётся вторым аргументом: window.open(url, '_blank', 'noopener')

✅ Настроить ESLint-правило, чтобы не пропускать «голые» target="_blank"

Коллеги, одна строчка в разметке закрывает целую категорию уязвимостей. Не «авось браузер разберётся», а явная защита в коде.

Вот так. Идем кодить дальше! 🚀

SEO:

Полное руководство по борьбе с дублями страниц

Коллеги, признавайтесь: хоть раз гуглили свой сайт через site: и находили там 3-4 копии одной и той же страницы? Поздравляю, вы не одиноки. Дубли — это как тараканы на кухне: вроде бы не критично, но поисковики морщатся, а ваш рейтинг потихоньку стекает в канализацию.


Почему это больно?

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


Где искать дубли

→ Screaming Frog — crawl-им сайт, смотрим отчёты по дублирующимся Title, H1, Meta Description. Вкладка «Page Data» сразу покажет проблемные URL.

→ Google Search Console → «Страницы» → фильтруем по «Дублирующимся без указания канонической». Гугл сам всё нашёл, вам остаётся только чинить.

→ Оператор site:ваш-домен.ру + проверка через inurl:, intitle:. Дёшево и сердито.

→ Проверка параметров: ?sort=price, ?utm_source=..., ?page=2. Если сервер отдаёт 200 вместо редиректа — у вас дубль.


Как лечим

1️⃣ 301-редирект — если страница-дубль не нужна вообще (удалённый фильтр, старый URL). Навсегда, без вариантов.

2️⃣ Canonical (rel="canonical") — если дубль нужен пользователям (пагинация, сортировки), но в индекс должна идти одна версия. Ставим в <head>.

3️⃣ robots.txt + meta robots — закрываем мусорные параметры от индексации. Но помним: Disallow не склеивает вес, а noindex + follow — да.

4️⃣ Единый формат URL — один слэш или без, www или без, http vs https. Прописываем редиректы на уровне сервера (nginx/Apache), а не надеваемся на CMS.

5️⃣ Карта сайта — в sitemap.xml только канонические версии. Никаких дублей. Точка.

Лайфхак из мастерской: после всех правок запускаем повторный crawl через 2-3 дня и сверяем количество проиндексированных страниц в Search Console. Если цифра упала на 15-20% — вы всё сделали правильно. Это не потеря, это уборка.

Коллеги, дубли — это не приговор, а просто бардак в структуре. Навели порядок — и поисковик начал вас уважать. Проверьте свой проект на этой неделе, не откладывайте.

Вот так. Идем кодить дальше! 🚀

Экстренный рефакторинг 32 проектов с mysql_* на PHP 8.5 без единой строчки правок в бизнес-логике

Читайте нашу статью на Хабре: https://habr.com/ru/articles/1098930/

Как я с <template> и <slot> подружиться пытался

Читайте нашу статью на Хабре:
https://habr.com/ru/articles/1098408/

ВАЖНО:

Многие так и не решили вопрос с уязвимостью в PHP. Поэтому, если на вашем сервере/VPS используется PHP, вам необходимо:

1. Обновить PHP до исправленной версии: 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (либо пакет дистрибутива с исправлением).

2. Если обновить сразу невозможно — временно установить в php.ini (для PHP-FPM/Apache) параметр:





session.upload_progress.enabled = Off

и перезапустить PHP-FPM/веб-сервер.

3. Ограничить доступ к административным панелям (Bitrix, WordPress, phpMyAdmin и т.п.) доверенными IP-адресами.

4. Проверить сервер на признаки взлома: неизвестные .php-файлы, подозрительные процессы и исходящие соединения.

Важно: взломанные ресурсы, используемые для атак, могут быть заблокированы ЦМУ ССОП на уровне сети.

Позаботьтесь о своем сервере как можно быстрее!

КЕЙС:

Редизайн каталога на 12 000 товаров: фильтрация без перезагрузки страницы

Коллеги, на днях закрыли проект, который начинался со слов клиента: «У нас каталог тормозит, покупатели уходят». А заканчивался тем, что мы перебрали всю логику фильтрации с нуля. Делюсь, что сработало в продакшене.

Дано: интернет-магазин строительных материалов. 12 000+ SKU, 6 уровней вложенности категорий, 14 параметров фильтрации (цена, бренд, материал, размер, наличие и т. д.). Старая реализация — классический сабмит формы, перезагрузка, белый экран на 3–4 секунды. Конверсия в корзину: 1,2%.


Что сделали:

1️⃣ Перенесли фильтрацию на клиент. Сервер отдаёт один раз срез по категории (макс. ~3 000 позиций), дальше крутим на фронте. Для 12 000 товаров по всей витрине — ленивая подгрузка через IntersectionObserver + пагинация по 200 карточек.

2️⃣ Debounce + Web Worker. Ввод в поиск и чекбоксы фильтров уходят в воркер с задержкой 300 мс. Воркер гоняет фильтрацию по индексу (простой Map по каждому параметру), возвращает массив ID. Основной поток не фризит.

3️⃣ Скелетоны вместо спиннера. Пока воркер считает, показываем анимированные заглушки карточек. Пользователь видит, что «что-то происходит», а не тупит в пустоту.

4️⃣ Синхронизация с URL. Каждый набор фильтров пишется в query-params через History API. Ссылку можно скопировать, отправить, добавить в закладки. Без перезагрузки.

5️⃣ Счётчик результатов в реальном времени. «Найдено 347 товаров» обновляется мгновенно, ещё до отрисовки карточек. Даёт ощущение контроля.


Результат через 3 недели после деплоя:

— Время отклика фильтра: 3–4 сек → 120 мс (медиана).
— Конверсия в корзину: 1,2% → 2,7%.
— Показатель отказов на страницах каталога упал на 38%.

Грабли, на которые наступили: на первом прототипе грузили все 12 000 объектов разом. На слабых мобилках Safari просто умирал по памяти. Пришлось резать на чанки и выгружать невидимые карточки из DOM.

Главный вывод: не бойтесь переносить логику на клиент, если объём данных вменяемый. Но всегда тестируйте на реальных устройствах, а не на MacBook с 32 ГБ оперативки. 😄

Вот так. Идем кодить дальше! 🚀

ДАЙДЖЕСТ НОВОСТЕЙ:

Коллеги, снова пятница, и у меня для вас свежая подборка новостей из мира веб-разработки! 🔥


🚀 React 19.3 вышел — что нового?
Команда React выкатила версию 19.3 с целым рядом улучшений. Ходят слухи, что скоро увидим и React 20, но пока довольствуемся тем, что есть. Если работаете на React — самое время обновиться и протестировать новые фичи в продакшене!


⚡ Next.js 16.4: Turbopack становится стабильным
Vercel продолжает радовать. Новый Next.js 16.4 приносит lazy compilation, уменьшенный вывод Turbopack и полную поддержку React 19.3. Скорость сборки выросла, билды стали быстрее — фрилансерам и студиям это точно понравится!


🟢 Node.js 26: Temporal API теперь по умолчанию
Долгожданное событие для бэкендеров. В Node.js 26 Temporal API включен по умолчанию, добавились Map upsert helpers и новый V8 14.6. Если вы все еще на старых версиях — пора планировать миграцию, потому что старая добрая Date уже уходит в прошлое.


🛡️ PHP2Shell: критические уязвимости RCE
Внимание, бэкендеры на PHP! Обнаружены две критические уязвимости (CVE-2026-109618 и CVE-2026-109619), позволяющие неаутентифицированному злоумышленнику выполнять произвольный код на сервере. Затронуты версии PHP от 5.4 до 8.5 — это практически все, что вы могли встретить в legacy-проектах. Срочно обновляйтесь и проверяйте свои клиенты!


⚠️ Vmanager под ударом: обход аутентификации
А здесь у нас Cisco Catalyst SD-WAN Manager (vManager). Уязвимость CVE-2026-76504 позволяет получить права администратора одним POST-запросом — буквально без всякой аутентификации. Если вы используете vManager для управления сетью — патчите инфраструктуру немедленно, иначе ваш сервер может уйти к злоумышленникам.

Всем удачи и да поможет нам Ктулху...

CMS:

Когда стоит выбирать Drupal вместо WordPress

Коллеги, давайте честно: в 8 из 10 проектов WordPress закроет задачу. Но есть те самые 2 из 10, где вы будете проклинать всё на свете, пытаясь натянуть его на сложный проект. И вот тут на сцену выходит Drupal.

Когда Drupal реально оправдан:

🔹 Сложная структура контента. У вас 15+ типов материалов, связанных друг с другом: статьи → авторы → категории → теги → регионы → ещё какая-нибудь сущность. В WP вы утонете в плагинах ACF и кастомных таксономиях. В Drupal это нативная история из коробки.

🔹 Гибкие права доступа. Когда нужно, чтобы редактор видел одно, менеджер — другое, а клиент из региона Х — только свой кусок. В Drupal система ролей и разрешений гранулярная до неприличия.

🔹 Мультиязычность на стероидах. Не просто «перевели страницу», а 5 языков, разные структуры меню, локализованные таксономии, переводы полей сущностей. Drupal делает это без танцев с бубном.

🔹 Безопасность уровня «госсайт». Не зря на Drupal сидят whitehouse.gov и куча университетов. Модуль Security Team работает как часы, патчи выходят быстро, аудит кода строгий.

🔹 Контент как API. Headless-архитектура, когда фронт на React/Next, а бэк отдаёт JSON. В Drupal это из коробки через JSON:API. В WP — через плагины и боль.


А когда Drupal — оверкилл:

Блог, лендинг, визитка, простой интернет-магазин на 50 товаров. Серьёзно, не мучайте себя. WordPress + Elementor/WooCommerce закроют это за неделю.

Главный критерий выбора: если вы ловите себя на мысли «мне нужна не просто CMS, а фреймворк для управления контентом» — смотрите в сторону Drupal. Порог входа выше, порог боли на третьем месяце поддержки — ниже.

Из практики
Переносили корпоративный портал с 200+ страницами и 8 ролями с WP на Drupal. Клиент перестал звонить в 2 часа ночи с вопросом «почему плагин конфликтовал». Бесценно. 😄

Вот так. Идем кодить дальше! 🚀