Asetukset ja niissä evästeiden käyttö

Hei
Tein pari lisäevästettä.

Eka on se, että laitoin sivulle intro-tekstin ja siihen linkin " Älä näytä tätä tekstiä uudestaan".

Se toimi joskus, mutta nyt ei. Loin asetussivun ja siellä sain pois. Mutta tuollaisen vain kerran näkyviin tarkoitetun opastetekstin ei pitäisi olla niin vaikeasti poistettavissa.

Loin yhden ulkoasuasetuksen asetussivulle. Piti aina klikata kahdesti, että tuli voimaan.

Evästeen määritin PHP:llä ja GET-metodilla linkkiä käyttäen href="...?..."

Miksi evästeiden vaihto toimii niin huonosti? Voiko asialle tehdä mitään? Onko PHP:llä homma jotenkin erilaista jos homman tekisi JavaScriptillä?

103

443

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • Anonyymi

      Ilahduin tästä tiedosta

      • Anonyymi

        KETJUA EI KANNATA LUKEA.

        EI SISÄLLÄ MITÄÄN TIETOA, PELKÄÄ, "MINUSTA TUNTUU ETTÄ". TÄTÄ PASKAA EI TÄÄLLÄ TARVITA.


      • Anonyymi
        Anonyymi kirjoitti:

        KETJUA EI KANNATA LUKEA.

        EI SISÄLLÄ MITÄÄN TIETOA, PELKÄÄ, "MINUSTA TUNTUU ETTÄ". TÄTÄ PASKAA EI TÄÄLLÄ TARVITA.

        K12
        Ihminen ei arvosta tyhmyyttä, tyhmyyden läsnäolo saa hänet voimaan pahoin. Näillä ihmisillä, alla olevat kirjoitukset, saattavat nostaa verenpainetta.


    • Anonyymi

      Kiitos. Tee vielä muutama lisää.

    • Mielestäni tarkempi sivuston käyttöohjeistus (intro) on hyvä uusille, juuri foorumille rekisteröityneille. Silloin se on helppo käsitellä tietokannassa linkittämällä tieto käyttäjätunnukseen. Kun henkilö kieltää/sallii jotain niin kantaan kirjoitetaan henkilön tietoihin kuittaus siitä. Aina kirjautumisen aikana tunnusten tarkistuksen yhteydessä taulusta katsotaan onko syytä introilla vai ei.

      Satunnaisille ei tunnuksilla surffailijoille mielestäni riittäisi jo se että etusivulla asetetaan keksien sijaan php-session merkiksi sivulla käynnistä. Jos kyse täysin uudesta kulkijasta, niin jokin kevyt tervehdysteksti saattaa toimia ilman sen kummempia hyväksyn/en hyväksy -kikkailuja. Satunnaiselle matkaajalle tuskin kannattaa kaataa sivun toimintalogiikkaa heti saranoiden naristessa ensimmäistä kertaa. Jos sama kulkija palaa lähiaikoina uudelleen, niin tunnistat kulkijan tutkimalla onko session tallella ja sitten sivulle käyttäytymisohjeet sen tilanteen mukaan.

      Yksinkertaisimmillaan siis etusivulle laitetaan php-tageilla esim.

      if(session_status() == PHP_SESSION_NONE){
      session_start();
      }
      //tutkitaan onko vierailija jo tuttu
      if(isset($_SESSION["Visited"])){
      $showintro=0;
      } else{
      $_SESSION["Visited"] = "1";
      $showintro=1;
      }

      Tuolla kikalla saat muuttujaan $showintro arvon. Vaikkapa ykkösellä tervehditään uutta kulkijaa, nollalla ei.

      Kannattaa tietysti muistaa että selaimet saa nykyään siivoamaan käyntijäljet niin hyvin ettei mikään cookie/session toimi kaikissa tapauksissa. Juuri siksi tuo alussa mainittu tunnusten mukana tieto kannan tauluun on toiminnaltaan varmin ja se ärsyttää selailijoita myös vähemmän.

      Toinen tärkeä juttu keksien asettamisessa on tietysti GDPR. Linnatuomiolle tuskin joutuu vaikka sivun cookies-politiikasta ei hiiskuisi sanaakaan, mutta laajalti vakiintunut tapa viime vuosina on ollut informoida siitä sikäli kun keksejä selailijan koneelle käynnin aikana asettaa.

      Lisätietoja os. https://cookieinfoscript.com/

    • Sivulle voidaan tulla google haulla ihan satunnaiselle sivulle, joten koodin on koskettava kaikkia sivuja. Silloin oltava joka sivulla.

      Jos laittaa session joka sivun yhteyteen, luoko se joka sivulle session? Ja onko siitä haittaa, jos luo?

      Evästeissä voi käyttää taulukkomuuttujaa - kai sama pätee sessioihin?

      Session tiedot kai voi muttaa GET-parametreilla, jolloin voisi käyttää myös asetuksissa?

      Sen kaiketi voi laittaa koodipätkänä Code Snippet avulla (lisäosa, jolla saa koodipätkiä WordPressiin ydintietostoihin koskematta) eikä suoraan php-tiedostoihin? Evästetiedon laitoin suoraan header.php -tiedostoon.

      Mitä tulee intro-tekstiin, kun siirtyy toiselle sivulle, sitä ei pitäisi enää näkyä. Ajattelin, että eväste toimisi näin. Olisi sama kaikille käyttäjille. Minulla on aika harva kirjautunu, joten ei ole oikein mielekästä laatia tietokantasovellutusta. Tietokantaan myös pitäisi manuaalisesti lisätä kenttä tätä tarkoitusta varten. Helppoa kyllä.

      Evästeen muutos vain tökki pahasti.

      Eikö sinsänsä ole ihan sama, lähetetäänkö GET-metodin tieto linkillä vai lomakkeella. Ei kai se tavasta ole kiinni?

      Intro-teksti voisi olla myös tiedote, että on evästeitä. Niitä WordPressa aina laittaa tästä on kyllä tiedote sivustolla. WordPress-sivustoilla ei yleensä sitä nosteta esille ikkunaan.

      • Yksittäisiin kysymyksiin on mahdotonta ottaa kantaa perehtymättä ympäristöön (code) missä sitä käytetään. Kuten jo edellä todettua, evästeet ja sessionit on kyllä näppäriä, mutta kun elämme aikaa jolloin selaimet joko automaattisesti tai käyttäjänsä aktiivisista toimista johtuen poistavat näitä omia "hiirijalanjälkiään" jopa muutamissa minuuteissa niiden luomisesta tai viimeistään selaimen sulkemisen yhteydessä, niin esittämäsi tapa johtaa helposti siihen, että samoille kävijöille hypähtelee introja silmille ja Sulo Surffari kokee ne helposti ärsyyntymisenä.

        Kannustan lisäkupin ääressä lukemaan tarkalla silmällä cookie ja session -opasteet esimerkiksi sivuilta

        https://www.w3schools.com/php/php_sessions.asp
        https://www.w3schools.com/php/php_cookies.asp

        ja miettimään kannattaako hommaan ryhtyä.

        Yhteen kysymykseesi on sentäs helppo vastata: sessionit on domain-kohtaisia.
        Luotpa sen millä sivulla tahansa, niin sitä voi hyödyntää muiden sivujen koodissa.

        Mitä evästeiden muuttamiseen tulee, niin minulla on päähän pinttynyt ajatus siitä että evästeitä ei periaatteessa muuteta mitenkään. Eväste joko asetetaan tai se poistetaan. Toisin sanoen, jos jo luotua evästettä halutaan muuttaa, niin se olemassaoleva eväste ensin poistetaan ja sen jälkeen luodaan uusi. Eväste on kuin armeijassa asento. Parempi tehdä kokonaan uusi kuin yrittää korjata vanhaa :)


      • Anonyymi
        Faktantarkistus kirjoitti:

        Yksittäisiin kysymyksiin on mahdotonta ottaa kantaa perehtymättä ympäristöön (code) missä sitä käytetään. Kuten jo edellä todettua, evästeet ja sessionit on kyllä näppäriä, mutta kun elämme aikaa jolloin selaimet joko automaattisesti tai käyttäjänsä aktiivisista toimista johtuen poistavat näitä omia "hiirijalanjälkiään" jopa muutamissa minuuteissa niiden luomisesta tai viimeistään selaimen sulkemisen yhteydessä, niin esittämäsi tapa johtaa helposti siihen, että samoille kävijöille hypähtelee introja silmille ja Sulo Surffari kokee ne helposti ärsyyntymisenä.

        Kannustan lisäkupin ääressä lukemaan tarkalla silmällä cookie ja session -opasteet esimerkiksi sivuilta

        https://www.w3schools.com/php/php_sessions.asp
        https://www.w3schools.com/php/php_cookies.asp

        ja miettimään kannattaako hommaan ryhtyä.

        Yhteen kysymykseesi on sentäs helppo vastata: sessionit on domain-kohtaisia.
        Luotpa sen millä sivulla tahansa, niin sitä voi hyödyntää muiden sivujen koodissa.

        Mitä evästeiden muuttamiseen tulee, niin minulla on päähän pinttynyt ajatus siitä että evästeitä ei periaatteessa muuteta mitenkään. Eväste joko asetetaan tai se poistetaan. Toisin sanoen, jos jo luotua evästettä halutaan muuttaa, niin se olemassaoleva eväste ensin poistetaan ja sen jälkeen luodaan uusi. Eväste on kuin armeijassa asento. Parempi tehdä kokonaan uusi kuin yrittää korjata vanhaa :)

        Näin on kyllä ohjelmoinnissa että on parempi tehdä alusta alkaen täysin uusi kuin alkaa korjaamaan jonkun toisen tekemää dokumentoimatonta koodia.

        Leviää kuin Jokisen eväät kaikki evästeetkin sitten jos niitä tunkee kaikkialle.


      • Anonyymi
        Faktantarkistus kirjoitti:

        Yksittäisiin kysymyksiin on mahdotonta ottaa kantaa perehtymättä ympäristöön (code) missä sitä käytetään. Kuten jo edellä todettua, evästeet ja sessionit on kyllä näppäriä, mutta kun elämme aikaa jolloin selaimet joko automaattisesti tai käyttäjänsä aktiivisista toimista johtuen poistavat näitä omia "hiirijalanjälkiään" jopa muutamissa minuuteissa niiden luomisesta tai viimeistään selaimen sulkemisen yhteydessä, niin esittämäsi tapa johtaa helposti siihen, että samoille kävijöille hypähtelee introja silmille ja Sulo Surffari kokee ne helposti ärsyyntymisenä.

        Kannustan lisäkupin ääressä lukemaan tarkalla silmällä cookie ja session -opasteet esimerkiksi sivuilta

        https://www.w3schools.com/php/php_sessions.asp
        https://www.w3schools.com/php/php_cookies.asp

        ja miettimään kannattaako hommaan ryhtyä.

        Yhteen kysymykseesi on sentäs helppo vastata: sessionit on domain-kohtaisia.
        Luotpa sen millä sivulla tahansa, niin sitä voi hyödyntää muiden sivujen koodissa.

        Mitä evästeiden muuttamiseen tulee, niin minulla on päähän pinttynyt ajatus siitä että evästeitä ei periaatteessa muuteta mitenkään. Eväste joko asetetaan tai se poistetaan. Toisin sanoen, jos jo luotua evästettä halutaan muuttaa, niin se olemassaoleva eväste ensin poistetaan ja sen jälkeen luodaan uusi. Eväste on kuin armeijassa asento. Parempi tehdä kokonaan uusi kuin yrittää korjata vanhaa :)

        Ihan kun olis sama kaveri ja pythonni hanurissa.


    • Tapio-Huuhaa

      Evästeille ei ole varsinaisesti poistoa eikä päivitystä. Eräänlainen poisto on laittaa aikamäärä, joka on menneisyydessä. Luin että päivitys on vain sitä, että luo saman evästeen uudestaan. Kuten kerroin toimi jollakin lailla, mutta ongelma on se, että ei tullut heti voimaan. Intro-teksti ei useammallakaan kerralla hävinnyt.

      Mutta jos evästeitä automaattisesti poistetaan, asetuksia ei siten ole mielekästä antaa muiden käyttöön kuin kirjautuneiden käyttäjien. Nehän joutuisi joka kerta laittamaan uudestaan.

      Pitänee luoda tietokantahakufunktio. Arvot pitäisi kirjoittaa

      nayta_otain1=jokin-arvo, nayta_joptain2=...,...

      ja luoda tuosta array ja tallennettaessa purkaa array takaisin string-muuttujaksi.

      Vai onko muita ehdotuksia.

      • Tuosta juuri aiemmin oli juttua. Kun ravintolan ovella kurkitaan sisälle, niin ei silloin vielä parane isännän iskeä nivaskaa kouraan siitä miten meillä käyttäydytään ja mitkä on talon tavat. Vasta kun asiakas on istuutunut pöytään niin se sitoutuminenkin on ihan erilaista kuin satunnaisella ohikulkijalla.

        Älä ajattele asioita liian monimutkaisesti niin että tietokantafunktiot, arrayt ja stringit vain vilisee silmissä.

        Yksinkertaistetaan vähän ja leikitään että haluat sille pöytään istahtaneelle, korjaan, tunnuksillaan kirjautuneelle näyttää jotain speciaalia (ohjeet, ehdot,...) mitä hän ei ole vielä kieltänyt. niin sinulla on tietysti tietokannassa jokin taulu mistä tieto login -vaiheessa pullahtaa jonkin $specialoffer -muuttujan mukana sivun tietoon.

        Sen jälkeen tarvitsee vain laittaa sivulle lyhyesti vaikkapa

        if($specialoffer==1{
        include("ehdot.php");
        }

        Näin sivusi näyttää ehdot.php -sivun sisällön vain niille tarkoin valituille vierailijoille, joiden asiakastiedoissa niin on määritelty. Mainitulla sivulla voi olla valintanappi "Älä näytä uudestaan..." mitä klikkaamalla tietokannan taulua samalla päivitetään niin ettei samalle tyypille ensi kerralla enää samaa stooria syötetä. Näin kaikki on tyytyväisiä. Myös ne satunnaiset ohikulkijat jatkavat elämäänsä turhia ärsyyntymättä. Tämä tapa toimii vaikka selaimissa evästeet siivottaisiin vartin välein.


      • Faktantarkistus kirjoitti:

        Tuosta juuri aiemmin oli juttua. Kun ravintolan ovella kurkitaan sisälle, niin ei silloin vielä parane isännän iskeä nivaskaa kouraan siitä miten meillä käyttäydytään ja mitkä on talon tavat. Vasta kun asiakas on istuutunut pöytään niin se sitoutuminenkin on ihan erilaista kuin satunnaisella ohikulkijalla.

        Älä ajattele asioita liian monimutkaisesti niin että tietokantafunktiot, arrayt ja stringit vain vilisee silmissä.

        Yksinkertaistetaan vähän ja leikitään että haluat sille pöytään istahtaneelle, korjaan, tunnuksillaan kirjautuneelle näyttää jotain speciaalia (ohjeet, ehdot,...) mitä hän ei ole vielä kieltänyt. niin sinulla on tietysti tietokannassa jokin taulu mistä tieto login -vaiheessa pullahtaa jonkin $specialoffer -muuttujan mukana sivun tietoon.

        Sen jälkeen tarvitsee vain laittaa sivulle lyhyesti vaikkapa

        if($specialoffer==1{
        include("ehdot.php");
        }

        Näin sivusi näyttää ehdot.php -sivun sisällön vain niille tarkoin valituille vierailijoille, joiden asiakastiedoissa niin on määritelty. Mainitulla sivulla voi olla valintanappi "Älä näytä uudestaan..." mitä klikkaamalla tietokannan taulua samalla päivitetään niin ettei samalle tyypille ensi kerralla enää samaa stooria syötetä. Näin kaikki on tyytyväisiä. Myös ne satunnaiset ohikulkijat jatkavat elämäänsä turhia ärsyyntymättä. Tämä tapa toimii vaikka selaimissa evästeet siivottaisiin vartin välein.

        Intro-tekstiä eivät kirjautuneet mielestäni kaipaa, koska he ovat jo tutustuneetsivuston logiikkaan. Toki siinä voisi tiedottaa, että foorumin ominaisuuksia voi säätää.

        include-käyttö ei minulla oikein toimi. Lisäosa Code Snippet ei hyväksy sen käyttöä. Mutta funktioita toki voi laittaa eri tietueisiin, kun laittaa prioriteetit oikein. Lisäosan funktion olemassaolon tarkistamiseen ei voi luottaa. Tekee siinä kaiken tyyppisiä virheitä. Asiat pitää testata. Olen bugien takia kaatanut sivuston muutaman kerran.

        Intro-tekstin sijaan ajattelin muita säätöjä. Kännykälle voi laittaa todella hyödyllisiä oikopolkuja, mutta kaikki eivät niistä pidä. Näitä ajattelin:
        * poista/palauta sivun keskellä olevat linkit
        * poista/palauta sivun lopussa olevat ylös/alanuolet
        * määritä valikkopainikkeen paikka

        Mobiilissa valikkopainike on kiinteä oikeassa yläkulmassa. Siinä on kaikki, mitä sivustolla tarvitaan. Oikeassa yläkulmassa se ei häiritse, mutta jos selaa peukaloilla, se on kaukana peukaloista. Sen voisi haluttaessa laittaa peukaloetäisyydelle.


    • WordPressissä on sisäänrakennettu tietokantafunktio, joka hakee käyttäjätiedot. Lisäsin kentän user_layout_settings. Pitäisi löytää jostakin myös funktio, jolla tiedot saa muutettua. Toki funktiion voi itsekin rakentaa.

      GET-parametrilla saadut tiedot saa heti käyttöön. Samalla saatu array-muttuja pitäisi muuntaa string-muuttujaksi. Pitää etsiä googlella tarkoitukseen sopivat funktiot kun en muista niitä ulkoa.

      Tallennetut pitää tehdä se string><array -muunnos.

      Ei tietokantaan laitettavien asetuksien määrittäminen mitään rakettitiedettä ole.

    • Tällaista introtekstiä ajattelin:


      Hei, kun tulet sivuilleni, löydät kaikki sivun toiminnot helposti. Sivun yläosassa oikealla on valikkopainike, josta löytyy kaikki sivun valikot. Oletuksena esillä on PÄÄVALIKKO. Löydät sivun oikean yläosan valikoista kaiken, mitä tällä sivustolla tarvitset.

      Lisäksi onmahdollista ottaa käyttöön sivun keskellä olevat valikkojen avaajat muuttamalla asetuksia. Voit asetuksissa mullakin tavoin vaikuttaa sivujen ulkoasuun.

      Älä näytä tätä tekstiä uudestaan.

      Sulje ikkuna

      • Anonyymi

        Taasko takapää täynnä tavaraa, ja levyt täynnä läppi ornoo


    • Tietokannan päivitys epäonnistui:

      $currentUrl='https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
      if(($currentUrl=='https://www.sanaristikkofoorumi.net/test/asetukset/') && is_user_logged_in() && isset($GET)){
      $updateValue=$GET['intro'].','.$GET['sivupalkki'].','.$GET['paavalikon_sijainti'].','.$GET['nuolet'].',1,1';
      $current_user = wp_get_current_user();
      $userID=$current_user->ID;
      $username="käyttäjänimi";
      $password="salasana";
      $database="tietokanta";
      mysql_connect('xx.xx.x.xx',$username,$password);
      @mysql_select_db($database) or die( "Unable to select database");
      $query='UPDATE `wp_forum_users` SET `user_layout_settings`=`'.$updateValue.'` where `ID`='.$userID;
      mysql_query($query);
      mysql_close();

      • HUH - näyttääpä vaaralliselta! Itse asiassa ihmetyttää miksi sivuja suojeleva botti ei ole poistanut viestiä heti kättelyssä.

        Syntaksissa on silmämääräisesti katsoen niin paljon pielessä että edes XXXL koon rautakangella sitä ei saa kammettua toimimaan. Tietokantasi taulurakenteeseen ei voi sanoa mitään mutta ihan alkuun kannustan korvaamaan mysql -sanan mysqli -sanalla.

        Tämä palsta on muutenkin aivan avuton minkäänlaisen koodin esittelyyn. Se voi näyttää kirjoitettaessa ihan selkeältä mutta kun täällä muotoilut poistuu julkaisuvaiheessa niin koodin luettavuus kärsii pahasti.


      • Faktantarkistus kirjoitti:

        HUH - näyttääpä vaaralliselta! Itse asiassa ihmetyttää miksi sivuja suojeleva botti ei ole poistanut viestiä heti kättelyssä.

        Syntaksissa on silmämääräisesti katsoen niin paljon pielessä että edes XXXL koon rautakangella sitä ei saa kammettua toimimaan. Tietokantasi taulurakenteeseen ei voi sanoa mitään mutta ihan alkuun kannustan korvaamaan mysql -sanan mysqli -sanalla.

        Tämä palsta on muutenkin aivan avuton minkäänlaisen koodin esittelyyn. Se voi näyttää kirjoitettaessa ihan selkeältä mutta kun täällä muotoilut poistuu julkaisuvaiheessa niin koodin luettavuus kärsii pahasti.

        käyttäjätietojen muuttamiseen saattaa olla WordPressissä oma funktio. En mielestäni paljastanut mitää dramaattista, koska poistin yksilöivän tiedon. Tuo MySQL-tietokannan käsittely löytyy melkein identtisenä eräältä nettisivulta. Tuohon tapaan siinä oli neuvottu, mutta SQL-komento oli eri ja mysql_query($query); otettiin muuttujaksi muuhun tarkoitukseen. Koska minulla ei ole muuta tarkoitusta, otin pois muuttujan edestä.


      • Tapio-Huuhaa kirjoitti:

        käyttäjätietojen muuttamiseen saattaa olla WordPressissä oma funktio. En mielestäni paljastanut mitää dramaattista, koska poistin yksilöivän tiedon. Tuo MySQL-tietokannan käsittely löytyy melkein identtisenä eräältä nettisivulta. Tuohon tapaan siinä oli neuvottu, mutta SQL-komento oli eri ja mysql_query($query); otettiin muuttujaksi muuhun tarkoitukseen. Koska minulla ei ole muuta tarkoitusta, otin pois muuttujan edestä.

        Mainitsit että esittelemäsi koodin ajo epäonnistui. Tulppa voi tuon pituisessa koodissa olla niin monessa kohtaa että se ratkeaa vain kun paloittelet sen ja testaat yksi kerrallaan että yhteys kantaan toimii, manuaalinen SQL-lause toimii, muuttujien rakentamisessa käyttämäsi GET-lauseet saa jotain arvoja...

        Sivustostasi päätellen olet siis sanaristikko-expertti eli ratkot ja analysoit. Kokoan sinulle "kostoksi" tähän aiheeseen liittyvän pähkinän pureskeltavaksi, jotta saat nettisivujen rakentamisen oheen muuta ajateltavaa ja sopivasti etäisyyttä niihin takkuileviin tietokantafunktioihin :)


      • Faktantarkistus kirjoitti:

        Mainitsit että esittelemäsi koodin ajo epäonnistui. Tulppa voi tuon pituisessa koodissa olla niin monessa kohtaa että se ratkeaa vain kun paloittelet sen ja testaat yksi kerrallaan että yhteys kantaan toimii, manuaalinen SQL-lause toimii, muuttujien rakentamisessa käyttämäsi GET-lauseet saa jotain arvoja...

        Sivustostasi päätellen olet siis sanaristikko-expertti eli ratkot ja analysoit. Kokoan sinulle "kostoksi" tähän aiheeseen liittyvän pähkinän pureskeltavaksi, jotta saat nettisivujen rakentamisen oheen muuta ajateltavaa ja sopivasti etäisyyttä niihin takkuileviin tietokantafunktioihin :)

        Itse asiassa sain koodin kuntoon käyttämällä WordPressin omian funktioita. Sitä ennen piti kuitenkin lisätä yksi rivin WordPressin erääseen tietokantatauluun. Lisäys on sen luonteinen, että niitä tekevät ns. lisäosat eli plugiti. Kun en laadi plugineja, lisäsin rivin manuaalisesti.

        Selitän tässä säikeessä edempänä yhden moka, joka liittyy takkuilevaan muistiin!


    • Sain muualta hieman opastusta. WordPressille on funktio

      update_user_meta()

      Se ei päivitä users-taulua vaan sen aputaulua. Minulta puuttuu siihen liittyvästä tietokanttaulusa yksi rivi. Niitä lisäillään yleensä lisäohjelmilla. Koska en tee lisäohjelmaa, sisäsin rivin suoraan.

      Yritän siis tehdä homman uusiksi tuota funktiota käyttäen.

    • get_user_meta() haetaan arvot.

      Yritän siis tehdä homman uusiksi noita kahta funktiota käyttäen.

    • Sain asetukset toimimaan. Oli hassu ongelma. En muistanut, että get-parametri haetaan $_GET-muuttujalle. Olin laittanut $GET. Ihmettelin pitkään, miksi print_r($GET); näyttää tyhjää. Piti googlella selvittää, missä on vika.

      Puolustukseksi voin sanoa, että viimeksi kuin loin get-parametreilla toiminnallisuutta, aikaa on n. 15 vuotta. En kertakaikkiaan muistanut tuota asiaa.

    • Tuli sitten leikittyä asetuksilla. Haluasin www-sivujen muistuttavan sovellutusten käyttöliittymää ennen kaikkea kännykkä pystysuunnassa.

      Ihan vaan kokeiluna versio, jossa joka reunassa on jotain. Ylhäällä päävalikko, josta pääsee muihin. Keskellä toimintovalikko ja -aihevalikko, joista pääsee muihin. Alhaalla muutama kommenttien ja aiheiden luomiseen liittyvä pikavalinta (ei aloitteleville, koska toimintojen merkitys tulee opetella).
      https://www.sanaristikkofoorumi.net/test/wp-content/uploads/IMG_20190925_221717.jpg

    • Oli vähän harmi, että ei järkevällä tavalla saanut evästeillä vastaavaa ja vaikka saisikin, se ei olisi kovin järkevää. Tosin ilman intro-tekstiä sen voisi antaa evästeilläkin - pitäkööt sitten evästeensä tai ei. Mutta evästeet eivät oikein tahtoneet lähteä toimimaan välittömästi kuten tietokantaan rakentamani systeemi.

      Ihan kiva olisi saada palautetta asetuksista.

      • Hyvä siitä tulee kun et puske koko aikaa vaan otat välillä etäisyyttä Code Snippeteihin. Muutaman kiperän ristisanan jälkeen pluginien koodaaminen sujuu entistäkin lennokkaammin.
        Lupasin tuossa aiemmin järjestää forumin rakentajalle väliin muuta ajateltavaa:

        https://tuuletus.net/hs/ristikot

        Lataa kaikki 64 tehtävää, mutta muista että pakko ei ole tehdä niitä kaikkia samoilla silmillä :)


      • Faktantarkistus kirjoitti:

        Hyvä siitä tulee kun et puske koko aikaa vaan otat välillä etäisyyttä Code Snippeteihin. Muutaman kiperän ristisanan jälkeen pluginien koodaaminen sujuu entistäkin lennokkaammin.
        Lupasin tuossa aiemmin järjestää forumin rakentajalle väliin muuta ajateltavaa:

        https://tuuletus.net/hs/ristikot

        Lataa kaikki 64 tehtävää, mutta muista että pakko ei ole tehdä niitä kaikkia samoilla silmillä :)

        Onko noi aina ilmaisia? Minulla on väliaikainen tunnus, joten näen, vaikka eivät olisikaan.


      • Tapio-Huuhaa kirjoitti:

        Onko noi aina ilmaisia? Minulla on väliaikainen tunnus, joten näen, vaikka eivät olisikaan.

        Ei varmaankaan ole ilmaisia eikä minulla ole aikomusta ylläpitää tuoreita ristikkoja koko ajan sitä mukaa kun ne lehdissä julkaistaan. Kokosin tuon lähinnä kertaluontoisena pakettina,


      • Faktantarkistus kirjoitti:

        Ei varmaankaan ole ilmaisia eikä minulla ole aikomusta ylläpitää tuoreita ristikkoja koko ajan sitä mukaa kun ne lehdissä julkaistaan. Kokosin tuon lähinnä kertaluontoisena pakettina,

        ok. Asia selvä. Minä keräsin varastoa kun tilasin SK 3 kk. IS Extra 1 kk. Edellisestä on paljon jäljellä. Jälkimmäisestä ei juurikaan. Ratkomattomat IS kovikset, joita saan ilman uutta tilausta ovat Sanariksen sivuston ratkomattoma ristikon analyys -osaston ristikot.


    • Jos aloitan ristikon, siitä tulee helposti pakkomielle - pakko saada ratkottua loppuun asti. Onneksi nykyisin kärsivällisyys riittää siirtää keskeneräisen useille päiville. Niin tein Mirja Pihlajamäen kenties kaikkien aikojen haastavimman ristikon kanssa.

      Code Snippet ei enää asetusten suhteen tuota ongelmia. Mutta kun asetuksia nyt on melko paljon, jokaiselle asetukselle sopivan CSS:n laatiminen on työlästä. Sivuvalikot hankalin tapaus laite vaakasuuntaan laitettaessa. Vielä pahasti kesken.

      CSS on osittain ehdollisissa lyhyissä pätkissä:

      elseif($CSS===6){
      $CSS='<style>
      @media screen and (max-width:782px){
      #top-opener #sidebar-top a,#top-opener #sidebar-top a::before{background-color:transparent!important}
      #sidebar-top a{position:absolute;top:0;right:0;border-radius:0 0 0 5px;}
      #sidebar-top a::before{}}
      </style>';
      }elseif($CSS===7)

      Muuten ei olisi voinutkaan toimia järkevästi sekoamatta - vaihtoehtona pitkä lista luokkia jokaiseen kohtaan - niiden kanssa sekoaa.

    • Laitan ton tuuletus-linkin linkkilistaani. Hesarin ristikoita en tykkää ratkoa kun niissä on huonolaatuinen kuvitus. Jotakuta muuta se ei niin häiritse.

      Minulla on vielä aika paljon ratkomattomia SK:n ristikoita ja vähän yli 20 kpl IS:n Kovis-ristikoita.

      • OK. Odotin näkeväni pian analyysin siitä miten valtakunnan ykköspäivälehti on viimeisen vuoden aikana kehittynyt 64 julkaisemansa sanaristikon (52 vko 12 kk) suhteen, mutta aina ei näemmä saa mitä toivoo. Poimi nyt kuitenkin se zip-pakattu säkki varastoosi jos vaikka talven hämärinä hetkinä mielesi muuttuu ja ristikkojen sanomalehtimäinen ulkoasu lakkaa häiritsemästä :)


    • HD/iPad vaakasuuntainen näyttö on melkein kunnossa. Jos sivuvalikot ovat päällä, en jostakin syystä saa määriteltyä valikoita saman levyisiksi enkä yhtä etäällä vasemmasta ja oikeasta reunasta.

    • Näytöllä on outo "1" jos tarkkaan katsoo. En ymmärrä, mistä se tulee. Vivaldin tarkista-toiminnolla sai katsottua, että se on heti body-elementin alussa.
      Kävin läpi kaikki Code Snippet -tiedostoni arvellen, että olisi unohtunut debug-data. Yhtään debug-koodia en huomannut.

    • Hauska välillä poiketa aiheesta, mutta mietin vielä alkuperäistä aihetta.
      Minulla on yksi asetusten käsittelyfunktio, jonka avulla ulkoasu määrittyy.
      Siinä voisi huomioida myös evästeet. Ne tosin toimisivat epäluotettavammin.

      function getLayoutSettings($userLayoutSettings_ar){
      if(is_user_logged_in()){
      $current_user = wp_get_current_user();
      $userLayoutSettings=$current_user->user_layout_settings;
      if(!$userLayoutSettings){$userLayoutSettings='2,1,3,2,1';}
      }
      else
      {$userLayoutSettings='1,1,3,2,1';}
      $userLayoutSettings_ar = explode(',', $userLayoutSettings);
      return $userLayoutSettings_ar;
      }
      voisi muuttaa
      function getLayoutSettings($userLayoutSettings_ar){
      if(is_user_logged_in()){
      $current_user = wp_get_current_user();
      $userLayoutSettings=$current_user->user_layout_settings;
      if(!$userLayoutSettings){$userLayoutSettings='2,1,3,2,1';}
      }
      elseif ($Cookie...{...}
      else
      {$userLayoutSettings='1,1,3,2,1';}
      $userLayoutSettings_ar = explode(',', $userLayoutSettings);
      return $userLayoutSettings_ar;
      }

    • Itse asiassa evästeet epäonnistuivat siksi, että en muistanut käytää alaviivaa muuttujien kanssa. Kun laitoin oikein, evästeetkin toimivat. Testasin print_r:llä.

      Muuten samat määritykset mutta intro-tekstiä en laittanut evästeiden varassa oleville, koska ne voi poistaa vaikka kesken istunnon.

    • Tämän säikeen aihe tuli käsiteltyä. Tuli aika lailla töitä laatia kaksi systeemiä, mutta samallapa tuli opittua monta asiaa. Ja tulipa perusmokani korjattua.

    • Se "1" arvoitus ratkesi. Erään muuttujan arvo on 1, jos sitä ei if-ehdolla muuta. Piti määrittää arvoksi '';

    • Tein testisivustolle sittenkin intro-tekstin. Mutta muutin sen lähinnä evästetiedotteeksi, jossa mainitsen mobiiliasetukset.

      Sivusto käyttää evästeitä, niihin kuuluu mobiiliasetukset. OK, ÄLÄ NÄYTÄ TÄTÄ TEKSTIÄ UUDESTAAN.

      Mobiiliasetukset on linkki. Sulje ikkuna vain sulkee ikkunan.

      Kiitos erittäin paljon tässä säikeessä nimim. Faktantarkistus kivasta keskustelusta.

    • Olisin kiitollinen testauksesta ja kommenteista. Ainakaan valinnanmahdollisuuksista ei ole pulaa. Valikoita on kolme erilaista. Niille on maks. kolme avaajaa, mutta voi selvitä yhdelläkin. Kaksikin voi valita.

    • Asetussivu on nyt dynaaminen eli se muistaa annetut asetukset ja esillä on ne asetukset, jotka on viimeksi määritelty. Sanomattakin on selvää, että piti testailla, että menee oikein. Erinäisiä virheasetuksia oli matkassa.

    • Ongelmana evästeissä on nyt se, että eivät mene heti käyttöön vaan pitää tehdä sama monta kertaa peräkkäin.

      Että voi vaihtaa asetukset, header-php:n alussa on seuraavankaltaisia rivejä:

      if($_GET["intro"]){setcookie("intro", $_GET["intro"], time() 8400000000, "/", "sanaristikkofoorumi.net", 1);}
      elseif(!isset($_COOKIE["intro"])) {setcookie("intro", "2", time() 84000000000, "/", "sanaristikkofoorumi.net", 1);}

      • Keksien kanssa pitää aina huomioida että selaimissa voi kieltää kokonaan niiden asettamisen. Tuossa pätkässä esimerkkikoodia ei nähdäkseni tutkita sitä hyväksyykö selaaja cookies -asetannat. Toisekseen tuossa koodissa asetat keksille elinajaksi satoja vuosia, mikä lienee lääketieteen kehittymisestä huolimatta hieman liioittelua :)

        Cookies on todellakin tarkoitettu pitämään muistissa jotain tarpeellista tietoa tulevia istuntoja varten. Jos haluat päivittää juuri kirjoittamasi uuden cookien asetukset avoimelle sivulle heti, niin sivu täytyy ladata uudelleen.

        Loogisesti siis sivulle tultaessa tutkit headerissä ensin onko sivustosi keksi jo olemassa. Jos ei ole niin yrität asettaa sen. Sen jälkeen tarkistat onko keksi nyt olemassa

        if(count($_COOKIE) > 0){
        //your code
        }

        Mikäli yhtään keksiä ei edelleenkään löydy, niin unohda koko cookies-juttu koska selaaja ei niitä hyväksy.

        Mikäli juuri luomasi keksi nyt löytyy niin saadaksesi asetuksen heti voimaan päivität avoimen sivun

        if(count($_COOKIE) > 0){
        $myUrl = "https://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
        header("Location: ".$myUrl);
        }

        *** Ole varovainen! Jos laitat edellä mainitun sivun päivityksen headerissäsi väärään if -lohkoon, niin saat aikaan ikuisen silmukan mikä kaataa koko sivustosi. ***

        Keksien kanssa eläminen ei todellakaan ole yksinkertaista maailmassa missä selaimissa voi joko sallia tai kieltää ne. Halutessasi voit tietysti yksinkertaistaa asioita ja rakentaa sivusi niin, että jos selaaja ei hyväksy keksejä, niin ohjaat hänet tylysti ulos omalta saitiltasi vaikkapa googlen etusivulle

        if(count($_COOKIE) == 0){
        header("Location: https://google.fi");
        exit();
        }


      • Faktantarkistus kirjoitti:

        Keksien kanssa pitää aina huomioida että selaimissa voi kieltää kokonaan niiden asettamisen. Tuossa pätkässä esimerkkikoodia ei nähdäkseni tutkita sitä hyväksyykö selaaja cookies -asetannat. Toisekseen tuossa koodissa asetat keksille elinajaksi satoja vuosia, mikä lienee lääketieteen kehittymisestä huolimatta hieman liioittelua :)

        Cookies on todellakin tarkoitettu pitämään muistissa jotain tarpeellista tietoa tulevia istuntoja varten. Jos haluat päivittää juuri kirjoittamasi uuden cookien asetukset avoimelle sivulle heti, niin sivu täytyy ladata uudelleen.

        Loogisesti siis sivulle tultaessa tutkit headerissä ensin onko sivustosi keksi jo olemassa. Jos ei ole niin yrität asettaa sen. Sen jälkeen tarkistat onko keksi nyt olemassa

        if(count($_COOKIE) > 0){
        //your code
        }

        Mikäli yhtään keksiä ei edelleenkään löydy, niin unohda koko cookies-juttu koska selaaja ei niitä hyväksy.

        Mikäli juuri luomasi keksi nyt löytyy niin saadaksesi asetuksen heti voimaan päivität avoimen sivun

        if(count($_COOKIE) > 0){
        $myUrl = "https://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
        header("Location: ".$myUrl);
        }

        *** Ole varovainen! Jos laitat edellä mainitun sivun päivityksen headerissäsi väärään if -lohkoon, niin saat aikaan ikuisen silmukan mikä kaataa koko sivustosi. ***

        Keksien kanssa eläminen ei todellakaan ole yksinkertaista maailmassa missä selaimissa voi joko sallia tai kieltää ne. Halutessasi voit tietysti yksinkertaistaa asioita ja rakentaa sivusi niin, että jos selaaja ei hyväksy keksejä, niin ohjaat hänet tylysti ulos omalta saitiltasi vaikkapa googlen etusivulle

        if(count($_COOKIE) == 0){
        header("Location: https://google.fi");
        exit();
        }

        Tämä kommentti jäi huomioimatta kun tuli kirjoitettua loppuun (tämä on sisäkkäisten kommenttien perusongelma).

        Tavallaan tutkin, onko evästeeni olemassa tällä koodilla:

        elseif(!isset($_COOKIE["intro"])) setcookie...
        ...

        Eikö järkevintä ole kysyä heti alkuun, hyväksyykö käyttäjä evästeet ts. onko ennestään evästeitä

        if (!(count($_COOKIE) == 0)){
        //your code
        }
        tai vain

        if($_COOKIE){}

        jos evästeitä ei ole, $_COOKIE on tyhjä ja saa arvon false.

        Jos ennestään on evästeitä, asetetaan uusi.

        Jos evästeitä ei hyväksytä, ei ole katastrofi. Asetukset vaan eivät tallennu - ja intro-tekstiä pukkaa.

        Toki jos evästeitä ei löydy, voisin lisätä koodia siten, että ei anneta intro-tekstiä.
        if(count($_COOKIE) == 0){

        tai
        if(!$_COOKIE){...

        olisi olestusasetukset vähän eri

        Sivujen päivitystarve on kyllä olemassa evästeillä. Ja tuon ikuisen loopin saaminen.

        Ongelmana on tässä se, että sivun uudelleen latausta tarvitaan vain kun on tietyt get-parametrit, mutta jos niitä on ja ladataan sivu tällöin uudestaan, syntyy se ikuinen silmukka koska samat parametrit on taas esillä. Toki jos testaa, että kaikki arvot on entiset, ja jos on entiset arvot ja sitten ladataan uudestaan, ei synny silmukkaa.

        Ehkä se ohjeteksti on hyvä ts. muistutus, että käyttäjän pitää ladata sivu uudestaan, jos haluaa heti nähdä muutokset.


      • Tapio-Huuhaa kirjoitti:

        Tämä kommentti jäi huomioimatta kun tuli kirjoitettua loppuun (tämä on sisäkkäisten kommenttien perusongelma).

        Tavallaan tutkin, onko evästeeni olemassa tällä koodilla:

        elseif(!isset($_COOKIE["intro"])) setcookie...
        ...

        Eikö järkevintä ole kysyä heti alkuun, hyväksyykö käyttäjä evästeet ts. onko ennestään evästeitä

        if (!(count($_COOKIE) == 0)){
        //your code
        }
        tai vain

        if($_COOKIE){}

        jos evästeitä ei ole, $_COOKIE on tyhjä ja saa arvon false.

        Jos ennestään on evästeitä, asetetaan uusi.

        Jos evästeitä ei hyväksytä, ei ole katastrofi. Asetukset vaan eivät tallennu - ja intro-tekstiä pukkaa.

        Toki jos evästeitä ei löydy, voisin lisätä koodia siten, että ei anneta intro-tekstiä.
        if(count($_COOKIE) == 0){

        tai
        if(!$_COOKIE){...

        olisi olestusasetukset vähän eri

        Sivujen päivitystarve on kyllä olemassa evästeillä. Ja tuon ikuisen loopin saaminen.

        Ongelmana on tässä se, että sivun uudelleen latausta tarvitaan vain kun on tietyt get-parametrit, mutta jos niitä on ja ladataan sivu tällöin uudestaan, syntyy se ikuinen silmukka koska samat parametrit on taas esillä. Toki jos testaa, että kaikki arvot on entiset, ja jos on entiset arvot ja sitten ladataan uudestaan, ei synny silmukkaa.

        Ehkä se ohjeteksti on hyvä ts. muistutus, että käyttäjän pitää ladata sivu uudestaan, jos haluaa heti nähdä muutokset.

        Siis ladataan uudestaan, jos entiset ja nykyiset ovat eri. Jos ovat samat, arvot on päivitetty, eikä ladata uudestaan.


    • Näemmä jos lataa asetussivun toistamiseen tai siirtyy toiselle sivulle, evästeiden vaikutus tulee esille. Mitähän tälle tekisi muuta kuin ilmoittaisi asiasta?

      älä näytä uudelleen en nyt meinaa saada toimimaan.

    • piti laitta eri koodi asetussivulle ja muille sivuille, koska asetussivulla voi tulla mukaan ylimääräisiä parametreja. ÄLÄ... kanssa kuitenkin sama toiselle sivulle siirtymisen tai uudelleen lataamisen tarve.

    • ÄLÄ NÄYTÄ UUDESTAAN -tekstin yhteydessä kun klikkaa linkkiä muulla kuin asetussivulla ja sen jälkeen sulkee ikkunan ja siirtyy toiselle sivulle, teksti häviää. Siinä kaiketi ihan OK.

    • Jotta evästeissä ja tietokannassa olisi sama tieto, jos evästeet eivät ole oletusarvoissa, funktiosta täytyi tehdä mutkikkaampi. Jos on kirjautumatta tehnyt muutoksia ja kirjautuu, seuraavan funktion pitäisi päivittää data:

      Koodi:
      function getLayoutSettings($userLayoutSettings_ar){
      if(is_user_logged_in()){
      if(intval($_COOKIE['sivupalkki']) ===2 || !(intval($_COOKIE['paavalikonsijainti'])===3) || intval($_COOKIE['nuolet']) ===1 || !(intval($_COOKIE['lisavalikko'])===1))
      { // oletusasetuksia on muutettu ja ne ovat evästeissä
      $userLayoutSettings=$_COOKIE['intro'].','.$_COOKIE['sivupalkki'].','.$_COOKIE['paavalikonsijainti'].','.$_COOKIE['nuolet'].','.$_COOKIE['lisavalikko']; // käytetään evästeitä
      $userLayoutSettings_ar = explode(',', $userLayoutSettings);
      $current_user = wp_get_current_user();
      $userLayouts = explode(',', $current_user->user_layout_settings);
      if(!($_COOKIE['intro']==$userLayouts[0] && $_COOKIE['sivupalkki']==$userLayouts[1] && $_COOKIE['paavalikonsijainti']==$userLayouts[2] && $_COOKIE['nuolet'] ===$userLayouts[3] && $_COOKIE['lisavalikko']==$userLayouts[4]))
      { // jos tietokannassa on eri tieto kuin evästeissä, päivitetään tietokanta
      $updateValue = $_COOKIE['intro'].','.$_COOKIE['sivupalkki'].','.$_COOKIE['paavalikonsijainti'].','.$_COOKIE['nuolet'].','.$_COOKIE['lisavalikko'];
      update_user_meta($current_user->ID,'user_layout_settings', $updateValue);
      }
      }else{ // ei ole ennestään tietokannassa tietoa tai se on sama kuin evästeissä
      $current_user = wp_get_current_user();
      $userLayoutSettings=$current_user->user_layout_settings;
      if(!$userLayoutSettings){$userLayoutSettings='2,1,3,2,1';} // asetetaan oletustiedot
      $userLayoutSettings_ar = explode(',', $userLayoutSettings);
      }
      }
      elseif($_COOKIE['sivupalkki']){// löytyy evästeet
      $userLayoutSettings=$_COOKIE['intro'].','.$_COOKIE['sivupalkki'].','.$_COOKIE['paavalikonsijainti'].','.$_COOKIE['nuolet'].','.$_COOKIE['lisavalikko'];
      }else{ // evästeitä ei ole koska käyttäjä on poistanut ne
      $userLayoutSettings='2,1,3,2,1';}
      $userLayoutSettings_ar = explode(',', $userLayoutSettings);
      return $userLayoutSettings_ar;
      }
      Tuon pitäisi taata se, että jos muutat tietoa kirjautumatta, muutos on voimassa kun kirjaudut. Samoin jos kirjaudut, muutos on voimassa jos kirjaudut ulos. Vain jos poistat evästeet etkä kirjaudu, menetät asetukset. Testasin, että toimii.

    • Anonyymi

      Ulkoasuun sen verran, että en ymmärrä, mikä väriskaalassa olisi pielessä. Kahta korostusväriä lukuun ottamatta on käytetty vain sinisen, mustan ja harmaan eri sävyjä.

    • Joku ehdotti sitä, että väriskaala olisi käyttäjän valittavissa. En osaa kuitenkaan tehdä tummaa väriskaalaa. Taito loppuu kesken siinä.

      En ole vieläkään päässyt ulkoasun kehittämiseen kun lisäilin joitakin elementtejä säätöihin ja testasin niitä.

      Muita asioita sangen helppo säätää.

      Kokeilin yhdellä kapealla (viewport-arvoissa mitattuna 20px) sivupalkilla. Lisäsin toiminto- ja aihevalikoihin ylösalasnuolet, jos niitä ei ole suoraan esillä. Toimii homma niinkin. Yhden painikkeen takaa löytyy:

      * haut
      * toimintovalikko
      * päävalikko
      * aihevalikko
      * ylös/alas-nuolet

      Käyttöliittymä on laitettu lähes absoluuttiseen minimiinsä.

      Absoluuttinen mini olisi sitä, että mukana olisi:

      * sivuston pääryhmät
      * murupolut

      Kyllä sekin on mahdollista, mutta ei minustakaan enää järkevää. Mutta käyttöliittymä on kyllä teoriassa minimoitavissa ja se on vielä varsin helposti toteutettavissa.

    • Vähän aiempaan. On kai syytä testata, että sallitaan evästeet. Ajattelin tällaista.

      setcookie("testi", "on", time() 86400, "/", "sanaristikkofoorumi.net", 1);
      if($_COOKIE["testi"]){
      ...
      }

      ja Code Snippet -tietueessa:

      ...

      elseif($_COOKIE['sivupalkki']){// löytyy asettamiani evästeitä
      $userLayoutSettings=$_COOKIE['intro'].','.$_COOKIE['sivupalkki'].','.$_COOKIE['paavalikonsijainti'].','.$_COOKIE['nuolet'].','.$_COOKIE['lisavalikko'];
      }elseif($_COOKIE){ // asettamiani evästeitä ei ole koska käyttäjä on poistanut ne, mutta evästeitä on olemassa
      $userLayoutSettings='2,1,3,2,1';
      }else{ // evästeitä ei sallita
      $userLayoutSettings='1,1,3,2,1';
      }

    • header.php muutos ei toimi, mutta PHP-funktiossa kohta

      }elseif($_COOKIE){ // asettamiani evästeitä ei ole koska käyttäjä on poistanut ne, mutta evästeitä on olemassa
      $userLayoutSettings='2,1,3,2,1';
      }else{ // evästeitä ei sallita
      $userLayoutSettings='1,1,3,2,1';
      }

      hoitanee asian

    • Anonyymi

      Panostaisit enemän sivustosi sisältöön kuin täällä mainostamiseen. Kukaan ei vaan viitsi kahtakertaa käydä kun toteaa sivustosi sisällön olevan perseestä.

      • Tuo nyt ei hyödytä ketään. Jos on arvosteltavaa, se pitää eritellä.


    • Faktantarkistuksen ehdottaman uudelleen latauksen sain kuntoon asetussivulla.
      setcookie("testi", "on", time() 86400, "/", "sanaristikkofoorumi.net", 1);
      if(isset($_COOKIE["testi"])){

      ... muutokset
      jos tullut muutoksia ladataan uudelleen ILMAN parametreja:


      if (!($_GET["intro"]==$_COOKIE["intro"] && $_GET["sivupalkki"]==$_COOKIE["sivupalkki"] && $_GET["paavalikonsijainti"]==$_COOKIE["paavalikonsijainti"]
      && $_GET["lisavalikko"]==$_COOKIE["lisavalikko"] && $_GET["nuolet"]==$_COOKIE["nuolet"] && $_GET["haku"]==$_COOKIE["haku"]))
      {
      $myUrl = "https://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
      $myUrlPos= stripos($myUrl,'?');
      $myUrl=substr($myUrl,0,$myUrlPos);
      header("Location: ".$myUrl);
      }

      }

      • Jos koodissa on virhe, rakentavaa on esittää korjausehdotus. Virheitä koodaamisessa tulee.


    • Ihan oikeasti suuri kiitos mainitsemalleni nimimerkille

      • Hyvä että projekti pala palalta etenee vaikka valmista ei bittiviidakossa ikinä tulisikaan.


      • Faktantarkistus kirjoitti:

        Hyvä että projekti pala palalta etenee vaikka valmista ei bittiviidakossa ikinä tulisikaan.

        Joo ei. Joku ehdotti eri väriteemoja. Ensin pitäisi saada yksi Code Snippet, johon koota värien käyttö (color,background-color,border,text-shadow, box-shadow,outline). Yritin, mutta pieleen meni - enkä taaskaan ymmärrä miksi. Tarkistin CSS:n syntaksin WordPressin omalla CSS:n syntaksin tarkistimella, joka on erittäin hyvä. Varsinaisten virheiden näyttämisen ohella muistuttaa vain padding-arvoista. Ei valita turhasta kuten W3C:n validaattori.


      • Tapio-Huuhaa kirjoitti:

        Joo ei. Joku ehdotti eri väriteemoja. Ensin pitäisi saada yksi Code Snippet, johon koota värien käyttö (color,background-color,border,text-shadow, box-shadow,outline). Yritin, mutta pieleen meni - enkä taaskaan ymmärrä miksi. Tarkistin CSS:n syntaksin WordPressin omalla CSS:n syntaksin tarkistimella, joka on erittäin hyvä. Varsinaisten virheiden näyttämisen ohella muistuttaa vain padding-arvoista. Ei valita turhasta kuten W3C:n validaattori.

        Kyse on oli väärästä palautuksesta.

        Jotkut funktiot pitää palauttaa return avulla ja toiset echo.
        No ensiksi pitäisi saada kaikki värit paitsi taustavärit pois. Vielä on joitakin värejä, jotka pitää poistaa.


    • Anonyymi

      Virussivuston mainostaminen vaan jatkuu.

      • On nyt aika ilkeämielistä ja väärin kuvata sivustoni noin. Ehkä olen käsitellyt aihetta turhan pitkään. Mutta jos jollakulla on kiinnostusta, hän voi laatia uuden väriteeman. Loin Code Snippet -tietueen, jossa on väreihin liittyvät ominaisuudet (color,background,border,outline,text-shadow,box-shadow,opacity). Jos sen ottaa pois päältä on vain HTML-elementtien oletusvärit. Tietueesta voi ottaa kopion ja sen avulla voi luoda toisen värimaailman. Onnistuneen voi laittaa vaihtoehdoksi nykyiselle. Kokeiluja voi tehdä niin paljon kuin huvittaa.


    • Koodareilla on usein tapana erotella PHP, CSS ja JavaSript toisistaan, mutta minä en moisesta erottelusta välitä. Ajattelen, että koodi pitää tehdä tarkoituksenmukaisesti.

      Väriteema on jo nyt PHP CSS -koodausta. Tätä voisi viedä pidemmälle. Ajattelin, että värit eräät muut ominaisuudet voisi laittaa muuttuijina, tähän tapaan:


      // funktion alussa värimuuttujat seuraavaan tapaan:
      /* header */
      $header_color='#fff';
      $header_text-shadow='3px 3px 3px #000'; // jos ei halua varjostusta, pitää laittaa 'none', mutta kohtaa ei saa jättää tyhjäksi
      /* valkoisen tekstin käyttö tummalle pohjalle */

      /* widget */
      $widget_color[1]='#fff'; // jos samalla alueella eri värejä, käytetään taulukkomuuttujaa
      /* footer */
      $footer_color='#fff';


      //CSS:ssä:

      /* valkoisen tekstin ja sille mahdollisen varjostuksen käyttö */
      /* header */
      ...
      /* valkoinen teksti tummalle pohjalle */
      ...
      /* widget */
      ...{color:'.$widget_color[1].';}
      /*footer */.site-footer,.site-info,.site-info a{color:'.$footer_color.';}
      ...

      Jos muuttaisin ominaisuudet muuttujiksi, väriehdotukseksi riittäisi joukko muuttujia. Tuskin palvelinta suuresti rasittaa värien määritys muuttujina.

      Yhteen värejä käsittelevään Code Snippettiin voisi laittaa useita väriehdotelmia ilman, että tietueesta muodostuisi kohtuuttoman pitkä.

    • Anonyymi

      Mistä kumpuaa tämän ketjun aloittajan korostettu halu poiketa vallitsevista käytännöistä ja jopa suosituksista? ~minä en niistä välitä~ -ajatusmalli johtaa väistämättä siihen ettei jatkajaa projektille löydy sitten kun edellinen väsyy.

    • Tuo on kyllä totta, mutta sivustoni on oma ikuisuusprojektini. Kun tein muille, olen syvästi pahoillani siitä, että en dokumentoinut tekemisiäni.

    • Anonyymi

      Tämä ketju pitäisi poistaa. Tällaista hölmöilyä on vaikea sietää. Avaaja voisi tavata näitä aakkosia omalla sivullaan, kun näistä ei varmasti ole kenellekään mitään iloa.

    • Kyllä minulla oli ihan aito kysymys.

      Tein typeriä mokia, hölmöilin. Totta. Sain myös ystävällismielistä apua, jonka seurauksena kehitin järkevän ja täysin toimivan ratkaisun.

      Ajatus värien säätämisestä on omaperäinen. Totta.

      Mutta ei erilaisuus tee ajatuksesta hölmöilyä.

      Jotkin linkitykset sivutolleni olivat piilomainontaa. Niitä voi pitää piilomainontana, sillä eihän minun olisi tarvinnut tuoda esille, missä käytän saamiani ohjeita. Pyydän tätä anteeksi.

    • Jos värit laittaa muuttujina, koodi tulee ymmärrettävämmäksi:

      .extra-windows .infoTextArea ul li,.extra-windows .infoTextArea ul li li{color:'.$generic_color.'!important;}
      /* sinisen tekstin käyttö linkeissä */
      a:link,a:visited,.extra-windows *{color:'.$generic_link_color.'}

      Eikös sitä ole oikeus hölmöillä ilman, että siitä suututaan? Eikö tarkoitus ole auttaa toisia?

      • Pari nopeaa huomiota ennen kuin laitetaan tämän ketjun osalta kansi kiinni:

        Sinulla on valtavirrasta poikkeava tyyli rakentaa projektiasi mikä näkyy hyvin tässä ketjussa. Ulkopuolisten on hankala ellei jopa mahdoton ottaa mihinkään kantaa edes neuvonantajan ominaisuudessa ettei tule neuvoneeksi harhaan ja toisekseen muiden (ainakin itseni osalta) on vaikea ottaa oppia noista yksittäisistä snippeteistä, koska sivuja rakennetaan niin eri tyyleillä.

        Taisit edellä jossain ampua alas yleisen tavan erotella esimerkiksi css:t omaksi tiedostokseen. Minusta siinä tavassa on ainakin yksi hyvä puoli: cache. Selaimet muistaa jo vierailtujen sivujen linkitetyt isot tyylitiedostot ja kuvatiedostot niin, ettei niitä tarvitse aina uudelleen ladata. Kaistaa säästyy ja sivut avautuu siis hyppysellisen nopeammin. Ymmärsin että laitat kaiken tietpkantaan. Eikös se johda siihen, että samaa bittivirtaa ladataan pakotetusti aina uudestaan...

        Nykyään tosin tiedonsiirto on nopeaa eli tuskinpa tuo pullonkaulaksi muodostuu, mutta ainakin periaatteessa tyylien erottamisella omaksi itsenäiseksi osakseen on puolensa.

        Tämä tästä teemasta. Hölmöillään muissa merkeissä sikäli jos jotain uutta ilmenee.


    • Tuota cache-seikkaa en ole tullut ottaneeksi huomioon. Hieman kompensoin sillä, että Autoptimize pakkaa HTML:ää ja itse käytän pääosin melko pakattua CSS:ää.

      Suurimman osan CSS:stä voisin toki laittaa tiedostoina. Mutta eräät palat ovat luonteeltaan sellaisia, että ne on pakko luoda PHP CSS -yhdistelmällä, koska osaa CSS:ää ei voi hallita BOBY-elementin luokkien avulla.

    • Järkevintä olisi kai siirtää suht. valmiit CSS:t erillistiedostoihin tuon cachen takia. Keskeneräisiä on helpompi testailla tietokannasta.

      • Tietämättä hakemistorakenteestasi yhtään mitään voi vain arvaillen vinkata, että suhteellinen viittaus kuuluisi olla

        joko

        ../wp-content/themes/forum_css.css //mikäli kansio samalla tasolla

        tai

        wp-content/themes/forum_css.css //mikäli kansio alikansiotasolla


    • Tuo link-tägi kertoo aika paljon hakemistorakenteesta. Yritin relatiivista osoitetta ilman /-merkkiä.

      link rel= ... "wp-content/themes/forum_css.css"

      Tuo ei toimi. Lähdekoodissa klikattuani linkkiä tuli "Sivua ei löydy". WordPress lisäsin tuon satunnaisen sivun perään.

      Yritin muuttaa hakemiston lukuoikeuksia. Ei auttanut.
      Loin .htacess-tiedoston kyseiseen hakemistoon. Poistin, kun ei ollut apua.
      Asennuksen juuressa on

      # BEGIN LSCACHE
      # END LSCACHE
      # BEGIN NON_LSCACHE
      # END NON_LSCACHE
      # BEGIN WordPress
      <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteBase /wordpress/
      RewriteRule ^index\.php$ - [L]
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /wordpress/index.php [L]
      </IfModule>

      # END WordPress
      # BEGIN ShortPixelWebp
      # END ShortPixelWebp

      Onko tuo väärin?

      On nyt perin outoa, että CSS-tiedostoa ei lueta, mutta muut tiedostot luetaan.

      Kun lähdekoodia tarkasteltaessa klikkaa linkkiä, tulee vain "Forbidden..."

      Yleensä kun klikkaa jonkin sivuston linkitettyä CSS-tiedostoa "Näytä lähdekoodi" -tilassa, CSS-tiedoston saa luettavakseen. Sivustollani se ei onnistu.

      • Haiskahtaa siltä että css-kansiossasi ei ole asianmukaisia lukuoikeuksia.
        Varmista että sen css:n sisältävän kansion tiedosto-oikeustaso on numeroltaan 751.

        Suhteellinen linkitys yksinkertaistettuna:

        linkityksen sisältävä tiedosto:
        <domain>/index.php

        <link rel="stylesheet" type="text/css" href="themes/forum_css.css" />


      • Faktantarkistus kirjoitti:

        Haiskahtaa siltä että css-kansiossasi ei ole asianmukaisia lukuoikeuksia.
        Varmista että sen css:n sisältävän kansion tiedosto-oikeustaso on numeroltaan 751.

        Suhteellinen linkitys yksinkertaistettuna:

        linkityksen sisältävä tiedosto:
        <domain>/index.php

        <link rel="stylesheet" type="text/css" href="themes/forum_css.css" />

        Oli 0777 eikä 0751 muuttanut tilannetta.


      • Tapio-Huuhaa kirjoitti:

        Oli 0777 eikä 0751 muuttanut tilannetta.

        Olisiko sen yksittäisen css-tiedoston itsensä ominaisuuksissa jokin lukitus päällä.
        Kokeile laittaa sille lukuoikeus numerolla 644.

        Turha näitä on enempää ulkopuolisten arvailla. Ota yhteys käyttämäsi webbihotellin tukeen. Osaavat varmasti parhaiten kertoa oikeat kikat miten pääset omiin tiedostoihisi käsiksi.


      • Faktantarkistus kirjoitti:

        Olisiko sen yksittäisen css-tiedoston itsensä ominaisuuksissa jokin lukitus päällä.
        Kokeile laittaa sille lukuoikeus numerolla 644.

        Turha näitä on enempää ulkopuolisten arvailla. Ota yhteys käyttämäsi webbihotellin tukeen. Osaavat varmasti parhaiten kertoa oikeat kikat miten pääset omiin tiedostoihisi käsiksi.

        Laitoin kokeeksi lukuoikeudet 7777. Tiedosto toimi. Pääsen kyllä käsiksi tiedostoihini.
        Oletusarvo on 0751.

        Tuo 7777 on varmaan liikaa. rwsr-sr-t eli 7755 toimi. On varmaan tosiaan järkevää siirtää isot tiedostoihin, mutta pienehköt voi olla style-tägeillä


      • Anonyymi

        Todella noviisi touhua!


    • Forbidden tuli siis absoluuttisen osoitteen kanssa

    • <link ... /wordpress/wp-content/themes/forum_css.css" />

      Toi absoluuttisen osoitteen, johon vieläkin

      Forbidden...

      Esittämäsi muoto taasen saa lähdekoodissa klikattaessa mm.

      ....forums/topic/suomen-kuvalehti-40-2019/themes/forum_css.css

      Eikä sitä lueta.

      testasin kaikkia näin:

      $CSS='<link rel="stylesheet" type="text/css" href="themes/forum_css.css" />';
      $CsSS=$CSS.'<style id="foorumiosion-css">

    • Sori nyt vaan tätä sähläilyä oikeiden tiedostolukuoikeuksien kanssa. Siirsin yhtä lukuun ottamatta isot CSS-tiedostot erillistiedostoiksi.
      Yhtä en voinut. Joskin syystä aivan sama CSS toi linkitettynä virheellisen lopputuloksen. Pitäisi selvittää, mistä ero johtuu.

    • Tulipa taas sähläiltyä. Mutta käytäntönä jatkossa kannattaa se, että testisivustolla käytän tietokantaa. Kun saan riittävään kuntoon, pakkaan CSS:n ja siirrän live-sivustolle. Tulipa vähän muutettua käytäntöjäni.

    • Mikä on Faktantarkistus mielestä järkevä raja sille, milloin style-tägin sijasta kannattaa siirtää link-tägille.

      Nyt siirsin 5K ja 11K tiedostotkin. Ehkä ne turhaan. Ison tiedosto live-sivustolla on muuten 84Kb. Sen olen jakanut testisivustolla kahteen osaan.

      • Mitään kokomääreitä en osaa tauluun piirtää. Itsellä yksinkertainen layout on aina ykkönen ja sitä myöten css:t on minifyituina niin pieniä että periaatteessa on aivan sama laittaako ne stylenä suoraan dokumenttiin vai linkittääkö irrallisena tiedostona. Ratkaisevaa on se, käyttääkö samaa css:ä useampi kuin vain yksi tiedosto. Luonnollisesti jos samalle layoutille kirjoitettuja sivuja on useita, niin css on omana linkattavana tiedostonaan, jolloin ylläpidossa muutos yhteen paikkaan muuntaa koko paketin.

        Sivut joka tapauksessa latautuu nopeammin aiemmin jo mainitun selainten cachen vuoksi ja itse dokumentit pysyy siistinä / helpommin luettavana kun tyyliasiat on eriytetty omaksi kakukseen.

        Muotoiluja testatessa hyödynnän myös järjestystä eli jos linkitetyssä css-tiedostossa on jokin asetus mitä haluaa vielä testailla toisin asetuksin yhdessä tiedostossa, niin ei tarvitse muuttaa sitä alkuperäistä linkitettyä tiedostoa mokoman testin takia, vaan ylikirjoittan testiasetuksia style-tageilla ja tällöin selain unohtaa sen mitä siellä linkatussa alunperin oli.


      • Faktantarkistus kirjoitti:

        Mitään kokomääreitä en osaa tauluun piirtää. Itsellä yksinkertainen layout on aina ykkönen ja sitä myöten css:t on minifyituina niin pieniä että periaatteessa on aivan sama laittaako ne stylenä suoraan dokumenttiin vai linkittääkö irrallisena tiedostona. Ratkaisevaa on se, käyttääkö samaa css:ä useampi kuin vain yksi tiedosto. Luonnollisesti jos samalle layoutille kirjoitettuja sivuja on useita, niin css on omana linkattavana tiedostonaan, jolloin ylläpidossa muutos yhteen paikkaan muuntaa koko paketin.

        Sivut joka tapauksessa latautuu nopeammin aiemmin jo mainitun selainten cachen vuoksi ja itse dokumentit pysyy siistinä / helpommin luettavana kun tyyliasiat on eriytetty omaksi kakukseen.

        Muotoiluja testatessa hyödynnän myös järjestystä eli jos linkitetyssä css-tiedostossa on jokin asetus mitä haluaa vielä testailla toisin asetuksin yhdessä tiedostossa, niin ei tarvitse muuttaa sitä alkuperäistä linkitettyä tiedostoa mokoman testin takia, vaan ylikirjoittan testiasetuksia style-tageilla ja tällöin selain unohtaa sen mitä siellä linkatussa alunperin oli.

        Noi 5 ja 11 Kb ovat mobiililaitteilla joka sivulla tarvittavia tiedostoja. Kirjautumisen tuomat pikku muutokset, asetusten tuomat pienet muutokset pakosti PHP CSS koodausta tarvitsevat ovat style-tägeillä.

        Miten toteuttaisin mahdollisen teeman värin muuttamisen on erittäin ongelmallista. Koska CSS on jaettu paloihin, värijutuissa pitäisi taas kasata osittain yhteen. Itse värien muuttamisen kannalta muuttujat tai vakiot olisi helpoin tapa testata eri värejä, mutta samalla kaikki pitäisi laittaa style-tägeillä. Yhteiskoko on arviolta n. 50 kB. Se on aika paljon style-tägillä laitettuna.


      • Tapio-Huuhaa kirjoitti:

        Noi 5 ja 11 Kb ovat mobiililaitteilla joka sivulla tarvittavia tiedostoja. Kirjautumisen tuomat pikku muutokset, asetusten tuomat pienet muutokset pakosti PHP CSS koodausta tarvitsevat ovat style-tägeillä.

        Miten toteuttaisin mahdollisen teeman värin muuttamisen on erittäin ongelmallista. Koska CSS on jaettu paloihin, värijutuissa pitäisi taas kasata osittain yhteen. Itse värien muuttamisen kannalta muuttujat tai vakiot olisi helpoin tapa testata eri värejä, mutta samalla kaikki pitäisi laittaa style-tägeillä. Yhteiskoko on arviolta n. 50 kB. Se on aika paljon style-tägillä laitettuna.

        Ota tasapainovaaka käyttöön: toiseen puntariin työmäärä ja toiseen työstä saatava hyöty. Jos hyöty jää korkeammalle, niin unohda koko juttu. Ihan kaikkea ei tarvitse nettisivuillakaan olla. Jotkut väittää jopa yksinkertaisen olevan kauniin.


      • Anonyymi
        Faktantarkistus kirjoitti:

        Ota tasapainovaaka käyttöön: toiseen puntariin työmäärä ja toiseen työstä saatava hyöty. Jos hyöty jää korkeammalle, niin unohda koko juttu. Ihan kaikkea ei tarvitse nettisivuillakaan olla. Jotkut väittää jopa yksinkertaisen olevan kauniin.

        Oikeastaan otin tuon vaihtoehtoisen värimäärittelyn haasteena (vähän kuin haastavan ristikon). En sinänsä koe tärkeänä. On vain älyttömän hankala toteuttaa nykyisellä rakenteella millään järkevällä tavalla. Olkoon tapa mikä tahansa, on työläs. Ei mielestäni millään lailla vastaa siitä saatavaan hyötyyn.


    • Laskin, että jos haluaa dynaamisesti kootun style-tägin, lopullista CSS-koodia tulee tietokoneelle lähes 60kB. Palvelin saa käsittelyyn vähän enemmän. Ei oikein tunnu järkevältä. Ehkä SASS saisi dynaamisen koodin, mutta silti moneen CSS-tiedostoon laitetun CSS:n? Osa CSS:stä on silti ongelmallista.

    • Kiitos vielä kerran nimimerkille Faktantarkistus.

      Cachea ajatellen valtavat style-tägit olivat huono ratkaisu. Tein koostesnippetin, jossa kaikki linkitykset samassa paketissa. Mukana myös välttämättömät style-tägit.

      Paleteille on oma koosteensa, jossa on myös linkitykset välttämättömät style-tägit. Yritin laittaa style-tägeja vain ihan pakon sanelemana.

      Mitään hyvää ratkaisua mahdolliselle vaihtoehtoiselle väriteemalle en siis löytänyt. Laitoin alihakemistoon värejä koskevat CSS-tiedostot. Helpoimmalla pääsee kun etsii ja korvaa tietyssä alihakemistossa olevien tiedostojen ominaisuuksia. Sinne kopioin myös kasaamistiedoston, jossa on PHP CSS -koodausta, jota ei voinut värejä koskeviin CSS-tiedostoihin laittaa.

      Ehkä testisivustolla otan uudestaan käyttöön style-tägit. Niiden kanssa versiointi on vain monin verroin helpompaa kuin erillistiedostojen kanssa. Versioita joistakin tiedostoista on tullut tehtyä yli 60 kpl. Tallessa en ole kovin montaa vanhempaa pitänyt.

    • Kun nyt muutin toimintatapaa, olisi kiva saada vähän ohjeita. Siirsin muuten JS:ääkin erillistiedostoihin niin paljon kuin mahdollista. Kaiketi niissäkin on hyötyä, että tallennetaan cacheen.

      Code Snippetin kanssa CSS:ää oli helppo tehdä versioita. Mutta erittäin huono kirjoittamiseen. Mikähän olisi paras ilmainen CSS-editori. Olisi kiva, jos se osaisi automaattisesti minimoida ja purkaa minimoinnin.

      SASS olisi järkevä, jos tekisi muille sivuja, mutta yhden sivuston kanssa en koe mielekkääksi.

    • Entä CSS:n pilkkominen entistä pienempiin paloihin media-attribuuteilla, esim.
      media="screen and (max-width: 782px)"

    • Tuohon leveyspohjaiseen pilkkomiseen en ryhtynyt. Mitä viimeksi tein, on "Uusi" -toiminnallisuus. Mitä halauaisin, olisi hälytys-toiminto, mutta minulla ei ole ideaa, miten sitä toteuttaisi.

    • Ihan kuriositeettinä tämä sivusto on koodattu JavaScriptillä. Suuri osa ellei suurin osa CSS:stä on style-tägeillä.

    • Ihan tiedoksi, että piti laittaa evästeet käyttäen WordPressin init-funktiota. Suora määrittely rikkoi WordPressin hakutoiminnon.

      Poistin tämän käytöstä, sillä se saattaa aiheuttaa ongelmia.

      if (!(($_GET["intro"]==$_COOKIE["intro"] && $_GET["sivupalkki"]==$_COOKIE["sivupalkki"] && $_GET["paavalikonsijainti"]==$_COOKIE["paavalikonsijainti"]
      && $_GET["lisavalikko"]==$_COOKIE["lisavalikko"] && $_GET["nuolet"]==$_COOKIE["nuolet"] && $_GET["haku"]==$_COOKIE["haku"]) || $_GET["varit"]==$_COOKIE["varit"]))
      {
      $myUrl = "https://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]";
      $myUrlPos= stripos($myUrl,'?');
      $myUrl=substr($myUrl,0,$myUrlPos);
      header("Location: ".$myUrl);
      }

    • Ihan oikea kysymys taasen.
      Mietin, miten toteuttaa aihelistauksen järjestyksen muutos. Ajattelin, että viimeisin muutos, aloitettu ja otsikko olisivat järjestyperiaatteina. Noissa itse asiassa "viimeisin muutos" ei tee mitään vaan palauttaa oletuksen.

      Ongelma on visuaalinen. Select-valikko vaatinee lisäpainikkeen ja on painiketta hankalampi. Painikkeet vievät liikaa tilaa kännykällä.

      Onko toi select-valikko kamala? Pitäisikö muutos tallentaa evästeisiin?

    • Anonyymi

      Select-valikko on sen verran epäkäytännöllinen, että laitoin vain evästeiden tukeman kolme vaihtoehtoa painikkeilla.

    Ketjusta on poistettu 10 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. Kiitos nainen

      Kuitenkin. Olet sitten ajanmerkkinä. Tuskin enää sinua näen ja huomasitko, että olit siinä viimeisen kerran samassa paik
      Tunteet
      12
      3690
    2. MTV: Kirkossa saarnan pitänyt Jyrki 69 koki yllätyksen - Paljastaa: "Se mikä oli hyvin erikoista..."

      Jyrki Linnankivi alias Jyrki 69 on rokkari ja kirkonmies. Teologiaa opiskeleva Linnankivi piti elämänsä ensimmäisen saar
      Maailman menoa
      72
      1934
    3. Hyväksytkö sinä sen että päättäjämme ei rakenna rauhaa Venäjän kanssa?

      Vielä kun sota ehkäpä voitaisiin välttää rauhanponnisteluilla niin millä verukkeella voidaan sanoa että on hyvä asia kun
      Maailman menoa
      542
      1598
    4. Kirjoita yhdellä sanalla

      Joku meihin liittyvä asia, mitä muut ei tiedä. Sen jälkeen laitan sulle wappiviestin
      Ikävä
      81
      1224
    5. Olet hyvin erilainen

      Herkempi, ajattelevaisempi. Toisaalta taas hyvin varma siitä mitä haluat. Et anna yhtään periksi. Osaat myös ilkeillä ja
      Ikävä
      67
      1057
    6. Yksi syy nainen miksi sinusta pidän

      on se, että tykkään luomusta. Olet luonnollinen, ihana ja kaunis. Ja luonne, no, en ole tavannut vielä sellaista, joka s
      Ikävä
      33
      988
    7. Hyödyt Suomelle???

      Haluaisin asettaa teille palstalla kirjoittelevat Venäjää puolustelevat ja muut "asiantuntijat" yhden kysymyksen pohditt
      Maailman menoa
      214
      888
    8. Hyvää Joulua mies!

      Toivottavasti kaikki on hyvin siellä. Anteeksi että olen hieman lisännyt taakkaasi ymmärtämättä kunnolla tilannettasi, o
      Ikävä
      60
      853
    9. Hyvää talvipäivänseisausta

      Vuoden lyhyintä päivää. 🌞 Hyvää huomenta. ❄️🎄🌌✨❤️😊
      Ikävä
      171
      844
    10. Paljastavat kuvat Selviytyjät Suomi kulisseista - 1 päivä vs 36 päivää viidakossa - Katso tästä!

      Ohhoh! Yli kuukausi viidakossa voi muuttaa ulkonäköä perusarkeen aika rajusti. Kuka mielestäsi muuttui eniten: Mia Mill
      Suomalaiset julkkikset
      3
      778
    Aihe