Новите "Block" теми

Еби му майката, това е същото като html-a в JS фунцките на реакт или подобно беше.
Да поясня, това е от functions.php
PHP:
        register_block_style(
            'core/heading',
            array(
                'name'         => 'asterisk',
                'label'        => __( 'With asterisk', 'twentytwentyfour' ),
                'inline_style' => "
                .is-style-asterisk:before {
                    content: '';
                    width: 1.5rem;
                    height: 3rem;
                    background: var(--wp--preset--color--contrast-2, currentColor);
                    clip-path: path('M11.93.684v8.039l5.633-5.633 1.216 1.23-5.66 5.66h8.04v1.737H13.2l5.701 5.701-1.23 1.23-5.742-5.742V21h-1.737v-8.094l-5.77 5.77-1.23-1.217 5.743-5.742H.842V9.98h8.162l-5.701-5.7 1.23-1.231 5.66 5.66V.684h1.737Z');
                    display: block;
                }

                /* Hide the asterisk if the heading has no content, to avoid using empty headings to display the asterisk only, which is an A11Y issue */
                .is-style-asterisk:empty:before {
                    content: none;
                }

                .is-style-asterisk:-moz-only-whitespace:before {
                    content: none;
                }

                .is-style-asterisk.has-text-align-center:before {
                    margin: 0 auto;
                }

                .is-style-asterisk.has-text-align-right:before {
                    margin-left: auto;
                }

                .rtl .is-style-asterisk.has-text-align-left:before {
                    margin-right: auto;
                }",
            )
        );
 
Само inline ли позволява? Ако не дава възможност за използване на стилове от отделен файл тогава супер тъпо. Ако позволява, тогава обвинявам програмиста.

Те всичките един от друг гледат. За PHP ми се струва странно обаче. Поне бъндлърите в JS ти дават повече възможности.
 
Това по-горе е отвратително... В Аргос си инжектирам библиотеките през евентите, така:
PHP:
        if (str_contains($_SERVER['REQUEST_URI'], '/pages/store')) {
            $this->dispatcher->emit('core_event_head_append', ['<link rel="stylesheet" href="ext/arenaplay/store/template/css/store.css?v=1">']);
            $this->dispatcher->emit('core_event_js_libs_insert', ['<script type="text/javascript" src="ext/arenaplay/store/template/js.js?v=10"></script>']);
            $this->dispatcher->emit('core_event_inside_custom_menu', [$this->custom_page()]);
        }
Тоест, ако съм попаднал на /pages/store ще ми инжектира в head секцията store.css, а долу в библиотеките js.js (под jquery библиотеката)
накрая викам логиката на custom_page() чрез метода му. (демек страницата)

Много просто и лесно, а не с глупавия WP. Чак ме е яд, че наляхме толкова пари за него. При първа възможност ще си пренапиша имотите през Аргос...
До колкото знам WP също има евенти иначе, какви са тия глупости и защо се пише така код не знам с точност... Аз лично съм иженктирал код на определено място в WP...
Някой може ли да обясни защо се пише код така като този горе в примера на uphero, а не се ползва конкретен евент, за да се извика цялостно css файл ?
И въобще този код горе къде отива ? Печата го във файл или го принтира директно в html-a ? :D хахаха ако е второто е много много зле...
Знаете, че е хубаво да е във файл, защото може да се кешира от браузъра, а ако го принтира в html-a се увеличава обема който трябва да се чете всеки път от браузъра... говорим за сорс кода на страницата в случая...

Мисля, че някой ме питаше защо ползвам str_contains от тук, ползвам го защото имам странициране и понякога имам ?pages като параметър в линка горе и със str_contains засичам само бейс url-то, пък ако има ?page си го чете автоматично... За това го ползвам и си работи ОК. Преди ползвах strpos, но от както str_contains излезе замених всичко с него.
 
Ох, Покчо не се излагай и ти с твоите неща 😂
Това, което ти показваш с нищо не е по-добро от това на WP.

Изсипването на целия CSS в страницата не е толкова лоша практика. Все пак и HTML файла се кешира от клиента, така че няма нищо да сваля докато не му се наложи.

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

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

Не вярвам да са оставили опция само за инлайн.
 
Е, че е по комплексна по-комплексна е :) Аз никога няма да я стигна, а и съм сам...
Само, че и там има евенти и съм сигурен за това, не е ли по-добре да се вкара библиотеката в евент и дотам... +Това файла винаги ти дава възможност във всеки един момент да го отвориш и да мяташ още код вътре...

Все пак и HTML файла се кешира от клиента, така че няма нищо да сваля докато не му се наложи.
Интересно е, ако е страницата без никаква промяна - мога да се съглася, но защо примерно като имам динамично инфо винаги се обновява в реално време ? Тоест, сваля се. А нашите сайтове вече всички са динамични... Статични отдавна мисля, че няма. Достатъчно е според мен да изкараш инфо от date('d.m.y H:i:s') и страницата винаги ще бъде сваляна, тъй като има промяна в нея... (заради секундите/минутите)
По принцип инлайн винаги се добавя като опция в случаите, в които имаш малко стилове за добавяне. Тогава файла става леко безсмислен и е по-лесно да проследиш нещата, когато са на едно място.
Може и да се съглася, и аз имам екстеншън който е вкарал само инлайн, имам евент в head секцията и само пиша <style>code</style> и го мята там.
Тоест, това:
PHP:
$this->dispatcher->emit('core_event_head_append', ['<link rel="stylesheet" href="ext/arenaplay/store/template/css/store.css?v=1">']);
става:
PHP:
$this->dispatcher->emit('core_event_head_append', ['<style>.emojionearea { z-index:9999 }</style>']);
Но пък не е ли лошо ? Смисъл да мешаш css и php... Позволявал съм си да правя този 'инлайн' само с 1-2 реда код... Примера от-горе - имах проблем с emojionearea-та и направих лек hotfix с z-index и вместо да правя файл го направих инлайн както вече споменахте.
Гледам кода на uphero има:
PHP:
'name'         => 'asterisk',
 'label'        => __( 'With asterisk', 'twentytwentyfour' ),
За какво са тези неща ?

Това, което ти правиш може един ден да ти изиграе сериозна шега.

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

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

Също няма да изпратя всичко заедно с <link>. Ако е файл, просто върни пътя до файла. Ядрото трябва да знае как да го зареди.

Какво имаш точно в предвид, за да се подсигуря ? Може би имаш в предвид, че може да се презаместят някакви класове/айдита ли ? Не мисля, че това може да е проблем, защото същото важи и за инлайн-а. Това е код от екстеншън. Не мисля, че може да стане кой знае какъв проблем, стига да си пишеш уникални класове/айдита и да работиш с тях..
Принципно разширението не трябва да знае какви библиотеки са вече заредени. Да речем, че основната част от уеб сайта ти използва bootstrap и jquery. Ако пишеш разширенията с идеята, че тези двете съществуват вече в главната част и ги използваш в разширението, то в момента, в който решиш да ги смениш, ще ти изгърмят всички разширения, които са зависи от двете библиотеки.

От друга страна, ако пишеш разширенията с идеята, че тези двете не са заредени вече, то означава, че разширението ти трябва да ги зареди и ако са различни версии, има вариант да счупиш неща, които не си очаквал.

Колкото за заместване на id-та и класове. Трябва да си сигурен, че всички разширения следват стандарт, който няма да афектира останалите части от системата.

Интересно е, ако е страницата без никаква промяна - мога да се съглася, но защо примерно като имам динамично инфо винаги се обновява в реално време ? Тоест, сваля се. А нашите сайтове вече всички са динамични... Статични отдавна мисля, че няма. Достатъчно е според мен да изкараш инфо от date('d.m.y H:i:s') и страницата винаги ще бъде сваляна, тъй като има промяна в нея... (заради секундите/минутите)
SPA (Single Page Application). HTML-а ти остава статичен.

Като всяко нещо, различните начини са си за конкретни ситуации. Не приемай всичко за чиста монета и да заключваш мозъка си само в една насока. Трябва да обмисляш кой вариант може да е по-добър за твоя случай.
Ако ползваш HTTP 2+, то тогава зареждане на много файлове е по-добре, защото протокола не е фен на големите файлове. Докато HTTP 1.1 протокола има по-слаба паралелност и обработва по-големи файлове по-лесно.

Като цяло оптимизации се правят, когато се види, че има проблем някъде. Не отделяй прекалено много време още в началото да го мислиш, без да си сигурен дали ще е проблем или не.
 
Ok,благодаря за разясненията.
 

Back
Горе