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

Ketjut yhdistetty. Otsikoksi jäi nyt "WWW-sivujen kännyversiolle käyttöliittymä", koska ko. ketjussa oli enemmän viestejä. Aloitusviestinä on kuitenkin tuon toisen ketjun aloitusviesti, koska kyseinen ketju oli vanhempi.

@Tapio X muokkaa ketjun otsikkoa ja aloitusviestiä tarvittaessa sellaiseksi, että se kuvaa mahdollisimman hyvin ketjun sisältöä.
 
Kiitti. Tuo esittämäsi koodi toimii. Huolimatonta lukemista, sillä tuohon tapaan koodiesimerkki oli W3C:n sivuilla. Kun kirjautuneet ei tuota tarvitse, pistin ehtolauseen.
Koodi:
if(!is_user_logged_in()){
$notLoggedInCSS='<style>
@font-face {font-family: dashicons;src:url(\'/wordpress/wp-includes/fonts/dashicons.woff2\');}
</style>';
}
Tämä oli kyllä oudoin tapaus niistä kaikista oudoista asioita joita olen kohdannut sen suhteen, miten kirjautuminen muuttaa sivujen käytöstä. Tulipa ratkaistua sentään. Mitenkähän joku WP-guru selittäisi tämän?

En ole guru, mutta loogistahan tuo on. dashiconsit on tarkoitettu käytttäväksi backendin puolella, joten oletuksena dashicons css:ää ei ladata jos et ole kirjautuneena.
Ehkä nätimmin tai ainakin enemmän wp-standardeja mukaillen, lisää tälläinen pätkä teeman functions.php:hen:
PHP:
/* Add Dashicons in WordPress Front-end */
add_action( 'wp_enqueue_scripts', function() {
    wp_enqueue_style( 'dashicons' );
});
 
Onhan esittämäsi tapa fiksumpi WP:n koodin osaamisen suhteen. Mutta kun mietin tarkemmin, se ei ole fiksu tapa, koska WP-laittaa aina resurssien osoitteet https://... . Omalla koodilla ei tarvitse käyttää nimipalvelinta vaan voi viitata relatiivisesti. Oma koodi on lopulta siis fiksumpi tapa!

WordPressin.org sivustolla dashicons käytetään kaikissa opasfoorumeissa bbPress kanssa, joten oletin, että ne on ilman muuta käytössä front-endissä. Mutta ne on sitten lisätty WordPress.org omillekin sivuille lisänä. WordPress.org foorumeista itse keksin niiden käytön front-end-puolella.

Mulla oli jossakin vaiheetta tuo @font-face, mutta tuli jossakin vaiheessa tipautettua se pois. No tuli asialle looginen selitys.

Käytin edellisen teeman kanssa liikaakin.
Pikkuhiomista vielä on. Jälleen kerran kirjautumisen jälkeen valikon avauspainike ja valikko muuttavat paikkaa siten, että pitää laatia valikkosysteemille hieman eri CSS jos on kirjautuneena tai ei. Aina sama juttu ei sen puoleen. Korkeusasemoinnit ei ole nyt ihan optimissa kun on hakemista, mikä on paras sijainti. Tulee pikkunäpertelyä ja vähän sekoilin, mikä tulee sijoittaa millekin korkeudelle.

Suunnittelun kannalta kirjautuneille tuleva yläpalkki on hankala tapaus, koska sen kokokin vaihtelee ja se laittaa välillä alavalikoita alle. Haittaa muiden elementtien sijoittelua järkevästi.
 
Viimeksi muokattu:
Koska sivusto ei ole leveälle näytölle suunniteltu keskittyväksi, jouduin hakemaan keskittämistä. Se ei kaikille leveyksille täysin onnistunut. Mutta esim. HD-tabletlaiteellani keskitys on just eikä melkein. Missään ei ole mitään ylimääräistä.

Tietokoneruudulla on pientä elävyyttä, joskin vähemmän kuin sivustoilla yleensä. Miten näkyy 1600+ laitteissa on puhdas arvaus. Mitä enemmän olisi (min-width:xxxx) and (max-width:xxx), sitä vähemmän elävyyttä, mutta miten paljon min- ja max-arvojen kanssa kannattaa säädellä?
 
Viimeksi muokattu:
Koska sivusto ei ole leveälle näytölle suunniteltu keskittyväksi, jouduin hakemaan keskittämistä. Se ei kaikille leveyksille täysin onnistunut. Mutta esim. HD-tabletlaiteellani keskitys on just eikä melkein. Missään ei ole mitään ylimääräistä.

Tietokoneruudulla on pientä elävyyttä, joskin vähemmän kuin sivustoilla yleensä. Miten näkyy 1600+ laitteissa on puhdas arvaus. Mitä enemmän olisi (min-width:xxxx) and (max-width:xxx), sitä vähemmän elävyyttä, mutta miten paljon min- ja max-arvojen kanssa kannattaa säädellä?

En tiedä mitä tarkoitat, mutta ainakaan 2560 pikselin leveydellä ei ole mitään silmiinpistäviä ongelmia.
 
Ok. Sitten saa olla. Kyse on nyt vain siitä, että keskitys ei mene pikselitarkasti keskelle kaikilla laitteilla. Mobiililaitteilla saisi aina pikselitarkasti keskelle, jos laittaa @media screen and (width:xxxx) tarpeeksi monta peräkkäin, mutta ei kai siinä mitään järkeä ole.

Valikossa on pieni ongelma. Jos sulkee päävalikon, mahdollisesti auki oleva toiminto- tai aihevalikko sulkeutuvat myös. Mutta jos toimintovalikossa on avoinna apuikkuna, tomintovalikon aukaiseminen uudestaan palaa tilanteeseen, jossa oli jätetty apuikkuna avoimeksi. Yritin kyllä luoda automaattisia sulkutoimenpiteitä, mutta en onnistunut.
 
Viimeksi muokattu:
Poistelin vielä turhaa CSS:ää ja niihin liittyviä turhia fontteja.

Poistin käytöstä Awesome -ikonifontin. Teema lataa myös Googlen fontteja, mutta kun nämä lataukset eivät näy irrallisissa CSS-tiedostoissa, en niitä yritä lähdekoodia muuttamalla poistaa ainakaan juuri nyt. Pitäisi sorkkia teeman ydinkoodia, jotta link rel='stylesheet' id='screenr-fonts-css' saa pois, sillä teema ei lataa noita paikallisesti vaan hakee (tyhmästi) Googlelta. Idioottimaista, mutta ikävä lähteä tätä idioottimaisuutta poistamaankaan.

Teeman CSS:ssä pienensin. Piti laittaa muutettu pääteemaan, sillä tämä teema ei jostakin syystä lue aliteeman style.css-tiedostoa. Jos sivustoni rikkuu, pitää poistettuja palauttaa. Jos käytän gallerioita, teen gallerioiden CSS:stä oman tiedoston ja lataan CSS:n vain galleriasivuille, en kaikille.

Mielestäni en tarvitse Awesome-fonttia. Muutamassa kohdin vain käytetty.. Jos tulee vastaan, täytynee palauttaa. Tää on taas näitä, että otetaan ikonifontti, jota käytetään tosi vähän.

En ymmärrä, miksi WordPress yrittää käyttää eot-fontteja,vaikka niitä tukee vain Microsoftin selaimet. MS:n selaimet eivät ole enää valtavirtaa. Kukaan ei ole lähtenyt Microsoftin kelkaan tässä asiassa.

Omaan @font-face... laitoin woff. Yleinen vaihtoehto on myös woff2, mutta mitä eroa näillä on?
 
Eli parempi. Olinkin muuten laittanut sen ja tuntui toimivan. WordPress yrittää dachicons suhteen käyttää kaikkia mahdollisia vaihtoehtoja, vaikka eot ja svg on käytössä vain murto-osassa selaimia Minusta siinä ei ole mitään järkeä.
 
Tuo on ihan loogista, kaikki selaimet eivät tue kaikkia fonttityyppejä joten kun annetaan useampi vaihtoehto niin selain sitten valitsee itselleen toimivan tyypin. Nykyaikaiset selaimet kyllä tukevat aikalailla kaikkia fonttityyppejä mutta tuolla varmistetaan että mahdollisimman monella selaimella fontti näkyy oikein. Sinänsä jos kohderyhmänä ei ole kaikki mahdolliset selaimet niin suurimman osan vaihtoehdoista voi jättää pois.

Itselläni on ainakin yhdessä omassa projektissa minkä muistan ulkoa määriteltynä eot, ttf, woff ja svg ja tuolla yhdistelmällä on toiminut aivan kaikilla laitteilla ja selaimilla millä olen keksinyt kokeilla (poislukien text-only -selaimet joilla itse sivut kuitenkin toimivat täysin). Tosin, tuo on omassa sisäverkossani oleva sivusto jolla ohjailen paria laitetta mutta halusin sen toimivan niin tv:n selaimella, kännyköillä sekä tietokoneella sekä ihan millä vaan vekottimella missä sattuu selain olemaan.
 
Katsoin vain, että woff ja woff2 tukevat kaikki modernit selaimet. eot vain Microsoftin selaimet ja svg vain Safari.


En nyt itse lähtisi erityisesti huomioimaan Safaria ja Edgeä, jos ne pärjäävät woff:lla tai woff2:lla. #952 WordPressin ehdotuksella annettaneen kaikki vaihtoehdot, mutta kaikille https://... Omallani suora polku ja yksi vaihtoehto.

Muuten Awesome poisto vaatii sen, että nuolet korvataan dashicons-setin vastaavilla ikoneilla, mutta se käyttää fonttia muutenkin.
Täytyy miettiä, onko muille tarvetta. Valikkoa varten voin vaihdon tehdä, mutta muuten en, koska Awesome on kattavampi kuin dashicons.
Awesome saattaisi kattaa front-edissä kaikki tarvitsemani Dasicons-setin ikonit, mutta kaikki menisi uudelleen määrittelyyn.
On nyt kaksi ikonifonttia, eikä toisesta pääse kovinkaan helposti eroon.

PS. Sen JavaScriptin kanssa minulla oli yksinkertaisesti vain huolimattomuusvirhe - liian tyypillistä minulle. JS toimi aivan kuin ajattelinkin kun korjasin mokani. Ei siis ole enää JS-virhettäkään. Kun mitään maininnan arvoista toiminta-ongelmaa ei ole, pitäisi välillä tehdä jotain muuta ja unohtaa taas joksikin aikaa nettisivujen kehittely. En keksi oikein kehiteltävääkään.
 
Viimeksi muokattu:
Päävalikossa ideana minulla on se, että jokaisella on sen verran uteliaisuutta, että hän klikkaa hieman eri värillä olevia linkkejä katsoakseen, mitä niiden takaa löytyy.

Sen jälkeen hän tietää, mitä löytyy ja osaa käyttää jatkossakin.

Sekä toimintovalikon että aihevalikon sisältö elää sen mukaan, millä sivulla ollaan. Aina pitäisi olla mielekäs kokonaisuus.
Oli hiton iso työ ja voi olla, että tuota työtä ei arvosteta, koska käyttäjältä vaaditaan se pikkuinen uteliaisuus - mitäänhän ei ole leivänmuruja lukuun ottamatta suoraan esillä.

Pelkistetymmäksi lähtönäkymää ei voi laittaa, mutta hieman epätavallisen valikon kanssa sen pitäisi riittää.

Sain sen, mitä tavoittelin ja aika näyttää, miten siihen suhtaudutaan.
 
Viimeksi muokattu:
Päävalikossa ideana minulla on se, että jokaisella on sen verran uteliaisuutta, että hän klikkaa hieman eri värillä olevia linkkejä katsoakseen, mitä niiden takaa löytyy.

Sen jälkeen hän tietää, mitä löytyy ja osaa käyttää jatkossakin.
Täysin väärä ajatusmalli. Toiminnot pitää toteuttaa niin, ettei käyttäjän tarvitse arvailla mitä mistäkin löytyy. Jos ensimmäinen käyttökokemus on huono, ei sivuille haluta tulla jatkossakaan.
 
Kun avaa valikon, en usko millään, että "Avaa toimintovalikko" ja "Avaa aihevalikko"olisi ylivoimaisen vaikea asia.
Nehän ovat ylimpänä kun avaa valikon ja vielä eri värillä.

Monet sivustot ripottelevat kaiken sinne sun tänne - se on kaukana käyttäjäystävällisyydestä.

Jos täällä liikkuu kännykällä, ei siinäkän hirveästi suoraan ole esillä. Ei paljoa sen enempää kuin minulla. Jotkut perustoiminnot ovat suoraan esillä.

Kyllä tällä sivustolla kun avaa valikon, joutuu aika pitkän rullauksen joutuu tekemään, että näkee, mitä valikko sisältää. Millä tavoin tämän sivuston valikko on tässä suhteess parempi kännykkäleveyksillä. Ja on aika ikävä työ rullata valikko takaisin ylös asti, että sen voi sulkea. Minusta erittäin huono toteutus.

Mutta aikahan tuon viimekädessä ratkaisee.
 
Se, että asiat on esitetty tavanomaisesti tai epätavallisesti ei merkitse, että etsityt asiat löytyvät helposti. Mikään sivusto ei voi kertoa, mistä mikin löytyy, käyttäjä joutuu AINA etsintähommiin.. Minä olen tavanomaisilta sivuilta joutunut usein etsimään palautelomaketta. Sen löytäminen ei aina ole helppoa. Sivustoilla on paljon ärsyttäviä etsittäviä asioita.

Lähestymistapani on nyt se, että ensinnäkin on ihan pakko käyttää valikkoa, jos jotain haluaa löytää, kun muualta ei mitään löydy. Minusta tämä pakkosyöttö helpottaa käyttäjää, kun ei ole eri paikkoja, joista etsiä.

Päävalikko itsessään on rakenteeltaan selkeä ja oikean kokoinen. Apuvalikko, joka aukeaa "Avaa toimintovalikko" on kooste pikavalinnoista. Kyllä sen aivan varmasti löytää, jos ei ensimmäisellä valikon avauskerralla niin toisella. Vaatii vain sen yhden klikin. Kun se on ihan ylimpänä ja eri värillä on ihme, jos sitä ei tule käytetyksi.

Ajattelin, että nimi "aihevalikko" sinänsä olisi riittävän kuvaava ilmN mitään arvailuja.

Hakua ei tarvitse etsiä kummemmin - kunhan avaa valikon, niin siinähän se toisena möllöttää.
 
Tuossa on vaan se vika että tuo ei ole kovin "accessible" eli kun esimerkiksi itse monesti selailen nettiä aika pitkälti näppäinkomennoilla niin tuo sinun valikkoratkaisusi aika tehokkaasti tappaa tuon toiminnallisuuden eli sivuja on aikalailla pakko käyttää hiirellä. Ja todennäköisesti kun omat näppäinkomennot ei toimi niin sivusi ei täytä nykyisiä esteettömyysvaatimuksia eli screenreaderit sun muut eivät toimi oikein. Tosin, eihän tuo ole mitenkään pakollista harrastelijasivuilla mutta esimerkiksi tuo rajoittaa näkövammaisten selailua (ja muitakin jotka eivät käytä pelkästään hiirtä selaamiseen).

Muutenkin tuo sinun valikkosi vaatii turhia klikkauksia verrattuna "normaaliin" sivustoon. Ehkä joku tuosta tykkää mutta ainakaan minä en, olen tottunut siihen että toimintoja ei tarvitse etsiä mistään ihmeen "päävalikosta" vaan yleensä oikea asia löytyy parilla klikkauksella jos on löytyäkseen. Monilta kaupallisilta sivuiltakin puuttuu tosin monia asioita jotka haluaisin jokaiselta kaupalliselta sivulta löytyvän, eli yhteystiedot/palautelomake (puhelinnumero ja sähköpostiosoite vähintään), aukioloajat ja osoitetiedot. Yllättävän monelta firmalta puuttuu vähintään joku noista. Se on aina yhtä hauska yllätys kun joku firma mainostaa "Tervetuloa tutustumaan myymäläämme" mutta osoitetta ei löydy mistään...
 
Tiedän, että tuossa tulee ylimääräisiä klikkailuja. Siltä ei voi välttää. Sen vastineeksi kaikki asiat ovat joka hetki käytettävissä eikä tarvitse siirtyä milloinkaan sivun alkuun tai loppuun minkään asian takia. Asioilla on aina hintansa ja suunnittelu on valintaa eri vaihtoehtojen välillä.

Nimesiin "Toimintovalikko" uudestaan nimellä "Pikavalinnat". Siitähän juuri on kyse. Se on kooste eri kohdissa sivua olevista käyttöliittymäelementeistä ja erityissivuista. Jos laittaisin linkin värin punertavalla, se voisi erottua vielä paremmin. Alakohdan "Opastus" vaihdoin "Pikaopas". Kyseessä ei ole täydellinen opastus vaan vain joidenkin erityiskohtien pikaopas. Osaa asioista ei edes löydy opassivuilta. Osa pitäisi niihinkin lisätä.

Aihevalikko nimesin vain "Aiheet". Kun klikkaa "Avaa aihevalikko", tiedetään jo, että on vaikko eikä mielestäni tarvitse toistaa sanaa "valikko". Sanat ovat myös lyhempiä, mistä on kännykkäleveyksissä etua. Kännykällä ei meinaa mahtua tekstit rinnakkain.

Tärkeätä on myös se, mitä linkissä lukee.

Onhan tämä myös koe, mitä on muutama lisäklikkaus vastaan siirtyminen sivun alkuun tai loppuun. Itseäni siirtyily ärsyttää, joten tein sille täydellisen vastakohdan. Siinä mielessä täydellisen, että ei ole mitään, mihin edes siirtyä.

Valikkoon itseensä on olemassa näkövammaisia varten siirtymä (kuuluu WP:n ominaisuuksiin), mutta valikon apuvalikot eivät toimi näkövammalsille. Niille pitäisi olla vaihtoehtolinkit. Vastaavasti näkeville tarkoitetut linkit piilotettaisiin sokeilta. Täytyy harkita asiaa. Kyllä tähän myös screen reader CSS:n voisi laatia. Pelkkä tekstille ohjaus päänavigaation ei riitä.

Tietokoneella se tosiaan tietokoneella toimii vain hiirellä. Itse en tietokoneella juuri käytä pikavalintoja muuta kun silloin kun sivusto siihen pakottaa. Esiim. Suomi24 puuttuu forumin reunasta nuolet ylös ja alas, Niihin käytän näppäinkomentoja - myös kosketusnäyttölaitteella Hacker's Keyboard käyttäen. Tavisselaaja ei osaa näppäinkomentoja käyttää eikä niitä kosketusnäytöllä ole kuin erikoisnäppiksellä.

Tuohon asioiden löytymättömyyteen olen törmännyt muilla sivustoilla kuten myös turhaan etsimiseen.

Sivusto on lähtökohtaisesti suunniteltu mobiililaite painotteisesti. Siksi poistin pudotusvalikon käytöstä, koska se olisi tullut iPad Pro -laitteille. iPad Prollalla pudotusvalikkoa voi käyttää kunnolla vain Apple Pencil avulla. Apple Pencil toimii kuin hiiri - vastaavasta on kokemusta saman tyyppisestä kynästä. Sellaisella :hover toimii kuin tietokoneella. Mutta ei ennen kaikkea piirtämiseen suunniteltu kynä ole hyvä selailuväline. Ärsyttävä se selailuun on.
 
Viimeksi muokattu:
Mutta haluasin puuttuua myös tämän sivuston kännykkäversioon. En pidä sitä onnistuneena ja syyt olen selittänyt aiemmin

Niistä olisi minusta syytä vakavasti keskustella. Näin päästäisiin asioissa myös yleisemmälle tasolle ja näin pureuduttaisiin säikeen alkuperäiseen aiheeseen.

Sen valikon sulkupainike on minusta todella ärsyttävä ja todella huonosti mietitty asia. Sen voisi kyllä melko helposti korjata. Puuttuisin itse välittömästi tämänkaltaisiin ongelmiin.

Toinen perusongelma on se, että se on pitkä kuin nälkävuosi. Tuli ihan sama tunne kuin edellisen teeman kanssa kun päävalikko ei ollut laajenna/supista -tyyppiä. Rullattavaa on tosi ikävän paljon.

Osa valikko ei ole laajenna/supista tyyppiä. Tätä tuskin voi muuttaa, sillä laajenna/supista vaatii taakseen melko kompleksin jQuery + CSS -viritelmän. Viritelmän JS pitää olla koodattuna ohjelmaan, eikä sitä voi jälkikäteen lisätä, jos valikosta puuttuu luokat, jotka mahdollistavat jQuery + CSS -rakennelman luomisen.

Vaihtoehtona pituudelle on siinäkin välilehdet. Mutta onko se toimivampi, se on toinen kysymys.

Minusta edelleenkin "Pikanavigointi" on aika turhake, sillä jotensakin samat asiat on päänavigaatiossa. Sen voisi minusta kokonaan piilottaa display:none avulla.
 
...

Kyllä tällä sivustolla kun avaa valikon, joutuu aika pitkän rullauksen joutuu tekemään, että näkee, mitä valikko sisältää. Millä tavoin tämän sivuston valikko on tässä suhteess parempi kännykkäleveyksillä. Ja on aika ikävä työ rullata valikko takaisin ylös asti, että sen voi sulkea. Minusta erittäin huono toteutus.

Mutta aikahan tuon viimekädessä ratkaisee.

Nyt kun tuo io-techin valikon sulkeminen on sinua jo tovin häirinnyt, niin on ehkä aika kertoa: siinä on clickawaylisteneri. Ei tarvitse scrollata tai etsiä rastia, sen kun klikkaa ohi niin valikko sulkeutuu.

Sama ominaisuus olisi kiva tuossa sinunkin valikossa, vaikka se kyllä melkein koko näytön peittää (mobiilissa). Tai oikeastaan uskaltaisin väittää että valikko olisi parempi jos se rehellisesti peittäisi koko näytön, tai vaihtoehtoisesti olisi jotain muuta kuin keskellä näyttöä kelluva kuutio.
 
Katsoin tämän sivuston koodia. Pikanavigaatiosta alkavaa linkkisettiä ei voi muuttaa laajenna/supista tyyppiseksi, jollainen on valikon lopussa. Välissä olevien linkkien rakenne koostuu samalla tasolla olevista li-elementeistä. Sisennyksillä on luokat, jotka määrittävät sisennystason.

Jos rakenne olisi ul.sub-menu > li -tyyppinen, sille voisi periaatteessa rakentaa sivuston käyttämän jQuery koodin kaltainen valikkosysteemi, jolloin linkit näyttäisivät saman tyylisiltä kuin valikon lopussa olevat linkit. Töitä tällainen muutost teettäisi.

Kyseessä on todennäikösti standardikoodi, joka on jostakin netin syövereistä noudettavissa minkä tahnsa sivuston käyttöön. Sovittaminen satunnaiselle sivustolle edellyttää luokkien nimien vaihtamista kulloiseenkin tilanteeseen sopivaksi. Se periaatteessa ei olisi iso työ.
 
Nyt kun tuo io-techin valikon sulkeminen on sinua jo tovin häirinnyt, niin on ehkä aika kertoa: siinä on clickawaylisteneri. Ei tarvitse scrollata tai etsiä rastia, sen kun klikkaa ohi niin valikko sulkeutuu.

Sama ominaisuus olisi kiva tuossa sinunkin valikossa, vaikka se kyllä melkein koko näytön peittää (mobiilissa). Tai oikeastaan uskaltaisin väittää että valikko olisi parempi jos se rehellisesti peittäisi koko näytön, tai vaihtoehtoisesti olisi jotain muuta kuin keskellä näyttöä kelluva kuutio.

[/QUOTE]

sen kun klikkaa ohi niin valikko sulkeutuu

No se helpottaa. Laittaisin kuitenkin ruksin kiinteäksi. Vaatii vain sen, että leveyteen jätetään valikkopainikkeen verran marginaalia oikealle.

Sama ominaisuus olisi kiva tuossa sinunkin valikossa, vaikka se kyllä melkein koko näytön peittää (mobiilissa

Valikko peittää leveyssuunnassa koko näytön kännykällä. Ylhäällä tuli ongelma z-index-arvojen kanssa, joten valikko alkaa vasta valikkopainikkeen alapuolelta. Valikkopainikke ei visuaalisista eikä toiminnallisista syistä ole aivan ikkunan yläreunassa.

HD-tablet-laitteella pystysuunnassa valikko voisi täyttää koko leveyden, mutta vaakasuunnassa koko näytön leveys ei enää näytä nätiltä. Tulee liian massiivinen. Aiemman teeman kanssa täytti koko tilan vaakasuunnassakin. Nyt määritin maksimileveyden 500px, jota yksi kommentoija tässä säikeessä piti hyvä arvona.

Edellisen systeemin kanssa minulla oli click-away siten, että pääsisältöaluetta kun klikkasi näytöltä hävisi apuvalikot.. Nyt pitäisi hävittää koko valikko. Sekin onymmärtääkseni mahdollista. Tämä oli hyvä ehdotus ja sitä täytyy ainakin kokeilla.

Nykyisessä teemassa on välittömästi header-osan alla tila omalle koodille. Lisäsin vastaavan tilan välittömästi footer osan yläpuolelle. Pääsisältöalueella on ylimääräinen DIV-elementti. Jos sille määrittää luokan, sille saa jQueryn, joka sulkee kaikki valikot. Ihan vanhanaikainen onclick mahdollista myös. Osassa JS-koodiani on onclick..., mutta merkittävä osa toimii jQueryllä.

Päävalikossa lisätty toiminnallisuus perustuu jQueryyn. Kaksi erikoislinkkiä ja Googlen haku on upotettu osaksi valikkoa jQueryn avulla.
 
Viimeksi muokattu:
Minusta tämän sivuston kapean näytön kohdalla itsestään sulkeutuvuus ei oikein ole hyvä idea kännykkäleveyksillä.
Niillä täysleveä valikko oli järkevä. Jos valikko ei ole täysleveä, oikeaan reunaan jää kumminkin varsin kapea sulkualue.
 
Jännä että sinun tarvitsee käyttää noin paljon aikaa muiden sivujen kritisointiin. Ei se omastasi tee hyvää, että haukut muita.
 
Jos koen aiheelliseksi kritiikkiin, kritisoin. Niin teen sanaristikoidenkin kohdalla. WWW-suunnittelu ei tee poikkeusta. Kritiikkiä ei pidä ottaa pahantahtoisuutena. Kyse on mielipiteeni siitä, minkä katsoisin parannukseksi.

Minua on koko ikäni arvosteltu ja koen, että työn arvostelu kuulee elämään ihan oleellisena osana. Siitä ei pidä ottaa liikaa nokkiinsa.

Tuo automaattinen sulkeutuminen oli hyvä idea. Sen kanssa oli ongelmia. Piti löytää sopiva HTML-rakenne ja sopiva JS. Muutaman mokayrityksen jälkeen onnistuin. Ongelmana oli HTML-rakenne, jota piti muuttaa niin, että lisäikkunat eivät tule sille alueelle, joka sulkee valikon ja mahdolliset apuikkunat. Jos jokin elementti oli sulkualueella, linkin painallus sulki valikon, vaikka ei pitänyt. Skripti ei ollut vaikea lisätä. Lisäsin vastaavan myös footer-osaan (luokkana siinä "site-footer"). Koska valikko avautuu header-osasta, siellä ei sulkemistoimintoa ole.

Koodi:
$('.extra-content-wrapper').click(function() {
var t = document.getElementById("social-login-3");
if(typeof(t) != 'undefined' && t != null)
t.style.display = "none";
var u = document.getElementById("forum-list2");
if(typeof(u) != 'undefined' && u != null)
u.style.display = "none";
var v = document.getElementById("infoText");
v.style.display = "none";
var w = document.getElementById("rulesText");
w.style.display = "none";
var x = document.getElementById("tabA");
x.style.display = "none"; 
var y = document.getElementById("tabC");
y.style.display = "none"; 
if(document.querySelector('.nav-is-visible'))
$('.open-mobile-menu').removeClass('nav-is-visible');
if(document.querySelector('.nav-menu-mobile'))
$('.nav-menu').removeClass('nav-menu-mobile');
}); 
  
});
 
Viimeksi muokattu:
Siten, että tässä säikeessä käsitellään sivujen toimimista mobiililaitteissa - ei ole kyse vain omista sivuistani. Voi mielestäni ihan hyvin käsitellä mm. tätä sivustoa tai vaikka Suomi24:ää tai mitä tahansa sivustoa.

Tutkin Suomi24 ja Sanaristikot.net. Tietokonenäytöllä Suomi24 valikko sulkeutuu sisältöä klikattaessa. Kännykkäleveydellä ei, koska valikko vie koko tilan.
Sanaristikot net ei ole "hampurilaisesta" avatun valikon automaattista sulkeutumista sisältöön mentäessä. Automaattinen sulkeutuminen on kaiketi kuitenkin yleinen käytäntö.
 
Viimeksi muokattu:
Makiksen kommenttiin viitaten vaikuttaa vaan siltä, että tämä muiden sivustojen kommentointi ja arvostelu on vain kummallista saivartelua.

Tuntuu siltä että muiden sivustojen ongelmat (jotka ei monesti valtaosan käyttäjistä mielestä ole ongelmia) nousevat esiin aina kun sivustosi suunnitteluun tai toteutukseen kohdistuu kritiikkiä. Tykkäät siis kritisoida, mutta olet huono ottamaan kritiikkiä vastaan. Vähän kuin kommunisti katsoisi maailmaa punaisten lasien läpi.

Itsekkään en vielä tajua mikä tämän uuden ja mullistavan valikko-rakenteen ja kummallisesti kelluvien komponenttejen hienous/idea on. Siis mikä tästä tekee paremman kuin niistä sivuista joiden suunnitteluun yritykset on pumpannut aikaa ja rahaa aivan perkeleesti, seurannut mihin käyttäjän katse kohdistuu ja mitä hän klikkaa.

Yksi ainakin aiemmin aiemmin mainitsemasi argumentti on että kaiken pitää olla saatavilla aina ja heti. Tätäkin on valitettavasti yritysmaailmassa ihan tutkittu ja todettu ettei asia ole näin. Monessa sovelluksessa valikkoihin syvyyttä hakemalla on saatu aikaan tyytyväisempiä käyttäjiä ja parempia tuloksia. Ei käyttäjä tarvitse kaikkea tietoa ja jokaista toimintoa aina. On siis parempi työntää ne johonkin vähän syvemmälle (mutta helposti löydettäväksi), jotta valikot ja näkymät yksinkertaistuvat ja selkenevät.

Ja tosiaan, näissä tutkimuksissa puhuu raha. Ja rahaa tulee toimivista palveluista, joita asiakkaat käyttävät. Toki näitä tehdään sovellus kohtaisesti, joten tulokset eivät välttämättä ole täysin universaaleja. Kuitenkin monen sovelluksen kohdalla nousevat esiin samat asiat.

...
Valikko peittää leveyssuunnassa koko näytön kännykällä. Ylhäällä tuli ongelma z-index-arvojen kanssa, joten valikko alkaa vasta valikkopainikkeen alapuolelta. Valikkopainikke ei visuaalisista eikä toiminnallisista syistä ole aivan ikkunan yläreunassa.
...

Mikä tämä ongelma on? Ja miten tuo pari milliä alhaalla ja pari milliä ylhäällä sivua taustalla auttaa toiminnallisesti tai visuaalisesti?
 
Sivut tarvitsisivat foorumille kävijöitä ja keskustelijoita + mielenkiintoisia artikkeleita. Muussa tapauksessa koko projekti on itseopiskelua ja uuden mullistavan käyttöliittymän suunnittelua ja täällä siitä keskustelua.

Tulee pakostikin mieleen tämä Vertikaaliakseloitu tuulivoimalani ( H-Darrelius ) ! projekti, joka on koko ajan piirustuspöydällä, etenemättä lopulta maaliin.

Sen verran voin sanoa, että nykyään on käytännössä mahdotonta saada perustettua sellaista foorumia, jossa oikeasti olisi vilkasta keskustelua ja joku vieraskirja kävijälaskurilla voisi olla järkevin vaihtoehto. Kukaan ei halua rekisteröityä foorumille ihan helposti (itseni mukaanlukien).

Ihmiset ovat sukeltaneet sosiaalisien medioiden ihmeelliseen maailman ja ilman sen kautta saatua julkisuutta ja lisämahdollisuutta keskustelulle, on käytännössä mahdotonta saada näkyvyyttä omille sivuilleen (paitsi täältä on saanut).

Itsellänikin on Facebook -ryhmä, jonka lisäksi siihen liittyvä WhatsApp -ryhmä.

Nyt olisi hyvä hetki kertoa mihin sivustolla ollaan pyrkimässä ja mikä sen lopullinen tarkoitus tulisi olemaan näin ulkoisen käyttäjän näkökulmasta.
 
  • Tykkää
Reactions: hmb
Mikä tämä ongelma on? Ja miten tuo pari milliä alhaalla ja pari milliä ylhäällä sivua taustalla auttaa toiminnallisesti tai visuaalisesti?

Valikkopainike ei minusta ei näytä hyvältä ihan yläreunaan sijoitettuna kun tullaan sivulle.
Toiminnallinen ongelma on se, että jos mobiililaitteessa selaimen käyttöliittymä häviää näkyvistä ja painaa valikkopainiketta, jos painike on aivan yläreunassa, saattaa siirtyä toiselle välilehdelle. Näin minulle kävi useinkin omilla sivuilla entisellä leiskalla ja näin on käynyt tablet-laitteella muutaman kerran tällä sivustolla. On perin juurin ärsyttävää siirtyä vahingossa toiselle sivustolle. Valikkopainike on sijoitettu niin, että Chromella ei voi siirtyä vahingossa toiselle sivustolle (Safarilla ehkä voi, koska siinä on korkeampi käyttöliittymä).

Pikavalintoja on valikon yhteydessä tälläkin sivustolla. Tämän sivuston valikoiden sisältö taitaa olla aika staattinen. Minulla vaihtuu tilanteen mukaan.
Minulla lisäksi pikavalinnat on omassa välilehdessä, eikä muussa valikossa. Kun pikavalinnat osasto on sangen pieni, minusta samat asiat on nopeammin löydettävissä siitä kuin massiivisesta isosta valikosta. Sana "Pikavalinnat" pitäisi olla välittömästi tajuttavissa, ilman opastusta. Olen sanavalinnoilla yrittänyt luoda selkeyttä.

Voisi varmaan auttaa, jos olisin Facebookissa, mutta sinne en todellakaan halua mennä. Jokin muu yleinen kanava saattaisi tulla kyseeseen. Twitter ei oikein toimi. Minulle aika turha tällä hetkellä, sillä en saa siihen kommentteja.
 
WordPressissä minulla on yksi pieni kooditekninen asia, jonka laitoin WordPressin Suomi-foorumiin:

Jos täällä olisi joku minua parempi WordPress-asiantuntija, joka osaisi tähän vastata, olisi kiva. Olen kolme tiedostoa vaihtanut suoraan bbPressiin.
Muut bbPressin omat mallinteet olen saanut toimimaan teeman lapsifoorumissa (nyt screenr-child/bbpress).
 
Eräs tuntematoin koodari laati chat-systeemin, jossa avoimena on TapChat.

Siinä on mahdollista ladata kuvia minulle niin, että minä näen master-tunnuksilla kuvat, mutta kuvat ei näy julkisesti. Sain pystyyn vastaavankaltaisen toiminnon, Ehto näkymiselle on, että lähetetään masterid lomakkeella post-muuttujalla. Kai tämä kuvien näyttämiseen riittää?

Kuvat näytetään yksityisellä sivulla WordPressissä iframessa. Jos joku muu kuin minä yrittää avata sivun, tulee ilmoitus "404 Page not found". Jos yrittää suoraan katsoa sivua ilman iframea, tulee ilmoitus "Sivua ei voi avata!"

Lisäisin pikavalintoihin vain admin-tason käyttäjälle yhden valikkokohdan, mutta en funktioluettelosta löytänyt mainintaa käyttäjäkohtaisista ehdoista.


Kaikkea muuta funktioluettelo sisälsi. Tietäisikö joku ehdon, joka tutkailee, onko kyseessä järjestelmävastaava vai ei.
 
Viimeksi muokattu:
WordPressissä minulla on yksi pieni kooditekninen asia, jonka laitoin WordPressin Suomi-foorumiin:

Jos täällä olisi joku minua parempi WordPress-asiantuntija, joka osaisi tähän vastata, olisi kiva. Olen kolme tiedostoa vaihtanut suoraan bbPressiin.
Muut bbPressin omat mallinteet olen saanut toimimaan teeman lapsifoorumissa (nyt screenr-child/bbpress).
Jotakuinkin tähän tyyliin, lisättynä vaikkapa lapsiteeman functions.php:hen.

PHP:
// forums/template.php:
add_filter('bbp_after_list_forums_parse_args', function($args) {
    $args['count_before'] = '<';
    $args['count_before'] = '>';

    return $args;
});

// replies/template.php
add_filter('bbp_after_get_reply_author_link_parse_args', function($args) {
    $args['size'] = 100;

    return $args;
});

// topics/template.php
add_filter('bbp_after_get_topic_author_link_parse_args', function($args) {
    $args['size'] = 100;

    return $args;
});
 
Tietäisikö joku ehdon, joka tutkailee, onko kyseessä järjestelmävastaava vai ei.
PHP:
if(current_user_can('activate_plugins')) {
    // do stuff
}
Tämä nyt ei ihan suoraan kerro, onko kyseessä admin tason käyttäjä, mutta wp:n perusasennuksessa vain admin saa aktivoida plugineja. Lisää testattavia oikeuksia täältä:
 
Tämän sivuston valikoiden sisältö taitaa olla aika staattinen. Minulla vaihtuu tilanteen mukaan.
Eikö tämä nyt ole pahin mahdollinen temppu käyttäjälle, että valikko muuttuu sen mukaan millä sivulla ollaan. Vai ymmärsinkö nyt jotain väärin.
 
Et tainnut ymmärtää ideaa. Valikon pitää ehdottomasti muuttua sivukohtaisesti.

Valikko muuttuu sen mukaan, mitä toimintoja sivulla on mahdollista käyttää. Jos ei olla foorumisivulla, et voi sivun loppuun laittaa uutta kommenttia.
Mutta jos olet tavallisella sivulla, ja sivulle on mahdollista laittaa kommentti, sen on pikavalinnoissa. Pikavalinnoissa on aina se, mikä on järkevää kullakin sivulla. Sisältö muuttuu myös oletko kirjautunut vai et. Jos et ole kirjautunut, voi rekisteröityä ja kirjautua. Jos olet kirjautunut, voi kirjautua ulos. Niihän sen pitää toimia. Ei ole mitään järkeä pitää pikavalinnoissa toimintoja, joilla ei tee mitään jollakin sivulla. Mutta kaikki mielekäs on hyvä laittaa pikavalintoihin.

Aihevalikon sisältö vastaa aina sitä sivua, jolla olla. Blogisivulla tulee blogit, ristikkoavuissa ristikkoapusivut jne.
 
Viimeksi muokattu:
// replies/template.php add_filter('bbp_after_get_reply_author_link_parse_args', function($args) { $args['sep'] = 'abc';
Tuo toimii vallan hyvin, mutta en sitä etsinyt. Etsin admin links -linkisetille mahdollisuuden poistaa oletuksena olevat erottimet. Laitoin vastaavalla kaavalla
Koodi:
add_filter('bbp_after_get_reply_admin_links_parse_args', function($args) {
    $args['sep'] = '';
    return $args;
});
Tuo ei tehnyt mitään.

On minulla joitakin filttereitä käytössä, mutta filttereiden logiikka ei ole minulla täysin hallussa.
 
Viimeksi muokattu:
PHP:
if(current_user_can('activate_plugins')) {
    // do stuff
}
Tämä nyt ei ihan suoraan kerro, onko kyseessä admin tason käyttäjä, mutta wp:n perusasennuksessa vain admin saa aktivoida plugineja. Lisää testattavia oikeuksia täältä:

Tärkeintä on suoraa tai epäsuoraa saada selville, onko admin tason käyttäjä. Laitoin ehdottamasi. Lisäsin Pikavalintoihin vain itseäni varten yhden linkin.
Koodi:
if(current_user_can('activate_plugins')) {
    $imageControl ='<div class="item"><a href="https://www.sanaristikkofoorumi.net/wordpress/????????/">Näytä kuvienhallintasivu</a></div>';
Tuo sivu antaa muille kuin minulle 404 Page not found

Parempi hyvä vippaskonsti, jos ei juuri etsittyä ehtoa löydä. Tällainen vippaskonsti ei tullut edes mieleen. Ohjelmoinnissakin tarvitaan välillä luovia keinoja.
Kiitos vinkistä. Täytyy itsekin näemmä ajatella luovasti. Ristikoiden kanssa sellaiseen on tottunut, mutta sama asenne täytyy ottaa ohjelmointiinkin. ;D
 
Viimeksi muokattu:
Tuo toimii vallan hyvin, mutta en sitä etsinyt. Etsin admin links -linkisetille mahdollisuuden poistaa oletuksena olevat erottimet. Laitoin vastaavalla kaavalla
Koodi:
add_filter('bbp_after_get_reply_admin_links_parse_args', function($args) {
    $args['sep'] = '';
    return $args;
});
Tuo ei tehnyt mitään.

On minulla joitakin filttereitä käytössä, mutta filttereiden logiikka ei ole minulla täysin hallussa.
Olit nuo kolme templatea listannut tuonne wp foorumin postaukseen. Kun en täysin ymmärtänyt mitä haluat tehdä, en tarkoittnutkaan noita suoraan käyttöön otettavaksi vaan esimerkiksi siitä, miten voit noiden filttereiden avulla vaihtaa mitä tahansa noista template tiedostoissa esiintyvistä argumenteista.
 
Tärkeintä on suoraa tai epäsuoraa saada selville, onko admin tason käyttäjä. Laitoin ehdottamasi. Lisäsin Pikavalintoihin vain itseäni varten yhden linkin.
Koodi:
if(current_user_can('activate_plugins')) {
    $imageControl ='<div class="item"><a href="https://www.sanaristikkofoorumi.net/wordpress/????????/">Näytä kuvienhallintasivu</a></div>';
Tuo sivu antaa muille kuin minulle 404 Page not found

Parempi hyvä vippaskonsti, jos ei juuri etsittyä ehtoa löydä. Tällainen vippaskonsti ei tullut edes mieleen. Ohjelmoinnissakin tarvitaan välillä luovia keinoja.
Kiitos vinkistä. Täytyy itsekin näemmä ajatella luovasti. Ristikoiden kanssa sellaiseen on tottunut, mutta sama asenne täytyy ottaa ohjelmointiinkin. ;D
En nyt vippaskonstiksi nimittäisi. Missään tilanteessa ei pitäisikään tukeutua suoraan noihin rooleihin, vaan aina käyttää noita capablityjä, tarpeen vaatiessa luoda vaikka uusi sellainen jos mikään olemassaolevista ei sovi käyttötarkoitukseen. WP:ssä (kuten monessa muussakin softassa) roolit ovat vain keino ryhmitellä näitä käyttöoikeuksia.
 
Et tainnut ymmärtää ideaa. Valikon pitää ehdottomasti muuttua sivukohtaisesti.

Valikko muuttuu sen mukaan, mitä toimintoja sivulla on mahdollista käyttää. Jos ei olla foorumisivulla, et voi sivun loppuun laittaa uutta kommenttia.
Mutta jos olet tavallisella sivulla, ja sivulle on mahdollista laittaa kommentti, sen on pikavalinnoissa. Pikavalinnoissa on aina se, mikä on järkevää kullakin sivulla. Sisältö muuttuu myös oletko kirjautunut vai et. Jos et ole kirjautunut, voi rekisteröityä ja kirjautua. Jos olet kirjautunut, voi kirjautua ulos. Niihän sen pitää toimia. Ei ole mitään järkeä pitää pikavalinnoissa toimintoja, joilla ei tee mitään jollakin sivulla. Mutta kaikki mielekäs on hyvä laittaa pikavalintoihin.

Aihevalikon sisältö vastaa aina sitä sivua, jolla olla. Blogisivulla tulee blogit, ristikkoavuissa ristikkoapusivut jne.
Nojoo, ymmärrän nyt logiikan, mutta itseäni ainakin kovasti hämmentää esim. tuo, että pikavalinnat on päävalikon sisällä. Mielestäni paremmin sopisi esim. päävalikon hampurilaisen vieressä oma pikavalikko- ja aihenappinsa tms.
 
Olit nuo kolme templatea listannut tuonne wp foorumin postaukseen. Kun en täysin ymmärtänyt mitä haluat tehdä, en tarkoittnutkaan noita suoraan käyttöön otettavaksi vaan esimerkiksi siitä, miten voit noiden filttereiden avulla vaihtaa mitä tahansa noista template tiedostoissa esiintyvistä argumenteista.
Huomasin kyllä esimerkinomaisuuden. Yritin vain noudattaa samaa logiikkaa. No jos ei onnistu, ei ole hirveän iso työ editoida vähän mallinnetta päivityksen jäljeen.

Nojoo, ymmärrän nyt logiikan, mutta itseäni ainakin kovasti hämmentää esim. tuo, että pikavalinnat on päävalikon sisällä. Mielestäni paremmin sopisi esim. päävalikon hampurilaisen vieressä oma pikavalikko- ja aihenappinsa tms.

Se on ulkoasukysymys. Minulla oli edellisen mallinteen kanssa tietokoneella nuo kolme erillisenä. Yhteen laitettuna tulee siistein ulkoasu. Kun sivua rullaa alaspäin, ei ole liikaa mukana kuljetettavaa. Jokaisella asialla on etunsa ja haittansa.

Uskoisin, että pikavalikon aukeamiseen päävalikon tilalle (todellisuudessa päälle) tottuu. Tämä on kyllä myös tietoinen kokeilu.
 
Huomasin kyllä esimerkinomaisuuden. Yritin vain noudattaa samaa logiikkaa. No jos ei onnistu, ei ole hirveän iso työ editoida vähän mallinnetta päivityksen jäljeen.
Tietysti tämä olisi ollu kerralla helpompaa, jos olisit alkuperäisessä viestissä kertunut mitä haluat muuttaa.
Filttereillä bbp_after_get_topic_admin_links_parse_args ja bbp_after_get_reply_admin_links_parse_args pitäisi adminlinkkien separaattorit saada vaihdettua.
 
bbp_after_get_reply_admin_links_parse_args
Kiitti hirveesti. Kyllä tosiaan erottajat muuttuivat. Nyt voin päivittää lisäosan ilman tarvetta peukaloida suoraan mallinteita. Lapsiteemassa minulla on joitakin peukaloituja mallinteita, mutta ne eivät haittaa päivitystä. Olen täältä saanut nopeammin WordPress-ongelmiini vastauksia kuin WordPressin Suomen foorumista, josta uusiin kysymyksiin ei vastauksia ole tippunut.

Kävin laittamassa Suomen WorPress sivuille, että sain ratkaistua ongelmat täällä. Suljin siellä aloitetut pari säiettä, jossa kyselin asioita, joihin sain täällä vastauksen.

Kun nyt päivitin, yksittäisen säikeen näyttävä sivu näyttää samalta kun ennenkin. Kiitoksia vielä kerran.

Vähän ärsyttää käännöskukkaset "Julkasu" ja "Avainmestari", mutta kun päivityksiä tulee silloin tällöin, ei kannata ruveta luomaan omia kielitietueita.
 
Viimeksi muokattu:
Huomasin äsken selaillessani nettiä, että Iltalehti on samaan tapaan kuin minäkin liittänyt valikkoon hakutoiminnon.
Yläpalkissa sama ongelma kuin yleensä - valikon sulkeminen johti minut toiseen välilehteen.
 
Huomasin äsken selaillessani nettiä, että Iltalehti on samaan tapaan kuin minäkin liittänyt valikkoon hakutoiminnon.
Yläpalkissa sama ongelma kuin yleensä - valikon sulkeminen johti minut toiseen välilehteen.
Siis onko tämä "valikon sulkeminen johti toiseen välilehteen" ongelma että et osu valikon sulkemisnappiin vaan sormi lipeää vieressä oleviin välilehtiin? En vain jotenkin pysty ymmärtämään ongelmaa.
 
Ei vaan sitä että kun painaa valikon sulkemisnappia tilanteessa, jossa Chromen käyttöliittymä on poistunut näkymästä tablet-laitteella. Jos siinä vaiheessa klikkaa sulkemispainiketta sulkemisen jäleen tulee vaihtaneeksi välilehteä.
 
No jos muut eivät ongelmaa usein kohtaa, kyse ei ole suuresta ongelmasta.

Se on kiva, kun täälläkin on WP-osaajia. Ihan kaikki asiat eivät ole itsellä tiedossa. WP:n teemassa ihmettelen sitä, miksi screenr ei lue screenr-child-hakemiston style.css-tiedostoa vaan aina lukee screenr-hakemiston tiedoston. Ei siinä muuta ongelmaa ole kuin että pitää joka päivityksen yhteydessä käydä ajamassa alkuperäinen tiedosto yli. Edellisen teeman kanssa tätä ongelmaa ei ollut. Ehkä theme.js ja editor.css, jotka ovat child-hakemistossakin, eivät sieltä toimi myöskään, joten ehkä kolme tiedostoa pitää ajaa yli joka teeman päivityksen yhteydessä.

Tällä hetkellä ei pitäisi olla merkittävää kehitettävää. Joku mainitsi sokeiden huomioimisen. Ehkä voisi laatia screen_reader.css ihan vaan harrastemielessä. Käyttäjäkunta nyt ei kyllä juuri millään sivuston osiolla kohtaa screen reader -laitteen käyttäjiä.

bbPressille tekemäni CSS sopii monelle teemalle. Jos joku kaipaa, voisin luoda siitä jonkinlaisen paketin. Onhan XenForo tietenkin helpompi tapaus kun se on lähtökohtaisesti ihan siistin näköinen eikä kovin amatöörimäisen oloinen kuten bbPress on oletusulkoasullaan.
 
Viimeksi muokattu:
No jos muut eivät ongelmaa usein kohtaa, kyse ei ole suuresta ongelmasta.

Se on kiva, kun täälläkin on WP-osaajia. Ihan kaikki asiat eivät ole itsellä tiedossa. WP:n teemassa ihmettelen sitä, miksi screenr ei lue screenr-child-hakemiston style.css-tiedostoa vaan aina lukee screenr-hakemiston tiedoston. Ei siinä muuta ongelmaa ole kuin että pitää joka päivityksen yhteydessä käydä ajamassa alkuperäinen tiedosto yli. Edellisen teeman kanssa tätä ongelmaa ei ollut. Ehkä theme.js ja editor.css, jotka ovat child-hakemistossakin, eivät sieltä toimi myöskään, joten ehkä kolme tiedostoa pitää ajaa yli joka teeman päivityksen yhteydessä.

Tällä hetkellä ei pitäisi olla merkittävää kehitettävää. Joku mainitsi sokeiden huomioimisen. Ehkä voisi laatia screen_reader.css ihan vaan harrastemielessä. Käyttäjäkunta nyt ei kyllä juuri millään sivuston osiolla kohtaa screen reader -laitteen käyttäjiä.

bbPressille tekemäni CSS sopii monelle teemalle. Jos joku kaipaa, voisin luoda siitä jonkinlaisen paketin. Onhan XenForo tietenkin helpompi tapaus kun se on lähtökohtaisesti ihan siistin näköinen eikä kovin amatöörimäisen oloinen kuten bbPress on oletusulkoasullaan.
Sun lapsiteeman style.css tiedostosta puuttuu Template: screenr, ja Theme Name pitää olla uniikki
 
Mulla oli siihen yritys, jossa oli eri otseketiedot kuin alkuperäisessä ja tein mielestäni ohjeen mukaan. Katsomasi oli kopio alkuperäisestä. Muutin vielä kerran:
Koodi:
/*
Theme Name: Screenr Child Theme
Theme URI: https://www.famethemes.com/themes/screenr
Author: FameThemes
Author URI: https://www.famethemes.com
Description: Screenr Child Theme
Version: 1.2.3
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Template: screenr
Tested up to: 5.0
Requires PHP: 5.6
Tags: one-column, two-columns, left-sidebar, right-sidebar, custom-background, custom-colors, custom-header, custom-logo, editor-style, featured-image-header, featured-images, footer-widgets, full-width-template, rtl-language-support, sticky-post, theme-options, threaded-comments, translation-ready, blog, portfolio

This theme, like WordPress, is licensed under the GPL.
Use it to make something cool, have fun, and share what you've learned with others.

Screenr is based on Underscores http://underscores.me/, (C) 2016 Automattic, Inc.
Underscores is distributed under the terms of the GNU GPL v2 or later.

Normalizing styles have been helped along thanks to the fine work of
Nicolas Gallagher and Jonathan Neal http://necolas.github.com/normalize.css/
*/
Mutta sama tulos ts. lapsiteeman css:ää ei lueta. Asialla tosin on vain periaatteellista merkitystä.
 
Viimeksi muokattu:

Statistiikka

Viestiketjuista
258 700
Viestejä
4 496 322
Jäsenet
74 273
Uusin jäsen
Aloittelija6271

Hinta.fi

Back
Ylös Bottom