SearXNG: CSS muutokset

Useimmilla alustoilla omat CSS muokkaukset ovat kohtuullisen helppoja tehdä. On jokin paikka, johon lisätään omat säännöt ja se siitä. SearXNG on ratkaissut asian toisin. Tai oikeammin, ei ole ratkaissut ollenkaan. Custom CSS on kuitenkin siedettävän helppo toteuttaa.

Ylipäätään, kun yrittää mukauttaa SearXNG:n ulkonäköä ja hyvin kevyitä UI/UX-muutoksia, niin tulee sellainen olo, että SearXNG ei halua mitään muutettavan.

Tai sitten kyse on open source’ maailman rasitteesta: devaajat tekevät toisille deveille, ja jo pelkkä asennus, admin-käytöstä puhumattakaan, vaatii tavanomaista osaamista reilusti syvempiä taitoja.

Toki voidaan alkaa keskustelemaan resursseista. Kun ne ovat rajallisia, eikä takana ole liiketoimintaa, niin kehittäjien motivaatio rakentaa tavanomaista käyttöliittymää edes logon vaihtamiseksi tai CSS-muutoksille on pyöreä nolla. He eivät itse tarvitse moista.

Minulla kesti logon vaihtaminen aika tarkkaan neljä tuntia. CSS:n muuttaminen vei hieman pidempään. Syy oli hyvin yksinkertainen. En osannut dockeria niin hyvin, että olisin ymmärtänyt hakemistojen ja tiedostojen mountaamista paikallisesta containeriin.

En täysin ymmärrä miksi minun pitäisi ymmärtääkään moisissa täysin rutiininomaisissa ja yleisissä muutoksissa.

Tuota on kysytty ja pyydetty. Siihen on kaksi vakiovastausta: koodaa ja tee PR (niinkuin logon vaihtoa kysyvä osaisi) tai forkkaa alkuperäinen repo, muuta, ja tee git rebase — joka kuuluu tekniikkaana erittäin edistyneeseen gitin käyttöön, ja jos sen hallitsee, niin ei taatusti tarvitse apua logon vaihtoon tai CSS:n muokkaamiseen.

Koodarit, devaajat ja kehittävät eivät elä samassa reaalimaailmassa muiden kanssa. Ja samaan aikaan ihmetellään miksi se oma alusta ei kasvata suosiota. Ei WordPress saanut asemaansa siksi, että se on hyvin koodattu. Eikä Discourse ole kasvattamassa osuuttaan foorumimaailmassa ominaisuuksien vuoksi. Kummassakin ymmärrettiin, että itse alustaansa hostaaville täytyy tehdä helposti hallittava järjestelmä.

Itse-hostaavat tekevät tuotteesta tunnetun, ei kehittäjä. Ja kun on tunnettavuutta, niin pystyy myymään maksullisia vaihtoehtoja. Paitsi tietysti SearXNG, jolla ei ole minkäänlaista liiketoimintamallia, ainoastaan intohimoiset vapaaehtoiset ja hyväntekeväisyys.

Koskee isoa osaa open source maailmaa. Jolloin kuuma kysymys on: mitä tehdään kun intohimo loppuu.

CSS:n muuttaminen

Minulla oli kaksi tarvetta:

• suurentaa haun etusivulla olevan logon kokoa, koska CSS:n remarvot eivät olleet sopivia oman logon kuvasuhteille; originaali on bannerimallinen, oma on neliö
• piilottaa hakukonelistauksessa http-yhteydestä varoittava huutomerkki; se on aiheeton, koska omilta sivustoiltani hakeva json engine liikkuu serverin sisäisesti urlilla http://host.docker.internal eikä SSL:lle ole minkäänlaista tarvetta

SearXNG:n perusajatus muutoksille on, että muokattava tiedosto korvataan. Toimii logon kohdalla, mutta ei CSS:n kanssa. Kehittäjät olisivat voineet linkittää tyhjän CSS-tiedoston muokkauksia varten, mutta ilmeisesti sekin oli liikaa pyydetty.

On kaksi tapaa tehdä tuo

• muokata base.htmltiedostoa
• injektoida lisättävän CSS:n polku Nginxissä

Kummassakin tapauksessa kannattaa aina mountata korvaavat tiedostot, kuten vaikka logon.

base.html muokkaus

Joudutaan siis tekemään kaksi asiaa:

• varsinainen tiedosto, jossa CSS-modaukset ovat, ja se täytyy mountata
• muokata base.htmltiedostoon (Simple käyttää tuota) tieto tuosta CSS-tiedostosta

Käytän esimerkkinä omia polkujani. Mutta paikallisestihan voi käyttää mitä haluaa. Lisäksi minulla SearXNG on hakemistossa /opt/searxng joten senkin joutuu muuttamaan itselleen sopivaksi.

Minulla on hakemisto static/customja sen alla alihakemistot css, js ja img. Olen mountannut ne tiedoston docker-compose.yml osaan volumes:

- /opt/searxng/static/custom:/usr/local/searxng/searx/static/custom

Alihakemistoja ei tarvitse erikseen mountata. Kun se tehdään ylemmälle hakemistolle, niin alihakemistot ja niissä olevat tiedostot tulevat automaattisesti mukaan.

Minulla on CSS-asioita varten tiedosto static/custom/css/custom.css

Noita kahta aiemmin mainitsemaani muokattavaa asiaa varten lisäsin nämä custom.css:

.index .title {
    background: url(/static/themes/simple/img/searxng.png) 50%/contain no-repeat;
    min-height: 12rem;
    margin: 1rem auto
}

/* Piilota http-huutomerkki */
.table_engines th.name > svg.sxng-icon-set-big { 
  display: none !important; 
}

Tuo tiedosto täytyy ottaa käyttöön. CSS-asiat, kuin aika monet muutkin läpi koko SearXNG-instanssin määritellään base.html tiedostossa. Joten base.html täytyy ladata paikalliseksi, muokata sitä ja mountata takaisin yliajaen alkuperäinen.

Kopiointi tapahtuu periaatteessa samalla tavalla kuin tutumman scp kanssa, mutta containerin ja paikallisen välillä. Joka tuo tietysti vaatimuksen, että hakemistot on oltava olemassa. Niitä ei luoda lennossa kun kopioidaan.

Kopiointi tapahtuu tällä:

docker cp searxng:/usr/local/searxng/searx/templates/simple/base.html /opt/searxng/templates/base.html

Paikallinen kohdehakemisto saa olla mikä tahansa. Minä käytän samaa kuin mikä on alkuperäisessä silloin kun muokkaan olevaa tiedostoa. Jos teen uuden, niin käytän custom-polkua. Kannattaa tehdä siten kuin itselle on mukavinta.

Joten tässä tapauksessa ennen kopiointia on syytä tehdä tämä:

mkdir -p /opt/searxng/templates/simple

Avaa ladattu base.html ja lisää viimeiseksi ennen </head> tagia linkitys omaan custom.css tiedostoon. Minulla tuo kohta näyttää tältä oman lisäyksen ja päättävän tagin kanssa:

<link rel="stylesheet" href="{{ url_for('static', filename='custom/css/custom.css') }}" type="text/css" media="screen”>

Kyllä, tuossa polun kirjoitustapa täytyy olla tuollainen. Nuo aaltosulkeet kuuluvat Jinja2-syntaksiin, jota käyttää python ja Flask. static viittaa containerin ensimmäiseen hakemistoon /usr/local/searxng/searx/ jälkeen, eli asennushakemistossa, joka tässä siis on static. Tiedostossa sitten kerrotaan polku suhteessa tuohon. Toisaalta, onhan tuo helpompi kuin /usr/local/searxng/searx/static/custom/css/custom.css, mutta ei visuaalisesti yhtä hahmotettava.

Jos tarvitset kommentteja, niin ne tehdään {{# kommentti #}}.

base.html täytyy vielä mountata takaisin containeriin. Joten taas docker-compose.yml auki ja osaan volumes: lisäys:

- /opt/searxng/templates/simple/base.html:/usr/local/searxng/searx/templates/simple/base.html

Huomaa: mounttaa tiedosto. Jos mounttaat /opt/searxng/templates/simple/ hakemiston, niin ylikirjoitat kokonaan containerissa saman hakemiston ja sen koko sisällön.

Sitten tarvitaan docker compose down && docker compose up -d. Avaa sivu ja muutokset pitäisi näkyä.

Jos muutokset eivät ilmesty, niin ensimmäinen peliliike on avata selaimen devtools ja vilkaista Networkista näkyykö base.htmlja saako se edes error 404.

Jos custom.css ei näy ollenkaan, niin joko base.html muokkaus meni peppulleen, containerin polku on väärin mountissa tai mount unohtui tehdä. Jos tulee 404, niin mountin paikallinen polku lienee väärin.

Kysymysmerkit base.html muokkaamisessa

En pidä siitä, että minut pakotetaan muokkaamaan järjestelmän tiedostoja. Kun seuraavan kerran tehdään päivitys komennolla docker compose pull, ja se päivitys osuu tuohon, niin se ylikirjoittaa muokatun version. Mutta koska päivityksen jälkeen tehdään sammutus ja käynnistys, niin oma muokattu versio ylikirjoittaa sen päivitetyn — koska paikallinen on vanha.

Jos päivitys on kohdistunut tiedostoon base.html niin sitä ei koskaan saada käyttöön ilman docker cp ja ylikirjoittamalla se oma paikallinen muokattu alkuperäinen. Jonka jälkeen on pakko taas tehdä muokkaukset käsin uudelleen.

Joten omat kustomoinnit on syytä dokumentoida. Ei niitä enää viikon päästä muista.

Nginx tekee työt

Toinen vaihtoehto on se mitä itse käytän. Jos base.html tarvitsee radikaaleja muutoksia rakenteeseen ja sisältöön, niin sitten kopioin sen, tai mitä tiedostoa sitten muokkaankaan, paikalliseksi, teen muokkaukset ja mounttaan takaisin.

Mutta tämänkaltaisissa yksinkertaisissa lisäyksissä annan Nginxin tehdä työt. Tosin tämä kikka ei toimi kuin html-pohjissa.

Näin voin jättää alkuperäisen koskemattomaksi ja Nginx lisää tarvittavat ennen kuin lopputuotos päästetään asiakkaalle.

Avaa vhost ja… ehkä on helpompi esittää miten oma on tehty:

location ^~ /static/ {

        include /etc/nginx/snippets/searxng-proxy.conf;

   }

    location / {

        proxy_set_header Accept-Encoding "";   # pakkaus pois vain HTML:ltä
        sub_filter_once on;

        # Custom CSS
        sub_filter '</head>' '<link rel="stylesheet" href="/static/custom/css/custom.css" type="text/css" media="screen"></head>';

        # Varsinainen upstream
        proxy_pass http://127.0.0.1:8888;

        proxy_http_version 1.1;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout  30s;
        proxy_connect_timeout 10s;
        proxy_send_timeout  30s;

    }

Sijainnissa /static oleva include on sama proxymääritelmä kuin varsinaisessa, eli siellä ei ole mitään muuta.

Nyt käytetään sellaista keksintöä kuin sub_filter. Sille annetaan ensimmäisenä määreenä mitä etsitään ja toisena kerrotaan millä se korvataan. Joten kun käskin korvata </head> tällä <link...></head>, niin CSS ilmeistyi paikalleen ollen head-lohkon viimeisenä.

Kokeilin erästä banneriratkaisu ja sen käyttämä JS oli tuolla tekniikalla helppo ilmoittaa ilman itse sivupohjan muokkaamista.

Noilla ei kannata liioitella. On helpohkoa aiheuttaa melkoinen kuorma, koska kaikki html-tiedostot tutkitaan. Niitä ei tosin ole kovinkaan montaa SearXNG:ssä. Mutta siitä syystä, ja tarpeettomana, en käytä sitä static-lohkossa. Eikä sinne mene edes mitään sellaista html-tiedostoa, jossa tuota CSS-fiksausta tarvittaisiin.

Extra: Logon vaihtaminen

Logo vaihtuu mountills, eikä tarvitse ladata SearXNG:n puolelta.

Tallennetaan kuva vaikka esimerkin mukaiseen hakemistoon. Paikallinen saa olla mitä haluaa, mutta kohde ja tiedoston nimi täytyy olla juurikin tuo — ellei halua alkaa muokkaamaan base.html tiedostoa.

Lisää tämä mount docker-compose.yml tiedostoon, ja perään sammutus ja käynnistys.

- /opt/searxng/static/custom/img/searxng.png:/usr/local/searxng/searx/static/themes/simple/img/searxng.png

Vaikka /static/custom on mountattu hakemistona ja sellaisenaan löytyy myös containerista, niin se ei paljoa lohduta. Logoa kun ei pyydetä siitä hakemistosta. Siksi on pakko mountata tiedosto.

Extra: faviconien vaihtaminen

Jos haluaa päästä helpolla, niin kannattaa vain mountata jo ne mitkä ovat käytössä base.htmltiedostossa. Tarvitset kaksi tiedostoa, favicon.png ja favicon.svg.

- /opt/searxng/static/img/favicon.png:/usr/local/searxng/searx/static/img/favicon.png
      - /opt/searxng/static/img/favicon.svg:/usr/local/searxng/searx/static/img/favicon.svg

Tai sitten voi edetä perinteisemmällä tavalla ja tehdä erikokoisia kuvatiedostoja ja korvata base.html favicon-säännöt kaikille versioille erikseen. Ne ovat rutiinimäärityksiä ja löydät ohjeet sekennissä miten sivuilla faviconeja käytetään, tai käytettiin. Mutta noinkin se onnistuu.

Laita pikkukuvat vaikka custom-hakemistoon, jos sellainen on mountattuna, niin ei tarvitse mountata jokaista kuvaa erikseen.

Kauhea urakka, ja ihan turhaan. Kaupan päälle täytyisi erikseen huolehtia mahdollista base.htmlsaamista päivityksistä.