Как да покажете известие за целия сайт на WordPress уебсайт

Известие за целия сайт в WordPress е постоянен банер или лента за известия, показвана на всяка страница на сайта, използвана за излъчване на чувствителни към времето съобщения, промоции, предупреждения за съгласие с бисквитки или прекъсвания на услугата до всички посетители едновременно. За разлика от съдържанието, специфично за дадена страница, известието за целия сайт се инжектира на ниво шаблон на темата — чрез куки на плъгин, functions.php на темата, механизъм за условия на показване на конструктор на страници или директна модификация на PHP шаблон — гарантирайки, че се появява независимо от това на кой URL попада посетителят.

Това ръководство обхваща четири метода от производствен клас, наредени от най-ниска до най-висока сложност на изпълнение, с технически гранични случаи, съображения за производителност и клопки при кеширане, които повечето уроци пропускат изцяло.

Защо известията за целия сайт имат значение извън маркетинга

Преди да изберете метод за изпълнение, разберете какво всъщност се случва зад кулисите. Известието за целия сайт се рендира при всеки отговор на сървъра или се инжектира чрез JavaScript след зареждане на DOM. Това разграничение има реални последствия:

• Рендиране от страна на сървъра (SSR) чрез PHP куки на шаблони е индексируемо от Googlebot и видимо преди изпълнението на JavaScript — критично за достъпност и SEO.
• Известия, инжектирани чрез JavaScript (характерни за някои плъгини), може да не се появят при първоначалното рендиране на Google и могат да причинят Cumulative Layout Shift (CLS), директно увреждайки резултата ви за Core Web Vitals.
• Кеширане на цели страници (WP Rocket, LiteSpeed Cache, Nginx FastCGI cache) ще кешира HTML на известието. Ако трябва да показвате известие само на влезли в системата потребители или въз основа на геолокация, кешираната статична страница ще игнорира тази логика изцяло, освен ако не конфигурирате изключения от кеша или не използвате фрагментно кеширане.

Средата за хостинг има значение тук. В среда за VPS Хостинг, където контролирате конфигурацията на Nginx или Apache, можете да внедрите правила за заобикаляне на кеша за специфични бисквитки, зададени от вашия плъгин за известия. При споделен хостинг сте ограничени до каквото и да е ниво на кеша, което хостът предоставя.

Метод 1: Използване на специализиран WordPress плъгин

Това е най-бързият път към готово за производство известие и не изисква никакво кодиране. Компромисът е натоварването от плъгина и зависимостта от цикъла на актуализации на трета страна.

Препоръчани плъгини

Стъпка 1: Инсталиране и активиране

Влезте в административния панел на WordPress и отидете на Плъгини > Добавяне на нов. Потърсете WPFront Notification Bar, кликнете Инсталирай сега, след това Активирай.

Стъпка 2: Конфигуриране на лентата за известия

Отидете на Настройки > WPFront Notification Bar. Ключови полета за конфигуриране:

• Съдържание на съобщението: Поддържа HTML, така че можете да вграждате тагове за котви, тагове <strong> или вградени стилове директно.
• Позиция: Горе или долу. Горното поставяне е по-видимо, но увеличава риска от CLS, ако лентата се зарежда след първоначалното рендиране. Долното поставяне е по-безопасно за Core Web Vitals.
• Фиксирано поведение: Активирането на „фиксирано” позициониране задържа лентата на екрана при превъртане. Това използва position: fixed в CSS, което премахва елемента от потока на документа и може да припокрие заглавката на темата ви на мобилни устройства — тествайте на множество размери на изгледа.
• Условия за показване: Ограничете известието до специфични типове публикации, страници или потребителски роли. Показването на известие само на невлезли в системата потребители, например, изисква плъгинът да зададе условна проверка спрямо is_user_logged_in().
• Отхвърляне с бисквитка: Когато потребител затвори известието, се задава бисквитка в браузъра. Известието няма да се появи отново, докато тази бисквитка не изтече. Задайте подходящо TTL — за 48-часова разпродажба, бисквитка за 2 дни е подходяща. За постоянно известие за GDPR, задайте това на 0 (никога не се отхвърля автоматично).

Стъпка 3: Запазване и проверка

Кликнете Запази настройките. Отворете сайта си в прозорец инкогнито (за да избегнете намеса на административни бисквитки в логиката на показване) и проверете дали лентата се рендира на началната страница, публикация в блог и статична страница.

Критичен граничен случай: Ако използвате плъгин за кеширане на цели страници, изчистете кеша след запазване. В противен случай посетителите ще виждат старата кешираната версия на страницата без известието.

Метод 2: Използване на WordPress Theme Customizer

Много съвременни теми — особено тези, изградени на базата на фреймуърки като Genesis, Astra, GeneratePress или OceanWP — включват нативен компонент Лента за съобщения или Горна лента. Този подход не добавя никакво натоварване от плъгини и е най-чистата опция, ако темата ви го поддържа.

Стъпка 1: Достъп до Theme Customizer

Отидете на Външен вид > Персонализиране. Потърсете секции с надписи Опции на заглавката, Горна лента, Лента за съобщения или Помощна лента. Точният надпис зависи от темата.

Стъпка 2: Конфигуриране на лентата за съобщения

В панела на персонализатора обикновено ще намерите:

• Текстово или HTML поле за въвеждане на съдържанието на известието
• Инструменти за избор на цвят за фон и текст
• Превключвател за глобално активиране/деактивиране на лентата
• Незадължително поле за връзка за бутон с призив за действие

Персонализаторът рендира промените в iframe с преглед на живо. Използвайте го, за да проверите как лентата взаимодейства с навигационното ви меню на десктоп и мобилни точки на прекъсване, преди да публикувате.

Стъпка 3: Публикуване

Кликнете Публикувай. Промените се записват в опцията на базата данни theme_mods за активната ви тема. Никакви файлове не се модифицират, което означава, че персонализацията оцелява при актуализации на темата (за дъщерни теми или теми, които съхраняват модификации в базата данни, а не в style.css).

Важно: Ако актуализирате родителската тема без използване на дъщерна тема и темата съхранява логиката на лентата за съобщения в шаблонен файл, а не в куки за филтри, конфигурацията на известието ви може да бъде презаписана. Винаги използвайте дъщерна тема при модифициране на поведението на темата.

Метод 3: Добавяне на известие за целия сайт с персонализиран код

Директното изпълнение с PHP и CSS ви дава пълен контрол върху логиката на рендиране, стилизирането и производителността. Това е правилният подход, когато имате нужда от условна логика на показване, която нито един плъгин не предоставя, или когато искате да минимизирате HTTP заявките и изпълнението на JavaScript.

Стъпка 1: Добавяне на HTML чрез куки на темата

Вместо да редактирате header.php директно — което се нарушава при актуализации на темата — използвайте куката за действие wp_body_open или куката wp_head в functions.php на дъщерната ви тема. Това е идиоматичният подход за WordPress.

Добавете следното в functions.php на дъщерната ви тема:

function alexhost_sitewide_notice() {
    // Only display for non-logged-in users
    if ( is_user_logged_in() ) {
        return;
    }
    ?>
    <div class="sitewide-notice" role="alert" aria-live="polite">
        <p>Scheduled maintenance on Saturday 02:00–04:00 UTC.
           <a href="/maintenance-info/">Learn more</a>
        </p>
        <button class="sitewide-notice__close" aria-label="Dismiss notice">×</button>
    </div>
    <?php
}
add_action( 'wp_body_open', 'alexhost_sitewide_notice' );

Защо wp_body_open вместо wp_head? Куката wp_head се задейства вътре в <head>, което е грешното място за видим HTML. wp_body_open се задейства веднага след отварящия таг <body>, което е семантично правилно и се поддържа от всички теми, които извикват wp_body_open() в своите шаблони. Ако темата ви не извиква тази функция, използвайте куката get_header с изходен буфер или редактирайте header.php в дъщерна тема.

Ако трябва да редактирате шаблонния файл директно, отворете header.php на дъщерната ви тема и вмъкнете маркировката на известието веднага след тага <body>:

<div class="sitewide-notice" role="alert" aria-live="polite">
    <p>This is an important announcement!
       <a href="https://example.com">Learn more here.</a>
    </p>
</div>

Стъпка 2: Добавяне на CSS чрез Customizer или functions.php

За малки CSS фрагменти използвайте Външен вид > Персонализиране > Допълнителен CSS. За по-сложни неща, добавете стилова таблица от дъщерната ви тема.

Поставете следното в Допълнителен CSS:

.sitewide-notice {
    background-color: #1a73e8;
    color: #ffffff;
    text-align: center;
    padding: 12px 40px;
    position: sticky;
    top: 0;
    width: 100%;
    z-index: 9999;
    box-sizing: border-box;
    font-size: 0.95rem;
    line-height: 1.5;
}

.sitewide-notice a {
    color: #ffffff;
    text-decoration: underline;
    font-weight: 600;
}

.sitewide-notice a:hover {
    opacity: 0.85;
}

.sitewide-notice__close {
    position: absolute;
    right: 16px;
    top: 50%;
    transform: translateY(-50%);
    background: transparent;
    border: none;
    color: #ffffff;
    font-size: 1.4rem;
    cursor: pointer;
    line-height: 1;
}

@media (max-width: 768px) {
    .sitewide-notice {
        font-size: 0.85rem;
        padding: 10px 36px;
    }
}

position: sticky срещу position: fixed: Използването на sticky задържа известието в потока на документа, предотвратявайки припокриването на навигацията ви. fixed го премахва от потока, което може да причини рендиране на съдържание под лентата, освен ако не добавите съответен padding-top към елемента <body> или <main>. За повечето теми sticky е по-безопасната настройка по подразбиране.

Стъпка 3: Добавяне на JavaScript за отхвърляне базирано на бисквитки

Без механизъм за отхвърляне, известието се появява отново при всяко зареждане на страница, което влошава потребителското изживяване. Добавете този скрипт чрез Външен вид > Персонализиране > Допълнителен CSS (не е идеално) или, по-добре, го добавете правилно в functions.php:

function alexhost_notice_dismiss_script() {
    wp_enqueue_script(
        'notice-dismiss',
        get_stylesheet_directory_uri() . '/js/notice-dismiss.js',
        array(),
        '1.0.0',
        true // Load in footer
    );
}
add_action( 'wp_enqueue_scripts', 'alexhost_notice_dismiss_script' );

Създайте /wp-content/themes/your-child-theme/js/notice-dismiss.js с:

(function () {
    var COOKIE_NAME = 'sitewide_notice_dismissed';
    var COOKIE_TTL_DAYS = 7;

    function getCookie(name) {
        var match = document.cookie.match(new RegExp('(^| )' + name + '=([^;]+)'));
        return match ? match[2] : null;
    }

    function setCookie(name, value, days) {
        var expires = new Date(Date.now() + days * 864e5).toUTCString();
        document.cookie = name + '=' + value + '; expires=' + expires + '; path=/; SameSite=Lax';
    }

    var notice = document.querySelector('.sitewide-notice');
    if (!notice) return;

    if (getCookie(COOKIE_NAME) === '1') {
        notice.style.display = 'none';
        return;
    }

    var closeBtn = notice.querySelector('.sitewide-notice__close');
    if (closeBtn) {
        closeBtn.addEventListener('click', function () {
            notice.style.display = 'none';
            setCookie(COOKIE_NAME, '1', COOKIE_TTL_DAYS);
        });
    }
}());

Този скрипт е самостоятелен, няма зависимост от jQuery и се изпълнява след зареждане на DOM, тъй като е добавен в долния колонтитул.

Стъпка 4: Проверка в различни контексти

• Отворете сайта в прозорец инкогнито, за да потвърдите, че известието е видимо.
• Кликнете бутона за отхвърляне и презаредете — известието трябва да е скрито.
• Изчистете бисквитката ръчно чрез DevTools на браузъра (Application > Cookies) и презаредете — известието трябва да се появи отново.
• Тествайте на мобилен изглед (минимум 320px ширина), за да потвърдите, че адаптивният CSS работи.

Метод 4: Използване на конструктор на страници (Elementor, Bricks, Oxygen)

Конструкторите на страници с модул Theme Builder ви позволяват да проектирате известие визуално и да го присвоите на всички страници чрез условия за показване. Това е най-добрата опция за екипи, които управляват съдържание визуално и се нуждаят от прецизен дизайн без докосване на код.

Elementor Pro: Подход с Theme Builder

Стъпка 1: Отидете на Шаблони > Theme Builder > Заглавка (или създайте нов шаблон за персонализирана заглавка).

Стъпка 2: Добавете нова Секция в самото начало на шаблона на заглавката. Вътре в нея поставете уиджет Текстов редактор или Заглавие с вашето съдържание за съобщение. Стилизирайте го с помощта на панела на Elementor — налични са цвят на фона, типография, отстъп и уиджети за бутони.

Стъпка 3: В Публикувай > Условия за показване, задайте условието на Целия сайт. Това гарантира, че секцията се рендира на всяка страница, която използва този шаблон на заглавката.

Стъпка 4: Публикувайте шаблона. Elementor записва изхода на шаблона в собствените си таблици в базата данни и го рендира чрез своя шаблонен механизъм при всяко зареждане на страница.

Забележка за производителността: Theme Builder на Elementor Pro зарежда допълнителни CSS и JavaScript ресурси. На сайт, чувствителен към производителността, измерете въздействието с Lighthouse преди и след. Ако натоварването е неприемливо, методът с персонализиран код (Метод 3) е по-ефективен.

Подход с Bricks Builder

В Bricks > Шаблони, създайте нов шаблон за Заглавка. Добавете контейнер в горната част на заглавката, проектирайте известието си и задайте Условията на шаблона да се прилагат за всички страници. Bricks генерира чист, минимален HTML в сравнение с Elementor, което го прави по-добър избор за изграждане, фокусирано върху производителността.

Сравнение на всички четири метода

Съображения за производителност и кеширане

Тази секция разглежда най-честия режим на неуспех в производството: известие, което работи перфектно при разработка, но се държи непоследователно на жив, кеширан сайт.

Кеширането на цели страници съхранява пълния HTML изход на страница. Ако известието ви е рендирано от страна на сървъра и след това страницата е кеширана, всеки посетител — независимо дали е отхвърлил известието — ще получи същия кеширан HTML. JavaScript за отхвърляне базирано на бисквитки все още ще скрие известието от страна на клиента, но HTML винаги ще присъства в изходния код.

Ако имате нужда сървърът да пропусне рендирането на известието за потребители, които са го отхвърлили (например, за да намалите HTML натоварването или да избегнете мигане на известието при зареждане), трябва да конфигурирате плъгина за кеш да заобикаля кеширането, когато бисквитката за отхвърляне е налице.

В WP Rocket добавете името на бисквитката в Настройки > Разширени правила > Никога не кеширай бисквитки:

sitewide_notice_dismissed

В LiteSpeed Cache отидете на Кеш > Изключения > Не кеширай бисквитки и добавете същата стойност.

На ниво сървър Nginx FastCGI кеш, добавете условие за заобикаляне на кеша в конфигурацията на Nginx:

map $http_cookie $skip_cache {
    default 0;
    "~*sitewide_notice_dismissed=1" 1;
}

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Това гарантира, че потребителите, отхвърлили известието, получават динамично генерирана страница без HTML на известието, докато всички останали посетители се обслужват от кешираната версия с непокътнато известие.

Ако използвате WordPress на VPS с cPanel или напълно управляван Dedicated Server, имате директен достъп до конфигурационните файлове на Nginx или Apache за прилагане на тези правила за заобикаляне на кеша на ниво сървър — нещо, което не е възможно при стандартни планове за споделен хостинг.

Изисквания за достъпност

Известие за целия сайт, което не отговаря на стандартите за достъпност, може да изложи сайта ви на правен риск съгласно рамките за съответствие с WCAG 2.1 и ADA. Прилагайте тези изисквания независимо от избрания метод на изпълнение:

• Добавете role="alert" и aria-live="polite" към контейнера на известието. Това кара екранните четци да обявяват съдържанието на известието при появата му.
• Уверете се, че контрастът на цветовете между текста на известието и фона отговаря на минимално съотношение от 4,5:1 за нормален текст (WCAG AA). Използвайте инструмент като WebAIM’s Contrast Checker за проверка.
• Бутонът за отхвърляне трябва да може да получава фокус от клавиатурата и да се управлява чрез клавишите Enter и Space. Нативен елемент <button> се справя с това автоматично — не използвайте <div> или <span> като цел за кликване.
• Не разчитайте само на цвят за предаване на спешността на известието. Използвайте изричен текст (напр. „Важно:” или „Известие:”) като префикс.

SEO последствия от известията за целия сайт

Фиксирано или залепено известие, рендирано в HTML на всяка страница, се индексира от Googlebot като част от съдържанието на страницата. Имайте предвид следните точки:

• Избягвайте текст на известието, претрупан с ключови думи. Google може да интерпретира повтарящ се идентичен текст на хиляди страници като нискокачествено шаблонно съдържание.
• Използвайте aria-hidden="true" за чисто декоративни известия (напр. банер за бисквитки без информационна стойност), за да предотвратите претеглянето на текста в SEO изчисленията на страницата.
• Въздействие на CLS: Известие, което се зарежда след първоначалното рендиране и избутва съдържанието надолу, ще генерира CLS резултат. Смекчете това, като запазите място за известието в CSS с помощта на min-height върху тялото или като рендирате известието от страна на сървъра, така че да присъства в първоначалния HTML.
• Структурирани данни: Ако известието ви обявява събитие или промоция, помислете за добавяне на схема Event или Offer към страницата, вместо да разчитате само на текста на банера за видимост в търсачките.

Практическа матрица за вземане на решения

Използвайте този контролен списък, за да изберете правилния метод за вашата конкретна ситуация:

• Имате нужда от известие на живо за по-малко от 10 минути без кодиране: Използвайте плъгин (Метод 1). Инсталирайте WPFront Notification Bar, конфигурирайте го, изчистете кеша.
• Темата ви има вградена лента за съобщения и не се нуждаете от персонализирана логика: Използвайте Theme Customizer (Метод 2). Нулево натоварване, оцелява при актуализации на плъгини.
• Имате нужда от условна логика на показване (потребителска роля, тип публикация, гео-IP, състояние на бисквитка) или максимална производителност: Използвайте персонализиран PHP/CSS/JS (Метод 3). Закачете се за wp_body_open, добавете скриптове правилно, внедрете отхвърляне базирано на бисквитки.
• Екипът ви е нетехнически и управлява сайта визуално: Използвайте Elementor Pro Theme Builder или Bricks (Метод 4). Задайте условията за показване на Целия сайт.
• Намирате се в кеширана VPS или среда с dedicated сървър: Независимо от избрания метод, конфигурирайте правила за заобикаляне на кеша за бисквитката за отхвърляне. Неспазването на това е единствената най-честа причина за тикети за поддръжка, свързани с известия.
• Имате нужда известието да отговаря на WCAG 2.1: Използвайте Метод 3 (персонализиран код) или Метод 1 с плъгин, поддържащ role="alert". Проверете съотношенията на контраст ръчно.

За екипи, управляващи WordPress на инфраструктура, която контролират — независимо дали е план за VPS Хостинг или Dedicated Server — подходът с персонализиран код, съчетан с правила за заобикаляне на кеша на ниво сървър, дава най-надеждния и ефективен резултат. За по-малки сайтове на Споделен Уеб Хостинг, добре конфигуриран плъгин с поддръжка за изчистване на кеша е прагматичният избор.

Ако сайтът ви обработва транзакционни комуникации заедно с известия за целия сайт — като потвърждения на поръчки или промоционални имейли — уверете се, че инфраструктурата ви за Имейл Хостинг е конфигурирана с правилни записи SPF, DKIM и DMARC, така че имейлите, задействани от известия, да не попадат в спам.

ЧЗВ

В: Ще навреди ли известие за целия сайт на SEO или резултата ми за Core Web Vitals?

О: Може, ако е внедрено небрежно. Известие, инжектирано чрез JavaScript, което се зарежда след първоначалното рендиране, причинява Cumulative Layout Shift (CLS), който е метрика на Core Web Vitals. Известията, рендирани от страна на сървъра, избягват CLS изцяло. Дръжте текста на известието кратък и неповтарящ се, за да избегнете Google да го третира като шаблонно съдържание в целия сайт.

В: Как да покажа известие за целия сайт само на излезли от системата потребители?

О: В персонализиран PHP код, обвийте изхода на известието в условна проверка: if ( ! is_user_logged_in() ) { ... }. В WPFront Notification Bar използвайте условието за показване „Потребителска роля”. В Elementor Pro задайте условие за показване, което изключва влезлите в системата потребители. Винаги изчиствайте кеша на страниците след промяна на тази логика.

В: Известието ми изчезва след актуализация на темата. Каква е причината?

О: Вероятно редактирате header.php на родителската тема директно, вместо да използвате дъщерна тема или куката functions.php. Преместете кода на известието в functions.php на дъщерна тема, използвайки куката за действие wp_body_open. Актуализациите на темата никога няма да презапишат functions.php в дъщерна тема.

В: Мога ли да планирам известие за целия сайт да се появява и изчезва автоматично?

О: Безплатните версии на повечето плъгини за известия не поддържат планиране. WPFront Notification Bar Pro и WP Notification Bars Pro предлагат планиране по диапазон от дати. В персонализиран код можете да внедрите планиране с просто PHP сравнение на дати: проверете current_time('timestamp') спрямо началните и крайните времеви отпечатъци, преди да изведете HTML на известието.

В: Защо известието за целия сайт не се показва на кешираните страници?

О: Кеширането на цели страници съхранява HTML снимка на страница към момента на първата заявка. Ако кешът е бил изграден преди добавянето на известието, посетителите получават стария кеширан HTML. Изчистете целия кеш на страниците веднага след публикуване на ново известие. Ако използвате бисквитка за отхвърляне, конфигурирайте плъгина за кеш или сървъра да заобикаля кеширането за заявки, носещи бисквитката за отхвърляне, така че връщащите се посетители да не виждат мигане на известието, преди JavaScript да го скрие.