Életbevágó apróságok

Múltkor már írtam hasznos apróságokról (klubtagoknak), a maiak viszont egyenesen életbevágóak lehetnek (no persze nem a Te életedet veszélyeztetik, annál inkább a honlapodét). Az alább felsoroltak mind olyan hibák, illetve olyan hibát okoznak, amelyektől a honlapod (vagy a Vezérlőpultod) egy szép, üres, fehér oldallá változhat, jobb esetben egyszerűen nem fog működni valami, vagy nem jelenik meg, pedig látszólag ott van.

1. Ne másolj be Wordből!

Erről már írtam, még a kezdet kezdetén, de úgy látszik, nem szólhatok elégszer – újra és újra kapok olyan segítségkérést, hogy a bejegyzések betűtípusa, színe nem egyforma, ezért kaotikus a weboldal kinézete, vajon mit lehetne tenni?

Az a baj, hogy a Wordben megírt és onnan egyszerűen átmásolt szöveg magával hoz egy csomó “kosz kódot”, saját formázást, amely felülírja a sablon eredeti csinos beállítását. Extrém esetben olyan kódok is átjöhetnek, amelyek akár tönkre is tehetik az egész weblapot (nem fogsz mást látni, csek egy üres, fehér oldalt a helyén).

MEGOLDÁS: olvasd el ezt a cikket »

2. Ne használj ékezetes fájlneveket a Médiatárban!

Amikor feltöltesz valamit a Médiatárba (képet, pdf-et, vagy bármi mást), feltöltés előtt mindenképpen írd át a fájl nevét. A médiaelemet elnevezheted szépen magyarul (a keresőknek ez tetszeni fog, és a vakok, gyengénlátók is hálásak lesznek érte), de maga a fájlnév ne tartalmazzon ékezetes betűket, szóközöket, egyéb speciális karaktereket. A NextGEN Gallery például meg sem jeleníti azokat a képeket, amelyeknek ilyen nevük van. Ez egyébként a szervered beállításaitól is függ.

MEGOLDÁS: a legokosabb, ha eleve úgy dolgozol, hogy a weblapodra töltött fájloknak egyszerűsített nevet adsz.

3. xmlrpc.php – ismert, de nem kezelt hiba a WordPressben.

Már jó ideje ismert a fejlesztők körében, hogy a blogok közti visszakövetést elősegítő funkciókon keresztül fel lehet törni a WordPress oldalakat, de valami miatt nem tesznek ez ellen semmit. A visszakövetés alapesetben jópofa dolog, mert ha valaki hivatkozik a cikkedre, akkor ez az információ megjelenik a hozzászólások között – bár, igaz, ami igaz, nem valami csinos formátumban.

MEGOLDÁS: a Vezérlőpulton a Beállítások -> Interakció menüpontban én eleve ki szoktam kapcsolni a “Megpróbálja értesíteni a bejegyzésről az összes hivatkozott blogot.” és a “Jelzések fogadásának engedélyezése más blogokból (visszajelzés és visszakövetés)” lehetőséget, de a legjobb, ha a tárhelyedről is letörlöd az xmlrpc.php fájlt (a WordPress telepítés gyökérkönyvtárában van).

4. Ne hagyj a tárhelyeden felesleges fájlokat!

A Vezérlőpulton keresztül történő frissítés nagyon kényelmes, de a régi verziókból megmaradt fájlokra már semmi szükség nincs a tárhelyeden. Nem valószínű ugyan, hogy komoly gondot okoznának, de végülis nyílt forráskódú fájlok, nehogy valami okostojás éppen rajtuk keresztül próbáljon bejutni az oldaladba.

MEGOLDÁS: hasonlítsd össze frissítés után a tárhelyeden lévő fájlokat a WordPress legfrissebb telepítőcsomagjával, ha nem is mindenhol, de legalább a gyökérkönyvtárban. Az alábbi fájlok már nem részei a telepítőcsomagnak, nyugodtan törölheted őket:
wp-app.php, wp-atom.php, wp-commentsrss2.php, wp-feed.php, wp-pass.php,
wp-rdf.php, wp-register.php, wp-rss2.php, wp-rss.php.

5. Ellenőrizd a közvetlen linkeket!

Ha a főoldal működik, de az aloldalak nem akarnak bejönni, 404-es hibát adnak, akkor könnyen lehetséges, hogy az alapértelmezett ?p=123 jellegű linkek helyett (okosan) csinos közvetlen linkeket (például %category%/%postname%) állítottál be, viszont nincs .htaccess fájlod, és ezért nem működnek a közvetlen linkek (az is lehet, hogy a tárhelyed úgy van beállítva, hogy a távoli létrehozás nincs engedélyezve).

MEGOLDÁS: hozz létre egy .htaccess fájlt kézzel! Egy egyszerű jegyzettömbben megteheted, ennek kell benne lennie:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Vigyázz, nehogy htaccess.txt vagy .htaccess.txt legyen a neve! Ha úgy van beállítva az Intéződ, hogy “az ismert fájltípusok kiterjesztését rejtse el”, akkor nem fogod látni, hogy a fájlnév végére odakerült a .txt. A helyes név tehát az, hogy egy pont és utána htaccess, és utána semmi más 🙂

Amikor kész vagy, töltsd fel a fájlt a tárhelyed gyökerébe, ahol a WordPress motor fájljai is vannak.

6. Módosítsd a .htaccesst, ha alkönyvtárban van telepítve a WordPressed!

Ha nem a tárhelyed főkönyvtárába telepítetted a WordPresst, hanem egy alkönyvtárba, akkor a közvetlen linkek nem fognak működni.

MEGOLDÁS: ilyenkor módosítanod kell a .htaccesst. Például ha az alkönyvtár neve proba, akkor a .htaccessben ez legyen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /proba/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /proba/index.php [L]
</IfModule>

ÖSSZEFOGLALÁS HELYETT:

Javaslom, hogy ha még nem tetted meg, nézd végig az “Új vagy itt? Kezdd ezzel!” című oldalon belinkelt bejegyzéseket, valamint a Wiki oldalakat is.

Ha egyedül, a magad tempójában szeretnéd megtanulni a WordPresst, arra ezek a cikkek, illetve a teljes szakmai blog rengeteg segítséget ad, de még többet az, ha gyakorolsz. Én erre biztatlak!

Ha gyorsabban szeretnél haladni, lehetőséged van a WP-Suli tanfolyamok elvégzésére (további információ itt »), ha pedig folyamatosan szeretnél segítséget kapni tőlem, akkor válaszd a WP-Suli Klub tagságot!

Végül pedig, ha “csak” kezelni szeretnéd a weboldaladat, feltölteni a saját tartalmaidat, de a weboldal technikai elkészítését ránk bíznád, akkor kérd webdesign ajánlatunkat ide kattintva.

Sok sikert kívánok WordPress oldaladhoz!

Oszd meg Te is:

Share on email
Share on facebook
Share on twitter
Share on whatsapp
Share on linkedin

Szerző:

Ezek is érdekesek lehetnek számodra: 

Iratkozz fel hírlevelünkre!

Javasolt eszközök:

Banner250x250.png
Elementor Pro
Generatepress Logo White Asset
GeneratePress
Divi 4.0
Divihello
Prémium támogatás és ajándék Divi licence
Adatvedelem.png
ADATVÉDELEM minta
Aszf.png
Webshop ÁSZF minta

“Életbevágó apróságok” bejegyzéshez 13 hozzászólás

  1. Köszi Móni!
    Hasznos, mint mindig. 🙂
    Végignéztem a dolgokat, szerintem rendben vagyunk.
    A .htaccess fájlt a gyökér- és az alkönyvtárban is megtaláltam, gondolom elég lenne egyik helyen. De nem látom, hogy zavart okozna…

    Jó munkát!
    Kati

    Válasz
    • Az index.php ÉS a .htaccess is kell hozzá.
      (Persze ha egyebet is beleírsz az index.php-ba, ami azt kiváltja… de alapesetben, ha úgy csinálod, ahogy a hivatalos leírásban van, akkor kell mindkettő.)

      Válasz
  2. Szia Móni!

    Volt egy kis .htaccess bajom (konkrétan véletlenül kitöröltem, mert azt hittem a tesztoldalban vagyok, közben az élesben voltam 🙂 Mindegy, pótoltam, működik úgy, mint előtte, bejönnek az aloldalak is szépen. Viszont a képek nem jelennek meg többé + a shortcode-dal beágyazott pdf-ek sem (google doc embedder plugint használom). Nem írnak ki hibaüzit, egyszerűen nincs a helyükön semmi.

    Szerinted mi lehet a gond?

    Válasz
  3. Kedves Móni!

    Olyan gondom lenne, hogy az általad szépen leírt visszakövetés tiltásához szükséges fájlt töröltem, illetve kikapcsoltam, amit írtál, de sajnos továbbra is vélhetően vírus következtében jönnek a visszakövetések.
    Esetleg volna valami ötleted, hogy mit lehetne ez ügyben még tennem?

    Köszönöm a válaszodat!

    Péter

    Válasz
    • Hú, ez már nagyon messze vezet… Neked is csak azt tudom válaszolni, mint Anitának korábban: így kívülről, látatlanban nem tudok segíteni, mert rengeteg oka lehet. (Például ma egész nap vírust irtottam egy ügyfelem weboldaláról…) Viszont ez már fizetős munka, mert sokáig tart, sajnos nem fér bele az ingyenes segítség kereteibe.

      Mindenesetre futtass le egy ellenőrzést a Sucurival (http://sitecheck.sucuri.net/scanner/), és nézd végig a tárhelyedet dátum szerint, az sokszor kiugrasztja a megtámadott fájlokat (például ha a sablonodat 2013.10.12-én tetted fel és tudod, hogy azóta nem nyúltál hozzá, akkor a 2014.01.10-i dátumú footer.php, header.php és functions.php nagy valószínűséggel vírusos – főleg ezekbe szokott belemászni, ami belemászik). Én is így kezdeném.

      Válasz
  4. Sziasztok!
    Lassan a hajam tépem!!! A közvetlen linkeket nem tudom tökéletesen beállítani a saját oldalamon.
    Egészen pontosan arról van szó, hogy működik minden lehetőség, de a saját szerkezetbe beírva a
    %postname%
    parancsot nem hozza a várt pl. “oldal.hu/kapcsolat” formátumot.
    Ugyanakkor ha a
    “/index.php/%postname%/”-et írom be, akkor tökéletesen működik az “http://oldal.hu/index.php/kapcsolat” módban.
    A GONDOM AZ, HOGY MINDEN ESETBEN CSAK AKKOR JÓ, HA A “oldal.hu/index.php/” ott van az aloldal neve előtt.

    Igy meg elég ronda pl. egy blog aloldalra hivatkozni, hogy “oldal.hu/index.php/blog”. Sokkal szemrevalóbb lenne az “oldal.hu/blog” formátum.

    a htaccess file így néz ki:

    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    Elképzelhető, hogy szerver oldalon van a gond? (Nem apache, hanem IIS szerver és Windows Server 2012 üzemelteti a tárhelyet!)

    A WordPress admin felületén az összes lehetőség jól működik, kivéve az utolsó saját szerkezetet.

    Tudja valaki a megoldást?

    Válasz
    • Szia!
      Igen, ez sajnos lehet, hogy szerverbeállítási probléma, én is láttam már ilyen oldalt, ahol az index.php mindenképpen benne volt a linkben.
      Ámbár az én .htaccess-em így néz ki:


      RewriteEngine On
      RewriteBase /
      RewriteRule ^index\.php$ – [L]
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /index.php [L]

      Tehát ebben van egy gyanús plusz sor. Nem tudom, ez jobb-e így, de egy próbát megér.

      Válasz

Szólj hozzá!

Ez a weboldal az Akismet szolgáltatását használja a spam kiszűrésére. Tudjunk meg többet arról, hogyan dolgozzák fel a hozzászólásunk adatait..