Mega menu on käytössä aika monellakin sivustolla. Se on se isoilla ruuduilla käytetyin valikkomuoto, jossa päävalikon alla olevat kohdat levittäytyvät eräällä tavalla sarakeotsikoiksi ja niiden alla on sitten kolmas porras suoraan näkyvissä. Paljon helpompi nähdä yhdellä silmäyksellä vaihtoehdot ja liikkua hiirellä. Perinteinen, jota mm. kaikki puhelimet käyttävät, on hankalampi. Näet vain pääkohdat ja niistä on sitten osattava päätellä mihin suuntaan lähteä. Käytettävyys on pääsyy mega menujen käyttöön ja siksi niiden toimimattomuus olisi myös heti korjattava.

Mega menu voidaan rakentaa myös lisäosilla. Yleensä niin tehdään silloin, kun halutaan näyttävää rakennetta. Aika usein tuosta seuraa mopon keuliminen ja valikosta tuleekin itseisarvo. Valikon rakentamiseen uhrataan enemmän aikaa ja vaivaa kuin sisältöön. Samalla unohdetaan perusteet:

• valikolla pyritään pääsemään nopeasti haluttuun kohteeseen
• mobiileilla tyylitelty valikko ei näy

Lisäksi kannattaa muistaa, että koska sisällöltään dynaaminen valikko – vaihtuvaa sisältöä – on tehokas tapa estää välimuistittaminen, niin esimerkiksi Varnish muuttuu cachena aika hyödyttömäksi. Uhrataan nopeutta sellaisen näyttävyyden eteen, jota ei katsota sekuntia kauempaa, ja joka ei valtaosalle edes näy. Valintakysymys, mutta minusta se on kova hinta.

Useimmiten mega menun toimimattomuus johtuu tutusta kolmikosta:

• teeman rajoitukset, kun mega menua ei ole ollenkaan
• lisäosien virheet, kun mega menu lakkaa kokonaan toimimasta
• PHP:n asetukset, kun osa mega menusta kuitenkin toimii

Teema sanelee paljon

Käytetty teema päättää onko WordPressin natiivi multi mega saatavilla vai ei. Jos ei, niin sen pystyy tekemään itse, mutta vaatii hieman näpräämistä functions.php -tiedoston ja CSS:n kanssa. Suoraan sanottuna, jos olet ”vain” ylläpitäjä, niin urakkaan ei kannata ryhtyä. Mutta toki jos sinussa on kokeilijan vikaa, niin voit kokeilla. Ohjeita löytyy netistä aika paljonkin.

Pointti on siinä, että jos kättämäsi teeman kanssa et löydä valikkoasetuksista rastia ruutuun mega menuksi, niin syy ei ole automaattisesti bugi tai konflikti lisäosien kanssa. Pääsääntöisesti teema ei vaan tue megamenua.

Jos olet aivan varma, että mega menu pitäisi olla valittavissa tai se on taatusti toiminut jossain vaiheessa, niin silloin olet törmännyt vanhaan tuttuun lisäosakonfliktiin. WP CLI:n avulla lisäosan ja teeman riidat ovat helposti selvitettävissä.

Mega menu lisäosalla

Aika harvoin enää tänä päivänä tarvitaan varsinaista mega menun perustoiminnallisuutta lisäosan (tai oman virityksen) avulla. Yleensä moinen koskee vanhempia ja päivittämättömiä teemoja, tai teemaa on mainostettu minimalistisena – turhan usein minimalistisuus ei tarkoitakaan yksinkertaistettua ulkonäköä, vaan yksinkertaistettua ja joskus jopa rampautettua toiminnallisuutta.

Mega menuja säätävät lisäosat ovat hyvin herkkiä teemojen kanssa. Tekisi mieli jopa sanoa, että jos käytössäsi on paljon toiminnallisuuksia sisältävä teema page builderilla, niin jonkinlainen konflikti on jopa odotettavissa. Joten ennen hankintaa lue huolellisesti dokumentit, toivottavasti sinulla on pääsy tukifoorumille ennen ostoa ja varmista, että osto on peruttavissa.

Osa mega menusta ei toimi

Edellä olevat ongelmat ovat helppoja sen suhteen, että lähes jokainen osaa löytää ongelman. Moisen korjaaminen niin, että saa pidettyä jokaisen palan toiminnassa, onkin sitten vaikeampaa ja edellyttää aina pluginin tekijän, teeman tekijän tai molempien yhteistyötä.

Sen sijaan tilanne, että aivan normaali mega menu toimii, mutta ei kuitenkaan toimi, onkin jo hankalampi. Moinen oireilee yleensä niin, että päävalikon kolme ensimmäistä kohtaa toimivat ihan hienosti, mutta neljäs kohta ja siitä eteenpäin unohtavat olevansa mega menuja. Kun menee WordPressin valikoihin, niin rasti mega menu kohdasta puuttuu. Laittaa sen paikalleen ja tallentaa, niin kaikki näyttää olevan ihan hyvin. Paitsi, että rasti ei pysy paikallaan.

Jos siirrät neljäntenä olevan valikkokohdan ykköseksi, niin se muuttuu mega menuksi ihan iloisesti – ja se neljänneksi pudonnut muuttaa tavallliseksi valikoksi. Toivottavasti et ole nähnyt niin paljon vaivaa, että olet tehnyt valikon uudestaan. Se ei nimittäin auta.

Tuo on yleinen vaiva, mutta mega menun osittaisen toimimattomuuden googlettaminen ei hevin anna korjausvinkkiä. Johtuu siitä, että sen korjaaminen on pääosin hyvin helppoa. Tai sitä ei korjata, koska apua ei löydy. Kolmas vaihtoehto on ostaa mega menu -lisäosa, joka sitten loihtiikin virheilmoituksen – ja sen avulla saa korjauksen tehtyä.

Ongelman aiheuttaa PHP:n asetus max_input_vars. Jos se on perusasetusten mukainen, niin sen arvo on 1000. Se pitäisi olla ainakin 3000, mutta mielellään 10 000.

Tuo liittyy jotenkin muuttujien määrään, joita voidaan kuljettaa mukana. Tai jotain, en minä ole koodari. Ihan kuin kyseessä olisi eräällä tavalla varastokirjanpito korttimalliin. Jos kortit on loppu, niin mitään ei laiteta mihinkään, vaikka tilaa olisi, koska sille ei saada tehtyä omaa korttia. Kohautetaan olkapäitä ja todetaan, että sellaista elämä on ja no can do.

PHP:n asetukset

Sinänsä ajatustasolla max_input_vars alimitoitus ei ole mitenkään uusi juttu. Olet varmaan törmännyt kahden megan siirtorajoitukseen. Tai liian lyhyeen koodien suorituaikoihin, jonka takia vaikkapa backup-lisäosa ei suostu toimimaan ja valittaa esimerkiksi time out -virheestä.

Silloin kysymys kuuluu, että pääsetkö PHP:n asetuksiin. Jos sinulla on VPS esimerkiksi DigitalOceanin kautta, niin pääset. Osa webhotelleista antaa muokata ainakin osaa asetuksista cPanelin kautta – käy katsomassa. Jos et pääse, niin sitten alkaa olla aika ottaa yhteyttä aspaan. Webhotellit ovat helppoja, mutta helppous tulee rajoitusten ja heikon tehon kanssa.

VPS/droplet ja oikea php.ini

Jos pääset muokkaamaan PHP:n asetuksia serverin tasolla, niin se mitä haet, on php.ini. Ongelmaksi nousee oikean php.ini -tiedoston löytäminen. Niitä kun on useampi.

• yksi php.ini säätelee sitä mitä tehdään shellissä
• yksi php.ini säätelee sitä mitä web-serveri tarjoaa (tätä etsitään)
• yksi php.ini saattaa määrittää cgi-bin toimintaa
• yksi php.ini saattaa olla ohjaamassa FPM/FastCGI toimintaa (stand alone PHP:n viritys, jonka pitäisi ehkä einen nopeuttaa web-serveriä)

Jotta asia ei muuttuisi yhtään helpommaksi, niin noiden sijainnit vaihtelevat sen mukaan mitä Linux, webserveri ja PHP-versio sinulla on. Minä tiedän vain Ubuntun ja Apache2 sijainnit, joten jos sinulla on jokin muu ympäristö, niin suhtaudu asioihin ohjeellisesti.

Yleensä web-serveriä ja siten verkkosivuja ohjaava php.ini löytyy polusta /etc/php/7.3/apache2/php.ini ja 7.3 täytyy vaihtaa käytössäsi olevaan PHP-versioon . ja jos sinulla on asennettuna useampi PHP-versio, niin sinun täytyy tietää mikä on käytössä oleva versio.

Jos sinulla in FPM asennettuna, niin php.ini sijaitsee hakemistossa /etc/php/7.3/fpm/php.ini – ja taas huomioi PHP:n versio.

Voit selvittaa oikein php.ini -tiedoston ilman arvailujakin. Tehdään tiedosto, joka kertoo sen.

nano /var/www/html/info.php

Liitä sinne tämä:

<?php phpinfo(); ?>

Tallenna ja avaa osoite https://www.example.com/info.php

Saat tämän kaltaisen sivun:

Jos scrollaat alaspäin, niin löydät jossain vaiheessa myös voimassaolevia arvoja.

Sinua kiinnostaa kohta Loaded Configuration File. Kopioi polku ja avaa se muokkausta varten.

Etsi tiedostosta max_input_vars ja muuta se arvoon vähintään 3000, mutta 10000 on hyvä.

Voit samantien tarkistaa

• upload_max_filesize = 32M (kuinka ison tiedoston saa siirtää)
• post_max_size = 48M (serverille lähtevän POST pyynnön koko, täytyy olla isompi kuin max_upload_filesize)
• memory_limit = 128M (paljonko PHP-skripti saa maksimissaan käyttää muistia)
• max_execution_time = 600 (sekunneissa kuinka kauan PHP-skriptiä saa ajaa)
• max_input_vars = 10000 (paljonko lähetettävässä saa olla inputteja)
• max_input_time = 400 tai -1 (sekunneissa kauanko PHP-skripti saa rakentaa inputeista sisältöä; -1 käyttää max_execution_time aikaa

Nuo ovat ehdotuksia ja oikeat arvot riippuvat monestakin asiasta. Joudun yhdellä toisella sivustolla työstämään paljon isompiakin tiedostoja, joten minulla upload_max_filesize = 32M ei riitä. Mutta useimmiten PHP:n oletuksen ovat liian pieniä.

Kun olet tehnyt muutokset ja tallentanut tiedoston, niin PHP pitää vielä uudelleenkäynnistää. Suurin osa ohjeista käskee käynnistämään Apache2, mutta se riippuu.

• jos sinulla on ”vain” PHP: systemctl restart apache2
• jos sinulla on FPM: systemctl restart php7.3-fpm (huomaa versionumero; käynnistetään FPM siksi, että se työskentelee nimenomaan osana Apachea)

Webhotelli tai jos php.ini ei ole saatavilla

Jos et pääse käsiksi php.ini -tiedostoon, niin sinulla on kolme vaihtoehtoa.

• tee php.ini tiedosto webhakemiston juureen
• muokkaa .htaccess, teeman functions.php tai wp-config.php -tiedostoja (mutta vain yhtä)
• pyydä webhotellin aspaa hoitamaan homman

Oma php.ini

Tehdään php.ini:

nano /var/www/html/php.ini

Kopioi tämä:

max_input_vars = 10000
upload_max_filesize = 32M
post_max_size = 48M
memory_limit = 128M
max_execution_time = 600
max_input_vars = 10000
max_input_time = 400

.htaccess

Avaa .htaccess:

nano /var/www/html/.htaccess

Lisää tiedostoon alkuun:

php_value max_input_vars 10000

Voit laittaa jonkun muunkin arvon, kunhan se on enemmän kuin 1000.

Jos on tarvetta, niin voit säätää myös ladattavan tiedoston koon ja lisätä muistia.

php_value upload_max_size 32M
php_value post_max_size 48M
php_value memory_limit 128M
php_value max_execution_time 600
php_value max_input_time 400

functions.php

Jos työskentelet mieluummin functions.php -tiedoston kanssa, niin lisää nämä:

@ini_set( 'max_input_vars', '10000' );
@ini_set( 'upload_max_size', '32M' );
@ini_set( 'post_max_size', '48M' );
@ini_set( 'memory_limit', '128M' );
@ini_set( 'max_execution_time', '600' );
@ini_set( 'max_input_time', '400' );

wp-config.php

Tässä olen epävarma, koska en ole koskaan tehnyt tätä. Siirrettävien tiedostojen maksimikokoon löytyy lisäosiakin, mutta moisen käyttö on enää vain tyhmää. Se ei tee muuta kuin poistaa tarpeen editoida suoraan tiedostoja.

Weblähteet ehdottavat tällaista, joka on aidosti sama kuin mitä functions.php -tiedostoon laitettaisiin. Lähteet ovat sitten eri mieltä siitä, että kumpaan nuo pitäisi laittaa vai onko sillä mitään väliä. Syy on selvä. Aidosti ei kuuluisi käyttää kumpaakaan, wp-config.php tai functions.php -tiedostoa.

define( 'WP_MAX_MEMORY_LIMIT', '128M' );
@ini_set( 'upload_max_size', '32M' );
@ini_set( 'post_max_size', '48M' );
@ini_set( 'max_execution_time', '600' );
@ini_set( 'max_input_time', '400' );

Ongelmat

Käytit mitä tahansa edellä olevaa kolmea tiedostoa, niin kyse on koko ajan kahdesta asiasta:

1. salliiko webhotelli muokkausta ylipäätään
2. jos sallii, niin mihin rajoihin asti

Salliminen on periaatteessa äkkiä kokeiltu. Avaa cPanel (jos olet webhotellissa, jossa ei ole cPanelia tai vastaavaa, niin vaihda äkkiä; olet autotallifirman asiakkaana).

Jos löydät valikoista PHP selectorin, ja pääset sielä PHP:n asetuksiin ja näet tällaisen tai samankaltaisen, niin saat muokata. Ainakin jossain rajoissa.

En ole noissa (muistaakseni) koskaan törmännyt max_input_vars asetukseen, mutta toki voit muuttaa esimerkin mukaan max_upload_size arvon. Mutta säätömahdollisuus saattaa juoruta siitä, että voit tehdä paikalliset asetukset.

Kokeile. Ei siitä mikään hajoa. Tai voi hajota, mutta ei lopullisesti.

Muutokset voivat aiheuttaa muutaman asian.

• Kaikki alkaa toimimaan, ja siihenhän on pyritty
• Kaikki on hyvin, mutta muutoksia ei näy missään. Silloin sinulla ei ole lupaa muuttaa mitään.
• WordPress kaatuu ja saat error 5xx virheen. Se antaa vahvan vinkin, että et saa muokata, joudut muokkaamaan jonnekin muualle tai ole tehnyt kirjoitusvirheen – yleisen on puuttuva puolipiste rivin lopusta tai jokin ylimääräinen merkki

Jos sivusto kaatuu, niin kommentoi risuaidalla (#) rivit ja kokeile, että toimiiko. Pitäisi ja sitten alat kokeilemaan rivi kerrallaan onko vika yhdessä määrityksessä vai että olet ylipäätään määrittänyt. Jos teit muutokset wp-config.php tai functions.php -tiedostoihin, niin poista niistä lisäykset ja kokeile miten käy .htaccess tai omalla php.ini -tiedostolla.

Järjestelmät ovat erilaisia ja webhotellit tekevät vielä erilaisempia ratkaisuja. Siksi mitään yleispätevää ohjetta on mahdotonta antaa. Tosin, jos sinulla on lisäykset .htaccess -tiedostossa ja saat Internal server error 500, niin se tarkoittaa käytännössä aina, että webserverin asetukset estävät omat muokkaukset.

Voit kokeilla laittaa tämän .htaccess -tiedoston alkuun. Oma villi veikkaukseni on, että se ei auta kotimaisen webhotellin kanssa (muista korjata ConfigPath).

<IfModule mod_suphp.c>
suPHP_ConfigPath /var/www/html
</IfModule>

Tai voit testata, että auttaako kun laitat nämä If-lausekkeet omien säätöjen ympärille (muista tarkistaa versio):

<IfModule mod_php7.c>

.. omat php_value rivit

</IfModule>

Kun ei voi itse muuttaa

Jos et saa itse muutettua webhotelli-ympäristössä, niin sitten et saa. Sen asian kanssa ei kannata kovin kauan riidellä. Ylipäätään jos upload_max_size arvoa lukuunottamatta mitä tahansa täytyy muuttaa, niin sitä varten heillä asiakaspalvelu. Kaikki mainostavat hyvää asiakaspalvelua, joten sitä kannattaa hyödyntää.

Pyydä, että he tekevät muutoksen. Kerro kuitenkin tarkkaan mikä arvo pitäisi muuttaa. Joko firma vaihtaa sen, tai asiakaspalvelun nimissä lähettävät sinulle tiedon mitä joudut itse säätämään. Mutta silloin tiedät mitä pitää muokata.

Asiakaspalvelujen suhteen kannattaa sitten muistaa, että kiire ei saisi olla. Hyvä asiakaspalvelu nimittäin tarkoittaa usein sitä, että he vastaavat jotain jollain aikavälillä. Jos haluat taatusti nopeat vastaukset, niin sinun oletetaan maksavan siitä palveluna kuukausittain ekstraa.

Jos vastaus on, että ei voida muuttaa, mutta pyyntösi on kohtuullinen, niin vaihda yritystä. WordPressin siirtäminen on melkoisen triviaali homma. Kyse on kuitenkin siitä, että jos valikkosi ei toimi siksi, että yhtä PHP:n asetusten arvoa täytyy nostaa, joka on rutiiniasia, niin mihin tarvitset moista ympäristoä? Sinä tarvitset toimivat sivut, ja se siitä – asiassa ei ole mitään keskusteltavaa.