Zvolené téma obsahuje celkem 9 odpovědí. Do diskuze (3 účastníci) se naposledy zapojil uživatel 
-
Příspěvky
-
Dobrý den,
lze nějak upravit automatické vkládání videí přes oEmbed? Třeba změnit vzhled youtube přehrávače na theme=light – obecně přidat další parametry, které nejsou pevně dané funkcí.
Momentálně používám Smart Youtube PRO, ale třeba by to šlo i bez něj.
Děkuji za rady.
Určitě dá třeba pomocí Youtube API. Ale musí se to samozřejmě naprogramovat pro WordPress. Tedy v šabloně vytvořit funkci, která přidá filtr (add_filter) na “the_content” (obsah článku), který třeba přes PHP funkci preg_match najde a “rozebere” HTML kód videa a doplní do něj (případně změní) potřebné parametry například pro změnu barvy přehrávače.
Teď nevím co přesně se bude měnit, jestli vožený odkaz? Nebo už wordpressem vložený iframe a v něm budu měnit parametry odkazu? V prvním případě WP parametry asi ignoruje, protože to nefunguje… Tak jsem si asi odpověděl sám :-)
Teď teda předpokládám, že oEmbed fukce bude probíhat dřív než filtr…
Filtr se aplikuje až na výsledný HTML kód stránky (článku) tedy až potom co si WordPress převede vložený odkaz na HTML kód.
Filtr tedy vytáhne hodnotu z atributu “src” což bude URL adresa videa a doplní do ní parametr “theme=light” třeba. Ve výsledku bude přehrávač bílý.
Případně může filtr vytáhnout pouze url adresu a celý HTML kód pro zobrazení videa změnit z embed na iframe nebo i na video tag z HTML5 a opět do něj vložit původní URL adresu doplněnou třeba o další parametry z API. Dá se s tím dělat prostě cokoliv…
Dobře no tak mi to prostě nedalo…
1) vložil jsem do příspěvku video klasicky a asi nejjednodušeji jak to jen jde – vložením URL adresy k videu.
2) V příspěvku se zobrazeným videem jsem si zobrazil zdrojový kód stránky abych věděl co mám nahradit nebo změnit a co nevidím – WP automaticky přidá k URL adrese řetězec “feature=oembed”. A protože u práce přemýšlím a nemám čas řešit voloviny s preg_match nebo s preg_replace, jednoduše vytvořím filtr který za “feature=oembed” doplní další parametry dle mé fantazie.
Upravený přehrávač, který se líbí třeba mi, docílíme vložením této funkce do souboru “functions.php” šablony vzhledu.
add_filter('the_content', 'WhiteYT');
function WhiteYT($content){
return str_replace('feature=oembed', 'feature=oembed&fs=1&rel=0&showinfo=0&theme=light', $content);;
}
fs=1 zajistí, že v přehrávači bude tlačítko pro fullscreen
rel=0 je vypnutí podobných videí
showinfo=0 je vypnutí zobrazení informací
theme=light je hezká světlá barva
Skvělé, jednoduché, moc děkuji.
Mně by to trvalo určitě déle…
Je to přesně tak, jak píše Lukenzi, ale je tam ještě jedna vychytávka :-)
Filtr
the_contentse spouští při každém zobrazení stránky, což je trochu zbytečně náročný proces. Mnohem jednodušším způsobem je upravit zmiňované parametry už v dotazu na oEmbed kód. Zadáte do textu URL videa, WordPress ji najde a dotáže se na příslušný oEmbed kód, který si pak myslím uloží do nějakého uživatelského pole, aby ho nemusel pokaždé zjišťovat znovu. A v této chvíli stačí použít filtrembed_oembed_html(nebo případněoembed_result), který vrátí už upravený kód a nemusíte ho tak při každém zobrazení stránky/příspěvku znovu kontrolovat a nahrazovat…Podobný příklad jsme konkrétně řešili zde.
Jinak plugin Smart YouTube je asi také vcelku dobrá volba.
Zkoušeno na localhostu, klasický web (5 článku na úvodu):
Spotřeba paměti navíc: 856b
Čas provádění navíc : 0.000041007 vteřin
Myslím, že v tomto případě je otázka výkonu úplně irevelantní… Pokud by se vám to i přesto zdalo hodně lze odkaz upravit pomocí javascriptu přímo na straně klienta (tedy v prohlížeči) – výkonové ztráty serveru by pak byly naprosto nulové (stejně tak se v některých pluginech přidává například atribut “nofollow” odkazům nebo atribut “lightbox” obrázkům).
Toto řešení bych nezdůvodňoval výkonem. V praxi mezi nimi není žádný rozdíl (mezi adminovým a mým řešení je rozdíl prakticky nulový, pár bitů a u času to nemá cenu ani psát). Mimochodem filtr the_content je paměově méně náročnější než embed_oembed_html (cca 500 bitů).
Zajímavé, díky za test, Lukenzi. Ano, v tomto případě je rozdíl opravdu nepatrný, je tam de facto jen jedna funkce str_replace() navíc. Problém ale nastává v případě, kdy filtr
the_contentvyužívá každý druhý plugin a ještě k tomu používá různé zběsilé funkce. Vše se potom kumuluje. Teoreticky by při použití 3 stejných funkcí napojených na tento filtr měla být spotřeba paměti nikoli trojnásobná, ale ještě trochu vyšší. Bylo by to zajímavé otestovat :-) Šlo mi tedy spíše o princip “řešit problémy co nejdříve a s minimem prostředků”, respektive je to trochu “postižení” z optimalizace webů, které mají návštěvnost v desítkách tisíc uživatelů :-)Takže filtr
embed_oembed_htmlmá spotřebu 500 bitů nebo o 500 bitů více nežthe_content? Teoreticky by měl být ale spouštěn pouze jednou za čas (12 hodin?) a nikoli při každém načtení stránky jakothe_content.Mě ty výsledky taky překvapili, popravdě jsem to ani netušil jen mě to po tvém postu nějak začlo zajímat tak jsem si to vyzkoušel.
Filtr the_content spotřeboval 856b a filtry embed_oembed_html a oembed_result něco přes 1.3kb což bylo zajímavé a ještě zajímavější bylo, že všechny filtry se spouštěli (respektive “užírali” stejné množství paměti navíc) také pokaždé bez ohledu na to jakou jsem měl zobrazenou stránku.
Myslím, že filtry jsou vývojáři navržené velice dobře, nefungují totiž tak, že když spustím 10x filtr the_content, že se znovu 10x získává obsah všech zobrazených článků (respektive počet použitých funkcí the_content v šabloně) nebo, že se 10x na tento obsah použije samotný filtr.
Funguje přesně opačně, tedy prvně se získá obsah článků, uloží se do nějaké proměnné a až poté se na tuto proměnnou použijí vlastní funkce vložené do všech filtrů – filtr se tedy provede ve skutečnosti jen jednou. Jediná režie navíc je tedy ta z naších vlastních funkcí a ta z interních funkcí PHP (která je ale většinou minimální nebo žádná). Pokud tedy ve všech vlastních funkcích vložených do filtru správně ošetříme uvolňování paměti např. pomocí unset(), kdy zahodíme obsahy nepotřebných porměnných bude výsledná režie naprosto minimální i kdyby těch filtrů bylo 1000 (ve skutečnosti se pouze vlastní funkce v tomto filtru “střádají” a až těsně před zobrazením obsahu se použijí jedna po druhé na obsah uložený v jediné proměnné).
Zkusím si s tím pohrát a dám sem nějaké výsledky konkrétních testů, jestli je má teorie správná tak použití 1000 filtrů na the_content by nemělo mít skoro žádný vliv na paměť, samozřejmě pokud svou vlastní funkci použitou v tomto filtru napíšu maximálně úsporně.
Jinak stačí se podívat do některých systémových souborů WP a uvidíme, že snad v každém systémovém souboru je funkce, která používá nějaký filtr na jinou systémovou funkci a nebál bych se tvrdit, že takových filtrů jsou v jádru možná i stovky…
Pokud chcete odpovědět na toto téma, musíte se nejdříve přihlásit.