Otto op WordPress

Otto op WordPress alleen voor de afgifte van

Al een tijdje geleden dat ik iets geschreven. Laten we praten over een aantal van de nieuwe dingen in de Customizer.

Vergeet over een aantal van deel twee

In de eerste plaats terug in het tweede deel. Ik had een beetje over Surfacing de Customizer. Dat beetje is nu achterhaald, WordPress doet dit voor u in latere versies. Dus ja, sla die.

Glanzende nieuwe ding: Panelen

Oke, dus panelen zijn niet zo nieuw. Ze werden in WordPress 4.0 toegevoegd. In principe zijn ze glijden containers voor secties. Ondervindt u problemen bij het aanbrengen van alle instellingen op het scherm? Groep de verschillende secties tot panelen. Panelen tonen als een item in de hoofdlijst en wanneer u op de pijl naast hen, glijdt de hele lijst buiten het scherm om alleen die secties tonen.


Zo, nu hebben we vier dingen: Panelen, afdelingen, Controls en Instellingen.

  • Panelen Groep Secties samen
  • Secties bevatten Controls
  • De controles zijn wat de gebruiker veranderingen
  • Instellingen bepalen wat de Controls veranderen

Het creëren van een panel is eenvoudig:

een sectie die panel toe te voegen is net zo eenvoudig:

Alles wat nieuw is, is een paneel instellen naar de sectie in die panel te gaan vertellen. Eenvoudig.

Active Callbacks

Een van de problemen met de Customizer was dat het weergegeven instellingen en liet ze veranderen op de site naar rechts, maar de site wordt weergegeven is de eigenlijke site. Wat betekent dat u kunt navigeren op. Soms is de besturing wordt getoond niet noodzakelijk van toepassing op de eigenlijke site die je ziet.

Voorbeeld: Als u een controle om de kleur van iets in de sidebar te wijzigen, maar dan op zoek bent naar een pagina waarop geen zijbalk heeft, dan heb je geen visuele feedback om u te vertellen wat de verandering eruit ziet.

Om dit op te lossen, "actief callbacks" worden gebruikt.

De active_callback is gewoon een nieuwe parameter die u kan overgaan in Panels, afdelingen of Controls. Het kan de naam van een functie bevatten, en die functie zal worden opgeroepen wanneer de pagina verandert. De functie moet waar of onwaar (of gelijkwaardig) weer te geven of het element van de aanpasser worden getoond dat pagina.

Dus, als je een hele panel dat alleen zin wanneer de gebruiker is op zoek naar de voorpagina van de site (en niet een individuele post) te maken, dan kunt u dit doen:

En voila, wanneer de gebruiker niet is te kijken naar de voorpagina, het paneel gewoon verdwijnt.

U kunt elk van de normale WordPress Template Tags gebruiken voor deze, of schrijf uw eigen functie als u meer specifiek over het te zijn.

Bewerk: Zoals in de reacties, dit zal niet werken met alle Template Tags. Met name zal is_single niet werken als gevolg van de optionele parameter kan nemen. Vind wrapper definiëren voor deze alternatieven hiervoor, om hetzelfde effect te krijgen. Voorbeeld:

Plezier met Active Callbacks

Als u nodig hebt om je eigen callback functie te schrijven, er rekening mee dat de functie ontvangt het object in kwestie wanneer het heet. Dus, als je een active_callback hechten aan een panel, uw functie zal een argument van de WP_Customize_Panel object in kwestie geslaagd om het te krijgen. Secties krijgen WP_Customize_Section en dergelijke. U kunt de informatie in deze om te beslissen of het paneel (of wat dan ook) getoond moeten worden voor die pagina.

Dus, hoe kunnen we dat object gebruiken? Nou, je kunt dit gebruiken om te maken of bepaalde controles te tonen of niet afhankelijk is van de waarden van andere instellingen. Alle verschillende items die u kunt dit gebruiken op een link terug naar de belangrijkste WP_Customize_Manager. Die klasse heeft een get_setting functie, die u kunt gebruiken om te bepalen wat te doen.

Dus, laten we een controle die andere controles te verschijnen, afhankelijk van een instelling leidt.

Ten eerste, laten we een eenvoudige radio selectie control:

Nu moeten we twee andere bedieningsorganen, één voor elke keuze. Je kunt eigenlijk zoveel als je wilt maken, zullen we het simpel houden.

Ten eerste, de controle voor de keuze A. Laten we het een eenvoudige tekst controle.

We zullen dat callback functie nodig hebben om te detecteren of de keuze A is geselecteerd in de afstandsbediening, en de return true als het is, anders false. Als volgt:

Je kan vereenvoudigen dat als je wilt, ik verwoord het uit met een if-statement om zo duidelijk wat er gebeurt.

Nu voor de keuze B, laten we het een kleurbeheer weer te geven in plaats daarvan:

En zijn callback:

Dus in plaats van het gebruik van twee verschillende callbacks, we wijzen onze controles om deze callback, die berekent wat moet komen opdagen voor welke instelling. Ik weet zeker dat je kunt dit verder te vereenvoudigen, afhankelijk van uw specifieke behoeften.

Nog één ding: de Customizer aanpassen

Niet iedereen houdt van de stijl van de Customizer. Misschien is het botst met uw thema. Misschien wilt u gewoon om het te tweaken een beetje. Misschien een hekel je dat grijze achtergrond kleur en een meer rustgevende blauw zou beter zijn voor uw thema te gaan.

Of misschien denk je niet dat het Customizer gebied is breed genoeg … wees voorzichtig met dit één hoewel, overwegen mobiele gebruikers ook.

U kunt de wachtrij hele extra CSS-bestanden in plaats daarvan, als je wilt. Of, als u speciale wensen voor javascript in een aantal van uw controles, en er is bibliotheken die nodig zijn om ze uit te voeren, dan kunt u deze bibliotheken de wachtrij hier ook.

Een van de beter om kwetsbaarheden te begrijpen is het CSRF. Het is ook een van de meest voorkomende problemen die we zien in plugins en thema’s, omdat mensen zelden over nadenken.

Stel je voor dat ik een vorm die input neemt, als volgt:

Nu, dat is een eenvoudige vorm (en het missen van een submit knop op te starten), maar je krijgt het idee. Het duurt een tekstinvoer. Vermoedelijk is er iets aan de andere kant (bij /example.php) processen die ingang, slaat deze op in een database, zoiets. Gemakkelijk.

Eerste vraag: Is dat nodig?

Wat je nodig hebt om te begrijpen is het verschil tussen de "autoriteit " en "aandachtig ".

Autoriteit

Er zijn verschillende manieren om dit te doen, kunnen we de CURRENT_USER informatie te controleren. WordPress heeft capaciteit controles voor gebruikers om te weten wat ze wel en niet mogen doen. Wanneer we deze te controleren, zijn we het verifiëren autoriteit. Ervoor zorgen dat de gebruiker is toegestaan ​​om deze dingen te doen.

Maar iets anders dat we moeten controleren die de meeste mensen denken niet na over is aandachtig. Heeft de gebruiker daadwerkelijk van plan om dat formulier, of niet hun browser legt dit voor hen automatisch, wellicht zonder hun medeweten?

Onderzoeken die vorm weer, en nadenken over wat er zou gebeuren als je naar een webpagina te bezoeken, ergens op het internet, dat bevat het volgende:

Nu, zou je kunnen denken dat dit een nogal gekunsteld voorbeeld, en je hebt gelijk op dat punt zou zijn, maar het dient om het punt aan te tonen. Uw browser laadt deze URL en dat is het equivalent actie om het indienen van die vorm, met "pwned" aangezien de tekst in kwestie.

Hier is de kicker, al die autoriteit controles te doen ons geen goed bij het voorkomen dit. Je doet eigenlijk hebben de bevoegdheid om die vorm, en uw browser in te dienen, met behulp van uw gezag, maar het voor u voorgelegd. Pwned, inderdaad.

(Voor degenen onder u denken "gewoon gebruik maken van POST formulieren", Van mening dat javascript POST formulieren kunt indienen. Dus dat is echt geen hulp.)

aandachtig

Wat we nodig hebben is aan opzet te controleren. We moeten weten dat de gebruiker die vorm ingediend, en niet alleen de browser doet het voor hen automatisch.

WordPress gebruikt om deze (een looong tijd geleden) doen met behulp van de referer. Voor degenen die niet weten, referer is een URL doorgegeven door uw browser om aan te geven waar een gebruiker vandaan kwam. Zo kan men controleren of de referer zegt dat de vorm van de pagina van het formulier en niet van een andere pagina op het internet werd ingediend. Het probleem is dat referer niet betrouwbaar. Sommige browsers hebben de mogelijkheid voor het script om nep de referer. Firewalls en proxies vaak strip de referer uit, voor de persoonlijke levenssfeer. Enzovoorts.

nonces

WordPress nu doet dit met behulp van nonces. Een nonce is een "aantal keer gebruikt" in zijn puurste vorm. Kortom, het is een eenmalig wachtwoord. Wanneer we de vorm genereren genereren wij een nummer. Wanneer het formulier wordt ingediend, controleren we het nummer. Als het nummer verkeerd of ontbreekt, staan ​​we niet toe het formulier in te dienen. Een script kan het aantal van tevoren niet weten. Andere sites kunnen het nummer niet raden.

Nu, technisch gezien, WordPress maakt geen gebruik van echte nonces, omdat ze niet "een keer gebruikt". In plaats daarvan, WordPress nonces draaien op een 12 uur draaiende systeem (waar 24 uur worden geaccepteerd). Voor een bepaalde periode 12 uur, wordt het nonce nummer voor een bepaalde actie hetzelfde. Maar het is dichtbij genoeg om een ​​echte nonce om het probleem te elimineren, maar met name het is alleen voor de kwestie van het verifiëren van opzet. Probeer niet om WordPress nonces gebruiken voor iets anders.

Dus, wanneer we een vorm genereren genereren wij een nonce. Dit nonce is gebaseerd op vijf dingen: site, de gebruiker, de tijd, de actie wordt uitgevoerd, en het object dat de actie wordt uitgevoerd op. Het veranderen van een van deze geeft ons een ander nonce.

Laten we zeggen dat ik wil een bericht te verwijderen. Om dat te doen, moet ik de nonce weten voor het verwijderen van die specifieke post, als ik, op mijn site, in de laatste 24 uur. Zonder die nonce, kan ik niet de actie uit te voeren. Belangrijker, zodat iemand "truc" mijn browser erin te doen voor mij, moeten ze die specifieke nonce en krijgen mijn browser om het binnen 24 uur te laden. Stoer te doen. En zelfs als ze trekken het uit, ze alleen in staat geweest om dat zeer specifieke actie uit te voeren zijn, de verkregen nonce is nutteloos voor andere doeleinden. Ze hebben geen enkele vorm van de volledige controle te krijgen via deze manier. Ze kunnen niet om mijn browser iets op mijnsite dat ze niet de nonce te laten doen.

Met behulp van nonces

Dus, laten we aan de slag om spijkers met koppen slaan. Het genereren van een nonce in WordPress is eenvoudig en kan op veel verschillende manieren worden gedaan, afhankelijk van uw specifieke behoeften. Wilt u misschien een eenvoudige koppeling te beschermen, of wilt u misschien een vorm te beschermen, of je zou zelfs nodig om een ​​javascript ajax call te beschermen.

link beschermende kan met wp_nonce_url (). Het duurt een URL en een actie en voegt een geldige nonce op die URL. Het werkt als volgt:

Hier nemen we een aantal URL, en het toevoegen van een nonce op het voor een specifieke werking op een aantal specifieke object. Dit is belangrijk, moeten maatregelen en voorwerpen zowel worden opgegeven als er een object wordt genoemd. Een voorbeeld hiervan is een link naar een bepaald bericht te verwijderen zijn. Een dergelijke code zou er als volgt uitzien:

De actie is "trash-bericht" en de post wordt vernield heeft haar ID-nummer toegevoegd aan die actie. Zo zal de nonce laat je die post en alleen dat na de prullenbak.

Anderzijds, misschien hebben we een vorm die we nodig hebben om plaats te beschermen. Binnen die vorm, kunnen we iets toevoegen, zoals deze:

Dit is de nonce voor het verwijderen van een reactie. Het voert een paar velden, als volgt:

De waarde voor de nonce zullen specifieke schrappen die opmerking, op die plaats, door die gebruiker.

Soms moeten we gewoon de nonce direct te genereren, in geen specifiek formaat. Één geval zou kunnen zijn voor een AJAX soort oproep, waar de gegevens door jQuery worden ingediend. In een dergelijk geval kunt u de wp_create_nonce functie gebruiken om dat te nonce waarde te krijgen, als volgt:

Voor AJAX aanvragen, wil je dat nonce waarde in de ingediende gegevens omvatten met een naam van "_ajax_nonce". Waarom dat bepaalde naam? Want het is wat controles WordPress bij het verifiëren van de nonce. Spreken van verificatie:

Het verifiëren van nonces

Het genereren van deze cijfers is niet goed als je ze niet te controleren ook. Gelukkig, WordPress maakt dit eenvoudig. Er zijn twee functies om inkomende nonces controleren.

De naam van de functie verwijst naar de tijd voordat nonces, wanneer deze functie oproep van de referer waarde uit de browser controleerde. Tegenwoordig controleert nonces plaats. Als de _wpnonce teruggestuurd in de vorm hier niet overeen met de actie en ID, dan is deze functie stopt verdere verwerking. Dit is de oorzaak van de "Weet je zeker dat je dit wilt doen?" screen die soms door de gebruikers wordt gerapporteerd. Om te voorkomen dat dit scherm de nonce gecontroleerd heeft te evenaren.

Een alternatief voor het controleren van formulieren of koppelingen controleert ajax verzoeken, dat is waarom we hebben deze functie:

Dit voert dezelfde fundamentele controle, maar als het niet lukt, geeft een eenvoudige "-1" respons en daarna stopt de verwerking. Uw AJAX javascript code kan die reactie herkennen en passende maatregelen op basis van het te nemen.

In beide gevallen, als de nonce mislukt, het script eindigt. Geen actie wordt ondernomen. Het formulier wordt niet verwerkt, de post niet verwijderd. Dat is het soort check je nodig hebt om CSRF aanvallen te voorkomen.

bottom Line

Als u een plug-in of een thema of een soort code die "doet iets" in WordPress, dan moet je die actie met een nonce te beschermen. Als je het niet bent beschermen met een nonce, dan is het mogelijk dat iemand anders in uw browser te verleiden tot het uitvoeren van die actie op uw rekening.

Merk ook op dat het niet genoeg om alleen de naam van de actie. U over het algemeen het nemen van maatregelen op een aantal specifieke "ding", En de ID van dat ding moet worden opgenomen in uw nonce ook. Hoe specifieker de actie, hoe beter.

Iedere vorm, elke handeling, ongeacht hoeveel "authenticatie" je hebt op het controleren van het, kan worden benut, omdat je niet echt de authenticatie van de "gebruiker"Je bent het authenticeren dat het vandaan komt "browser van de gebruiker". Je moet iets anders dat regelmatig wordt aangepast, zodat u kunt controleren of de gebruiker inderdaad dat bepaalde vorm heeft laden en legt dit vrij recent, en dus waarschijnlijk bedoeld om die actie uit te voeren.

Nonces zijn eenvoudig te implementeren. Dus doe het al. We hebben genoeg plugins het niet te doen, dat dit duidelijk moet worden gezegd.

We krijgen veel van de inzendingen aan de WordPress.org plugin repository. en zo is er vaak veel gevaarlijke code ingediend. Meestal is dit niet kwaadaardig is, het is gewoon door mensen die eerlijk gezegd niet weten dat hun code heeft problemen. Het begrijpen van deze problemen is de eerste stap op weg naar de vaststelling van hen.

Dus hier is een gemeenschappelijke kwetsbaarheid zien we in de code inzendingen veel: SQL Injection

Om SQL Injection te begrijpen, laten we citeren Wikipedia voor een moment:

SQL-injectie is een code-injectie techniek gebruikt om data gedreven applicaties, waarbij kwaadaardige SQL-statements in een invoerveld voor de uitvoering worden ingevoegd te vallen

Hier is een stukje code gemaakt voor WordPress, die is het bevragen van de database voor een post:

Als u het probleem met deze code niet meteen ziet, dan moet u lezen van dit bericht voort te zetten.

(Ja, dit artikel toont de basisprincipes van de functie voor te bereiden (). Als u al weet over de functie voor te bereiden (), zou je geschokt door het aantal mensen die dat niet doen.)

Om het meest effectief te gebruiken, is er een paar basisregels die u, als een plugin of thema auteur, moet volgen. Gelukkig, ze zijn vrij eenvoudig.

Text-domeinen = de plugin / thema slug

In de eerste plaats, voor de taalpakketten te werken, uw tekst-domein moet identiek zijn aan de plugin of slak thema’s zijn.

Wat is een "naaktslak"? Goede vraag. Als u de URL van uw plugin of thema op WordPress.org onderzoeken, zult u merken dat het ziet er als volgt uit:

Dat "some-text-hier" deel is de slak. Het kan niet worden gewijzigd door de plugin of thema auteur zodra de ingang wordt gecreëerd voor het in de WordPress.org directory. Het is een unieke Item aan plugins / thema’s, en dat is hoe WordPress.org wordt het beheer en het benoemen van de taalbestanden.

Daarom is uw "text-domein" moet zijn dezelfde als die slug. In al uw vertaalfunctie gesprekken, moet de tekst-domein er zijn, het moet een gewone tekenreeks zijn, en het moet identiek zijn aan de slak van uw plugin of thema op WordPress.org zijn.

headers

Voor de vertaling naar het meest effectief voor uw plugin / thema te zijn, moet je een header in het dat u niet kan worden, waaronder onder meer:

Deze "text Domain" header wordt gelezen en gebruikt om uw taalpakket bestanden, zelfs laden als je plugin niet is geactiveerd. Hierdoor kan de headers van de plug-in (zoals de beschrijving en dergelijke) te vertalen naar behoren wanneer de plug-in op het scherm Plugins / Thema’s wordt weergegeven. Dus uw internationale gebruikers in staat zal zijn om die tekst te lezen, voordat ze het ooit met behulp van de code.

Als u wilt uw eigen vertaling bestanden in plaats van het gebruik van het taalpakket systeem op te nemen, dan is dit nog steeds werkt. De core code gaat op zoek naar de desbetreffende * .mo vertaling bestanden in de map van de plugin. Als u een subdirectory, zoals gebruikt "/ talen", Dan kunt u een kop als het volgende te gebruiken:

Merk op dat de Domain Pad voor plugins standaard de plugin eigen root directory, maar het Domain pad voor thema standaard "/ talen" beginnen met. Als de standaard voor u werkt, dan heb je niet nodig om deze header at all.

Merk ook op dat als een taal bestand niet is gevonden voor een bepaalde configuratie, dan is WordPress 3.7 zal terugvallen naar het gebruik van het taalpakket systeem om te proberen om het te vinden. Dus als je alleen bestaan, laten we zeggen, 3 talen, en er zijn taalpakketten voor 4, dan zijn die 4 zal nog steeds werken.

Spreken van de configuratie,

Functie oproepen: load_plugin_textdomain of load_theme_textdomain

Hier is hoe ze goed te bellen met de headers die je nodig hebt opgenomen voor een goede maatregel:

Als u wilt toestaan ​​voor de vertaling MO bestanden in eigen map van de plugin:

Als u wilt toestaan ​​voor de vertaling MO bestanden in talen subdirectory de plugin:

Wilt u taalpakketten uitsluitend te gebruiken (noot: WP zal nog steeds controleren de basis / wp-content / plugins map voor taalbestanden, voor het geval):

Als u wilt toestaan ​​voor de vertaling MO bestanden in talen subdirectory de thema’s:

Als u wilt toestaan ​​voor de vertaling MO bestanden in de thema’s "LANG" directory:

Wilt u taalpakketten uitsluitend te gebruiken (let op: WP wordt nog steeds gecontroleerd eigen directory van de thema’s voor de taalbestanden, voor het geval):

  • Oproepen naar load_plugin_textdomain moet een functie aan de "plugins_loaded" actie haak.
  • Oproepen naar load_theme_textdomain moet een functie aan de "after_setup_theme" actie haak.

Hoe het zal werken

Uiteindelijk zal WordPress.org een manier om plugin / thema auteurs vertalen bestanden te uploaden hebben. Of, zal het een manier om gebruikers in staat om hun vertalingen via translate.wordpress.org … Ongeacht aan hen, de relevante MO bestanden worden gemaakt op een aantal basis, en de bestanden zijn beschikbaar voor WordPress gebruikers via het worden gemaakt hebben normale plugin / thema update-proces. De auto-update systeem automatisch downloaden van deze MO bestanden naar de / wp-content / talen directory. Er zullen plugins en thema’s submappen onder dat om deze bestanden te houden.

De bestanden worden genoemd "slug-locale.mo", Waarbij slug is de plugin of slak thema’s, en de locale is de relevante locale informatie over de taal (zoals "nl_NL" bijvoorbeeld). Wanneer load_plugin / theme_textdomain wordt genoemd, zal WordPress kijk in de aangegeven plaats voor de desbetreffende MO-bestand, en als het haar niet vinden, dan valt het terug te kijken in de / wp-content / talen map voor het, op dat de naam basis . Als het vindt het, laadt het op en gebruikt het.

Dit geeft de plugin of thema auteurs de mogelijkheid om door te gaan hun vertaling zelf te beheren, zoals ze altijd hebben gedaan, of gebruik maken van het nieuwe taalpakket systeem en laat WordPress.org lukt het je. Het taalpakket systeem heeft een aantal voordelen:

  • Gebruikers alleen downloaden van de talen die zij eigenlijk nodig hebben, in plaats van hen allen. Uw plugin is kleiner, de download is sneller.
  • Nieuwe vertalingen kunnen worden goedgekeurd en geduwd als updates onafhankelijk van de plugin of thema. Niet meer nodig om de versie gewoon bump om nieuwe vertalingen naar gebruikers.
  • Vertalingen kunnen veel gemakkelijker worden afgehandeld, of genegeerd door de auteur geheel. Gemeenschappen kan (uiteindelijk) doen hun eigen vertalingen door middel van translate.wordpress.org.

Dat soort dingen. Deze zijn allemaal afhankelijk van plugins en thema’s doet vertalingen een zekere en specifieke manier, samen met hun code correct internationalisering voor de vertaling.

Het is duidelijk dat elke code niet te doen dit soort dingen zal deze voordelen te krijgen. Nou, we kunnen niet repareren alles tegelijk. Maar hopelijk zal de meest voorkomende en populaire dit te doen (of al zijn), en ze kunnen snel en eenvoudig worden geïntegreerd in het systeem.

Sommige instrumenten om te helpen

Als u een plug-in of thema auteur bent, doe jezelf een plezier en gebruik je SVN-client om een ​​kopie van deze repository krijgen:

Dit is de kern ontwikkelen opslagplaats voor WordPress. Het komt met de WordPress trunk code (in / src), maar het heeft ook een aantal belangrijke tools die je nodig hebt in de / tools / i18n directory. Merk op dat deze tools te gebruiken, moet u de * gehele * checkout, niet alleen de gereedschappen. De gereedschappen bellen terug in de WordPress core code om een ​​deel van het werk te doen, zodat de hele / kofferbak directory moet er beschikbaar zijn.

Ook zijn deze instrumenten worden beheerd door het kernteam. Dus houden ze tot op heden door het doen van een svn-update elke keer in een tijdje ook.

Hier is een van die tools:

Dit zal telefoonboek van uw plug-in te scannen en een POT file voor u om te geven aan vertalers of opnemen met uw plugin. Thema auteurs, dezelfde deal, vervang "" met "wp-theme".

add-textdomain.php

De newfile.php zal identiek zijn, maar al het vertaalwerk gesprekken worden opgeknapt en hebben de plugin-slug daar zoals bedoeld.

"" zoals je hierboven ziet. Dit is zodat het non-destructief standaard. Als u zeker bent, en hebben back-ups van de bestanden voor het geval, kunt u deze gebruiken in plaats als volgt:

Het originele bestand zal worden vervangen door de gewijzigde versie. Gebruik dit op eigen risico. Ik ben paranoïde, ik de voorkeur aan een nieuw bestand voor handmatige vergelijking te maken.

Het is een nette template. Doet een aantal zeer leuke dingen. HTML5, CSS3, slim Javascripty goedheid. Beetje vervelend om al aan te passen, en zeer hardcoded. Dus, ik maakte er een WordPress theme plaats.

"slides"

Bericht navigatie

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

drie × vijf =