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

Laitoin mustan reunan ajatellen, että erottuu - mutta näemmä erottuu vähän liiankin terävästi. Toi punertava on teeman linkin korostusväri, joka on aktiivisessa välilehdessä samana kuin linkin korostuksessa ja ei-aktiivisessa vaaleampana. Jos vaihtaa sitä, pitäisi ehkä vaihtaa linkin korostusväriäkin? Voihan ne toki itsenäisestikin määrittää.

En tiedä, miten taustan skrollaamista voisi hallita. Auttaisiko valikolle ja apuvalikoille fokuksen asettaminen? :focus liittyy ymmärtääkseni vain linkkeihin eli taidetaan mennä JS:n puolelle?

Yksi tapa estää taustan scrollaus on asettaa <body> elementille overflow:hidden kun valikko on auki.

Esimerkiksi sen voisi tehdä laittamalla theme.js tiedostoon riville n.170 jQuery('#nav-toggle').on('click', function(event){}) funktioon että lisää luokan <body> elementille (ja vastaava rivi missä luokka poistetaan kun valikko suljetaan) ja sitten tälle luokalle että overflow:hidden. Joku valmiiksi määritelty luokka jolla on overflow:hidden saatta myös löytyä valmiiksi.

En kokeillut että hajoaako jokin muu asia tuolla ja varmaan täytyy syystä X tehdä pikkasen eritavalla mutta ideana näyttäisi nopealla testillä toimivan.
 
Tuo on ihan hyvä idea, kiitos. Yritin muuten kuin muuttamalla theme.js-tiedostoa, mutta en saanut toimimaan. Kun muutin tuota theme.js-funktiota homma pelasi. Kiitti, oikein toimiva, hyvä ehdotus. Lisäsin luokan poiston myös sisältöalueille. En voinut lisätä header-osaan, sillä valikko avataan sieltä.
Koodi:
    jQuery('#nav-toggle').on('click', function(event){
        event.preventDefault();
        jQuery('.header-layout-fixed').toggleClass('set-hidden');
        jQuery('#nav-toggle').toggleClass('nav-is-visible');
        jQuery('.main-navigation .nav-menu').toggleClass("nav-menu-mobile");
        jQuery('.header-widget').toggleClass("header-widget-mobile");...
    
    

$('.extra-content-wrapper').click(function() {
if($('.header-layout-fixed').hasClass('set-hidden'))
    $('.header-layout-fixed').removeClass('set-hidden');
});

$('. site-footer').click(function() {
if($('.header-layout-fixed').hasClass('set-hidden'))
    $('.header-layout-fixed').removeClass('set-hidden');
});

Tietokoneella toimii täysin ja mobiilissakin melkein. Toimii niin kauan kuin selaimen käyttöliittymä pysyy näkyvissä. Kun se häipyy horisontin taakse, sisällön rullautuminen tapahtuu. Selkeä parannus kuitenkin mobiiliinkiin. Minusta on erittäin huono idea Googlelta laittaa selaimen käyttöliittymä häipymään horisonttin taakse. Siitä aiheutuu suunnitteluun ja käyttöön vain ja ainoastaan harmia minun mielestäni.

Tämä sivusto toimii samaan tapaan kapeilla leveyksillä. Pikku parannuksena voisi laittaa sen, että kun avaa valikon, vasemman reunan vierityspalkki häviäisi näkyvistä. Näyttäisi hitusen paremmalta.

Sisällön harmaannutus tällä sivustolla mobiilivalikon kanssa oli niin hyvä idea, että toteutin sen (!important oli tässä tapauksessa välttämätön, koska jatkossa tuli body.luokka {overflow:auto}, joka olisi ilman !important-sääntöä kumonnut merkityksen):
Koodi:
body.set-hidden{overflow-y:hidden!important;overflow-x:hidden!important}
body.set-hidden .extra-content-wrapper{background-color:lightgray;opacity:0.3}
body.set-hidden .site-footer,body.set-hidden #breadcrumblistTop{opacity:0.3}
 
Viimeksi muokattu:
Eräs koodaaja suositti, että niin paljon kuin mahdollista käyttäisin relatiivisia polkuja. CSS:n kanssa se onnistuu muidenkin luoman CSS osalta, jos vain CSS-tiedostossa on id="css-nimi-css", mutta ei onnistu JS:n kanssa jos yrittää poistaa tietyn JS:n käytöstä ja määrittää sille relatiivisen polun wp_head()..., . Konsoli huomauttaa aina virheestä jos niin tekee. WP luulee, että niitä ei ole käytössä vaikka onkin.

Relatiiviset polut tulee kyseseen, ku koodissa/tyylitiedostoissa viittaat toiseen tiedostoon, joka on about samassa polussa ja liittyy suoraan tiedostoon, jota viitataan. Jos muu polku muuttuu, niin ei tarvi joka tiedostoon polkuja uusiksi kirjoittaa (varsinkaan, kun et taida näppärimpiä työkaluja käyttää). Juuri-tasolla toi on vähä se ja sama.
 
Eli minun ei kannata enempää asiaa pohtia ja sinunkin mielestäni muutokseni olivat turhia?

No päivittyi sentään lopulta #1051 ehdotukseen pohjautuva koodi. Tyhjensin moneen kertaan selaimen välimuistin, mutta ei ollut heti vaikutusta. theme.js muutos ja seuraava CSS toimivat todella hyvin kännykässäkin. Parantaa käytettävyyttä selvästi.
Koodi:
body.set-hidden{overflow-y:hidden!important;overflow-x:hidden!important;}
body.set-hidden .extra-content-wrapper{background-color:lightgray;opacity:0.3}
body.set-hidden .site-footer,body.set-hidden #breadcrumblistTop{opacity:0.3}
Tietokoneessa välimuistin tyhjennys toimii paremmin. Yksin näppäinkomennus ja on tuore sivuversio käytössä.
 
Viimeksi muokattu:
Ei varmaan kannattaisi tiivistää tuota CSS:ää, on helpompi etsiä virheitä järkevästi muotoillusta kuin tuollaisesta tiivistetystä. Herkästi joku aaltosulkeen tai puolipisteen puuttuminen tai väärässä paikassa olo jää tuollaisesta mössöstä huomaamatta. Itse en oikein luottaisi tuohon että kaikki on kirjoitettu yhteen pötköön ilman välejä, luultavasti kaikki selaimet eivät tulkitse sitä oikein. Se, että tuossa tiivistyksessä säästää pari tavua ei vaikuta nopeuteen mitenkään. Vähän meinaan epäilen tuollaisten hidden!important -kohtien ja vastaavien toimivuutta. Tuolla vaan turhaan kaivaa verta nenästään.
 
Ei varmaan kannattaisi tiivistää tuota CSS:ää, on helpompi etsiä virheitä järkevästi muotoillusta kuin tuollaisesta tiivistetystä. Herkästi joku aaltosulkeen tai puolipisteen puuttuminen tai väärässä paikassa olo jää tuollaisesta mössöstä huomaamatta. Itse en oikein luottaisi tuohon että kaikki on kirjoitettu yhteen pötköön ilman välejä, luultavasti kaikki selaimet eivät tulkitse sitä oikein. Se, että tuossa tiivistyksessä säästää pari tavua ei vaikuta nopeuteen mitenkään. Vähän meinaan epäilen tuollaisten hidden!important -kohtien ja vastaavien toimivuutta. Tuolla vaan turhaan kaivaa verta nenästään.

?? Tottakai tuotannossa kaikki on tiivistettyä. Se mitä devaaja työstää on eri asia. edit: ja selaimet ei rivinvaihdoista ja turhista välilyönneistä välitä. Ei kyl tähän liity, mut yleensä kaikki devaajan koodi menee babelin ym. läpi eikä sitä ole ihmissilmin tarkoitus lukea.
 
Viimeksi muokattu:
?? Tottakai tuotannossa kaikki on tiivistettyä. Se mitä devaaja työstää on eri asia. edit: ja selaimet ei rivinvaihdoista ja turhista välilyönneistä välitä.
Juu, varsinkin devatessa (kuten nyt ollaan tekemässä) on fiksumpi pitää tuo vähän luettavampana. Joskus silloin aikanaan vuosia sitten kun itse enemmän nettisivuja tein niin jotkut selaimet eivät tykänneet jos aivan kaikki oli yhtä pötköä vaan esimerkiksi juuri tuossa hidden!important -kohdassa ainakin jollekin selaimelle piti olla välilyönti tuon n-kirjaimen ja huutomerkin välissä, muuten tuollainen kohta jäi tulkitsematta. En sitten tiedä kuinka paljon paremmin nykyselaimet selviävät noista. Tottakai tuotantoon voi maltillisesti tiivistää tuota mutta vasta sitten kun homma alkaa olemaan "valmis".

edit:
Piti oikein kokeilla tuota esimerkkipätkää muutamaan validaattoriin ja näköjään nykyään noinkin paljon tiivistetty kelpaa validiksi. Aikanaan, joskus CSS1 -aikoihin tuo oli vähän tarkempaa mutta siitä onkin jo aikaa, tosin silloin selaimet muutenkin ymmärsivät tuota css:ää vähän vaihtelevammin. Muutamia warningejahan tuo antaa mutta pääosin id-määritteestä ja important-määreistä eli ei mitään fataalia.
 
Viimeksi muokattu:
Jos joudun editoimaan, puran pakkauksen
tuo tekee vähän rumaa jälkeä kun }@media jää yhteen, mutta se on helppo korvausajona muuttaa. Ihan pikkaisen parempi se saisi olla. Jos joku tietää hitusen paremman vastaavan palvelun, olisi kiva tieto.
Jos koen, että koodi on kunnossa, pakkaan sen
Validoin aina pakkaamattomana
Se ei teeman kaikkea swiper-koodia pidä oikeana, joten swiper osalta jopa virheilmoitukset pitää ohittaa.
Muuten se on hyvä validaattori, johon voi luottaa. Huomautuksista en välitä. Se ei siedä sitä, että laitetaan sisennettyjä lohkoja, esim. seuraavaa (teemassa oli yksi tämän tyylinen):
Koodi:
@media{
    #sidebar{
     .wigdet {margin...}
     .muu{...}
    }
}
Olisiko netissä sellaista palvelua, että se osaisi etsiä mahdollisia duplikaatteja ja osaisi yhdistellä mahdollisesti samoille elementeille tulevaa koodia yhteen. En onnistunut siistimään manuaalisesti koodiani.

Muuten pitää antaa vain olla CSS hieman epäjärjestyksessä. Eipä sitä epäjärjestystä kukaan muu katsele kuin itse ja joku kehittelijä. Tavis selaaja ei siitä tiedä mitään. En voi testata ja kokeilla testisivustolla, sillä se ei toimi oikein. Jostakin oudosta syystä valikko on kokonaan valkoinen, vaikka siinä pitäisi olla täsmälleen sama CSS. Kopioin kaikki tiedostot ja yhden CodeSnippet tietueen, joka liittyy CSS:ään. Kun testisivusto ei toimi pitää kai joskus pystyttää paikallinen palvelin.
 
Viimeksi muokattu:
Jos joudun editoimaan, puran pakkauksen
tuo tekee vähän rumaa jälkeä kun }@media jää yhteen, mutta se on helppo korvausajona muuttaa. Ihan pikkaisen parempi se saisi olla. Jos joku tietää hitusen paremman vastaavan palvelun, olisi kiva tieto.
Jos koen, että koodi on kunnossa, pakkaan sen
Validoin aina pakkaamattomana
Se ei teeman kaikkea swiper-koodia pidä oikeana, joten swiper osalta jopa virheilmoitukset pitää ohittaa.
Muuten se on hyvä validaattori, johon voi luottaa. Huomautuksista en välitä.
Kuulostaa kokoajan enemmän siltä, että teet ihan hirvittävän määrän ylimääräistä työtä ja näet vaivaa validoinneista, minifioinneista ja vieläpä näiden purkamisista. Kaikki tämä olisi täysin automatisoitavissa kunhan suostuisit käyttämään edes vähän modernimpia menetelmiä ja työkaluja näiden muutostesi kanssa.

Lupaan kirjoittaa sinulle step-by-step ohjeen Loacalin käyttöönotosta ja siitä kuinka pääset sen kanssa devauksessa kokonaan toiselle tasolle, jos sinä lupaat kokeilla kehitystä sen avulla :D

Se ei siedä sitä, että laitetaan sisennettyjä lohkoja, esim. seuraavaa (teemassa oli yksi tämän tyylinen):
Koodi:
@media{
    #sidebar{
     .wigdet {margin...}
     .muu{...}
    }
}
Olisiko netissä sellaista palvelua, että se osaisi etsiä mahdollisia duplikaatteja ja osaisi yhdistellä mahdollisesti samoille elementeille tulevaa koodia yhteen. En onnistunut siistimään manuaalisesti koodiani.
Tämä näyttää kääntämättömältä SASS/SCSS koodilta. Tuo aiemmin postaamasi SourceMap virhe liittyy juuri tähän. Kun käytetään sassia ja siitä käännetään css, tekee kääntäjä .map päätteisen tiedoston, jonka tarkoitus on antaa selaimen dev-toolsille riittävä määrä tietoa, jotta se osaa siitä käännetystä css tiedostosta viitata alkuperäiseen sass lähdekoodin ja sen oikeisiin rivinumeroihin. Tuotantosivustollahan tuollaisia .map tiedostoje ei kuulukaan olla.
 
Mukava huomata että valikon osalta on tapahtunut edistystä. Noihin nappien väreihin voisin melkeimpä suositella palettien googlailua jos ei ketään visuaalisesti lahjakasta kaveria löydy lähipiiristä. Tuo valkoinen fontti mustalla reunalla pistää ikävästi silmään (valikossa). Ihan rehellisesti valkoinen voisi toimia...
Valkoisen reunustavan mustan vaihdoin harmaaseen. Se terävöittää valkoisia kirjaimia, mutta ei terävöitys ei pistä silmään - tai niin ainakin ajattelen.

Värijuttuja täytyy vielä pohtia. Kun otin bbPressin edellisen version CSS:n jotensakin muuttumattomana käyttöön, se muutti suurimman osan painikkeiden värin. Yksi tai kaksi punertavaa painiketta piti erikseen muuttaa.

Huomasin, että eräälle artikkelisivulle jäi teeman mukainen punertava painike. Sekin pitäisi yhtenäisyysyistä vaihtaa.

Kun punertavaa sävyä teemasta on alkuperäisen CSS:n pohjalta lähinnä vain linkeissä , voisi ajatella, että teeman alkuperäisvärejä voisi ajatella muuttavansa siinäkin. Näin teeman väreistä ei jäisi jäljelle juuri mitään. Värimuutoksia saa ehdottaa. Aiemmin aktiivinen välilehti ja sivu korostettiin värillä "gold".

Teema olisi lähinnä runko. Sellaisena kyllä minä nämä WordPressin teemat itselleni näenkin. Kun en itse tee kokonaan, puran teemaa ja muutan rajullakin tavalla. Onhan siinä toki se ongelma, jos teemaan tulee merkittäviä CSS-päivityksiä, niistä en tiedä mitään. JS-päivityksistä theme.js jää päivittämättä. Minulla oli joskus HTML-Kit tai jokin muu ohjelma, jossa sai rinnakkain kaksi tiedostoa. Kun tiedostot laittoin rinnakkain, oli toiminto, jolla ohjelma näytti tiedostojen erot. Erot korostettiin. Tällainen olisi nytkin kiva olla.

Suurin muuttamaton teeman komponentti on swiper. Jos sitä päivitetään, sen päivitykset jäävät tekemättä. Mutta nykyinen swiper koodi toimii ihan ok, joten tuskin kai sen mahdollisista muutoksista pois jääminen olisi merkittävä asia.

Swiperin otsikon luontia ei voi käyttää foorumiosiolla, koska teema lykkää väärän otsikon. Mietin, heivaisiko swiperin pois kokonaan foorumiosiosta? Voisi heivata samalla siihen liittyvän JS-tiedostot sekä teeman CSS:stä swiperin CSS vain muille sivuille. Foorumiin voisi swiperin tilalle tulla maksimissaan n. 100px suuruinen otsakekuva, jolle tulee taustaväri. Iso swiper saattaa foorumissa olla pidemmän päälle ärsyttävä.

Swiperin JS ei näy lähdekoodissa, joten sitä ei voi heivata tyyliin
wp_deregister_script('screenr-wiper');

Jos haluan visuaalisesti heivat pois vain osittain toimivan swiper-efektin foorumiosiosta, mikä olisi järkevä tapa päästä eroon myös sen JS:tä?
 
Viimeksi muokattu:
Olikos se living_death, joka on tämän sivuston värisuunnittelun takana. Sen punertavan voisi jotenkin korvata jollakin muulla. Mitä living_death ehdottaa?

En poistanut swiperia foorumiosiolta, mutta pienensin kokoa. Laitoin yleiseksi maksimikorkeudeksi 150px ja kännykälle 100px.

Vaihdoin välilehtien ja linkkien värejä täältä kopsatuilla väreillä. Punertava nyt vaan ei istunut. En tiedä, onko nykyinenkään hyvä sivustolleni.
Jos antaa hex-arvoina, ne on helppo vaihtaa etsi- ja korvaa -toiminnolla.
 

Liitteet

  • 2021-05-20 18.57.26 www.sanaristikkofoorumi.net 1b1d1b51eae9.png
    2021-05-20 18.57.26 www.sanaristikkofoorumi.net 1b1d1b51eae9.png
    6,1 KB · Luettu: 54
Viimeksi muokattu:
Lataan sen localin. Valikko pitää kyllä luoda uusiksi, sillä https//-alkuisista omista linkeistä pitää päästä eroon, jotta voi testata asioita. Foorumitkin voi merkitä WP:n omilla mekinnöillä. Ei minulla kyllä mitään akuutteja kehitysajatuksia ole. Tähän projektiin voi nyt pistää taas tauon.

Tutkin CSS organisoijia. En nyt tiedä, mikä olisi paras, mitä ilmaiseksi tarjotaan.
Tuolla tutkin päällekkäisyyksiä. Prosentuaalisesti päällekkäisyys osoittautui merkityksettömäksi selaimen kannalta.

Yritin yhdistää kaiken yleisen CSS:n, mutta yhdistetty CSS ei toiminut suunnitellusti. Yhdistämisellä olisin saanut vain 14kB:n vähennyksen, mikä on muuhun verrattuna täysin merkityksetöntä.

Päällekkäisyys ja siitä johtuva !important liikakäyttö haittaa vain omaa CSS:n hallintaani. Siirsin väliaikaiseksi tarkoitetut muutokset pakattuna vain tiedostojen loppuun. Näyttää ainakin koodin katsojille siistimmältä suunnittelulta kuin onkaan. Huiputus.


Kiitos saamistani kehittelyvinkeistä.
 
Viimeksi muokattu:
Tosin olisihan tässä vielä kehitettävää. Edellisen version kanssa minulla oli evästetiedote + muutamia asetuksia. Ne liittyivät yhteen, joten homma täytyisi miettiä uudestaan, koska yhtä paljon asetuksia kuin oli ennen, ei tule.

Merkittävin asetus oli ikoneja käyttävä pikavalikko. Siinä oli seuraavat toiminno silloin kun oltiin yksittäisessä säikeessä:
  1. Siirry aihelistaukseen.
  2. Luo uusi aihe
  3. Luo uusi aihe foorumi valiten (avasi apuvalikon)
  4. Luo uusi kommentti
  5. Näytä/piilota toimintopalkki
  6. Lataa sivu uudestaan
Tuolla palkille oli neljä sijoittelupaikkaa. Mutta jos viitisi, voisiha siihen sisällyttää vaikka mitä. Voisin halutessani luoda siitä netin eniten käyttäjän itsensä säädettävissä olevan. Idea olisi sama kuin itse asiassa tämän säikeen alussa esitin, mutta käyttäjän itsensä päätettävin toiminnoin.

Siihen voisi sijoittaa seuraavia asioita:
  1. Kirjaudu/kirjaudu ulos (kirjautuminen siirtäisi eri sivulle)
  2. Kirjaudu somen kautta (avaisi apuikkunan)
  3. Näytä profiili (siirtäisi eri sivulle)
  4. Siirry aihelistaukseen (siirtäisi eri sivulle)
  5. Luo uusi aihe ( (siirtäisi eri sivulle, jos muokataan yksittäistä säiettä)
  6. Luo uusi aihe foorumi valiten (avasi apuvalikon)
  7. Luo uusi kommentti foorumiin (siirtäisi sivun loppuun)
  8. Näytä foorumin pikaopas (avaisi apuikkunan)
  9. Näytä säännöt (avaisi apuikkunan)
  10. Vaihda listauksen järjestystä (avaisi apuvalikon)
  11. Näytä/piilota toimintopalkki
  12. Lataa sivu uudestaan
  13. Sirry edelliseen kohtaan
Valikko Pikavalikko sisältää nyt mielekkään kokonaisuuden, sitä käyttäen toimintopolku on joillekin asioille turhan pitkä. Käyttäjän itsensä määrittelemissä ja haluamaansa paikkaan laitettavassa pikavalikossa, kaikki, mitä käyttäjä itse haluaa, olisivat todellisia pikavalintoja.

Kun kaikki nyt eivät kumminkaan kompaktista pikavalinnasta tykkäisi, mikä tuli varsin pian selväksi, ei oletusasetuksilla olevaa pikavalikko voi oikein vakionakaan olla. Tai sitten sen piilotus pitäisi olla helppoa, jos se jotakuta ärsyttää.
Sijoittelumahdollisuudet:
  • Yhäällä keskellä
  • Oikealla ylhäällä
  • Oikealla keskellä
  • Vasemmalla keskellä
  • Vasemmalla alhaalla
  • Keskellä alhaalla

Pystyn siis luomaan foorumin, joka on hyvinkin käyttäjän mieltymykset huomioiva. Mutta jos siihen ryhdyn siitä tulisi vain kehittelydemo jollekulle muulle - vaikka tämän sivuston koodaajalle, sillä ei sellaisen luominen vain omaa foorumia ajatellen ole mitään järkeä. Nettiin voisin laittaa täydellisen paketin bbPressille. Sitä voisi kuka tahansa kehittelijä kokeilla. Silloin sitä voisi joku muukin kehitellä.

Monipuolinen asetussivu vaatisi aika lailla evästekoodausta. Runko evästeille minulla on olemassa.

Ongelmana on toki, että foorumilistaus liittyisi vain foorumiini. Foorumilista pitäisi tyhjentää ja kertoa, että se pitää itse täydentää.

Tosin bbPressistä puuttuu ominaisuuksia, joita on XenForossa, joten ei bbPressistä omin viritelminkään kunnon kilpailijaa XenForolle tule, se täytyy myöntää. Vain jos osaa lisätä ne puuttuvat ominaisuudet, se voisi oilla kilpailukykyinen.
 
Viimeksi muokattu:
Katsoin Ylilauta-foorumin valikkoa. Se on lähes yhtä leveä kuin omani, viewport-arvona n. 460px. Minusta se on järkevämmin mitoitettu kuin tämän sivuston mobiilivalikko. Laitoin seuraavaan kommenttiin vähän vertailua omani ja tämän sivuston mobiilivalikon välillä.
 
Viimeksi muokattu:
Asetin valikot rinnakkain. Minusta siis
  1. Vasemmanpuoleinen on liian kapea ja monet valikkokohdat rivittyvät ikävän näköisesti monelle riville. Valikko saisi olla sen verran leveä, että rivittymistä ei tapahtuisi. Oikeanpuoleisessa valikossa ei ole rumalta näyttävää rivittymistä.
  2. Vasemmalla valikko ei näytä hyvältä koska se on pitkä. Avautuva/sulkeutuva näyttäisi paremmalta. Oikeanpuoleinen päävalikko näyttää paremmalta. Mutta se vaatii enemmän klikkejä, jos haluaa käydä sitä lävitse. Asioilla on aina etunsa ja haittansa.
  3. Vasemmanpuoleisessa valikossa oikeassa reunassa vain hälytyskello ja haku on tarpeen olla aina esillä. Muut voisi olla päävalikossa. Haku siksi, että sillä on lisävalintoja. Minun valikossani haku voi olla valikon yhteydessä, koska lisäominaisuuksia siinä ei ole. Jos olisi hälytyskellotoiminto, se olisi hyvä olla tarpeen tullen esille tuleva komponentti oikeassa reunassa. Kiinteää elementtiä en siitä tekisi. Sellaisena se on ihan turha.
  4. Jos vasemman puoleinen valikko olisi leveämpi, osa kohdista voisi laittaa välilehteen. Se lyhentäisi valikon pituutta. Toki tulisi yksi klikki enemmän, joten sr ei ole ongelmaton ratkaisu.
  5. Valikon sulkupainike saisi vasemmanpuoleisessa olla kiinteä, ettei "häipyisi horsontin taakse". Oikeanpuoleisessa valikossa avauspainike on myös sulkupainike, joten erillistä sulkupainiketta ei tarvita. Avaus/sulku toimivat mielestäni fiksummin.
 

Liitteet

  • Untitled1944_20210522151747.png
    Untitled1944_20210522151747.png
    787,5 KB · Luettu: 117
Viimeksi muokattu:
Katsoin muuten äsken paria muuta XenForo-sivustoa (After Dawn ja Matkapuhelinfoorumi). Niissä näemmä ei ole kiinteää yläpalkkia. Täällä on tehty enemmän töitä sivuston kanssa. Jos yläpalkin joku haluaa rullautuvan ja vaihtoehto löytyy asetuksista, tämä sivusto on selvästi kehittyneempi.

Koska alue Pikanavigaatio puuttuu, valikko on siistimpi. Samalla leveydellä ei tule tekstien rivittymistä.
 
Katsoin muuten äsken paria muuta XenForo-sivustoa (After Dawn ja Matkapuhelinfoorumi). Niissä näemmä ei ole kiinteää yläpalkkia. Täällä on tehty enemmän töitä sivuston kanssa. Jos yläpalkin joku haluaa rullautuvan ja vaihtoehto löytyy asetuksista, tämä sivusto on selvästi kehittyneempi.

Koska alue Pikanavigaatio puuttuu, valikko on siistimpi. Samalla leveydellä ei tule tekstien rivittymistä.
Kyse on siitä että esim. matkapuhelinfoorumilla ei varmaan ole haluttu mitään kiinteää yläpalkkia koska sille ei ole nähty olevan tarvetta.
 
Pidän pääosin tämän foorumin tyylistä. Muutaman pikku huomautuksen tein, mutta kyse ei ole vakavista seikoista.
Ylilauta laittaa massiivisen valikon, jossa on yhdessä paikassa hirveän paljon kaikenlaista "sälää". Onko sekään hyvä.

Ainahan systeemien kanssa joutuu tekemään kompromisseja. Toisen mielestä joku kompromissi on toista parempi.

No parin vuoden takaisesta tämän foorumin toteutus ja oma toteutukseni ovat kovasti lähentyneet toisiaan ja niissä on nykyisin paljon samaa.
Kumpiakin voi verrata esim. Suomi24 ja Ylilauta toteutuksiin.

Silti kiehtoo vieläkin luoda ihan kokeilumielessä alkuperäistä ideaani toteuttava pikavalikko. Se ei olisi oletusarvo, mutta sen voisi joko valikosta Pikavalinnat ottaa kiinteämuotoisena käyttöön tai sitten rakentaa ihan harrastemielessä asetussivu.

Minusta nyt oli hieman tyhmää nostaa esille tämän foorumin toteutukseen liittyvät huomautukseni. Säie, jossa asia nostettiin esille, on poistettu. Kun säie poistettiin, asia unohtunee, mutta jatkossa jos asia liittyy tähän foorumiin, se on hyvä pitää tämän foorumin sisällä.

Tuli selväksi, että pientenkin muutosten tekeminen tämäntyyppisellä sivustolla ei ole niin yksinkertainen juttu kuin omalla sivustollani. Jos tämä sivusto näyttää joiltakin osin liian erilaiselta kuin muut XenForo-foorumit, se voi tuntua oudolta. Muutoksilla tämänkaltaisilla sivuilla voi olla kumulatiivisia seurauksia. Vaikka niitä olisikin, koen silti ehdotukseni kommentissa #1066 mielekkäinä. Niistä ei pidä loukkaantua, mutta nyt on taidettu loukkaantua.
 
Viimeksi muokattu:
Joku haukkui pystyyn seuraavan sivun:


Säie, jossa sivu haukuttiin perusteellisesti on poistettu. Tein sivulle suuriakin muutoksia, jotta olisi vähemmän kritisoitavaa. Tiivistin myös säikeiden esitystapaa, kun foorumiosiota arvosteltiin liiallisesta väljyydestä. Tarkistin joitakin marginaaleja ja korjasin etenkin numeroitujen listojen margin- ja padding-arvoja.

Vaikka toimin joidenkin asioiden suhteen jääräpäisesti, otan kyllä huomioon esitettyä kritiikkiä milloin katson kritiikin olevan sellaista, että edellyttää toimenpiteitä.
 
Viimeksi muokattu:
Voisinkohan kopioida täältä omaan foorumiini WordPress-vinkkejä? Laittaisin vaikka otsikoksi Saamiani WordPress-vinkkejä. Näin vinkit olivat jossakin kootusti esillä. Kiitos saamistani vinkeistä. Niistä on ollut paljon apua. Tosin mielestäni annetut vinkit ovat WordPressin kooditietoa, joten en lupaa ymmärtääkseni tarvitse.

Fiksumpaa kyllä olisi, jos tästä säikeestä poimisi spesiaalisti WordPressiä koskevia koodivinkkejä WordPress-säikeeseen.
 
Viimeksi muokattu:
Kuulostaa kokoajan enemmän siltä, että teet ihan hirvittävän määrän ylimääräistä työtä ja näet vaivaa validoinneista, minifioinneista ja vieläpä näiden purkamisista. Kaikki tämä olisi täysin automatisoitavissa kunhan suostuisit käyttämään edes vähän modernimpia menetelmiä ja työkaluja näiden muutostesi kanssa.

Lupaan kirjoittaa sinulle step-by-step ohjeen Loacalin käyttöönotosta ja siitä kuinka pääset sen kanssa devauksessa kokonaan toiselle tasolle, jos sinä lupaat kokeilla kehitystä sen avulla :D


Tämä näyttää kääntämättömältä SASS/SCSS koodilta. Tuo aiemmin postaamasi SourceMap virhe liittyy juuri tähän. Kun käytetään sassia ja siitä käännetään css, tekee kääntäjä .map päätteisen tiedoston, jonka tarkoitus on antaa selaimen dev-toolsille riittävä määrä tietoa, jotta se osaa siitä käännetystä css tiedostosta viitata alkuperäiseen sass lähdekoodin ja sen oikeisiin rivinumeroihin. Tuotantosivustollahan tuollaisia .map tiedostoje ei kuulukaan olla.
Voisiko vähän selittää SASS ideaa. Tuntuu vain melkoisen turhalta lisältä.Jos pitää voida vertailla SASS-koodia ja lopullista CSS:ää, silloihan ei teeman CSS:ään saisi koskea. Se ei oikein tunnu mielekkäältä. Jos teeman CSS:n olisin jättänyt, olisi hirveän paljon turhaa CSS:ää ja todella paljon uudelleen määrittelyjä. Siinä viimeistään olisi vaikea hallita kokonaisuutta. Turhaa CSS:ää on toki vieläkin, mutta paljon sitä poistin.

Onko millään mahdollista päästä eroon valituksesta, että map-tiedistoa ei saada luotua tai sitä ei löydy? Kai SASS-vertailun voisi jotenkin kokonaan ohittaa?

Muuta valitusta konsoli ei anna.

Silti yksi lisäosa ei nyt toimi. Onneksi ei kyse ole kovin törkeästä lisäosasta.

Editori (TinyMCE) hieman oikkuilee välillä (laittaa näkyviin <p>...</p>).
 
Viimeksi muokattu:
Voisinkohan kopioida täältä omaan foorumiini WordPress-vinkkejä? Laittaisin vaikka otsikoksi Saamiani WordPress-vinkkejä.
Omasta puolestani saat kopioida niin paljon kuin huvittaa, kunhan jätät lähdeviittauksen ja nimimerkkini pois.
Voisiko vähän selittää SASS ideaa. Tuntuu vain melkoisen turhalta lisältä.Jos pitää voida vertailla SASS-koodia ja lopullista CSS:ää, silloihan ei teeman CSS:ään saisi koskea. Se ei oikein tunnu mielekkäältä. Jos teeman CSS:n olisin jättänyt, olisi hirveän paljon turhaa CSS:ää ja todella paljon uudelleen määrittelyjä. Siinä viimeistään olisi vaikea hallita kokonaisuutta. Turhaa CSS:ää on toki vieläkin, mutta paljon sitä poistin.

Onko millään mahdollista päästä eroon valituksesta, että map-tiedistoa ei saada luotua tai sitä ei löydy? Kai SASS-vertailun voisi jotenkin kokonaan ohittaa?
SASS:ia käyttämällä saat organisoitua koodin paremmin vaikka eri tiedostoihin, voit käyttää muuttujia (esim. värien määrittelyyn), luoda erilaisia uudelleenkäytettäviä komponentteja (Mixins), tehdä laskutoimituksia (sekä väreille, että mitoille) ja paljon muuta. SASS on oikeasti kätevä, kun siihen vähän syventyy. Katsele täältä nuo esimerkit lävitse, noissa on kivasti rinnakkain SASS ja käännöksestä syntyvä CSS, niin päässet hieman kärryille mahdollisuuksista.

SASS:ssa idea onkin, että et sen jälkeen enää ikinä koske käsin varsinaiseen css-koodiin.

Se, että selaimen dev-konsolissa näkyy tuo map- virheilmoitus on vain kosmeettinen ongelma. Selain ei normaalisti sivuja ladatessa noita .map tiedostoja yritä ladata, ainoastaan silloin kun avaat dev-konsolin. Toki siitä eroonkin pääsee, jossain selaimen dev-konsolin asetuksissa on mahdollisuus kieltää .map tiedostojen lataus. Mutta jatkoa ajatellen tuota ei kannata tehdä.

Käyttämäsi Screenr teeman tekijät ovat näköjään senverran mukavaa porukkaa, että jakavat teeman SASS kooditkin. Teepä nopea harjoitus, mieluusti sivuston kopioon (ota varmuuskopiot ensin!)

1. Kopioi screenr/assets/sass/ hakemiston sisältö aliteemaasi screenr-child/assets/sass/ hakemistoon.
2. Muokkaa tiedostoa screenr-child/assets/sass/style.scss poista tiedoston alusta Screenr:n omat teeman kuvauskommentti ja lisää tilalle aliteeman tiedot:
Koodi:
/**
Theme Name: Screenr Child Theme
Version: 1.2.3
Template: screenr
*/

Pienen yhteensopivusongelman takia pitää muokata vielä paria muutakin tiedostoa:
screenr-child/assets/sass/_variables.scss noin riviltä 130 lähtien, korvaa mixin tällä versiolla:
Koodi:
@mixin rem($property, $px-values) {
        $baseline-rem: $baseline-px;
        #{$property}: $px-values;
        @if type-of($px-values) == "number" {
                #{$property}: $px-values / $baseline-rem + rem; }
        @else {
                $rem-values: unquote("");
                @each $value in $px-values {
                        @if $value == 0 {
                                $rem-values: append($rem-values, $value + rem); }
                        @else {
                                $rem-values: append($rem-values, $value / $baseline-rem + rem); } }
                #{$property}: $rem-values; }
}

Tiedostossa screenr-child/assets/sass/_sections.scss noin rivillä 371 poista välilyönti miinusmerkin jälkeen.
@include rem('margin-left', - (60px / 2) ); => @include rem('margin-left', -(60px / 2) );

3. varmista, että lapsiteeman functions.php:ssa on koodit:
PHP:
add_action('wp_enqueue_scripts', function(){
    wp_dequeue_style('screenr-style');
}, 99);

add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('screenr-child', get_stylesheet_directory_uri() . '/style.css', [], wp_get_theme()->get('Version') );
}, 10);

4. Asenna lisäosa wp-scss ja lisäosan asetukset näin:
1622908978384.png

5. Lataa etusivu uudelleen.

Nyt pitäisi tapahtua seuraavaa:

screenr-child/style.css generoituu uudelleen sass koodista käännettynä. Samalla syntyy style.css.map tiedosto. Nyt kun avaat selaimessa devel toolin, ei sen enää pitäisi valittaa puuttuvasta .map tiedostosta ja dev-konsolin css- viitteet kertovat missä scss tiedostossa ja millä rivillä näytettävä css koodi on.

Tämä tietysti hävittää kaikki style.css tekemäsi muutokset ja joudut ne tekemään uudelleen, mutta tällä kertaa teetkin ne tuonne assets/sass/ alla oleviin tiedostoihin. wp-scss lisäosan Compiling modea vaihtamalla saat määritettyä minkälaista css koodia scss tiedostoista synnytetään. Tuotannossa 'Crunched' ja devaillessa 'Expanded'
 
Ok. Perusidea tuli selväksi. Olen niin paljon poistanut CSS:ää, että ehkä tällä kertaa en ala muutostyöhön. Kun yritin siistiä foorumiosan CSS-tiedostoa, ei siitä oikein tullut mitään.

Sisäkkäiset lohkot CSS teeman style.css-tiedostossa ovat kaiketi käännösvirheitä?

Teeman CSS ei tosin niin paljon lisäyksiä sisällä kuin foorumin CSS. Kyse on lähinnä poistoista.

Tätä pitäisi testata testisivustolla, mutta jostakin syystä se ei toimi oikein, joten sillä ei saa kaikkea testattua.
 
Viimeksi muokattu:
Tilastoista käy ilmi, että n. 60% on kännykän käyttäjiä. Jos täälläkin on sama lukema, suosittelen esittämiäni muutoksia.
 
Tilastoista käy ilmi, että n. 60% on kännykän käyttäjiä. Jos täälläkin on sama lukema, suosittelen esittämiäni muutoksia.
Ristikoita, sudokuita tms. ratkoessa yleensä avataan se puhelin siihen lehden viereen toisin kuin tietokoneaiheisella foorumilla missä ihmisillä on varmaankin valikoima tietokoneita. Suosittelen että et kerro ammatikseen foorumia pyöritettäville että miten tehdä sitä, ei kukaan ammattilainen halua että hänelle tullaan kertomaan huonoja vinkkejä. Nettisivun tekemisessä on paljon enemmän mitä voisi kuvitella, syystäkin osaavat tekijät velottaa 80-100€/h.

Et ole myöskään itse toteuttanut sinulle suositeltuja saavutettavuusmuutoksia, tällä foorumilla sentään pääsee kaikkin valikkoelementteihin käsiksi ilman hiirtä. Ihan tiedoksi että suomessakin on yli miljoona (eli n. 20%) henkilöä jotka tarvitsee saavutettavia palveluita. Tällä hetkellä laki jo vaatii kaikkia yleishyödyllisiä palveluita olemaan saavutettavia ja mm. verkkokaupoille on jo annettu deadline asioiden kuntoon hoitamisessa.

Kokeile vaikka harjoitteena että "murrat" hiirikätesi ja pyrit käyttää ei hallitsevalla kädellä sivustoa, sitten kokeile pimeässä/kirkkaassa valossa/puhelimella/puhelimella kirkkaassa valossa ei hallitsevalla kädellä. Ja jos vielä tuntuu helpolle niin kokeile ruudunlukijalla, viimeistään silloin huomaat että valikko ei ole käytettävissä.
 
Juu, tuosta accessibilitystä itsekin jo aikanaan mainitsin, ongelmat ovat sillä tasolla että jopa jotkut validaattorit herjaavat asiasta. Ja ei se accessibility tarkoita vain jollakin tavalla vammaisia ihmisiä, monet tavalliset ihmisetkin käyttävät esimerkiksi pelkkää näppäimistöä selaamiseen tai haluavat käyttää jotain standardeja näppäinoikoteitä tai hiirieleitä selaamisessa ja nuo asiat ovat yllättävän monella sivulla rikki vähintään osittain tavalla tai toisella.

Itse käytän monesti näppäinoikoteitä, yleisimmin varmaan tab-näppäintä lomakkeen kentissä liikkumiseen ja pari kertaa on jo verkkokauppaostokset jääneet tekemättä kun taborder on ollut niin älytön että ei vaan ole jaksanut taistella sivun kanssa loppuun asti.

Hyvänä esimerkkinä joku verkkokauppa joka oli bindannut tab-näppäimen loikkaamaan AINA sivun ylälaidassa olevaan hakukenttään. Kuten arvata saattaa, itse kun olen tottunut täyttämään kenttiä niin että kirjoitan ensimmäiseen kenttään etunimen, painan tab-näppäintä ja oletan että se menee seuraavaan lomakkeen kenttään, kirjoitan sukunimen, tab, katuosoite, tab, postinumero jne... Vitutus oli taattu ja ostin muualta.
 
Voisiko vähän selittää SASS ideaa. Tuntuu vain melkoisen turhalta lisältä.Jos pitää voida vertailla SASS-koodia ja lopullista CSS:ää, silloihan ei teeman CSS:ään saisi koskea. Se ei oikein tunnu mielekkäältä. Jos teeman CSS:n olisin jättänyt, olisi hirveän paljon turhaa CSS:ää ja todella paljon uudelleen määrittelyjä. Siinä viimeistään olisi vaikea hallita kokonaisuutta. Turhaa CSS:ää on toki vieläkin, mutta paljon sitä poistin.

Onko millään mahdollista päästä eroon valituksesta, että map-tiedistoa ei saada luotua tai sitä ei löydy? Kai SASS-vertailun voisi jotenkin kokonaan ohittaa?

Muuta valitusta konsoli ei anna.

Silti yksi lisäosa ei nyt toimi. Onneksi ei kyse ole kovin törkeästä lisäosasta.

Editori (TinyMCE) hieman oikkuilee välillä (laittaa näkyviin <p>...</p>).

SASS on vain CSS supersetti, mutta turhaan mietit vielä asiaa, jos et ole kunnolla siäistänyt vanilla CSS:ää. Suosittelen että nappaat alkuun tyylittelyt kunnolla haltuun ja samalla opiskelet vähän UX-perusteita.

Sen jälkeen opettelet kirjoittamaan luettavaa ja modulaarista koodia, niin elämänlaatu paranee huomattavasti. Kaikki lähtee kumminkin perusteista liikenteeseen vaikka käyttäisitkin Wordpressiä tai muuta CMS.

Jätä myös kaikki turha hilu ja työvaiheet pois. Ne tuo vaan turhaa kompleksiivisuutta koodiin ja muutosten tekeminen vaikeutuu huomattavasti.
 
Ristikoita, sudokuita tms. ratkoessa yleensä avataan se puhelin siihen lehden viereen toisin kuin tietokoneaiheisella foorumilla missä ihmisillä on varmaankin valikoima tietokoneita. Suosittelen että et kerro ammatikseen foorumia pyöritettäville että miten tehdä sitä, ei kukaan ammattilainen halua että hänelle tullaan kertomaan huonoja vinkkejä. Nettisivun tekemisessä on paljon enemmän mitä voisi kuvitella, syystäkin osaavat tekijät velottaa 80-100€/h.

Et ole myöskään itse toteuttanut sinulle suositeltuja saavutettavuusmuutoksia, tällä foorumilla sentään pääsee kaikkin valikkoelementteihin käsiksi ilman hiirtä. Ihan tiedoksi että suomessakin on yli miljoona (eli n. 20%) henkilöä jotka tarvitsee saavutettavia palveluita. Tällä hetkellä laki jo vaatii kaikkia yleishyödyllisiä palveluita olemaan saavutettavia ja mm. verkkokaupoille on jo annettu deadline asioiden kuntoon hoitamisessa.

Kokeile vaikka harjoitteena että "murrat" hiirikätesi ja pyrit käyttää ei hallitsevalla kädellä sivustoa, sitten kokeile pimeässä/kirkkaassa valossa/puhelimella/puhelimella kirkkaassa valossa ei hallitsevalla kädellä. Ja jos vielä tuntuu helpolle niin kokeile ruudunlukijalla, viimeistään silloin huomaat että valikko ei ole käytettävissä.
Saavutettavuusjuttuihin tein sellaisen kompromissin, että foorumissa oleelliset linkit on tuplana footer-osassa.
Myönnän, etten ole suuremmin miettinyt saavutettavuuskysymyksiä.

Minusta nyt vain esittämäni muutokset valikkoon olisivat eduksi tavallisille käyttäjille. Kyse ei ollut isoista muutoksista. Kännykällä valikon viereen jäänee varsin pieni tila sulkea valikko siirtymällä sisältöön. Mielestäni kiinteä sulkupaine ja leveämpi valikko olisi toimivampi ratkaisu kaikille mobiililaitteille. Ei noin pienten asioiden ehdottamisesta pitöusi hernettä nenäänsä ottaa.
 
Viimeksi muokattu:
SASS on vain CSS supersetti, mutta turhaan mietit vielä asiaa, jos et ole kunnolla siäistänyt vanilla CSS:ää. Suosittelen että nappaat alkuun tyylittelyt kunnolla haltuun ja samalla opiskelet vähän UX-perusteita.

Sen jälkeen opettelet kirjoittamaan luettavaa ja modulaarista koodia, niin elämänlaatu paranee huomattavasti. Kaikki lähtee kumminkin perusteista liikenteeseen vaikka käyttäisitkin Wordpressiä tai muuta CMS.

Jätä myös kaikki turha hilu ja työvaiheet pois. Ne tuo vaan turhaa kompleksiivisuutta koodiin ja muutosten tekeminen vaikeutuu huomattavasti.
CSS:n enempi siivoaminen ei onnistunut. Tuli vain ongelmia. Päällekkäisten määrittelyjen osuus ei kuitenkaan mielestäni ole kohtuuttoman suuri. En vaan jaksa organisoida CSS:ää nykyistä paremmin.
 
CSS:n enempi siivoaminen ei onnistunut. Tuli vain ongelmia. Päällekkäisten määrittelyjen osuus ei kuitenkaan mielestäni ole kohtuuttoman suuri. En vaan jaksa organisoida CSS:ää nykyistä paremmin.

Sitten se on vain tyydyttävä siihen mitä on.
 
Huomasin sattumoisin, että Etusivu (Vesilahden seurajunta) sivut toimivat samaan tapaan kuin omat sivuni.
Vähän massiivinen valikko kyllä on.
 
Kehittämäni systeemi ainskin toimii käyttötarkoituksessaan varsin optimaalisesti.

Footer-osan hyödyntäminrn oli järkevä ratkaisu. Käytän itsekin sivun footer-osan linkkejä kun koen ne nopeimmaksi tavaksi siirtyä toiselle sivulle.

Mutta jos haluan keskeneräisen kommentin kohdalla siirtyä toisaalle, nopein tapa on avata valikko. Joko haen haetun sivun päävalikosta tai aihevalikosta ja sen jälkeen avaan linkin uuteen välilehteen. Kun suljen valikon jatkan kommentin työstämistä. Viimeisimpien aiheiden avaamisen tähden ei tarvitse siirtyä kommenttitilasta minnekään. Voin väliaikaisesti siirtyä avatulle sivulle ja lisätä avatulta sivulta jotain keskeneräiseen kommenttiin. Sitten suljen väliaikaisesti avatun sivun tai sivut ja lopetan kommentin.

Systeemi toimi itseni näkökulmasta tosi hyvin. Sillä saa erittäin tehokkaan toimintatavan, mikä minulla on kaiken suunnittelun päämäärä.

En voi joka sivua merkitä kirjanmerkkeihin ja kirjanmerkkien käyttö on hitaampaa. Aihevalikkoa ei voi joissakin tilanteissa korvata millään.

Jos aihevalikon ja pikavalinnat saisi ylimääräisillä painikkeilla avattua väliaikaisesti sivun päälle, se hieman, mutta ei merkittävällä tavalla tehostaisi toimintaa. Koska nopeutus olisi varsin marginaalinen, en ole niitä alkanut kehitellä.

Sivujen muut käyttäjät ehkä etsivät aihevalikon sisällön mieluummin sivun lopusta, koska heillä ei ole samaan tapaan kuin minulla tarve kesken kirjoittelua avata sivustoni toista sivua.

Mikään valmis ratkaisu ei tarjoa sitä toimivuutta, jonka loin. Systeemini on ainakin itselleni paras mahdollinen.

Muut käyttäjät valitkoon, miten toimivat. Yksikään aktiivikäyttäjä ei ole valittanut, vaikka systeemissä voi olla apuvalikoita, joita sivuillani vieraillut ei koskaan käytä.

Pitäisi kyllä tehdä joskus kysely eräistä seikoista, mutta en ole saanut aikaiseksi.
 
Viimeksi muokattu:
Huomasin että palvelin on LiteSpeed mutta et käytä tai ole kokeillut LiteSpeed Cache lisäosaa WordPressiisi vielä? Sillä voisi jopa teoriassa puolittua latausajat. LiteSpeed Cache - kokeile saatko samat tulokset mitä itse sain.
 
Mistä huomasit asian? Itse en tiennyt sen olevan. Kiitos tiedosta. Asensin sen. Ihan hyvin sivusto nyt toiminut eikä kukaan ole valittanut hitaudesta.

Googlen uusin maksullinen Captcha toimiii varsin hyvin. Akismet-lisäosan poistin. Se ei anna riittävää roskapostinestoa.

Lisäys. Mutta eipä näemmeä Googlenkaan roskapostisuodatus ole täydellinen. Meni tarkastukseen viisi uudelleenohjausta epämääräisille sivuille. Yritti luoda linkit BBC-koodilla, mikä ei ole sivuillani tavalliselle käyttäjälle sallittua.

Korjaus. Kyse oli Googlen roskapostisuodatuksen viheellisestä versiosta. Otin yhteyttä lisäosan tekijään, joka antoi väliaikaisen oikein toimivan version. Virheellinen versio päästi lävitse myös pornoviestejä.

Ainoa pikku ongeln'ma on graafinen editori, joka toimii välillä väärin, jolloin tekstissä tulee esille <p>....</p>. Nimen omaisesti P-tägi oikkuilee sekä herkästi myös taulukointi, harvemmin jokin muu.

P-tägejä joutuu aina silloin tällöin poistamaan. Taulkoita täytyy tehdä varmuuden vuoksi vällillä tavallisilla sivuilla, jotta saa toimivan takaisin, jos kommenteissa rikkuu.

Osaisitko selittää sivulla käsittelemääni statistiikkaeroja WordPressin statistiikkalisäosat
 
Viimeksi muokattu:
Cache saattaa foorumissa tuottaa ongelmia, koska sisältö päivittyy usein. Ainakin yksi ilmennyt saattoi johtua cachesta. Parempi vähän hitaampi toiminta kuin toimintaongelmat.
 
Mistä huomasit asian? Itse en tiennyt sen olevan. Kiitos tiedosta. Asensin sen. Ihan hyvin sivusto nyt toiminut eikä kukaan ole valittanut hitaudesta.

Googlen uusin maksullinen Captcha toimiii varsin hyvin. Akismet-lisäosan poistin. Se ei anna riittävää roskapostinestoa.

Lisäys. Mutta eipä näemmeä Googlenkaan roskapostisuodatus ole täydellinen. Meni tarkastukseen viisi uudelleenohjausta epämääräisille sivuille. Yritti luoda linkit BBC-koodilla, mikä ei ole sivuillani tavalliselle käyttäjälle sallittua.

Ainoa pikku ongeln'ma on graafinen editori, joka toimii välillä väärin, jolloin tekstissä tulee esille <p>....</p>. Nimen omaisesti P-tägi oikkuilee sekä herkästi myös taulukointi, harvemmin jokin muu.

P-tägejä joutuu aina silloin tällöin poistamaan. Taulkoita täytyy tehdä varmuuden vuoksi vällillä tavallisilla sivuilla, jotta saa toimivan takaisin, jos kommenteissa rikkuu.

Osaisitko selittää sivulla käsittelemääni statistiikkaeroja WordPressin statistiikkalisäosat

Huomasin tuon GTMetrix.com nopeustesterillä, Waterfall-näkymässä saa tietoja palvelimen versioista ym. Tuo GTMetrix on kätevä muutenkin kun sillä näkee visuaalisesti missä järjestyksessä eri elementit latautuvat. Tässä on muutama LiteSpeed Cachen asetus jota itse olen kokeillut myös omalla sivustollani: LiteSpeed-palvelin nopeuttaa WordPress-sivustoja: asennusohjeet

Voit myös cachen kytkeä pois päältä tietyiltä sivuilta ja cachettaa vain staattiset/vähemmän vaihtuvat sisällöt. Itselläni tosin se flushaa cachen aina kun julkaisen uuden artikkelin tai teen muutoksen sivuun. Foorumi saattaa vaatia ehkä jotain LiteSpeed Cache asetussäätöjä!

Minulla oli joskus samanlainen ongelma <p> tagien kanssa jotka tuli automaattisesti paikkoihin, joihin en halunnut. Silloin sain ratkaistua ongelman käyttämällä tätä editoria joka ikäänkuin tarjosi puhtaampana koodin eikä yrittänyt koodata kappalejakoja <p> tagein, testaa jos on apuja: Advanced Editor Tools (previously TinyMCE Advanced)
 
TinyMCE on käytössä. Backend-käytössä ei ole ogelmia, mutta foorumilla välillä toimii virheellisesti.

Kokeilin vielä sitä Cachea.
 
Viimeksi muokattu:
Yksi hyvä puoli omissa rakenteissa on ainakin se, että systeemin saa toimimaan käyttötarkoitustaan ajatellen mahdollisimman näppärästi.

Siihen saa lisättyä yhtä sun toista, viimeksi lisäsin OpenAI ChatGPT:n kommentointilomakkeen ja kuvienlähetystoiminnan jälkeen.

Ei AI Googlea korvaa, mutta on siitä joskus apua. Tosin jos kysyy väärin, voi tulla väärä vastauskin
IMG_20230421_091804.jpg


Oikea vastaus olisi ollut "Ilse", mutta kun kysyin väärällä kirjaimella, se harhautui. Vähän aikaa hämäsi botin väärä hyväsyntä, mutta tarkistin Googlella.
 
Valikko toimi joskus vähän paremmin.

Päävalikkoon jäi pikkuisen ärsyttävä piirteitä.

  1. Jos avaa apuvalikon auki, se jää näytölle vaikka raksista sulkee valikon; kun klikkaa sisältöä, apuvalikot sulkeutuvat
  2. Tausta jää harmaaksi kunnes klikkaa sisältöä
Idea valikossa on se, että kun selaat valikkoa taustalla oleva sivu lukkiutuu, ettei skrollaus liikuttaisi sisältöä. Kun klikkaa sisältöä, lukitus poistuu. Lukitus/vapautus ei harmautta kaipaa se on vain siksi, että korostetaan, että tarkastellaan valikkoa. Ehkä se harmaus olisi syytä poistaa?

Ongelmat liittyvät seuraavaan skriptiin:

$(‘.open-mobile-menu’).click(function() {
// $(‘.open-mobile-menu’).addClass(‘open-mobile-menu-shut’);
if(!$(‘.header-layout-fixed’).hasClass(‘set-hidden’))
$(‘.header-layout-fixed’).addClass(‘set-hidden’);
});
$(‘.nav-is-visible’).click(function() {
var x = document.getElementById(“tabA”);
x.style.display = “none”;
var y = document.getElementById(“tabC”);
y.style.display = “none”;
if($(‘.header-layout-fixed’).hasClass(‘set-hidden’))
$(‘.header-layout-fixed’).removeClass(‘set-hidden’);
});
Valikkopainiketta, jolla on luokka “open-mobile-menu” saa lukituksen ja se lisää luokan “nav-is-visible”, mutta lisätyllä luokalla ei voi tehdä mitään. Kokeilin samaa toisella lisätyllä luokalla, mutta se ei myöskään tehnyt mitään.
 
Ongelmat liittyvät seuraavaan skriptiin:

Vaikea debugata sun puolesta, mutta pseudo-mutulla skriptin pitäisi näyttää enemmänkin tältä:
JavaScript:
$(".open-mobile-menu").on("click", function () {
  $(".header-layout-fixed").toggleClass("set-hidden");
});

$(".nav-is-visible").on("click", function () {
  $("tabA").css("display", "none");
  $("tabC").css("display", "none");
  $(".header-layout-fixed").toggleClass("set-hidden");
});
 
Noista puuttui #

Tilanne ei muuttunut. Elementti, jolle JS:llä luotu luokka "nav-is-visible", ei saa toimivaa komentoa. Vain ylempi funktio toimii.

Jos kerran klikkaa, on siinä tilanteessa luokka "open-mobile-menu". Ymmärtäisin, että luokka "nav-is-visible" olisi poistuessa käytettävissä johonkin tarkoitukseen ennen kuin se poistuu. En ymmärrä, miksei sille ei saa mitään toimintoa. Vaikuttaako, että is-nav-visible on luotu toggle käyttäem?

Kokeilin "open-mobile-menu-stop" lisäluokkaa, mutta sekään ei tuntunut toimivan. Jos "nav-is-visible" on toggle-funktiolla, saako siihen lisätoimintoja, jos koodaisin uudestaa lisäosan JavaSript-tiedoston open-mobile-menu ja is -nav-visible osalta?

Entä jos toggle sijaan laittas click ja addClass ja removeClass ja sitten määrittelee lähes kaikki näillä funktioilla? Niin ainakin luulisi saavan kaiken toiminaan halutusti.

Luokka open-mobile-menu loisi luokan nav-is-visible sitten ehdolla
if($(‘.open-mobile-menu’).hasClass(‘nav-is-visible’)) pois. Varmistetaan if-lausella, ette mikään ei mene väärin. Vosiko alla oleva toimia alkuperäisen toggle-toiminnon sijaan?

Koodi:
if(!$(‘.open-mobile-menu).hasClass(‘nav-is-visible’)){
   $(‘.open-mobile-menu’).click(function() {
   if(!$(‘.header-layout-fixed’).hasClass(‘set-hidden’))
      $(‘.header-layout-fixed’).addClass(‘set-hidden’);
   $(‘.open-mobile-menu’).addClass(‘nav-is-visible’);
});
}

if($(‘.open-mobile-menu).hasClass(‘nav-is-visible’)){
  $(‘.nav-is-visible’).click(function() {
     $("tabA").css("display", "none");
     $("tabC").css("display", "none");
     if($(‘.header-layout-fixed’).hasClass(‘set-hidden’))
        $(‘.header-layout-fixed’).removeClass(‘set-hidden’);
     $(‘.open-mobile-menu’).removeClass(‘nav-is-visible’);
});
}
 
Viimeksi muokattu:
  1. Jos avaa apuvalikon auki, se jää näytölle vaikka raksista sulkee valikon; kun klikkaa sisältöä, apuvalikot sulkeutuvat
- apuvalikot "sulkeutuvat", koska linkkiä klikkaamalla sivu latautuu alusta asti uudelleen. Ei sen ihmeempää.
- en jaksa purkkaa parempaa tarjota purkkaan, mut katoppa semmonen ku "trigger": .trigger() | jQuery API Documentation
-> etsi päävalikon sulkemis-nappia painaessa avonaiset alivalikot ko. sulkemisnapin funktiossa ja triggeröi niiden kohdalla "nuoli ylös"-napin painallus.
 
Luin tuota. Ehkä sekään ei ratkaiss ongelmaa.
Ongelmahan on se, että $(‘.nav-is-visible’).click(function() {... ei tee mitään ja samaa luokkaa pitäisi trigget avulla käsitellä.
 
Luin tuota. Ehkä sekään ei ratkaiss ongelmaa.
Ongelmahan on se, että $(‘.nav-is-visible’).click(function() {... ei tee mitään ja samaa luokkaa pitäisi trigget avulla käsitellä.
Sulla ilmestyy " nav-toggle-dropdown " avatulle alivalikolle, joka sun pitää alivalikolta vaa poistaa sulkeaksesi alivalikon. Eli removeclass noille tonne #nav-toggle klikkauksen yhteyteen, kun päävalikkoa suljetaan.
1684477521320.png


e: tollaisen pykäilin chromen konsolissa:
Koodi:
$("#nav-toggle").click(function(){
    $(".nav-menu .menu-item").each(function() {
        $(this).removeClass("nav-toggle-dropdown");
     });
});
Sulkee siis kaikki alivalikot, kun suljetaan tai avataan päämenu. Toki tossa voi if-ehtoa käyttää, että vain suljettaessa, mut se ja sama.
 
Viimeksi muokattu:
Alivalikot ei ole ongelma. Ne kyllä ovat aina oikein sulkeutuneet. Ongelma on luomani lisävalikot, Pikatoiminnot (#tabA) ja Aiheet (#tabC), jotka eivät sulkeudu päävalikon sulkemisen yhteydessä. Yritin luokalla is-nav-visible pakottaa niiden sulkemisen. Ne pitäisi saada sulkeutumasn valikon sulkemissn yhteydessä, mutta ei avaamisen. Kaikki sulkemiseen liittyvät asiat pitäsi saada koottua yhden funktion alaisuuteen.

themr.js on vain

jQuery('#nav-toggle').toggleClass('nav-is-visible')

Kokeilin poistaa tuon käytöstä ja laittaa tilalle komm. 1095 olevan systeemin. Ei toiminut, sillä "nav-is-visile" ei edelleenkään piilota apuvalikoita.
 
Viimeksi muokattu:
Alivalikot ei ole ongelma. Ne kyllä ovat aina oikein sulkeutuneet. Ongelma on luomani lisävalikot, Pikatoiminnot (#tabA) ja Aiheet (#tabC), jotka eivät sulkeudu päävalikon sulkemisen yhteydessä. Yritin luokalla is-nav-visible pakottaa niiden sulkemisen. Ne pitäisi saada sulkeutumasn valikon sulkemissn yhteydessä, mutta ei avaamisen. Kaikki sulkemiseen liittyvät asiat pitäsi saada koottua yhden funktion alaisuuteen.

themr.js on vain

jQuery('#nav-toggle').toggleClass('nav-is-visible')

Jos poistaisi ja yrittäisi luoda oman systeemin.
Aa, joo. Nyt ymmärsin. Eli tabeista oli kyse.. hetken katsoin ja oletpaha vaa ihme härvelin rakentanut. Sulla on jostain syystä noi muiden tabien sisällöt toisaalla omassa divissään kuin "päävalikon" sisältö, vaikka ovat samaa navigaatiota. Jokainen tabi vieläpä tyyliltää erinäköinen?

Yksinkertaisesti; sulla on tossa kolme listaa, joita vuorollaan näytetään tabi-linkkejä painamalla. Semanttisesti siis kuuluvat kaikki site-navigationin alle ja jakavat saman tyylin. Turhaan tommosten tab-AC divien kans kikkailet. Sit ku ne on samaa kokonaisuutta, nii voit togglettaa koko navia, välittämättä mikä tabi navin sisällä on aktiivisena.
 
Viimeksi muokattu:
On joo. Ne on erillään siksi, että alkuperäiseen koodiin ei tarvitse koskea vaan lisäykseni saa mukaan erillispaloina, eräänlaisina "raameina". Jos ne pyrkisi laittamaan faktisesti samaan kokonaisuuteen, joutuisi ydinkoodia muuttamaan turhan paljon. Riittää, että kaikki näyttää ikään kuin olisi samaa kokonaisuutta.
Tabit on eri tyyliä kun on eri käyttötarkoitus.

Mutta voishan sitä yrittää muuttaa header.php niin, että koko höskä olisi yhtä kokonaisuutta. Eli functions.php kaikkI mahdollinen valikkoon liittyvä tulisi header.php yhteyteen ja koko höskää hallitsisi yhdellä komennolla nav-is-visible. Se kyllä poistaisi sen, että lisätabit jöisi näkyviin.

Ongelmaksi saattaisi muodostua ns. shortcode hyödyntävät aihevalikot. No jos tekee kaikesta varmuuskopiot, jos jokin ei toimi, voi palauttaa toimivan version.

Pikavalinnoissa minulla on neljä omaa toimintoa. Pikavalinnat on lähinnä omaan käyttöön, mutta on niissä yleisiäkin toimintoja. Kun koodaan sen itse, siitä saa just sellaisen kuin haluaa. Riviväli on matalampi kuin päävalikossa, jotta toimintoja saa mahtumaan enemmän ilman skrollauksen tarvetta.Samasta syystä toimintoja on osittain rinnakkain.

Aiheet on itselle tärkeä, sillä usein tarvitsen tietoa aiemmin käsitellyistä kohdista, jotka saan valikosta näppärästi uuteen välilehteen. Voihan niitä muutkin hyödyntää, mutta jos itselle on siitä apua, sekin riittää. Muut käyttäkööt footer-osaa, jos eivät Aiheet-valikon ideaa hiffaa.

Foorumi on käyttötarkoitukseensa suunniteltu mahdollisimman näppäräksi. Näppäryyden vuoksi tekoälyn yläpuolella on "linkkipatteristo". Tekoälyltäkin saa välillä apua, mutta välillä vastaukset ovat aivan vääriä. Väärien vastausten määrä on yllättynyt. Toisaalta hyvä kieli on positiivinen yllätys. Virheellistä kieltä on ollut yksi sana.

Toivoisi, että kaikki toimisi oikein. Mutta sitäkin tärkeämpää on se, että foorumi on optimaalinen sille annetussa käyttötarkoituuksessa. Pienet virheet siedän, jos en niitä saa korjattua. Tämänkertaiset virheet vain kiusaavat, kun ongelman syytä en ymmärrä.

Kun sisältöä klikkaa header-osan alapuolelta, kaikki sulkeutuu nätisti ja vaikko palaa alkutilanteeseen. Mutta en ymmärrä, miksei ihan samat toiminnot tapahdu is-nav-visible luokkaan liitettyinä komm. 1093 esitetyllä tavalla, ei, vaikka toggle on poistettu käytöstä.

$(‘.open-mobile-menu’).removeClass(‘nav-is-visible’);

näyttäisi toimivan, koska toggleClass on pois käytöstä.
sen sijaan seuraava ei tunnu toimivan.

if($(‘.header-layout-fixed’).hasClass(‘set-hidden’))
$(‘.header-layout-fixed’).removeClass(‘set-hidden’);
 
Viimeksi muokattu:
On joo. Ne on erillään siksi, että alkuperäiseen koodiin ei tarvitse koskea vaan lisäykseni saa mukaan erillispaloina, eräänlaisina "raameina". Jos ne pyrkisi laittamaan faktisesti samaan kokonaisuuteen, joutuisi ydinkoodia muuttamaan turhan paljon. Riittää, että kaikki näyttää ikään kuin olisi samaa kokonaisuutta.
Helpottaisi asioita. Eikait tossa paljoa refaktoroitavaa olis, mut mite vain.
No jos tekee kaikesta varmuuskopiot, jos jokin ei toimi, voi palauttaa toimivan version.
git tai vastaava versiohallinta käyttöön

Tabit on eri tyyliä kun on eri käyttötarkoitus.
Ei mitää järkeä, sekava.

Toivoisi, että kaikki toimisi oikein. Mutta sitäkin tärkeämpää on se, että foorumi on optimaalinen sille annetussa käyttötarkoituuksessa. Pienet virheet siedän, jos en niitä saa korjattua. Tämänkertaiset virheet vain kiusaavat, kun ongelman syytä en ymmärrä.
Itse en jaksa sen enempää paneutua, ku turhan sillisalaattia ja spagettia.
 

Statistiikka

Viestiketjuista
258 680
Viestejä
4 495 819
Jäsenet
74 271
Uusin jäsen
Esa.

Hinta.fi

Back
Ylös Bottom