Faktantarkistus
Faktat tiskiin. Valheille korkeintaan säälivä katse.
Liittynyt sitten
Muokkaa profiilia1 aloitusta · 82 kommenttia
- 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. - 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 :) - 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/ - Onneksi ei tullut kutsua linnaan joulukuun kuudenneksi, koska siitä voisi olla jo vaikea kieltäytyä :)
Forum-ohjelmistot ei ole millään lailla lähellä minun osaamista / mielenkiinnon kohteita. Äkkiseltään liittyminen johonkin kehitysporukkaan tarkoittaisi liittymistä palomies-asenteella 24/7 -päivystäjiin jotka samalla luopuisivat kaikesta muusta omassa elämässään.
bbPress lienee ydinkoodiltaan tarkoituksella kehitetty ketteräksi, pieneksi forum-alustaksi, mihin ei tuupata kaikkia mahdollisia ominaisuuksia. Sen syntytarina on kaiketikin siinä, että kun kaikki muut paisuu niin luodaan bbPress joka on ja pysyy slim fittinä. Siksi epäilen että vaikka kuinka lähettelisi painostavaa viestiä "pääkonttorin pojille" niin kaikkia toiveita ei ydinkoodiin lisätä.
Avoimen lähdekoodin bbPressiin tietysti voi halutessaan koodailla lisäosia. Niihin löytyy varmasti ohjeet googlea hyväksikäyttämällä. Lisäosien rakentaminen on juuri sitä aiemmin mainittua päivystystä. Juuri kun olet saanut jotain valmiiksi niin core codesta tulee uusi julkaisuversio, mikä vaatisi muutoksia lisäosan sujuvan toiminnan takaamiseksi.
Eli, ihan hetken mielijohteesta ei kannata mokomaan ryhtyä.
PS. Googletin ja ainakin pluginien luontiin on olemassa sivukaupalla ohjeistusta
https://developer.wordpress.org/plugins/
mikäli jokin todellinen ongelma on vielä ratkaisematta ja sen ratkaisemiseen on itsellä vahva usko ja kyky olemassa. - Se ei ole tekijän vika jos jotkut ei ymmärrä retron päälle. Jokainen teos on aina tekijänsä näköinen. Ihan sama onko se teos diginä ruudulla vai kehystettynä nykytaiteena seinällä.
Mitä tuohon aiempaan tulee niin...
$articles = $list[2];
todennäköisesti toimisi ja funktiosi pageLists() olemassaolon tarkoitus jää ikuiseksi arvoituksesi. - Vaikea ottaa kantaa kun ei tiedä mikä kysymyksessäsi mainittu pageLists() -funktion sisältö on eli mitä se on ohjelmoitu tekemään kun syötät sille ilmeisesti array-muuttujan nimeltä $list ja sen kolmannen arvon.
Suosittelisin testeissä käyttämään aina ehtoa eli tutkimaan toiminnan kohde määritelty ja olemassa ja vasta sen jälkeen tehdään jokin toimenpide. Muussa tapauksessa printataan info siitä ettei toiminnan kohdetta edes ole olemassa ja sitä kautta löytää helpommin tien ongelman ytimeen.
Laita testeissäsi print_r ja echo laulamaan yhdessä if(isset()){}:in kanssa, niin pala palalta homma hahmottuu. - Tarvitsetko oikeasti jQuerya vai pärjäärkö sittenkin ihan raaka-js:llä. Kirjoitin minimalistisen esimerkin missä napista avataan ja suljetaan ja sama tuplana eli ensin jQueryna ja sitten Javascriptina. Jälkimmäisessä säästää hiilijalanjäljessä ainakin yhden kirjastolatauksen verran.
HUOM! Koko homman pointti on siinä, että ID:t on uniikkeja.
https://tuuletus.net/lataamo/harjoitus_jquery.php
Kurkista koodiin jos kiinnostaa. - Kierrä ne toistensa kaima-id:t keinolla millä hyvänsä muutoin sivun hallinnasta tulee ylläpitäjällekin turhan vaikeaa. Jos mahdollista niin tee CSS:än identtiset määrittelyt esim. id:ille nappi1, nappi2 ja nappi3. Sitten tilanteen mukaan sivulla näytetään elementti jollakin noista id:istä minkä jälkeen javascriptin / jQueryn keinoin pystyt yksilöllisesti hallitsemaan vain sitä ilman että alkaa tapahtua kummia vähän joka puolella.
- Oletpa+urakan+ottanut!+Hatunnosto+siitä+että+teet+etkä+vain+huutele+puskista+että+voi+kun+joku+tekisi+antamieni+ohjeiden+mukaan.+
- "Jotta saan haluamani, array pitäisi purkaa yksittäisiksi muuttujiksi."
$articles -arrayn sisältämät arvot voit purkaa yksittäisiksi ($articles_0, $articles_1, jne) muuttujiksi esim. näin:
$articles=array("",1,1,"","","","","");
for($x=0;$x<count($articles);$x ){
${'articles_'.$x}=$articles[$x];
echo "\$articles_".$x." = ".${'articles_'.$x};
echo "<br />";
}
Purkamisurakan jälkeen voit rakentaa ehtoja hyödyntäen juuri luomiasi yhden arvon sisältäviä "normalimuuttujia" ihan normaalisti
if($articles_1==1){
//your code
} - En+useammallakaan+luentakerralla+saanut+ihan+selvää+kuvaa+ongelmastasi,+mutta+jos+oletetaan+että+haluat+array-muuttujan+sisältämistä+arvoista+true/false+-erittelyn,+niin+ohessa+muutama+rivi.
- Kaikissa tilanteissa on syytä tarkastaa lomakkeilta tuleva syöttö. Mieluummin siis ylivarovainen kuin huoleton.
Tässä esimerkissä ei ole formia edes rakennettu ja tarkoitus oli aluperinkin vastata demoamalla ketjun aloittajan kysymykseen siitä miten preparea käyttäen tietokannasta luettava data ohjataan includella lisättävään scriptiin. Siltä osin asia lienee ratkennut ja kysyjä etenee projektissaan. Tarkoitus ei ole ollut edes yrittää rakentaa kaikki poikkeusolot huomioivaa tietojen syöttölomaketta. Niitä löytyy googlaamalla.
Kuten aina, asioilla on tapana lähteä lapasesta. Päivitin vielä kerran esimerkkifaileja edellä esille nousseen tärkeän portti-määrityksen osalta sekä hienosäädin vähän "trimmausta" siltä osin ettei tyhjää hyväksytä tietokantaan tallennettavaksi.
Oikeassa elämässä on usein tarpeen rajoittaa vaikkapa lomakkeilla syötettäessä sallittavia merkkejä (nimissä ei sallita numeroita, syöttöjen minimi- ja maksimipituudet, jne), mutta tämä menee jo liian kauas ketjun alkuperäisestä aiheesta. Se siitä sitten. - Vai olisiko se portin määritys peräti noin helpoksi tehty eli erotetaan se syntaksissa omaksi osakseen $servernamen ja dbnamen väliin:
new PDO("mysql:host=$servername;port=XXXX;dbname=db_name", $username, $password) - Nopealla googlauksella pisti silmään muutamia esiintuotuja PDO-ongelmia juurikin $servernamessa olevan portin kanssa. Asia saattaisi selvitä ihan sillä että kysäiset asiaa webhostisi aspasta. Minulla on oletusportit eli en ole joutunut niiden kanssa säätämään ja en osaa asiassa jeesata enempää.
- Täällähän on vekkuli tunnelma viikonlopun kynnyksellä :)
Tuo mainitsemasi virheilmoitus viittaa vahvasti siihen, että $servername on unohtunut vaihtaa asianmukaiseksi, eli localhostista johonkin xxx.xxx.xx muotoiseen tietokantasi palvelimen osoitteeseen. Ainakin omassa testissä scripti rullasi vain sitä yhtä asetusta vaihtamalla edelyttäen tietysti että se testitaulukin on aluksi muistettu luoda.
Hyvää viikonloppua! - OK, tulkitsen viestisi kauttarantain niin että sait esimerkkifailit toimimaan omassa localhost/server -ympäristössäsi ja ymmärsit näiden kahden puheena olleen "protokollan" välisen eron. Sitten eikun soveltamaan aihetta omissa projekteissa, niin kauan kun teema on kirkkaana mielessä.
Esitettyyn kysymykseen vastattu -> case closed.
Ylläpito saa poistaa :) - Lisäsin pitkin hampain yhden version pyydetystä mysqli-vaihtoehdosta, vaikka ystävällisesti kehotankin kaikkia aihetta vasta alkumetreillä opiskelevia panostamaan siihen PDO-vaihtoehtoon ensisijaisesti.
Jos testeissänne huomaatte ongelmia, niin ne menee hätäisesti hutaistun työn piikkiin ja sori siitä jo etukäteen. - PHP Data Objects ja MySQLi eivät ole identtisiä kaksosia.
PDO -syntaksiin ei iitä ole määritelty ja siksi sen itsepäinen lisääminen aiheuttaa virheen. On oma valintasi käytätkö MySQLi-proseduuria vaiko PDO-proseduuria. Arvelisin itse että PDO on monipuolisempi ja sillä lienee kirkkaampi tulevaisuus kuin mySQLi:lla, mutta tulevaisuus näyttää miten lopulta käy.. Googlaamalla löydät helposti lisätietoja näiden kahden eroista käytännössä.
Kysyjälle tehdyssä esimerkissä käytin viimeksimainittua. - Pidetään asiaketjut asiaketjuina.
Tällainen vähemmän esillä olleesta aiheesta tehty avaus ansaitsee enemmän kehuja kuin haukkuja. - Peukuttamaan pääset kun luot tunnukset. Eikä edes maksa mitään.