Lähes kaikki ohjeet neuvovat laittamaan aivan kaiken serveriin ja hakemistoihin liittyvät asiat .htaccess -tiedostoon. Tämä johtuu siitä yksinkertaisesta syystä, että kaikilla on pääsy sivuston juurihakemistossa olevaan piilotiedostoon. Sen sijaan webhotelli-asiakkailla, joita suurin osa lienee, ei ole pääsyä serverin ja oman virtual hostin asetuksiin. .htaccess -tiedoston neuvominen on siten turvallinen ratkaisu. Siinä on vain yksi ongelma. .htaccess on tehosyöppö ja kun se paisuu tarpeeksi, niin se alkaa näkyä serverin suorituskyvyssä, joka jossain vaiheessa tarkoittaa sivuston kaatuilua.

Joka kerran kun sivu ladataan, niin käydään katsomassa jokaisen sivuun liittyvän hakemiston .htaccess -tiedoston sisältöä, mitä se määrää ja mitä se sallii. Tuo tarkoittaa aina vähintään sivuston juurihakemiston .htaccess -tiedosto. Joten jos sinulla on vaikka tuhat käyntiä, niin se on aina tuhat kiertoa avaamassa .htaccess ja sen lukemista. Jos sama kävijä tulee ensin etusivulle, käy sitten lukemassa uuden blogin ja piipahtaa selailemassa tuotteita, niin joka ainut kerta sama .htaccess avataan – eikä siihen auta välimuistitkaan. Ja kun joka jutussa ja tuotteessa on vähintään kuva, useimmiten useampikin, niin myös jokaisen kuvan hakemiston .htaccess avataan ja luetaan plus kuviin johtavien kaikkien hakemistojen .htaccess. Siitä alkaa tulla liikennettä.

TL;DR

Jos et pääse serverin hallintaan, sinun on pakko käyttää .htaccess -tiedostoa.

Jos pääset serverin hallintaan, niin sinun kannattaa käyttää example.com.conf -tiedostoa (NGINX:llä se on nimetty toisin).

• Siirrä kaikki .htaccess -tiedostosta example.com.conf -tiedostoon
• Laita tiedot <Directory /var/www/html> ja </Directory> väliin
• Vaihda AllowOverride arvoksi none
• Käynnistä Apache2 uudestaan

Aidompi tilanne

Nyysin nämä luvut täältä.

Minulla on täällä .htaccess käytössä, jotain tilanne on jopa kohtuullisen realistinen sinun lukiessasi tätä juttua (paitsi kuvamäärien suhteen, koska en esittele mm. vimpaimissa julkaistujen juttujen artikkelikuvia)

Artikkeli tarvitsee

• 6 HTML-tiedostoa
• 5 CSS-tiedostoa
• 5 JS-tiedostoa
• 26 kuvaa
• plus tolkuttomasti, esim. 104, ulkoisia tiedostoja, mutta ei lasketa niitä, koska ne eivät tule sivustoa pyörittävältä serveriltä

Tuossa on 42 omalla serverillä olevaa tiedostoa, yhteensä 146.

Jokainen hiukankaan WordPressin kanssa paininut tietää, että CSS-tiedostoja tulee useammasta paikasta. Teema asettaa omansa ja monet lisäosat asettavat omiaan. Tämä on yksi sellainen asia, miksi optimointia tekevät lisäosat yhdistävät CSS-tiedostoja isommaksi palikaksi kykyjensä mukaan. Sama koskee tietysti JavaScript-tiedostoja.

Esimerkissä CSS- ja JS-tiedostot tulevat kolmesta ”peruspaikasta”:

• /wp-content/theme/nimi/
• /wp-content/plugins/(kaikki käytetyt)
• /wp-includes/js/

Kun sivu rakennetaan, niin

• .htaccess -tiedostoja on suoritettu 42 kertaa
• .htaccess -tiedostoja on luettu 249 kertaa

Jos sinulla on päivässä 1000 sivulatausta, niin osannet laittaa määriin kolme nollaa lisää…

Serverille tuo tarkoittaa, että se on tehnyt yhden sivun takia 84 tiedostojärjestelmän lukua ja 249 tiedostojärjestelmän tutkimista.

Jos .htaccess ei olisi käytössä ja aivan samat tiedot tulisivat Apache2 -serveriltä normaalien kyselyjen ohessa, niin tehtäisiin 42 lukua ja 42 tiedostojärjestelmän vilkaisua.

.htaccess ja example.com.conf erot

Eroja sen mukaan, että jotain pitäisi vain pistää toiseen, ei ole. Kaikki mikä on .htaccess -tiedostossa voidaan laittaa vhostin conf-tiedostoon, ja päinvastoin. Mutta pari pientä eroa on.

Yksi selvä ero on, että .htaccess -tiedostoon voidaan asioita läimiä peräkkäin sen enempää miettimättä. .conf -tiedostossa taasen joudutaan selvittämään minkä lohkon alle mikäkin menee. Mutta ei se niin vaikeaa ole.

Jos jokin koskee eräällä tavalla yleisesti domainia, niin se tulee periaatteessa mihin tahansa ennen lopussa olevaa </VirtualHost> direktiiviä, mutta ei jonkun muun lohkon sisälle (ellei sille ole nimenomaan tehtävä omaa, joka on aina kerrottu esimerkissä).

Jos jokin koskee nimenomaan suoraan web-sivuja, niin se laitetaan sivuston juuren hakemiston lohkoon esimerkiksi <Directory /var/www/html> ja </Directory> väliin.

Annan vielä yksinkertaisemman muistisäännön: aivan kaikki .htaccess -tiedostossa olevat laitetaan <Directory /var/www/html> ja </Directory> väliin.

Kumpaa kannattaa käyttää?

Jos haluaa serverille kevyempää kuormaa ja hieman nopeutta lisää, niin ehdottomasti conf-tiedostoa. Mutta siinä on muutama rajoitus.

Sinun täytyy päästä serverin asetuksiin. Jos et pääse, niin voit lopettaa lukemisen tähän. Sinun on pakko käyttää .htaccess -tiedostoa. Tai sitten alat pohjustamaan siirto virtuaaliserverille esimerkiksi DigitalOceanin asiakkaana.

Jos pääset asettamaan virtuaali hostin asetuksia, niin silloin sinun kannattaa heivata .htaccess. Paitsi jos olet laiskahko. Nimittäin .htaccess on hieman helpompi. Lisäät rivin ja se on heti käytössä. Jos taasen pidät asiat serveripään hommana, niin joudut aina käynnistämään web-serverin uudestaan. Ei se ole kuin yksi komento ja vie aikaa kaikkineen pari sekuntia, mutta silti – sinun on otettava aina shell-yhteys, kun .htaccess -tiedoston muokkaa vaikka FTP:n avulla.

Näitä ei kuitenkaan tarvitse tehdä usein. Minulla on WordPressin asennuksen jälkeen kolme lisäosaa halunnut muokata .htaccess-tiedostoa:

• WP Rocket, joka hoitaa välimuistitusta
• EWWW, joka haluaa aika ajoin muuttaa kuvien tiedostomuotoa
• NinjaFirewall omien etuoikeuksiensa takia

Mutta jos asentaa jonkun lisäosan, joka haluaa asettaa .htaccess -tiedostoon jotain, niin se valittaa kun ei pysty. Mutta aina ne kertovat lisättävät tiedot, joten kopypeistaa ne ja lisää conf-tiedostoon. Ei se aidosti ole suuri vaiva, mutta päätä itse – hiukan vaivaa joskus harvoin tai hitaammat web-sivut.

.htaccess pois päältä

Jos .htaccess on Apachessa sallittu, niin serveri käy aina katsomassa sitä, vaikka tiedosto olisi tyhjä. Siksi sen käyttö pitäisi estää kokonaan. Mutta ennenkuin eston tekee, niin tietysti .htaccess kannattaa tyhjentää.

cp /etc/apache2/sites-available/example.com.conf /etc/apache2/sites-available/example.com.conf.backup

nano /etc/apache2/sites-available/example.com.conf

Kopioi haluamallasi tavalla .htaccess -tiedoston sisältö ja liitä se example.com.conf -tiedostoon.

Tässä on yksi esimerkki. Huomioi, että sinulla saattaa olla, ja varmasti onkin, erilainen VirtualHost määrittely ja luultavasti löytyy rivit SSL:n määrittelyyn. Tämä esimerkki on tuolta osin domain, joka on Hitchin ja Varnishin takana (jotka kannattaa asentaa, jos kaipaa nopeampaa HTTP/2:sta)

Kopioidaan .htaccess talteen:

cp /var/www/html/.htaccess /var/www/html/.htaccess.backup

Tyhjennä .htaccess ja tallenna. Tai komenna:

rm /var/www/html/.htaccess && touch /var/www/html/.htaccess

Periaatteessa uutta tyhjää ei tarvittaisi, mutta olen mielelläni ylivarovainen.

Kerrotaan Apachelle muutokset.

systemctl restart apache2

Jos virheilmoitusta ei tullut, niin tarkista sivuston toimivuus silmämääräisesti:

• pääsetkö hallintaan
• latautuuko etusivu
• pääsetkö artikkeleihin
• pääsetkö verkkokauppaan

Jos vastaus on kyllä, niin kaikki on hyvin. Jos ei, niin jossain kohtaa on vika – ja se vika löytyy conf-tiedostosta.

Sillä aikaa kun etsit vikaavikaa, niin sivusto kannattaa palauttaa linjoille, jos sinulla on kävijöitä. Nopeimmin teet sen FTP:llä poistamalla olevat ja nimeämällä uudestaan niin .htaccess.backup -tiedoston kuin example.com.conf.backup -tiedoston ilman .backup loppua ja pyöräyttämällä Apache2 uudestaan käyntiin.

Jos Apache2 kaatuu, niin vilkaise vinkkien mukaiset kohdat. Varsinkin

systemctl status apache2

kertoo sinulle rivin tarkkuudella missä sen mielestä on vika. Aina siihen ei voi luottaa, mutta jos se huutelee kirjoitusvirheestä tai että jokin määritys ei saa olla juuri siinä ja siinä lohkossa, niin ne pitävät paikkaansa. Pienellä pähkäilyllä saat kokeiltua mitä pitää korjata.

.htaccess oikeasti pois päältä

Äsken vasta siirrettiin .htaccess tiedot conf-tiedostoon. Mutta jos kopioit esimerkkinä olleen conf-tiedoston, niin sinulla on jo .htaccess estettynä.

Avataan example.com.conf.

nano /etc/apache2/sites-available/example.com.conf

Etsi kohta AllowOverride All – se löytyy melkoisen heti rivin <Directory /var/www/html> alta.

Muuta se muotoon:

AllowOverride none

Tallenna ja kerro asioiden nykytilanne Apachelle.

systemctl restart apache2

Se oli siinä. Enää .htaccess tiedostosta ei piitata.

Hassu virhe

Itse tietenkin jätin testaamisen väliin, ja huomasin vasta seuraavana päivänä, että artikkelit antoivat virheen 404. Kaikki muut julkaisutyypit, kuten podcastit, verkkokoulutukset, sanasto, tuotteet jne, toimivat ihan hyvin – mutta jokainen blogipostaus antoi error 404.

Olin asennellut välissä uutta eväste-juttua sekä Google Analytics -lisäosaa, joten potentiaalisia ongelmanaiheuttajia oli kourallinen. Otin pois päältä asentamani lisäosat, ja kun virhe ei poistunut, niin syy täytyi olla .htaccess -tiedoston poistossa.

Palautin tilanteen ja kaikki toimi. Joten aloin siirtämään kokonaisuus kerrallaan takaisin conf-tiedostoon ja yhdessä vaiheessa virhe uusiutui.

Kyseessä oli rivi

Options All -Indexes

Sen idea on estää ottamasta hakemistoista tiedostolistausta. Sehän usein estetään index.php tai index.html tiedostoilla, mutta olen usein törmännyt tilanteeseen, että hakemistot ovat levällään maailmalle. Toki meistä jokainen tietää mitä /wp-includes pitää sisällään, mutta ei niitä versioita myöten kannata silti esitellä.

Tuolla sallitaan kaikki muu, mutta estetään indexit. Ihan perusasiaa. Itseasiassa se oli omalla tavallaan toistoa, koska <Directory> alussa oli komennettu:

Options -Indexes +FollowSymLinks +MultiViews

Se on aivan sama hieman eri tavalla ilmaistuna, mutta annoin sen eräällä tavalla kahteen kertaan.

Joten outous on, että kun .htaccess oli sallittu, niin

• Options All -Indexes tiedostossa .htaccess ei aiheuttanut ongelmia
• Options All -Indexes tiedostossa example.com.conf antoi vain blogiteksteille error 404

Syy ei ole selvinnyt.