Support » Kokeneille käyttäjille » CSS:n palikoiminen

  • han mielipettä vaan kyselen. Olen jakanut CSS:ää paloihin, joissa palvelin tekee perusjakotyön selaimen sijaan. Perus CSS on kolmessa pääosassa: yleinen, foorumi ja muut sivut. Foorumi/muut sivut erillisyys poistaa käytöstä 30-40% CSS:stä toisesta osiosta.

    Lisäksi palvelin erottelee mobiiliversion ja tietokoneversion CSS:t. Tämä jako on mielestäni joka tapauksessa järkevää laittaa palvelimen tehtäväksi eikä yrittää CSS-luokilla tms. erotella versioita toisistaan.

    Mutta jos ajatellaan sivujen latautumista, tämä kai on tilannekohtainen asia. Jos on tehokas palvelin, se tehnee homman nopeammin kuin selain. Jos on tehokas oma laite, sen selain saattaa tehdä homman nopeammin. Minulla ei ole tähän mitään faktatietoa.

Esillä 7 vastausta, 1 - 7 (kaikkiaan 7)
  • Järkevää on ainakin tuo jako foorumin ja muiden sivujen CSS:ään: jos on CSS:ää, joka on käytössä vain tietyllä osalla sivustoa, se kannattaa ehdottomasti pilkkoa erikseen.

    Mobiiliversion ja tietokoneversion erillisyys taas… no, tavallisestihan tuo tehdään media queryillä ja tietyistä näytönleveyksistä riippuen ja sitähän ei taas kannata tehdä eri tiedostoihin pilkkomalla, koska sitten sivusto ei pysty reagoimaan näytönleveyden muuttumiseen. Mutta jos sivustolla on hyvin selkeästi erilaiset tietokone- ja mobiiliversiot eikä yhtenäistä responsiivista toteutusta, silloin toki erilliset tiedostot ovat järkevä juttu.

    Mutta noin yleensä ottaen CSS:n optimoiminen on vähän sellaista pienhinkkausta. Jos palvelin osaa pakata siirrettävät tiedostot automaattisesti, CSS pakkaantuu kyllä hyvin, ja voihan sen minifioidakin, jolloin se vie yleensä melko vähän tilaa.

    Muuten käytetystä tekniikasta riippuu, minkä verran on haittaa siitä, jos CSS on useammassa tiedostossa; noin yleisesti ottaen on nopeampaa ladata yksi isompi tiedosto kuin monta pientä, mutta jos on moderni HTTP/2-tekniikkaa käyttävä palvelin, erillisten tiedostojen lataaminenkaan ei ole suuri ongelma.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    No aika lailla tuohon tapaan itsekin päättelin. Mobiili/tietokone-erittely on tarpeen, koska mobiilissa on eri päävalikko. HD/iPad 9,7 vaakasuuntaan on muutenkin erilainen kuin tietokoneversio. CSS on pääosin minimoitua. Suurin osa CSS:stä on Code Snippet avulla style-tägien sisällä.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Osaatko selittää, miksi wp_head anonyymin funkion käyttö ei aina toimi. Jos laittaa anonyymin funktion edelle if(is_bbpress()) sivusto kaatuu.

    if(is_bbpress()){
    add_action( ’wp_head’, function ()…

    Mutta jos kutsuu omaa funtiota, jossa on if(is_bbpress()), sivusto ei kaadu:

    function myCSSforbbPress(){
    if(is_bbpress()){
    $CSS=…
    add_action( ’wp_head’, ’myCSSforbbPress’);

    Selitit jossain, että funtiota ei ole määritelty ennen kuin sitä käytetään, mutta is_bbpress() on mielestäni kummassakin tapauksessa ihan samassa asemassa suhteessa wp_head-funktioon. Mutta koodiajossa kuitenkin vain jälkimmäinen vaihtoehto on toimiva.

    Toisaalta oma funktio anonyymin funktion ehtona toimii:

    if(tap_is_mobile()){
    add_action( ’wp_head’, function ()

    Oma funktio on määritelty ennnen käyttöä.

    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Minulla siis oma CSS on palikoitu Code Snippet sisään style-tägeihin. Tiedostoja on helppo editoida ja on helppo luoda versioita kun vain kloonaa aiemman. Jos menee pieleen, vaihtaa edelliseen toimivaan versioon. Osa tietokantatietueista on varsin isoja, vaikka CSS on pakattuna. Irtotiedostoissa versionhallinta on hankalaa. Vai pitäisikö jossakin vaiheessa siirtyä irtotiedostoihin?

    Ei CSS:stä saa millään niin isoa – ainakaan käsin kirjoitettuna – että se haittaisi tietokannassa yhtään. Tietokantaanhan menee vaivattomasti megatavukaupalla tavaraa ja kun CSS on pelkkää tekstiä, sitä pitää olla aivan käsittämättömiä määriä, jotta siitä tulisi ongelma. Että sikäli ei tarvitse.

    Toki sinänsä helpommin hallittava ratkaisu voi olla käyttää class-attribuutteja ja sijoittaa tyylit tiedostoihin. Kyllähän tiedostoillekin saa versionhallinnan esimerkiksi gitillä, mutta toki jos palveluntarjoaja ei tue gitin käyttämistä sivujen julkaisemisessa, niin vähän hankalaksihan se menee. Mutta ainakin omalla koneella gitiä on mahdollista ajaa ja hallinnoida tiedostojen versioita sillä.

    Tuo ongelma is_bbpressin():n kanssa johtuu juurikin siitä, että is_bbpress() ei ole olemassa. Nuohan eivät nimenomaan ole samassa suhteessa wp_headiin! Onko tuo koodi teeman functions.php:ssa? Jos on, niin sitä ei suinkaan ajeta wp_headissa, vaan koukussa after_setup_theme, joka tulee hyvän aikaa ennen wp_headia ja myös ennen pluginien lataamista. Eli teeman functions.php:ssa ei saa koskaan viitata suoraan mihinkään, mikä on pluginien lisäämää.

    Tuo oman funktion käyttö wp_headissa toimii, koska silloin teeman latauksen yhteydessä ei kutsuta is_bbpressiä(), vaan rekisteröidään vain koukku ajettavaksi wp_headissa ja siellä pluginit on jo ladattu ja is_bbpress() toimii.

    Veikkaan, että se anonyymi funktiokin kyllä toimii, kunhan is_bbpress() kutsutaan siellä anonyymin funktion sisällä. Nythän tuossa se on ehtona tuolle add_actionille(), eli sitä ei ajeta wp_headissa vaan heti teeman latauksessa. Tämän pitäisi toimia:

    add_action( 'wp_head', function () {
       if ( is_bbpress() ) {
           // tee jotain
       }
    });
    Thread Starter tapiohuuhaa

    (@tapiohuuhaa)

    Mainittu koodi on Code Snippet -tietueessa. Header.php minulla on kyllä sama oma funktio ehtona valikon käytölle. No näiden funktioiden käsittelyongelmien vuoksi sivusto on muutaman kerran kaatunut. Suurin ongelma molemmilla kerroilla oli hoksata, mikä kaatoi sivuston. Täytyy muistaa nämä prioriteettiseikat. Ne ovat siitä hankalia, että Code Snippet ei pysty niistä varoittamaan.

    Code Snippetin kohdalla voi tosiaan olla vähän mysteeri, missä vaiheessa WordPressin toimintoketjua ne koodinpätkät ajetaan.

Esillä 7 vastausta, 1 - 7 (kaikkiaan 7)
  • The topic ‘CSS:n palikoiminen’ is closed to new replies.