WWW-sivujen kännyversiolle käyttöliittymä

Käytän Vivaldia, joka näyttää samoin kuin Chrome, sillä Vidaldi on vain ja ainoastaan chromium pohjalle rakennettu erilainen käyttöliittymä, mutta "moottori on sama". Katsoin sivuja sekä kirjautuneena että kirjautumatta. Kummassakaan tapauksessa virhettä ei tullut. Kun itse en saa kauneusvirhettä, en voi mitään muuttaa.
 
Mitä hitaututeen tulee, tyhjensin välimuistin. Sen jälkeen etusivulta foorumisivulle meni 14 sek. ja siitä eteenpäin 7s. Yhden funktion käsittelyn poisto pienensi aikaa 1 s.

Ohjelmointini on aika teoriapohjaista. Suurin ongelma siinä on se, että en osaa arvioida, mitä töitä PHP:tä pyörittävälle www-palvelimelle minkin oman lisäyksen käyttäminen merkitsee. Oma PHP-koodi on tietokantatietueissa, ei php-tiedostoissa. Ehkä pitäisi siirtää koodi lapsiteeman functions.php-tiedostoon. Oma ongelmansa on myös se, että tietokannassa olevaan php-koodiin ei voi tuoda tiedostoista include- tai require-toiminnoilla.

Myönnän, että hitaus on suurin ongelma ja ennen kaikkea se, etten tiedä, mistä se voisi johtua.
 
Viimeksi muokattu:
1619366946801.png

Tuon painikkeen putoaminen on korjattavissa helposti, ottamalla käytöstä pois nuo kaksi riviä:

CSS:
@media screen and (min-width: 783px)
#inner-cont, #top-buttons-container {
    position: fixed;
    /* top: 48px; */
    right: 0;
    /* width: 150px!important; */
    height: 48px;
    z-index: 1;
    overflow: hidden;
}

Tuo virhe näkyy iPad Pro ja sitä leveämpää näyttöä käyttävillä laitteilla, joka tapauksessa täysin tarpeettomat rivit ja joutavat pois.
 
Pidän mielessä. En nyt vain löytänyt tuota määritystä mistään. Mandollisesti jäänne leiskan edellisestä versiosta.

Voiko syynä olla se, että oma koodi tulee tietokannasta?
Oman koodin voisi siirtää functions.php-tiedostoon.
Etuna olisi se, että järjestys olisi luonnostaan oikein eikä sitä tarvitsisi miettiä.

CodeSnippet ei hyväksy include eikä require -toimintoja.

Voisiko muuten include tulla if-lausekkeen sisään, jos tiettyä koodia tarvitaan vain tietyssä tilanteessa? Kyse Html-koodista. Tällaista ei koskaan ole tullut esille.
 
Pidän mielessä. En nyt vain löytänyt tuota määritystä mistään. Mandollisesti jäänne leiskan edellisestä versiosta.

Se määritellään: https://www.sanaristikkofoorumi.net/wordpress/wp-content/themes/mobile_no_sidebars_nocolor.min.css

Mutta, siellä on käyttämättömiä CSS tiedostoja, jotka käyttäjät joutuvat lataamaan turhaan.

Eikä siinä kaikki, siellä on myös käyttämättömiä JavaScript tiedostoja:

MIKSI, olet asettanut vierailijoiden seurannan päälle ( oneallcdn.com ja oneall.com ), ja niin edelleen miksi kierrätät kuvat ( shortpixel.ai ) palvelun kautta. Sinun sivu on niin pirstaleina ympäri maailmaa, ettei mikään validaattori pysty sivustoa analysoimaan.
 
Ok. En olisi tajunnut etsiä no_sidebars... tiedostosta. Kun uudistin sivuja, en tullut tarkistaneeksi tätä tiedostoa. Täytyy siis tarkistaa pari tiedostoa, jottei niihin ole jäänyt jotain tarpeetonta.

Kylllä noi listaamasi CSS-tiedostot ovat käytössä. Genericicons.css olisi vaan kiva saada pois käytöstä, koska WP:n oma vastaava on käytössä. Teema käyttää sitä tosi vähän ja käytön voisi vaihtaa dashicons setin vastaaviin fonttikuviin.

block-library on ns. taustakäytössä oleva CSS-tiedosto. Frontend puolella editori todennäköisesti käyttää sitä.

JS-tiedostoille, joita listaat, en voi mitään. Ne on joko WordPressin omia tai lisäosien asentamia.

Oneal on some-kirjautumisten mahdollistaja. Muita tapoja some-kirjautumiseen en WordPressille löytänyt.

ShortPixel lupasi, että se skaalaa kuvat automaattisesti sopiviksi ja tallentaa DNS-palvelimelle. Lupasi nopeuttaa toimintaa, mutta idea ei taida toimia. Jos poistaa, voi joutua tekemään tietokoneajoja.
 
Kylllä noi listaamasi CSS-tiedostot ovat käytössä.

Voisit ainakin testata niiden tarpeellisuuden, kun kerta sinulle on osoitettu niiden tarpeettomuus. Nimeä ne X etuliitteellä, ja katso kuinka pahasti sivu hajoaa, ja kutsu minutkin katsomaan, muutoin en sanomaasi usko. Ja jos sinulla on uBlock Origin asennettuna, voit silläkin estää tiedoston käyttöön oton, siihen riittää kun laitat omiin suotimiin vaikka tämän, joka vaikuttaa otsakepalkin väritykseen:

 
Viimeksi muokattu:
Itse määrittämäni CSS-tiedostot tunnen. Tiedosto common.min.css on kaikkein keskeisin teeman tiedosto.

Mutta WP:n ja sen lisäosien asentamien tiedostojen tarpeellisuus voi olla vähän niin ja näin.

Se, että en nähnyt visuaalista ongelmaa valikon avaajan suhteen, johtui siitä, että minulla oli käytössä toinen CSS-tiedosto, nimittäin.
mobile_sidebars_nocolor.min.css

Kun muuttaa käyttäjäasetuksia, tietyillä määrityksillä muuttuu tietyt CSS-tiedostot. Tein ehdottamasi korjaukset ja ongelma korjaantui. Aina ei tajua testata kaikkea. Itse asiassa menetin työni koodaajana juuri siitä syystä, että kaikkia mahdollisia tilanteita ei tullut otettua huomioon. Selaimen toimivat myös PALJON eri lailla kuin nykyisin ja erot olivat todella paljon suurempia, hyvin vaikeasti hallittavia.
 
Viimeksi muokattu:
Eniten tässä masentaa sivuston hitaus, jonka syyt ovat mysteeri.
Eräs koodari ei ainakaan ulkoasua haukkunut. Seuraavan kaltaiset näkymät mobiililaitteissa ovat ensisijaisia.

Aihe: Sivuston mobiiliversio – Mobile version of this site | Sanaristikkofoorumi – sanaristikot & muuta pohdittavaa
Kestää toki varmaan iäisyys ladata sivu. Olen suht. tyytyväinen kuvakaappauksessa esitettyihin ulkoasuihin, mutta jos sivusto ei pelitä riittävän nopeasti, ulkoausta ei ole iloa.

PS. "Julkasu" on suomentajan moka, ei minun.
 
Viimeksi muokattu:
Minkälaisella palvelimella ne sivut on hostattu? Mietin, että voiko vika olla siinä eikä koodissa? Tuollaisen sivun ei kyllä pitäisi vaatia mitään kovin ihmeellistä sen puolesta.
 
Hostaus on entiseltä työnantajalta peruspaketti. Ei kuulu palvelimen cache eikä DNS. Chat-sivustoni koodaaja lähetti testisivun. Hänen mukaansa palvelin latasi sen nopeasti, joten hänen mukaansa syy on sivustossani.

Blogin ja foorumin yhdistäminen on ongelmallista.
  1. Kirjautuminen on suunniteltu blogin ylläpitäjälle. WP lisää kirjautuessa ylimääräistä. Ikävin foorumin kannalta on näkyvä palkki, jonka oletuksena piilotin. Mutta kun kirjautuminen lisää CSS:ssää, se tuo ongelmia elementtien sijoittelulle. Pitää aina olla varuillaan, miten sivu käyttäytyy kirjautuessa ja ei kirjautuessa. Ihan saman näköisiksi en onnistunut tilanteita saamaan. Asia on ollut iso riesa.
  2. WordPress ja bbPress eivät synkkaa koskaan hyvin keskenään, koska ei ole bbPressille optimoitua teemaa. bbPressille ehkä saa omia teemoja, mutta on hirveästi soviteltavaa. Teeman vaihto on siten viimeinen asia, minkä haluaa tehdä, koska edessä on uusi sovitteleminen. Ainakin uusi teema pitää väriteemaltaan ja perusrakenteeltaan olla mahdollisimman samankaltainen.
Tuli vähän turhan monimutkainen paketti, sillä CSS:n rakenteluun vaikuttaa seuraavat asiat:
  1. Laitteet - teema ei toiminut mobiilissa yli 782px arvoilla lainkaan. Piti rakentaa mobiiliverio uusiksi. Pitkään oli melkoisesti eri ulkoasu tietokoneelle ja mobiilille. Päädyin hylkäämään kokonaan alkuperäisen tietokoneversion valikkosysteemin ja suurelta osin perusrakenteenkin. Siitä on vain rippeitä. Pääpaino on kuitenkin toimivuus mobiililaitteissa. Tietokoneessa on eräs visuaalinen ongelma, jota mobiililaitteissa ei ole lainkaan. Suurin ero on Googlen haku. Googlen haulla on Googlen luoma CSS. Rakenne on niin kompleksi, että koin toivottomana saada haun saman näköisenä sekä mobiili- että tietokonelaitteille.
  2. Viewport - aluksi sekä WP että bbPress sekoilivat sen kanssa ikävästi. Oli iso työ selättää pahimmat viewport-ongelmat. Päädyin visuaalisesti mahdollisimman samankaltaiseen ratkaisuun kaikille viewport-arvoille. Vain välttämättömät eroavaisuudet laitoin, jotta tarvittavat linkit mahtuvat linkeille varattuun tilaan ja toisaalta linkit eivät olisi isolla näytöllä liian pieniä. Pääpaino on mobiilitoimivuudessa.
  3. Väriteemat - värit on pääosin erillisissä CSS-tiedostoissa.
  4. Käyttäjäasetukset - joillekin asetuksille on omia CSS-tiedostoja.
  5. Sivustoalueet. Nykyisellään liittyvät vain joihinkin linkkien korostuksiin eli hyvin vähäinen asia. Aiemmin mukana oli myös otsakekuvat. Niitä ei nykyisessä versiossa hoideta CSS:llä.
  6. Kirjautuminen/ei-kirjautuminen - se on pysyvä, mutta melko pieni ongelma. Sitä en koskaan saa täysin ratkaistua, mutta erot kirjautumisen ja ei kirjautumisen välillä ovat pienet. Ero koskee vain 783 px alle meneviä viewport-lukemia. Nykyisessä versiossa asian merkitys on hyvin vähäinen, mutta aiemmin ero oli häiritsevä, koska yläosassa oli taustakuva. Ainoa, mitä huomaa, on yläosan korkeuden pieni kasvu kirjautuessa. Senkin vain huomaan kun vaihtaa laitteen orientaatiota. Tuskin on häiritsevä. Ja vaikka olisikin, en ole asiaa onnistunut korjaamaan.
  7. Jotkut selaimet - tietyissä tilanteissa Chrome. Tämä yritys kyllä meni totaalisesti puihin. Joillakin mobiililaitteilla Chrome näyttää väärin, enkä saa korjattua asiaa.

Noissa on siis kokonaisuutta ajatellen pieniä ongelmia, mutta ne nyt ovat pieni murhe siihen nähden, että sivut toimivat hitaasti. Pitäisi varmaan yrittää kasata suurin osa PHP-koodista functions.php-tiedostoon ja jättää tietokantaan vain pienehköjä php-pätkiä. Suurin ongelma on se, että olen ihan pihalla, mikä on hitauden ydinsyy.
 
Mulla alkaa olemaan sellainen fiilis että tuota on niin monta kertaa tunkattu, viilattu, höylätty ja puukotettu sekä paikkailtu teipillä, rautalangalla ja purukumilla että tuosta vaan ei enää saa hyvää aikaiseksi muuta kuin vetämällä koko höskä matalaksi ja rakentamalla alusta.

Jos tuota PHP-koodia on osa kannassa ja osa fileinä, samoin css:ää, kaikenlaisia skriptejä on repullinen ja vähän joka filettä on ruuvattu vähän kokeilumielessä eikä ole ollut ihan tarkkaan tietoa lopputuloksesta, on viittauksia ympäri nettiä sun muuta niin tuossa on melkoinen suo setviä tuo kuntoon. Heti alkuun veikkaisin että CodeSnippet on tarkoitettu vain jollekin yksittäiselle pikku koodinpätkälle ja veikkaisin että jos sitä käyttää enemmänkin niin se on ainakin yksi pullonkaula, kuten ylipäätään koodin lataaminen kannasta.

Ylipäätään tuossa sivustossa on myös paljon sellaisia asioita jotka mielestäni ovat älyttömiä eli lähinnä toimivat aivan eri tavalla kuin kaikkialla muualla mutta eipä niistä sen enempää kun niistä on väitelty tässä ketjussa jo aiemmin enemmän kuin riittämiin.
 
Ylipäätään tuossa sivustossa on myös paljon sellaisia asioita jotka mielestäni ovat älyttömiä eli lähinnä toimivat aivan eri tavalla kuin kaikkialla muualla mutta eipä niistä sen enempää kun niistä on väitelty tässä ketjussa jo aiemmin enemmän kuin riittämiin.
Tätä minäkin olen hymähdellyt ketjun alusta lähtien. Roskiin vaan koko hässäkkä ja best practise -linjauksia noudattaen ja kaikki tällaiset ihmeelliset viritykset unohtaen uutta tulille.
 
Mulla alkaa olemaan sellainen fiilis että tuota on niin monta kertaa tunkattu, viilattu, höylätty ja puukotettu sekä paikkailtu teipillä, rautalangalla ja purukumilla että tuosta vaan ei enää saa hyvää aikaiseksi muuta kuin vetämällä koko höskä matalaksi ja rakentamalla alusta.

Jos tuota PHP-koodia on osa kannassa ja osa fileinä, samoin css:ää, kaikenlaisia skriptejä on repullinen ja vähän joka filettä on ruuvattu vähän kokeilumielessä eikä ole ollut ihan tarkkaan tietoa lopputuloksesta, on viittauksia ympäri nettiä sun muuta niin tuossa on melkoinen suo setviä tuo kuntoon. Heti alkuun veikkaisin että CodeSnippet on tarkoitettu vain jollekin yksittäiselle pikku koodinpätkälle ja veikkaisin että jos sitä käyttää enemmänkin niin se on ainakin yksi pullonkaula, kuten ylipäätään koodin lataaminen kannasta.

Ylipäätään tuossa sivustossa on myös paljon sellaisia asioita jotka mielestäni ovat älyttömiä eli lähinnä toimivat aivan eri tavalla kuin kaikkialla muualla mutta eipä niistä sen enempää kun niistä on väitelty tässä ketjussa jo aiemmin enemmän kuin riittämiin.

Epäilen itsekin, että syyllinen voi olla CodeSnippet, jota on käyttänyt liian isojen kokonaisuuksien kanssa. Lienet oikeassa sen käyttötarkoituksesta.
Olen koodannut nyt niin, että oma koodi olisi function.php + siihen liitetyissä tiedostoissa include avulla. Kaikki include-komennot, jotka pystyy, olen laittanut if-lausekkeiden taakse, jolloin php-koodia lisätään vain kun se on ehdottoman välttämätöntä.

Aion edelleenkin tehdä ihan omalla laillani. Kyllä se VALIKOT + sen välilehdet ovat toimiva ratkaisu. Vihaan sijoittelua sinne sun tänne. Uskon, että all-in-one-ratkaisua vielä joskus arvostetaan, mikäli vain saan sivustoni toimimaan riittävän nopeasti.

Jotta sivusto ei kaadu ihan heti, pitää vaihtaa eri teema. Sen jälkeen CodeSnippet pois käytöstä ja hyvällä onnella uusi systeemi pelaa.
PHP:n syntaksi pitää ensin tarkistaa CodeSnippetin avulla. Turvallista, jos ei aktivoi koodia.

CodeSnippet ehdoton hyvä puoli on 100% luotettava syntaksin tarkistus!


Tuon tarkistus ei ole täysin luotettava. Tarkistin kohdan, jossa väitti virheen, mutta sitä ei ollut. Jos on CSS:n tuottamista välissä, sekoilee ja antaa vääriä ilmoituksia. Kun tarkistin CodeSnippetillä, se ei valittanut olemattomasta virheestä.

Onko luotettavampaa koodintarkistussivua.
 
Viimeksi muokattu:
Ei onnistunut. Ongelmana on nyt, että en tiedä, mistä kiikastaa. WordPress ei kerro tarkkaa syytä.


Tuttu epäili palvelinongelmaa.
Nyt väliaikaisesti teema ja bbPress ilman ainuttakaan muutostani.

Jos nyt toimii hitaasti, vika on palvelimessa. Käyttämäni palvelu ei riitä foorumin pyörittämiseen.


Tuo nyt testaa, onko kyse palvelinongelmasta vai ei. Tuon pitäisi pyöriä moitteetta.

Eräs toinen teema olisi lähtökohtaisesti parempi. Se ei tarjoa mobiiliin siinä huonosti toimivaa pudotusvalikkoa.
 
Viimeksi muokattu:
Ei onnistunut. Ongelmana on nyt, että en tiedä, mistä kiikastaa. WordPress ei kerro tarkkaa syytä.


Tuttu epäili palvelinongelmaa.
Nyt väliaikaisesti teema ja bbPress ilman ainuttakaan muutostani. Jos nyt toimii hitaasti, vika on palvelimessa. Käyttämäni palvelu ei riitä foorumin pyörittämiseen.


Tuo nyt testaa, onko kyse palvelinongelmasta vai ei. Tuon pitäisi pyöriä moitteetta.
Ihan yhtä hidas. Laita sinne juureen joku yksittäinen tiedosto ilman mitään näitä foorumivirityksiä ja testaa sillä.
 
Testattu. Toimi sillä. Mutta kun sivuston pitäisi toimi muuttamattomilla WordPress & bbPress -kombinaatiolla moitteetta. Jos ei toimi, ei palvelimen antama kapasiteetti riitä tämän parin nopeaan suorittamiseen. Tosin WordPress etsii joitakin ns. shortcode-asetuksia, jotka nyt on pois käytöstä ja tulee tilalle vain [jotain]. Tuskin jokin puuttuva shortcode on olennainen asia, koska jos ei ole määritystä [jotain] on vain tekstiä.

Jos palvelimelta annettu kapasiteetti ei riitä, ei toimi minkään teeman kanssa, jos ei sitten jotain teemaa ihan rajusti yksinkertaista. Tuskin pystyy yksinkertaistamaan tarpeeksi, sillä bbPress käyttää joka tapauksessa resurseja.

Laitan päälle toisen teeman. Tämä on lähtökohditaan parempi, sillä mobiiliin ei tarjota pudotusvalikkoa millään leveyksillä. Jos muuttaa tälle kaiken paremmin sopivaksi, hirveä työ siinäkin on. Tuskin yhtään nopeampi. Jos tällä kombinaatiolla ei toimia riittävän nopeasti, ei mahdollisuuksia toimia koskaan nykyisellä palvelulla.
 
Viimeksi muokattu:
Minun ratkaisu tähän sivusto ongelmaan, oli tämä:
! 2021-04-26 TechBBS
bbs.io-tech.fi##.threadListItemIcon-default.js-threadListItem-174768
bbs.io-tech.fi##.threadListItemIcon-default.js-threadListItem-233247
*sanaristikkofoorumi.net
 
Minun ratkaisu tähän sivusto ongelmaan, oli tämä:
! 2021-04-26 TechBBS
bbs.io-tech.fi##.threadListItemIcon-default.js-threadListItem-174768
bbs.io-tech.fi##.threadListItemIcon-default.js-threadListItem-233247
*sanaristikkofoorumi.net
Foorumin ylälaidassa olisi ollut myös tällainen:

1619439620824.png
 
Ollaanpa sitä kannustavia.

No tein vielä sen, että otin pois ulkomaisen DNS-palvelun, joka lupasi nopeuttaa sivujen latausta, mutta ei tainnut sitä tehdä.
 
Paljon tyylikkäämpi ulkoasu muutes tuolla oletuksella, tosin edelleen hidas kuin mikä.

Hieman kun vielä tusaa sillä omalla tyylillä, niin ehkä se siitä nopeutuu..
 
Lighthouse antaa hitauden syyksi turhat CSS ja JS tiedostot ja hitaan palvelimen. Voiko olla että yksittäisen asian muuttaminen ei vaikuta nopeuteen huomattavasti mutta jokainen vaikuttaa pikkasen ja huomatakseen eron pitäisi korjata useampi asia?

Screenshot 2021-04-26 at 16.45.48.png
 
Millähän sitä turhaa JS:ää ja CSS:ää lasketaan? Osa määrittämästäni WordPressin ja bbPressin CSS:stä oli sellaista, että se ei ollut käytössä kuin tietyillä ehdoilla. WordPressin teeman ja bbPressin alkuperäiset CSS-tiedostot olivat pois käytöstä. Omaa JS olen luonut vähän.

Lisäosien CSS:lle ja JS:lle en voi mitään, en myöskään WordPressin asentamalle CSS:ssä, sillä siitä saattaa koitua vakavia toimintaongelmia.

CSS ja JS määrälle en voi paljoakaan tehdä. Ainoa mitä voin, on WordPressin teeman ja bbPressin tarvitseman CSS:n karsiminen manuaalisesti minimiin.
Ajattelin sekä vähän lisätä CSS että omaa koodia ja poistaa tarpeetonta CSS:ää.

No jos silläkin hidas, sitten vaan kyse on siitä, että palvelimessa pitäisi olla enemmän tehoa. Palvelun tarjoaja pitäisi vaihtaa. Näillä nopeuksilla foorumi on enemmänkin kehittelyharrastus kuin toimiva foorumi.

Lisään tai poistan jotain, tuskin sillä nopeuden suhteen suurta merkitystä on. Pitäisi maksaa kunnolla, että saisi kunnon palvelun.
 
Viimeksi muokattu:
Millähän sitä turhaa JS:ää ja CSS:ää lasketaan?
Kaikki mitä ei oikeasti tarvita, on turhaa. Ihan sama mistä se koodi on peräisin.

No tein vielä sen, että otin pois ulkomaisen DNS-palvelun, joka lupasi nopeuttaa sivujen latausta, mutta ei tainnut sitä tehdä.
Mietipä vähän itsekin, että mikä on DNS:n tarkoitus ja että voiko sitä vaihtamalla saada palvelinpäässä jotain merkittävää nopeusetua asiakkaan suuntaan? Kaikki tällaiset ihmeelliset härväykset kun kasataan yhteen, niin lopputulos on helposti sellainen sillisalaatti ettei sitä perkaa kukaan. Keep it simple ja silleen.

Ja kuten aiemmin sanoin, palvelimelta pitää odotella vastausta 5-6s ennen kuin tapahtuu mitään.
 
Taisi joo mennä. ShortPixel tarjoaa CDN-palvelun omalla palvelimellaan. On ties missä, joten onko siitä enemmän hyötyä vai haittaa?
 
Kokeilen nyt rakentaa uuden teeman pohjalta, jättäen vielä paluun edelliseen. Se hyvä puoli edellisen teeman CSS:tä on, että foorumille tekemäni CSS sopii täysin uudemmalle teemalle. Ei tällä nopeuden suhteen merkitystä ole.
 
Kokeilen nyt rakentaa uuden teeman pohjalta, jättäen vielä paluun edelliseen. Se hyvä puoli edellisen teeman CSS:tä on, että foorumille tekemäni CSS sopii täysin uudemmalle teemalle. Ei tällä nopeuden suhteen merkitystä ole.
Todennäköisesti tällä on merkitystä nopeuden suhteen. Käy lataamassa Lighthouse plugari niin näet mitkä tiedostot vie aikaa. Lighthouse | Tools for Web Developers | Google Developers

Teeman mukana tulee mm SwiperJs mitä en ainakaan nopeasti löytänyt sivulta käytöstä, teema on muutakin kuin pelkkä CSS. Sivulle ladataan myös jQuery ja Bootstrapilta paljon tauhkaa mitä ei käytetä. jQuerya ei tänä päivänä tarvitse ja Bootstrapista ei tarvitse tarjoilla kokonaan vaan ottaa siitä vain tarvitut palat.
 
Mutta jos teemaa haluaa siivota, täytyy tietää, mitä tekee. Osaan teemassa muokata HTML-rakennetta ja CSS:ää. Teeman JS:n hallintaan en uskalla koskea.
Kokeilin tätä teemaa siksi, että havaitsin heti, että bbPressille rakentamani CSS sopii sellaisenaan uudelleen teemalle. Minulle teeman valinnassa tämä on olennaista, sillä bbPressin CSS:n editoinnissa oli paljon töitä.

Teeman CSS:ää vilaisin. Sitä on jopa enemmän kuin mukauttamassani versiossa. Foorumialue jää oletuksena tässäkin liian kapeaksi paitsi tablet-laitteiden pystyasennossa ja kännyköillä pystysuunnassa. Sisältöalue jää usein ikävän kapeaksi. Sain sellaiseksi, että sisältöalue ei missään tilanteessa ole turhan kapea.

Sain foorumiosion muutamalla pikku korjauksella melkein kuntoon. Leivänmurut lähinnä rikki. Tosin muualla kuin foorumiosiossa ne on huonoja, sillä muotoileva CSS puuttuu.

Se kehitystyökalun turhien tiedostojen ilmoitus ei ole ollenkaan luotettava vaan pitää tarkistaa, onko ilmoitus oikein vai väärin. Minulle kerrottu "turha" CSS oli totaalisen väärää tietoa. Ensinnäkin edellinen teema ihan oikeasti käytti genericons-ikoneja. Tiedän, missä se niitä käytti. Käytti hakupainikkeessa sekä eräissä nuolissa. Hakupainikkeelle oli genericons-setti, koska dashicons-setin hakupainike on liian karkeapiirteinen eikä sopinut teemaan. Nuolet olisi voinut hakea dashicons-setistäkin. Siis aivan selvä virheilmoitus. Vielä selvempi virhetieto oli common.min.css, joka on teeman eniten käytetty CSS-tiedosto.
 
Viimeksi muokattu:
On tämä nyt merkittävästi nopeampi, vaikka ei kehuttava. Tyhjensin välimuistin tietokoneelta. Etusivulta seuraavalle aikaa meni 5-6s. Sen jälkeen aikaa sivulta toiselle meni n. 3,5 s.

Onhan tuo luku hidas verrattuna Suomi24:ään, jossa homma hoituu sekunnin sisällä.

Tämä sivusto toimii hitaammin kuin Suomi24.

Tyhjensin välimuistin.
Foorumi -> softakeskustelu n. 3,5s. Softakeskustelu tähän n. 2 sek.

Jää siis nopeudessa Suomi24 ja minun sivustoni väliin. Minun toimii viime mittausten pohjalta noin puolta hitaammin kuin tämä sivusto. Miksikään nopeasti toimivaksi sivustoksi tätä ei voi kutsua.

Kyllä tämän kanssa pärjää, mutta pärjäänkö omani. Saan sen kyllä nätiksi ja pienin parannuksin näppärämmäksi, mutta ehkä siitä ei nykyisin käytossä olevin resurssein ole suurta iloa.

Osa teeman turhasta CSS:stä on se, että siinä on samassa taustakäytön editorin CSS. Sitä en kaipaa. Sen vois heivata kokonaan pois. Ei turhan CSS:n hiivaamisella paljoa nopeutta lisää saane.
 
Viimeksi muokattu:
Laitoin sponssikyselyn, johon sai agressiivisen vastauksen.

Foorumeiden erilaisesta luonteesta - Sanaristikot - Suomi24 Keskustelut

Olette oikeassa siinä, että hitaus on suurin ongelma. Täytyy yrittää saada tämä uusi teema toimimaan kunnolla. Mistään suurista asioista ei ole kyse. Voin yrittää sen jälkeen vielä kysyä palvelun tarjoajalta, jos hän sponssaisi lisää tehoa.

Uuteen teemaan tarvitisin yhden konkreettisia JavaScript neuvoja. Haluasin, että sen jälkeen kun sivua on rullattu tietty pikselimäärä, valikon avaaja siirtyy n. 100px kohdalle sivun yläreunaan ja valikko siirtyy sivun yläreunaan ja sille tulee tarvittaessa vierityspalkit. Samassa yhteydessä tulisi myös nuolet ylös ja alas. Ne voisin kyllä laitttaa ihan kiinteksikin eikä vasta liikuteltaessa ilmestyviksi kuten täällä. Kivahan se olisi, jos nuolet toimisivat samoin kuin täällä, mutta ei ole mitenkään olennaista. UNOHDA TÄMÄ - EN KAIPAA TÄTÄ.
 
Viimeksi muokattu:
Siirrän suuren osan CodeSnippet-datasta functions.php-tiedostoon tai sen hakemaksi. Pitää vain jokainen siirto testata erikseen ja pitää olla edellisestä aina varakopio, jonka saa hetkessä palautettua, jolloin katkos on vain n. 10 s. luokkaa.
 
Miksi et vaan osta kunnollista maksullista teemaa, joka hanskaisi kaikki nämä asiat ilman jatkuvaa "koodissa" säätämistä ja sitä kautta sivuston rikkomista ja saisit samalla tyylikkäät sivut näkyville?

Yleensä niissä "kunnollisissa" maksullisissa teemoissa on valmiiksi tuhat ja yksi vipua, jota kautta saisit säädettyä sivun ihan sellaiseksi kuin haluat ja samalla varmistuisit, että sivut toimisivat kaikenlaisilla päätelaitteilla.

Kertasijoituksena 50$ ei ole paljon, kun katsoo tätä jatkuvaa ja loputonta säätämistä. Eri asia sitten jos haluaa keksiä polkupyörän uudestaan ja harjoitella sivujen rakentamista, mutta localhostissa ne pitäisi tehdä, eikä suoraan palvelimella.
 
Joitakin asioita haluan rakentaa uudestaan ja pyysin uudelleen rakenteluun apua kommentissa #773. Sen saa kyllä unohtaa. Avaus/sulku painike toimii kyllä ihan kiinteänäkin. Ainoa, mikä siinä harmittaa, on se, etten saa painikkeelle taustaväriä. Kun valikko on kiinteä, mutta tarvittaessa rullautuu, pysyn rakentamaan valikon yhteyteen ihan mitä ikinä päähän juolahtaa.

Valikkoon lisäisin kolme erikoispainiketta jQueryn avulla. Sen osaan. Yksin toteuttaa haun, yksi toiminnot ja yksi aiheet. Ikävintä tässä on se, että pitää käyttää Googlen hakua, jotta saa kattavan haun. WordPressin normaali haku ei hae foorumeilta. Foorumien haku koskee vain foorumeita. Vain kolmannen osapuolen haulla voi hakea kaikkialta. Google haku vain on kovin erilaisen näköinen mobiilissa ja tietokoneella, mistä aiheutuu harmia. Toki ehkä lapsiteemalla voisi Googlen haun CSS:n määrittää samaksi, jolloin tästä riesasta pääsisi eroon. Todella ärsyttävä piirre kannaltani. Hakua on erittäin hankala saada sopimaan valikkoon.

Sitäpaitsi maksullisesta teemasta ei ole mitään hyötyä, jos se ei ole varta vasten tehty bbPress kanssa toimivaksi.
WordPressille on Woocommercelle varta vasten tehtyjä ilmaisia ja maksullisia teemoja. Vastaavaa en ole bbPresille löytänyt.
Niin kauan kun ei ole varta vasten bbPressille suunniteltua teemaa, ei teemasta kannata maksaa mitään.
Ihan sama säätäminen tulee vastaan maksullisen teeman kanssa, joka ei ole varta vasten bbPressille suunniteltu. Kuten kerroin tämä, minkä vaihdoin, sopii parhaiten yhteen edelliselle teemalle rakentamalleni CSS:lle. Muutosten tarve on hyvin pieni. Pienempää muutostarvetta en edes osaa ajatella.

Mitä nykyiseen tilanteeseen tulee, nykyinen sivuston "foorumi" ei toimi foorumina, koska se on foorumiksi yksinkertaisesti liian hidas.
N. 3,5s odotus toiselle sivulle siirtymiseen ja uuden kommentin näkymiseen sivulla on vaan yksinkertaisesti liian paljon.

Mutta blogin osana tuokin aika toimii, sillä blogia luetaan eri lailla kuin foorumia. Blogia luetaan yleensä pidempään ja sitten siirrytään muualle.
Nykyisellä "nopeudella" "foorumi" toimii siis vain blogin osana, paikkana jonne laittaa tiettyä ristikkoa tai muita asioita koskevia kommentteja.

Jos siis haluaisin kunnolla toimivan foorumin, ei rahaa kannattaisi tuhlata maksulliseen teemaan, koska se ei auta mitään foorumin rakentamisessa vaan tuo vain lisäharmia. Sijoittaa pitäisi tehokkaampaan palvelimeen. Mutta siihen en juuri nyt ole valmis.
 
Viimeksi muokattu:
Teeman CSS:n yritin sellaisen muutoksen, että siirstäisin mobiilivalikon aloituskohdan 1280px kohdalle. Pudotusvalikko alkaisi 1281px kohdalta.

Siirtopisteen sain 1141px kohdalle. Tiedän, että iPad Pro saa sen piip ärsyttävän pudotusvalikon, joka on *piip piip piip* ärsyttävä kosketunäytöllä. Kuka *piip* tarjoaa sellaista kosketusnäytölle, ihan idioottimaista.

Pudotusvalikko on äärimmäisen huono kosketusnäytölle eikä se saisi tulla millekään kosketuslaitteelle. Sitä ei voi tietokoneellekaan kiinteäksi laittaa, sillä pystytila loppuu kesken. Haluasin siitä kokoaan eroon, mutta tuo taitepisteen siirto nyt vielä riitä. Pitää selvittää asiaa vielä.
 
Viimeksi muokattu:
Siirtohommassa tuli outo juttu. Kun laitoin functions.php-tiedostoon näin
Koodi:
if(is_bbpress()){
    include '/wordpress/wp-content/themes/screenr-child/stylepack.php';
    include '/wordpress/wp-content/themes/screenr-child/tinymce.php';
}
Palvelin ei löytänyt tiedostoja. Sen näki siitä, että editorissa ei näkynyt muutoksia. Olen CSS-tiedostot linkittänyt tuohon tapaan eli suhteessa palvelimen juuren ja ne ovat löytyneet. Ei löytynyt myöskään
Koodi:
include 'tinymce.php';
Nettituttu kertoi, että include pitäisi toimi ehdollisenakin. Ei auta vaikka ottaa ehdot pois. Voiko olla mahdollista, että include on functions.php-tiedostossa estetty?

No jostakin ihme syystä sama koodi toimi CodeSnippet kanssa, mutta eipä toimi functions.php, vaikka laittaa sen sinne suoraan. Ainakin jotain koodia on pakko laittaa CodeSnippet avulla.
 
Viimeksi muokattu:
Laitoin aukeavan/kasaan menevän navigaation kiinteäksi. Hieman tietokoneella tarvittaessa esiin tuleva vierityspalkki on ruma. Sen saa pienemmäksi ja eri väriseksi jos kiusaa tai kokonaan pois näkyvistä. Sitä vaan en ymmärrä, miksen saa painikkeelle hieman taustaväriä?
Koodi:
@media screen and (max-width:1141px){
#nav-toggle{position:fixed!important; right:0px!important;padding-right:10px;top:48px!important;display:block;background-color:rgba(0,0,0,0.2))!important;border-radius:3px}
#nav-toggle span::before,#nav-toggle span::after{background-color:rgba(0,0,0,0.2))!important;}
#site-navigation ul.nav-menu {position:fixed!important;top:116px!important;right:0!important;overflow-y:auto;overflow-x:hidden;z-index:100000000000000000}}

Kysyin kyllä asiasta teeman foorumissakin. Kai siellä joku osaa vastata. Antaa olla. Ei vaivan arvoista keneltäkään. Painike häviää sivun yläosan tummiin osiin, mutta taustattomana on jatkossa häiritsemättömpi.
 
Viimeksi muokattu:
Mobiililaitteen tyypillisillä leveyksillä ulkonäkö pitäisi olla ok paitsi tekstialueen leveyden suhteen. Pientä hiomista tietenkin riittää.

Isolla näytöllä header-osa on ongelmallinen. Selain ei aina lataa koko osaa. Ns. leivänmurujen saaminen toimimaan leveällä näytöllä oli vaikeaa eikä se ole nytkään ongelmatonta. Pitäisi päästä kokonaan eroon pudotusvalikosta! En saa sivuja haluamakseni niin kauan kuin jollekin selaimelle on pudotusvalikko. En nimittäin saa siististi toteutettu sen kanssa sitä, mitä tavoittelen. Sen on minulle todellinen murheekryyni.
 
WordPressillä on paljon englanninkielisiä alafoorumeita. Olisi kivempi ihan suomeksi kysyä apua. Suomenkielinen tuki on aika pientä. Tiedän, että tämän foorumin yhdellä aktiivisella osallistujalla on kokemusta WordPressistä.

Haluaisin screenr-teemaan tehdä sellaisen radikaalin muutoksen, että haluaisin päästä kokonaan eroon teeman oletusnavigaatiosta, jota se käyttää yli 1140px viewport-arvoilla.

Kun mobiilileveyksillä katsoin lähdekoodia, siinä näkyy vain oletusvalikko. Mobiilivalikossa on CSS:lle luokkia, joita lähdekoodissa ei näy.Valikolle luodaan luokkia "lennosta" JavaScriptillä.

Haluaisin jQueryä hyödyntäen luoda valikkoon toiminnallisuuksia, joita ei siististi saa toteutettua kuin mobiilivalikkoon. Lisäksi ongelmana on se, että jos mobiililaitteen viewport on vaakasuunnassa yli 1100px, se oletuksena saa äärimmäisen huonosti kosketusnäytölle soveltuvan valikon. Pudotusvalikko olisi saatava toiminnasta. Sen sain pois toiminnasta poistamalla siihen liittyvän CSS:n, mutta sitten leveälle näytölle en saa valikkoa ollenkaan, koska mobiilivalikon käyttämiä luokkia ei ole olemassa!

Löysin taitekohdan määrityksen ja muutin sitä theme.js-tiedostossa, jossa se on määritelty.

Koodi:
jQuery( document ).ready( function( $ ){

    var mobile_max_width =  6000; // Media max width for mobile
Mutta mitään ei tapahtunut - edelleen pukkaa sitä hiivatin pudotusvalikkoa eikä mobiilivalikko tule tilalle.
Poistin pudotusvalikon CSS:n tyylitiedotostakin.

Koska pudotusvalikko ei toimi lainkaan ajattelemissani systeemeissä, jos jollakulla on yli 1140px näyttö, valikko ja haku yksinkertaisesti eivät ole käytössä ollenkaan. Sivuja voi leveällä näytöllä navigoida vain ns. leivänmuruilla.

Laitoin kyllä asiasta säikeen myös Suomen tukifoorumille:
 
Viimeksi muokattu:
Laitoin uuden säikeen vartavasten WordPress-ongelmista.
 
Ei nyt pahalla, mutta kehitätkö sä tätä livenä?

Menen https://www.sanaristikkofoorumi.net/ niin etusivuna on blogi, josta ei pääse muualle.

1619718021266.png


Tuosta kun painaa, niin avautuu kyllä tällainen:

1619718050535.png


Ja aivan järjetön viive noita sivuja avatessa...
 
Viimeksi muokattu:
Tuli kehitettyä livenä.

Sivulla pystyy pääsemään eteenpäin, jos laitteen viewport-arvo EI ylitä arvoa 1140px. Jos ylittää, sivustolta puuttuu kokonaan päänavigointi syystä, etten etten halua sellaista navigointia, jota teema oletuksena tarjoaa. Siitä ei saa kivasti toimivaa yli 1140px arvoilla sitten millään. Tulee aina lopputulos, jota itse inhoan enkä haluaisi kenellekään antaa. Tämä on siis suurin ongelma kehittelyssä.

Juuri siksi tein toisen säikeen nimen omaisesti WordPress koodaamiseen liittyen. Kyseessä on spesifisesti WordPressin ongelma.


Etusivu pitäisi saada kivemman näköiseksi kuin se oli ennen. Siksi yritin kokeilla, josko teeman tarjoamasta etusivusta saisi paljon kivemman näköisen kuin mikä on entinen vähän tylsänoloinen etusivu. Ainakin entisen oloista etusivua pitäisi parannella jotenkin.

Tuo etusivun sivutyypin laittaminen erityiseksi etusivuksi oli hetken kokeilu, mutta en keksinyt, miten tuota voisi muokata. Pitäisi varmaan jostain kaivaa dokumentaatio, miten ton etusivun saisi mieleisekseen. En löytänyt teeman asetuksista riittävästi kohtia.

Lakin joskus sekunttarista edellisen teeman kanssa, että sivulta toiseen siirtyminen vei tavallisesti 3-4 sekuntia sen jälkeen kun oli parilla sivulla liikuttu (tyhjensin ensin selaimen cashen). Eka siirtymä cachen tyhjennyksen kanssa vei enemmän aikaa. Tiedän, että hitaus on sivuston suurin ongelma. Sivuston pitäisi toimia ainakin n. neljä kertaa nopeammin ollakseen varteenotettava foorumisivusto. Nyt se on vain ulkoasudemo ja se ulkoasukin meni kehittelyksi teeman vaihdon myötä, vaikka paljon vanhasta teemasta sain myös mukaan.

Ajattelin, jos uudemmalla teemalla toimisi vähän nopeammin. Sillä on saatavissa ainakin kauniimpi lopputulos.

Uudessa teemassa on nyt sekä pääteemaa että lapsiteema. Lapsiteemassa muokkauksen jälkeen tuli liian iso fontti, alkuperäisessä on liian pientä. Laitoin nopsasti foorumiin pikakorjauksen, joka toimii kohtuullisesti.
 
Viimeksi muokattu:
Muusta nyt en tiedä, mutta iPad 2020 mallilla näkyy hampurilainen oikealla, josta pääsee navigoimaan foorumia. Toki vähän epäselvästi tuokin näkyvillä. Eli vain kolmena mustana viivana. Muuten samoin näkyy mitä tässä pöytäkoneellakin Chromella (2560x1440).
 
Teemassa hampurilaiselle ei ole tekstiä. Toki sellaista voisi yrittää lisätä. Kun painike jää sivun yläreunaan teksti häviäisi näkyvistä. En osaa toimintoa siististi koodata. Jos teksti vain rullautuu pois, se näyttää vähän hassulta. Sen pitäisi siihen asti jäädä näkyviin, kun sivua on rullattu niin kauan kuin ollaa ohitettu se kohta sivua, jossa hampurilainen sijaitsee. Toki netistä löytyy varmasti jostakin siistin koodauksen ohjeet.

Kyllä se hampurilainen Chromellakin näkyy, jos kavennat ikkunan alle 1141 leveyteen ei alle puolenvälin näyttösi leveydestä.

Hampurilainen näkyy perus iPadilla, siis 9,7:lla. Muistan lukeneeni, että joissakin iPad Pro -malleista vaakasuuntainen viewport-arvo on 1340px tai jotain sinne päin. Tällöin päänavigointia ei ole ollenkaan.

Yksi ongelmista, mikä tässäkin säikeessä on tullut esille on se, etten ole onnistunut laittamaan hampurilaiselle taustaväriä. Kun se hampurilainen jää kiinteäksi sivun reunaan ja sivulla on tummat leivänmurut ja sen alapuolella väillä tumma otsakekuva, käy niin, että se ikään kuin häviäisi jonnekin. En sitten millään ymmärrä, miksen saa sille määriteltyä taustaväriä. Ei kai se taustavärin puute iso asia ole. Kyllä se yleensä on näkyvissä ja jos tarkkaan katsoo, kyllä sen erottaa aina, jos tausta ei ole #fff. Ongelma on pienimpiä eikä ole kovin korkealla prioriteettilistassa. Kysyin asiasta teeman foorumissa, mutta en ole apua saanut.

Jos jätetään huomiotta hitaus, pahin ongelma 1141+ näytöt. V*** niin ***, että en keksi ratkaisua.
 
Viimeksi muokattu:
Tuo on vähän hankala kun nykyään porukalla alkaa olemaan niitä 1440p näyttöjä. Jos asian tietäisin niin kertoisin. Itse en tiedä mitään webbi hommista. Lohdutan, että vähemmän kuin sinä.
 
Näytön resoluutio sinänsä ei kerro juuri mitään paitsi tietokoneella. Mobiililaitteilla näytön todellinen pikselimäärä jaetaan jollakin kertoimella sellaiseksi, joille sivut suunnitellaan.
Kännykässä voi olla vaikka 2700x4000 näyttö, mutta se saattaa teeskennellä selaimelle, että se on kännykän leveys on vajaa 400px. Olennaista on laitteen selaimelle ilmoittama viewport-arvo.
Jos tablet-laitteessa on täsmälleen sama pikselimäärä kuin kännykässä, tablet-laitteessa sivut näkyvät jotain 700x1000px luokkaa.
En muista tarkkoja arvoja. Laitevalmistaja suunnittelee viewport-arvon sen mukaan, minkä katsoo kunkin kokoiselle laitteelle olevan järkevää.
Kun iPad Pro 12,9 on isohko laite, valmista nostaa viewport-arvon perustabletteja korkeammaksi.
Sivut näkyvät sen hampurilaisen kanssa kaikille muille mobiililaitteille paitsi ei iPad Pro 12,4, eikä ehkä muillekaan iPad Pro malleille. Kun laitteen kääntää pystysuuntaan, nykyy niissäkin. Mobiilissa vain iPad Pro on minulla ongelma. Tietokonepuolella käytännössä kaikki tietokoneet.
 
Viimeksi muokattu:
Todennäköisesti tällä on merkitystä nopeuden suhteen. Käy lataamassa Lighthouse plugari niin näet mitkä tiedostot vie aikaa. Lighthouse | Tools for Web Developers | Google Developers

Teeman mukana tulee mm SwiperJs mitä en ainakaan nopeasti löytänyt sivulta käytöstä, teema on muutakin kuin pelkkä CSS. Sivulle ladataan myös jQuery ja Bootstrapilta paljon tauhkaa mitä ei käytetä. jQuerya ei tänä päivänä tarvitse ja Bootstrapista ei tarvitse tarjoilla kokonaan vaan ottaa siitä vain tarvitut palat.

Ystävä hyvä, olet ymmärtänyt väärin, mitä tarkoitetaan turhalla. Vai oliko se joku toinen henkilö, joka ehdotti koko tiedoston poiston. Niin ei tule tehdä, sillä sitten sivusto on totaalisen rikki.

Se, että ilmoitetaan tietty tiedosto, ei tarkoita, että tiedosto itsessään on turha, vaan sen sisällä on paljon turhaa. Jokainen WordPress teema luo jokaiselle sivustolle automaattisesti hyvin paljon turhaa CSS:ää ja JS:ää. Näin siksi, että teema määrittää, miten WordPressin jokainen vakiolisuke pitää näkyä ja toimia. Sen lisäksi teema määrittää omia lisukkeitaan ja niille CSS:ää ja JS:ää. Nettisivujen rakentaja ei koskaan käytä kuin vain osan määritellystä CSS:tä ja JS:stä.

Tajusin, että strategia on p***stä. Luomalla lapsiteeman, sivuston ylläpitällä on mahdollisuus siivota turhat pois. Ilman lapsiteemaa siivoamiseen ei pidä ryhtyä, sillä muutokset häviävät teeman päivityksen yhteydessä.

Järkevä strategia olisi, että CSS ja JS otetaan käyttöön sen mukaan kuin niitä tarvitaan. Osaan kyllä siivota CSS:ää, mutta kun osasta CSS:ää on ihan pihalla, mihin sitä käytetään, ei uskalla siivota niin paljon kuin voisi. JS:ään en uskalla koskea lainkaan.

Kolmas seikka on oma php-koodaukseni väärät strategiat. Yksi perustavalaatuinen ongelma itse ylläpidettävän ja WordPress.comin maksullisen palvelun välillä on lisukkeiden hallinta. Maksullisessa palvelussa on hyvä lisukkeiden hallinta sen suhteen, mikä lisuke näkyy milläkin sivulla. Tällaista ei ole oletuksena lainkaan itse hallinnoidulla sivustolla. Tätä varten on lisäosia, mutta ne eivät ole yhtä käteviä kuin maksullisen palvelun tuoma systeemi. Näkyvyttä ei monessa tapauksessa voi hallita muuten, kuin kysymällä, onko selain tietyillä sivuilla vai e.
Siinä kysellään, onko osoite https://www.sanaristikot.net/...
Joka lisukkeella on omia tällaisia
Aiheuttaako tällainen kyseleminen ongelman?
Jos aiheuttaa, olen vähän pulassa, sillä loogiset kyselyt is_page,!is_page jne.eivät erottele sivuja riittävästi toisistaan. CSS:ssä voi osan hallita display:none avulla, mutta sekään ei kata kaikkia tilanteita. Jos haluaa kohdentaa just oikein, pitää laittaa joillekin sivulistat.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
258 769
Viestejä
4 498 504
Jäsenet
74 281
Uusin jäsen
staffanjohansson34

Hinta.fi

Back
Ylös Bottom