What we want to achieve is to "force" refreshing of style.css of our template after changes.
Usually this is made by adding template version number as a parameter of the stylesheet, so in the HEAD section the output looks something like this:
If we change 1.0.1 to 1.0.2 browsers should download the new version. Now we want to make it simple, and there is a version parameter already present in any Wordpress theme's style.css in its header part, so why not use that? Logically if we make changes in the stylesheet, we should also increment its version number.
To get the stylesheet HTML output as mentioned above, modify enqueuing of the stylesheet in functions.php like this:
Be aware that you shouldn't have style.css inserted into Wordpress output in any other way. Sometimes it can be "hardcoded" in head.php or other template files.. Check the output HTML if it contains only one line of style.css link tag and that it is the one with the version number...
Zobrazují se příspěvky se štítkemwordpress. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemwordpress. Zobrazit všechny příspěvky
úterý 12. února 2019
pondělí 15. května 2017
Pass values from shortcode in Contact Form 7
I'm releasing this article because it took me a few hours to find the solution, though it is very simple. The internet is full of references to Contact Form 7 Dynamic Text Extension plugin, which is not necessary, in fact I wasn't able to achieve what I wanted with it and pure CF7 plugin was enough.
The task was to pass the values from the Wordpress template script to Contact Form 7 form. PHP template script creates the correct Contact Form 7 shortcode with generated values and the result is form with pre filled fields with these values. In my case I then used CSS styling to make the fields look like regular text, as Contact Form 7 has no function to simply output the values without creating the form fields (AFAIK).
In the Wordpress Contact Form 7 admin - create a form and add fields like this (I'm adding more then one as an example). The default:shortcode_attr parameter means that the prefilled value is expected to be passed from the shortcode. You have also other options, which can be multiple and are processed one after another until the value is passed (see this for details). I'm also adding readonly parameter as I will use the value as regular text, not real input field.
In Wordpress template I generate the form:
And to be able to pass the values to these custom variables, also this piece of code has to be added to your Wordpress template's functions.php file. You need to change the names of the fields to match both form in admin and shortcode in template script:
The resulting CF7 form will have two fields (here field-one and field-two) pre populated with the text "This can be dynamic" and "This can be also dynamic".
The task was to pass the values from the Wordpress template script to Contact Form 7 form. PHP template script creates the correct Contact Form 7 shortcode with generated values and the result is form with pre filled fields with these values. In my case I then used CSS styling to make the fields look like regular text, as Contact Form 7 has no function to simply output the values without creating the form fields (AFAIK).
In the Wordpress Contact Form 7 admin - create a form and add fields like this (I'm adding more then one as an example). The default:shortcode_attr parameter means that the prefilled value is expected to be passed from the shortcode. You have also other options, which can be multiple and are processed one after another until the value is passed (see this for details). I'm also adding readonly parameter as I will use the value as regular text, not real input field.
In Wordpress template I generate the form:
And to be able to pass the values to these custom variables, also this piece of code has to be added to your Wordpress template's functions.php file. You need to change the names of the fields to match both form in admin and shortcode in template script:
The resulting CF7 form will have two fields (here field-one and field-two) pre populated with the text "This can be dynamic" and "This can be also dynamic".
úterý 25. prosince 2012
Vývoj Wordpress pluginu s použitím Custom Post Types
Zadáním nedávno spuštěného Wordpress pluginu pro zákazníka bylo vytvořit systém dokumentů, ke kterým je omezen přístup a mají specifickou strukturu. Nebudu popisovat celý vývoj, ale vzhledem k tomu, že v rámci daného řešení bylo nutno sáhnout po pokročilejších záležitostech jako custom post type, custom taxonomy, custom roles, nastavení capabilities atd. popíšu alespoň tyto netriviální věci.
Na konci uvádím i tipy na nástroje, frameworky a odkazy, na které jsem narazil v průběhu vývoje a buď mi pomohly, nebo bych je nejspíš použil při podobné budoucí záležitosti.
Nebudu se rozepisovat o detailech, bez reference v podobě Wordpress codexu (dále jen Codex) se určitě neobejdete.
http://codex.wordpress.org/
Na míru definovaný typ “dokumentu” Wordpressu s požadovanými položkami. Položky můžou být buď klasické jako známe z klasických článků a příspěvků - tzn textové políčko (v administraci jako input), pole pro větší text (textarea), ale i vyloženě custom záležitosti (color picker apod).
Ke kompletnímu vysvětlení odkazuju na Codex, jde o obecnou definici nového typu, definujeme jeho název, který je jeho identifikátorem v systému, popisky “labels”, chování v systému.
V ukázce kódu je zahrnuta i další záležitost:
Vzhledem k tomu, že nám v tomto projektu nevyhovuje využití defaultních práv k postům Wordpressu (tedy je nutno oddělit psaní klasických článků a vytváření těchto dokumentů), musíme si nadefinovat názvy speciálních práv k tomuto Post Typu a napojit je na defaultní práva, aby systém věděl, co znamenají. Custom capabilities mají název podle defaultního práva pro “post”, jen místo tohoto slova vkládáme název právě našeho Post Typu. V příkladu výše “muj_document” resp “muj_documents” - toto je potřeba odlišovat dle původního vzoru.
Opět nám nevyhovuje klasické rozřazení Wordpress uživatelů (Administrator, Šéfredaktor, Redaktor atd..), ale chceme uživatelům přiřazovat speciální role, které mají námi definovaná práva.
V prvním řádku jsme přidali do systému novou uživatelskou roli, níže pak přidáváme práva pro manipulaci s našili dokumenty (capabilities), viz výše, pro jistotu můžeme i některé capability odebrat..
Tento kus kódu je vhodné vložit do bloku instalace pluginu, aby se nespouštěl pokaždé. Tzn ho vložíme např. do funkce muj_activate(), kterou pak voláme následujícím způsobem.
Jak jsem uvedl výše, jednou ze zásadních věcí je, že jsme schopni si nadefinovat svou strukturu dokumentu, tedy nemusí jít o klasiku v podobě názvu, úvodu, textu, kategorie a štítku, ale lze vše změnit. Kód níže zavádí nové pole Vydavatel, které funguje na principu číselníku (tzn. vlastně upravená verze štítku). Zde opět navazujeme capabilities na námi definované výše.
Pro editaci v administraci je nutné nadefinovat si ovládací prvky. Můžete opět postupovat ručně, dle Codexu. Já našel a použil framework, který ulehčuje velké množství práce.
https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress
Pro představu doporučuju prezentaci autorů zde:
http://wordpress.tv/2012/09/04/steve-bruner-and-kevin-miller-building-powerful-websites-and-web-applications-with-piklist/
Web projektu: http://piklist.com/
Obecně velký zdroj všeho kolem těchto rozšíření Wordpressu a customizace je na blogu Justina Tadlocka, takže při studiu určitě chtě nechtě zabrousíte na http://justintadlock.com/.
Pro kontrolu nastavení práv jsem používal Justinův plugin Members. http://wordpress.org/extend/plugins/members/
Na konci uvádím i tipy na nástroje, frameworky a odkazy, na které jsem narazil v průběhu vývoje a buď mi pomohly, nebo bych je nejspíš použil při podobné budoucí záležitosti.
Nebudu se rozepisovat o detailech, bez reference v podobě Wordpress codexu (dále jen Codex) se určitě neobejdete.
http://codex.wordpress.org/
Custom Post Type
http://codex.wordpress.org/Post_TypesNa míru definovaný typ “dokumentu” Wordpressu s požadovanými položkami. Položky můžou být buď klasické jako známe z klasických článků a příspěvků - tzn textové políčko (v administraci jako input), pole pro větší text (textarea), ale i vyloženě custom záležitosti (color picker apod).
Ke kompletnímu vysvětlení odkazuju na Codex, jde o obecnou definici nového typu, definujeme jeho název, který je jeho identifikátorem v systému, popisky “labels”, chování v systému.
V ukázce kódu je zahrnuta i další záležitost:
Custom capabilities
http://codex.wordpress.org/Function_Reference/register_post_typeVzhledem k tomu, že nám v tomto projektu nevyhovuje využití defaultních práv k postům Wordpressu (tedy je nutno oddělit psaní klasických článků a vytváření těchto dokumentů), musíme si nadefinovat názvy speciálních práv k tomuto Post Typu a napojit je na defaultní práva, aby systém věděl, co znamenají. Custom capabilities mají název podle defaultního práva pro “post”, jen místo tohoto slova vkládáme název právě našeho Post Typu. V příkladu výše “muj_document” resp “muj_documents” - toto je potřeba odlišovat dle původního vzoru.
Custom Roles
http://codex.wordpress.org/Function_Reference/add_capOpět nám nevyhovuje klasické rozřazení Wordpress uživatelů (Administrator, Šéfredaktor, Redaktor atd..), ale chceme uživatelům přiřazovat speciální role, které mají námi definovaná práva.
V prvním řádku jsme přidali do systému novou uživatelskou roli, níže pak přidáváme práva pro manipulaci s našili dokumenty (capabilities), viz výše, pro jistotu můžeme i některé capability odebrat..
Tento kus kódu je vhodné vložit do bloku instalace pluginu, aby se nespouštěl pokaždé. Tzn ho vložíme např. do funkce muj_activate(), kterou pak voláme následujícím způsobem.
Custom Taxonomy
http://codex.wordpress.org/Function_Reference/register_taxonomyJak jsem uvedl výše, jednou ze zásadních věcí je, že jsme schopni si nadefinovat svou strukturu dokumentu, tedy nemusí jít o klasiku v podobě názvu, úvodu, textu, kategorie a štítku, ale lze vše změnit. Kód níže zavádí nové pole Vydavatel, které funguje na principu číselníku (tzn. vlastně upravená verze štítku). Zde opět navazujeme capabilities na námi definované výše.
Custom Meta Boxes
http://codex.wordpress.org/Function_Reference/add_meta_boxPro editaci v administraci je nutné nadefinovat si ovládací prvky. Můžete opět postupovat ručně, dle Codexu. Já našel a použil framework, který ulehčuje velké množství práce.
https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress
Tipy
Téměř ke konci vývoje jsem narazil na Piklist, který mohl celý vývoj dost zásadně ulehčit, bohužel v dané fázi už to nemělo cenu, ale doporučuju zvážit. Framework se zdá dostatečně flexibilní a umí jednoduše nadefinovat vše, co jsem popsal výše a vyvíjel jsem “ručně”.Pro představu doporučuju prezentaci autorů zde:
http://wordpress.tv/2012/09/04/steve-bruner-and-kevin-miller-building-powerful-websites-and-web-applications-with-piklist/
Web projektu: http://piklist.com/
Obecně velký zdroj všeho kolem těchto rozšíření Wordpressu a customizace je na blogu Justina Tadlocka, takže při studiu určitě chtě nechtě zabrousíte na http://justintadlock.com/.
Pro kontrolu nastavení práv jsem používal Justinův plugin Members. http://wordpress.org/extend/plugins/members/
Přihlásit se k odběru:
Příspěvky (Atom)